La façon la plus rapide pour transférer des fichiers sur un Système Windows

Je veux déplacer environ 800 go de données à partir d'un périphérique de stockage en NTFS à FAT32 appareil (les deux sont des disques durs externes), sur un Système Windows.

Quelle est la meilleure façon d'atteindre cet objectif?

  1. Simplement en utilisant la fonction couper-coller?
  2. À l'aide de l'invite de commande ? (move)
  3. L'écriture d'un fichier de commandes pour copier un des petits morceaux de données sur un intervalle donné ?
  4. Utiliser certaines application qui fait le travail pour moi?
  5. Ou une meilleure idée...?

Ce qui est le plus sûr, efficace et rapide pour réaliser un tel processus prend beaucoup de temps?

  • Assurez-vous que tous les fichiers sur votre disque NTFS sont valables pour FAT32, c'est à dire rien de plus de 2G. J'ai fait la même chose avec robocopy il y a quelques semaines.
  • Je suis sur le point de passer à 1,5 to de un Backblaze lecteur de sauvegarde pour mon nouveau remplacement 7200 tr / min lecteur sur Windows 10 et je suis choqué que les gens n'ont pas pose cette question depuis 2008 (ou à la fourniture de nouvelles réponses). Espérons que Robocopy (la principale réponse à l'heure actuelle) est toujours la meilleure idée, parce que c'est probablement ce que je vais essayer.
InformationsquelleAutor Andreas Grech | 2008-12-12
  1. 35

    Robocopy

    Vous pouvez redémarrer la commande et il va recommencer. Je l'utilise tout le temps sur le réseau. Travaille sur de gros fichiers.

    • Robocopy comprend également un commutateur de ligne de commande pour retard entre les paquets, rendant co-existent bien avec d'autres types de trafic. Mon expérience avec Robocopy est que vous vous retrouvez autour de 2x le débit de la Windows XP Explorer.
    • Parfait...juste ce dont j'avais besoin! Je suis actuellement en utilisant robocopy pour copier les données. Tout le monde, merci pour l'entrée.
    • option /mt en fait un multi-thread copie avec 8 threads - j'entends cette option a été ajoutée sur robocopy fourni avec Windows Server 2008 R2 et supérieur depuis je ne l'ai pas, j'ai essayer de copier par exemple 4 répertoires à un moment, l'émission de 4 robocopy commandes
    • Robocopy a également été recommandons ici (avec des conseils): superuser.com/a/364995/74576
    InformationsquelleAutor Pyrolistical
  2. 6

    Je voudrais déplacer physiquement le dur dsk si possible.

    • éteignez les périphériques de stockage, débranchez les câbles, retirez le disque dur, insérez le lecteur dans de nouveaux périphérique de stockage, attachez les câbles, revenir sur...
    • NE PAS PLACER le lecteur dans votre sous-système raid - ils généralement initialiser (réinitialiser) un disque dès que vous faites. Me demandez comment je le sais.
    InformationsquelleAutor RedFilter
  3. 4

    J'ai trouvé la copie rapide en assez bonne pour ce genre de chose. Ses un outil graphique ....

    http://www.ipmsg.org/tools/fastcopy.html.en

    InformationsquelleAutor benlumley
  4. 2

    Si vous devez vous déplacer sur un réseau, vous souhaitez utiliser FTP entre les serveurs. Le système de Fichiers de Windows va s'enliser avec le bavard protocoles.

    • Vous auriez à zip avant. FTP est lente avec des milliers de fichiers.
    InformationsquelleAutor kemiller2002
  5. 2

    J'ai trouvé Teracopy assez rapide et pratique. Aurait Fastcopy (comme suggéré par benlumley) est encore plus rapide, mais je n'ai aucune expérience avec elle.

    InformationsquelleAutor Arnout
  6. 2

    Essayer à l'aide de WinRar ou un outil de compression. Gros "fichiers" sont déplacés plus rapide que beaucoup de petits.
    Plus la compression outils permettent de diviser l'archive(zip) des fichiers en plusieurs archives.

    Vous pouvez même réduire la taille d'un bit lorsque vous activez la compression.

    InformationsquelleAutor Johannes
  7. 1

    Ligne de commande: xcopy est probablement votre meilleur pari

    Référence De La Commande:
    http://www.computerhope.com/xcopyhlp.htm

    InformationsquelleAutor FallenAvatar
  8. 1

    J'ai utilisé Teracopy et copié 50+GO à 128 GO lecteur flash.

    Trop près de 48 heures...fallait le faire deux fois parce qu'il avait un pouvoir
    le hoquet. A re-formater et recommencer...Pas mon truc préféré
    à faire...

    • qui semble anormalement lent, seulement 290kb/sec... Vous pouvez obtenir USB3 128 go flash des lecteurs qui ne près de 9 mo/s aléatoires 4k écrire maintenant, et de la pointe d'écriture de près de 250 mo/sec.
    InformationsquelleAutor Harry
  9. 1

    L'un des moyen le plus rapide pour copier des fichiers est d'utiliser robocopy comme indiqué par Pyrolistical dans le post ci-dessus. son très souple et puissant.
    Si la commande ne fonctionne pas à partir de votre dos directement, essayez avec powershell option comme l'exemple ci-dessous.

    Doit Vérifier les documents de cette commande avant de l'utiliser "robocopy /?".

    powershell "robocopy  'Source' 'destination' /E /R:3 /W:10 /FP /MT:25 /V" 

/E - Copy subdirectory including empty ones.
/R - Retry 3 times if failed.
/W - wait for 10 seconds between retries.
/FP - include full path name in output.
/MT - Multi thread.
/V - verbose output.
    InformationsquelleAutor kumar chandraketu
  10. 1

    Je voulais commenter un commentaire à propos de multithreading, à partir de @hello_earth, 201510131124, mais je n'ai pas assez de points de réputation sur Stackoverflow (j'ai surtout posté le super-Utilisateur jusqu'à maintenant) :

    Le Multithreading est généralement pas efficace lorsqu'il s'agit de la copie de fichiers à partir du 1er périphérique de stockage de 1 autre, parce que la manière la plus rapide du débit est atteinte pour des lectures séquentielles, et l'utilisation de plusieurs threads en faire un disque dur de hochet et de limer comme un fou à lire ou à écrire plusieurs fichiers en même temps, et depuis un disque dur peut seulement accéder à un fichier à un moment il doit lire ou d'écrire un morceau à partir d'un fichier, puis passer à un morceau à partir d'un autre fichier situé dans une zone différente, ce qui ralentit considérablement le processus (je ne sais pas comment un SSD serait se comporter dans un tel cas). Il est à la fois inefficace et potentiellement dangereux : la contrainte mécanique est beaucoup plus élevé lorsque les têtes sont en mouvement à plusieurs reprises sur les plateaux pour atteindre plusieurs zones du court succession, plutôt que de rester au même endroit pour analyser un grand fichier contigu.

    J'ai découvert cela quand lot de vérifier les sommes de contrôle MD5 d'un très gros dossier plein de fichiers vidéo avec md5deep : avec les options par défaut, l'analyse a été multithread, donc il y avait 8 threads avec un core i7 6700K CPU, et il a été atrocement lent. Ensuite, j'ai ajouté le j1 option, sens 1 fil, et il a procédé beaucoup plus rapide, étant donné que les fichiers ont été maintenant lire dans l'ordre.

    Une autre considération qui en découle est que la vitesse de transfert sera beaucoup plus élevé si les fichiers ne sont pas fragmentés, et aussi, plus marginalement, si elles sont situées au début d'un lecteur de disque dur, correspondant à la limite extérieure de pièces de plateaux, où la vitesse linéaire maximale (cet aspect n'est pas pertinente avec un lecteur à état solide ou à l'autre de la mémoire flash en fonction de l'appareil).

    Aussi, l'affiche originale voulait “le plus sûr, efficace et rapide pour réaliser un tel processus prend beaucoup de temps” – je dirais que l'on a à choisir un compromis favorisant soit vitesse/efficacité, ou de sécurité : si vous voulez de la sécurité, vous avez pour vérifier que chaque fichier a été copié sans problème (par la vérification des sommes de contrôle MD5, ou quelque chose comme WinMerge) ; si vous ne le faites pas, vous ne pouvez jamais être sur à 100% assurez-vous qu'il n'y avait pas certains Écueils dans le processus (problèmes matériels ou logiciels) ; si vous faites cela, vous avez à dépenser deux fois plus de temps sur la tâche.

    Par exemple : je me suis appuyé sur un petit outil appelé SynchronizeIt! pour mon fichier de la copie, parce qu'il a l'énorme avantage par rapport à la plupart des outils de préservation de tous les timestamps (y compris le répertoire d'horodateurs, comme Robocopy ne avec le /DCOPY:commutateur T), et il dispose d'une interface simplifiée avec seulement les options dont j'ai besoin. Mais j'ai découvert que certains fichiers ont toujours été endommagé après une copie, tronqué après exactement 25000 octets (donc la copie d'un 1 go de vidéo, par exemple, était 25000 bonne octets puis 1 go de 00s, le processus de copie a été anormalement rapide, a pris seulement une fraction de seconde, ce qui a déclenché mes soupçons en premier lieu). J'ai signalé ce problème à l'auteur une première fois en 2010, mais ensuite, il a écrit à la craie jusqu'à une défaillance matérielle, et ne pense pas à deux fois. J'ai toujours utilisé de l'ES, mais a commencé à vérifier les fichiers à fond chaque fois j'ai fait une copie (avec WinMerge ou Total commander) ; lorsque les fichiers retrouvés endommagés j'ai utilisé Robocopy à la place (les fichiers qui ont été corrompu par SynchronizeIt, lorsqu'ils ont été copiés avec Robocopy, puis copié à nouveau avec SynchronizeIt, ont été copiés parfaitement, donc il y avait quelque chose dans la façon dont elles ont été enregistrées sur la partition NTFS qui confond le logiciel, et qui Robocopy d'une certaine manière fixe). Puis, en 2015, je l'ai signalé à nouveau, après avoir identifié plus de motifs à l'égard de laquelle les fichiers ont été corrompus : ils avaient tous été téléchargés, avec en particulier les gestionnaires de téléchargement. Cette époque, l'auteur a fait quelques recherches, et a trouvé l'explication : il s'est avéré que son outil avait des problèmes lors de la copie des fichiers avec le peu connu “sparse” attribut, et que certains gestionnaires de téléchargement définir cet attribut pour économiser de l'espace lors du téléchargement des fichiers en plusieurs morceaux. Il m'a fourni une version mise à jour et correctement copies les fichiers fragmentés, mais n'a pas publié sur son site web (la version actuellement disponible est de 3.5 à partir de 2009, la version que j'utilise maintenant est de 3.6 bêta à partir d'octobre 2015), donc si vous voulez essayer ce que, par ailleurs excellent, de logiciels, d'être au courant de ce bug, et chaque fois que vous copiez des fichiers importants, vérifier minutieusement si chaque fichier copié est identique à la source (à l'aide d'un autre outil), avant de les supprimer de la source.

    InformationsquelleAutor GabrielB