Quel est le moyen le plus simple et le plus rapide pour transférer des fichiers volumineux via un réseau Windows?

J'ai une machine Windows Server 2000 exécutant MS SQL Server qui stocke plus de 20 Go de données. La base de données est sauvegardée tous les jours sur le deuxième disque dur. Je souhaite transférer ces fichiers de sauvegarde vers un autre ordinateur pour créer un autre serveur de test et pour pratiquer la récupération. (la sauvegarde n'a jamais été restaurée depuis près de 5 ans. N'en parlez pas à mon patron!)

J'ai du mal à transférer cet énorme fichier via le réseau. J'ai essayé la copie réseau simple, le téléchargement apache et ftp. Toute méthode que j'ai essayée finit par échouer lorsque la quantité de données transférées atteint 2 Go. La dernière fois que j'ai réussi à transférer le fichier, c'était via un disque dur externe attaché USB. Mais je veux effectuer cette tâche régulièrement et de préférence automatiquement.

Vous vous demandez quelle est l'approche la plus pragmatique pour cette situation?

Un échec prévisible à 2 Go semble être à blâmer pour le système de fichiers cible ... Les deux sont-ils sur NTFS? Êtes-vous en train de passer par une compression (zip échouait aux limites de 2 Go) ((Apache fait-il la compression))

J'ai copié de nombreux fichiers de plus de 20 Go en utilisant robocopy (comme d'autres l'ont mentionné), mais j'éviterais d'utiliser le commutateur / MIR jusqu'à ce que vous soyez sûr que la copie fait ce que vous voulez - car elle supprimera les fichiers et les copiera.

SMB souffre d'un seul paquet à une limite de temps, c'est donc souvent le moyen le plus lent de copier des fichiers - vous avez la possibilité de copier en utilisant push ou pull. Personnellement, je préfère la méthode push (la copie est initiée par la source).

L'outil MS Exchange eseutil est un excellent utilitaire pour copier rapidement de gros fichiers sur un réseau:

eseutil / y fichier_source / d fichier_dest.

Je recommande fortement d'utiliser l'utilitaire gratuit RichCopy . Il est multithread et peut suspendre et reprendre les opérations de copie de fichiers. J'ai eu beaucoup de chance de l'utiliser pour transférer des fichiers entre serveurs.

Mes trois meilleurs conseils pour utiliser RichCopy

1. Si vous copiez un ou quelques gros fichiers, définissez l'attribut "Copie de fichier" sur plus de "1". Il utilise des ressources mais copie les gros fichiers plus rapidement

2. Si vous copiez de nombreux fichiers, définissez les attributs «Numéro de fil» sur 10-10-1. Cela copiera plus rapidement plusieurs fichiers

3. Si vous copiez sur une connexion douteuse. Vous pouvez relancer le téléchargement et il ira chercher les fichiers qu'il n'a pas réussi à obtenir la première fois.

http://blogs.technet.com/markdea/archive/2009/03/24/richcopy-is-it-the-new-sliced-bread.aspx

En ce qui concerne les utilitaires de copie de fichiers, TeraCopy est un bon GUI (pas de ligne de commande) qui peut mettre en file d'attente de nombreux fichiers, prend en charge la pause et la reprise, peut changer dynamiquement sa taille de mémoire tampon pour optimiser la vitesse et peut éventuellement remplacer Windows Explorer par défaut copier / déplacer avec le sien.

Robocopy avec l'option / MIR est très utile pour les sauvegardes rapides et sales entre les machines. Vous pouvez trouver robocopy dans le Kit de ressources Windows Server 200X

MIR va Miroir le contenu d'un répertoire vers un autre serveur. Il ne copiera que les fichiers qui ont changé.

La solution la plus pragmatique aux brassages répétés de gros fichiers de sauvegarde SQL Server consiste à utiliser un produit de compression de sauvegarde tiers ou la compression de sauvegarde intégrée de SQL Server 2008 Enterprise Edition.

Il y en a plusieurs de différents fournisseurs. Je travaille pour Quest Software, les créateurs de LiteSpeed, mais je ne suis pas ici pour vendre quoi que ce soit. Vous voulez vérifier tous les produits et décider ce qui convient le mieux à vos besoins. Voici un récent article de blog traitant spécifiquement de LiteSpeed, mais les mêmes concepts s'appliquent également à d'autres produits:

http://blogs.lessthandot.com/index.php/DataMgmt/DBAdmin/title-8

Copiez-vous le fichier sur un réseau local ou via une connexion WAN comme l'ADSL? Je suppose que c'est un WAN car 20 Go n'est pas un gros fichier à copier sur un LAN. Je copie quotidiennement de nombreux fichiers de ce type.

S'il s'agit d'une connexion WAN, la façon dont je le fais est d'utiliser la version Cygwin de rsync.

JR

J'ai eu des échecs de transfert réseau à environ 2 Go - il s'est avéré être une carte réseau défectueuse.

J'utilise syncback ( http://www.2brightsparks.com/syncback/sbse.html ) quotidiennement pour transférer des fichiers plusieurs fois plus volumineux que le vôtre. Je n'ai jamais eu de problème avec ça.

C'est un peu tard mais je recommanderais une option d'application de sauvegarde et de restauration tierce. Nous utilisons Red Gate SQL Backup ( www.red-gate.com ), il a des options de compression et d'emplacement alternatif dans l'interface graphique. J'obtiens une économie de compressions de 80% en moyenne - donc vous ne transférez que 20% de la taille réelle de la base de données. Il prend également en charge le chiffrement afin qu'il puisse être utilisé sur un WAN sans soucis d'interception.

Il est entièrement planifiable et peut donc s'exécuter automatiquement à un cycle de votre choix.

L'interface graphique vous permet également de configurer et d'administrer l'envoi de journaux.

Version d'essai gratuite disponible ci-dessus.

Je n'ai pas d'expérience avec un fichier aussi volumineux, mais pourriez-vous utiliser robocopy ou même xcopy avec l'option / Z qui prétend être redémarrable. Il semble que cela soit destiné aux copies de fichiers volumineux où le réseau n'est pas fiable.

J'ai utilisé robocopy pour plus de 1 Go et je n'ai eu aucun problème. ss64.com a une bonne explication des commutateurs. Je ne peux pas poster le lien cependant :-(

Mauvaise réponse ..

Utilisez Netcat . Un tutoriel orienté Unix pour le transfert de fichiers peut être trouvé ici . Vous pouvez accélérer encore les choses en:

1. Compressez côté expéditeur et décompressez côté destination. (fenêtres de mandrin équivalentes à gzip au milieu des lignes de commande.)
2. Choisissez d'envoyer des données via udp au lieu de par TCP (hé homme, qui se soucie de l'intégrité des données ?? !!)

Blague à part, netcat est probablement le moyen le plus rapide de transférer de gros fichiers sur un réseau local. Comme aucune somme de contrôle n'est effectuée, vous souhaiterez peut-être faire une somme MD5 du fichier avant de l'envoyer et la comparer à la somme MD5 du fichier reçu.

J'ai beaucoup utilisé netcat de cette manière, je ne l'ai jamais vu échouer, je ne l'ai jamais vu échouer non plus à maximiser le réseau ..

Cela pourrait valoir la peine de diviser le fichier en petits morceaux comme solution à court terme jusqu'à ce que vous puissiez identifier le problème. Nous avons eu des problèmes similaires à cela dans le passé, et ftp a toujours fonctionné pour nous

S'il s'agit de fichiers SQL .bak que vous copiez, je vous suggère fortement d'effectuer l'une des opérations suivantes pour réduire vos fichiers avant de les copier:

• Réduisez la base de données et tronquez le journal avant d'exécuter la sauvegarde. OU
• Compressez le fichier .bak avant la copie. Les fichiers SQL .bak sont compressés de façon descendante si vous n'utilisez pas l'espace entièrement alloué dans les fichiers de données et les fichiers journaux.

Pourrait éliminer le besoin d'une méthode alternative pour copier de gros fichiers.

Je ne pense pas que trouver quelque chose à transférer plus rapidement soit votre problème, vérifiez que votre système de fichiers cible n'est PAS GRAS, comme d'autres l'ont dit. En outre, assurez-vous que les cartes réseau des deux côtés ont des pilotes mis à jour et ne sont pas autrement floconneuses.

Cela dit, déplacez-vous de nombreux petits fichiers ou seulement quelques gros? J'ai vu des problèmes de contrôleur RAID en essayant de déplacer des millions de petits fichiers.

Je ne pense pas que vous aurez un problème à automatiser cela une fois que vous aurez déterminé la cause de l'échec. Il peut être utile de répertorier plus de détails sur votre matériel et toutes les erreurs pertinentes que vous pouvez voir dans l'Observateur d'événements.

Avez-vous essayé d'utiliser une connexion eSATA à un disque dur externe? Les connexions sont rapides (3 gigabits!) Et devraient pouvoir transférer ce fichier en un rien de temps!

Quelle est la vitesse de votre carte réseau sur le serveur, 10/100 ou 10/100/1000? À quoi ressemble la bande passante réseau du serveur et le commutateur lorsque vous copiez le fichier? À quoi ressemble la bande passante réseau de l'emplacement de destination (du serveur?) Lors de la copie? Avez-vous essayé d'associer 2 cartes réseau ensemble? Les pilotes de carte réseau sont-ils à jour? Le BIOS est-il à jour?

Il y a beaucoup de choses qui pourraient poser problème pour les transferts de fichiers. S'assurer que les pilotes matériels et le BIOS sont à jour peut vraiment faire la différence.

-JFV

Le moyen le plus simple et le plus rapide: les disques USB externes et la marche.

À ma façon: utilisez rsync. Si la copie échoue, redémarrez-la simplement et elle reprendra là où elle était.

L'autre chose à vérifier serait de voir si le service de quota est configuré sur le serveur cible; Je pense qu'il utilise 2 Go comme quota par défaut par utilisateur.