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

14

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?

sql-server backup file-transfer files Saké
la source
Quel système de fichiers utilisez-vous sur le disque vers lequel vous transférez?
Marko Carter,
NTFS. C'est ça?
Sake
Cela est important car le système de fichiers cible aurait pu avoir une limite de taille de fichier de 2 Go, ce qui aurait pu provoquer votre erreur à 2 Go. Mais c'est NTFS donc ce n'est probablement pas ça :)
Lucas
Ouais, je parie que ce n'est pas réellement NTFS.
Brent Ozar

Réponses:

16

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).

Iain
la source
3
Entièrement d'accord. 2 Go est un goulot d'étranglement commun pour les systèmes de fichiers FAT. Je vérifierais vraiment attentivement pour vous assurer que vous n'essayez pas de copier vers un système de fichiers FAT.
Brent Ozar
je pensais que c'était 4 gb?
Journeyman Geek
10

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.

this.matthew
la source
+1 Je n'ai jamais pensé à l'utiliser pour autre chose qu'Exchange! Je vais devoir faire un tourbillon.
squillman
3
À partir de technet.microsoft.com/en-us/library/aa998673(EXCHG.80).aspx "Le mode de fichier de copie des utilitaires de base de données Exchange (Eseutil.exe) / Y est optimisé pour copier efficacement de très gros fichiers. Vous pouvez utiliser le / Y pour copier un fichier de base de données ou un fichier journal. Cependant, le mode ne convient pas comme utilitaire de copie à usage général "
Goyuix
+1, c'est probablement l'effet secondaire le plus impressionnant d'un utilitaire de maintenance de base de données jamais entendu parler!
Massimo
6

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

notandy
la source
5

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.

Lucas
la source
3

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é.

Cephas
la source
2
/ Z est également une option douce. Il vous permet de reprendre les copies ayant échoué. Cela m'a sauvé la vie sur des réseaux lents
Nick Kavadias
2

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

Brent Ozar
la source
1

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

John Rennie
la source
1

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

Lazlow
la source
3
NIC défectueux a toujours échoué autour de 2 Go? bizarre!
Lucas
peut-être que cette carte réseau avait TCP accéléré par le matériel avec un bogue?
qbeuek
Je ne suis pas sûr à 100% de ce qui n'allait pas avec la carte réseau elle-même, mais c'était une affaire sans marque d'eBay - dès que je l'ai remplacée, les transferts réseau se sont considérablement améliorés sans baisse de connectivité.
Lazlow
1

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.

Fatherjack
la source
0

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.

Knox
la source
0

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 :-(

JoeOD
la source
0

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 ..

Matthieu
la source
Peut-être que Netcat est facile et rapide à utiliser, mais je n'avais pas obtenu de vitesses élevées avec. IIRC il peut à peine atteindre 2-3 Mo / s. Quand il s'agit de vitesse, il aspire trop.
Cristian Ciupitu
Je sens que des tests de performances arrivent ... Je vais voir si je peux trouver le temps de comparer nfs, cifs, ftp et nc sur mon réseau domestique local.
Matthew
Si netcat ne vous donne que 2-3 Mo / s, votre système est en panne. ftp et netcat devraient tous deux fonctionner de manière identique. nfs et cifs sont également à peu près les mêmes.
Justin
0

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

beakersoft
la source
0

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.

squillman
la source
J'ai essayé ça. Pas beaucoup d'aide malheureusement.
Sake
Par simple curiosité, alors ... Avez-vous réglé votre croissance automatique sur une valeur d'octet dur ou un%? Ou l'avez-vous même réglé sur la croissance automatique?
squillman
0

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.

jhayes
la source
0

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

JFV
la source
0

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.


la source
0

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.

Jason Cumberland
la source