Est-ce que robocopy reprendra après avoir été interrompu ?

Si le dossier contient un très grand nombre de fichiers, alors il faudra effectivement du temps, nécessaire en raison des accès fréquents aux catalogues du disque, pour à la fois la source et la cible.

De plus, un disque USB3 sur un port USB2 fonctionnera à la vitesse de l'USB2. Le disque USB3 s'adaptera au port et à son protocole lors de l'initialisation de la connexion.

Vous utilisez /MT:32 pour le mode Multi-Threaded, indiquant à robocopy de copier 32 fichiers à la fois. Cela provoquera 32 threads qui se battent pour accéder aux disques, ralentissant encore davantage la copie, la tête du disque perdant du temps à aller et venir sur le disque. Dans le cas d'une copie lente sur USB2, le mode Multi-Threaded n'est pas recommandé.

Utilisez le mode de redémarrage /Z pour traiter les fichiers partiellement copiés. Avec cette option, en cas d'interruption de la copie sur un fichier en particulier, la prochaine exécution de robocopy peut reprendre là où elle s'était arrêtée plutôt que de recopier entièrement le fichier. Malheureusement, il y a des cas où ce commutateur ralentira la copie.

Il est OK d'arrêter Robocopy en plein milieu d'une opération.

Par défaut, il ne recopiera pas les fichiers qui ont déjà été copiés.

Le surcoût pour déterminer où reprendre (ou essentiellement vérifier quels fichiers sont les mêmes) est très faible - seulement quelques secondes.

Cependant, si vous n'écrivez pas dans un journal (ou utilisez /TEE pour écrire également dans une console) le /V augmentera ce surcoût car il prendra plus de temps pour écrire toutes les lignes dans la console.

NB : Le mode reprise (comme mentionné dans les commentaires) est simplement pour reprendre des fichiers individuels (par exemple, si un fichier géant est arrêté en plein milieu, vous pouvez reprendre à partir de là au lieu de recopier tout le fichier) et n'est pas nécessaire pour reprendre la copie en lot comme demandé dans la question.

J'ai utilisé robocopy pendant des années maintenant, et je sais que vous pouvez arrêter une copie en plein milieu d'un fichier et reprendre rapidement là où vous vous étiez arrêté. À moins d'utiliser l'option /XN, robocopy supprimera le dernier fichier sur lequel il travaillait et recommencera la copie. Lorsqu'il crée un fichier pour la première fois, il définit l'heure de modification à 1/1/1980, donc fondamentalement aussi longtemps que votre horloge est réglée correctement, il verra cette heure et redémarrera le processus de copie. Comme vous l'avez dit, les autres fichiers seront ignorés car ils ont la même date/heure de modification que les fichiers source.

Personnellement, j'utilise toujours l'option /TEE avec les options /V et /LOG: lors de l'utilisation de robocopy afin de surveiller ce qui se passe, (et en cas de plantage, je peux revenir en arrière et voir s'il y a eu des problèmes). Cela ralentira un peu les choses si vous avez un nombre extrême de petits fichiers (des dizaines de milliers ou plus), mais cela peut également vous aider à déterminer s'il y a un problème. Si vous réduisez la hauteur, ou mieux encore, minimisez la fenêtre d'invite de commande, vous pouvez grandement accélérer la copie lorsque vous avez beaucoup de petits fichiers.

18 heures, c'est très long pour la quantité que vous essayez de copier, donc il est possible que vous ayez un nombre insensé de petits fichiers à copier, ou que vous ayez une récursivité dans votre structure de répertoires. Comme vous avez un journal, vous pourriez essayer de regarder en bas de celui-ci pour voir si la structure du répertoire se répète. Si c'est le cas, vous pourriez essayer de sauter les points de jonction avec /XJD pour voir si cela vous permet d'arrêter la ou les boucles dans lesquelles il est bloqué. L'option /XD peut également être utilisée pour ignorer complètement des répertoires spécifiques.

À propos de l'option /Z, cette option fonctionne UNIQUEMENT pour les "transferts réseau". Je mets cela entre guillemets car les copies locales NE utiliseront PAS le mode de redémarrage; cependant, si robocopy voit un chemin réseau, il utilisera le mode redémarrable, même si la source et la destination sont locales (cela pourrait juste être ma version de robocopy car je ne passe pas à Windows 7). Si vous partagez votre lecteur ou un dossier sur le lecteur, (de préférence à un compte auquel seul vous avez accès), et activez les autorisations Modification, puis utilisez ce chemin comme destination, cela devrait fonctionner en mode redémarrable. Bien sûr, il peut y avoir une baisse de performance lors de l'utilisation du mode redémarrable.

Est-il possible d'arrêter Robocopy?

Je tue souvent la tâche Robocopy sans problème. Si le processus est arrêté, le fichier qui était en cours de copie aura, autant que je me souvienne, (a) une horodatage de 1980-01-01 (b) la même taille que le fichier d'origine.

En supposant qu'il reprenne, quel est le surcoût en temps pour déterminer quels fichiers il reste à copier et où reprendre?

Si vous lancez à nouveau la tâche avec ces paramètres, elle (a) sautera les fichiers déjà copiés (b) recopiera le fichier interrompu en raison d'une incohérence de dates (c) copiera les fichiers qu'elle n'a pas copiés lors de la tentative précédente (d) supprimera les fichiers de destination qui n'existent plus dans la source en raison de l'option /MIR.

Il s'avère que la raison pour laquelle cela prenait tant de temps était parce que...

Avant d'arrêter le processus, vous pouvez ouvrir le fichier journal dans un éditeur de texte pour voir ce qu'il fait; la dernière ligne contiendra le fichier en cours de copie et sa taille. S'il y a eu une erreur, celle-ci sera également répertoriée comme suit:

2019/12/13 06:26:38 ERREUR 32 (0x00000020) Copie du fichier C:\Redacted
Le processus ne peut pas accéder au fichier car il est utilisé par un autre processus.

Attente de 60 secondes... Nouvel essai...

Une fois la copie réussie, le fichier journal contiendra un résumé incluant le taux de transfert (mégaoctets par minute) qui vous donnera une idée approximative du temps nécessaire la prochaine fois.

Cette réponse traite de :

Il a été en cours d'exécution depuis plus de 18 heures maintenant ce qui est plus long que ce que j'attendais.
Même à une vitesse lente pour l'USB 2, il ne devrait prendre que environ 8 heures

et suggère une alternative possible à Robocopy

VÉRIFICATION DE LA VITESSE DE TRANSFERT :

D'autres ont abordé les raisons possibles pour une vitesse inférieure à celle attendue.

VITESSE ACTUELLE :

Notant le taux de changement de l'espace libre sur le lecteur cible vous indiquera le taux de copie actuel. En le faisant par exemple avec 10 secondes entre chaque vérification, en laissant passer une minute vous donnera une meilleure moyenne.

Vous pouvez le faire avec n'importe quel outil Windows approprié ou, en utilisant ma préférence, en utilisant ce qui passe de nos jours pour une "fenêtre DOS".

       dir cible:\

devrait être adéquat.

VITESSE DE TRANSFERT JUSQU'À PRÉSENT :

Vous pouvez trouver combien de fichiers et quelle volume de données ont été copiés jusqu'à présent avec par exemple

     dir cible:\dossier_destination /s

Cela ralentira le taux de copie pendant le processus de dir.
Les DIRs suivants seront généralement plus rapides en raison de la mise en cache de la majorité du résultat.

ADÉQUATION DE LA VITESSE DE TRANSFERT :

58 Go/18 heures est un peu moins de 1 Mo/seconde, ce qui est faible pour tout processus de copie de USB2 - USB3. La taille des fichiers réellement transférés peut être consultée comme ci-dessus - ce qui vous permet de savoir si le taux est même beaucoup plus lent que 1 Mo/s.

Les vitesses de transfert de pire cas que j'ai connues sur une machine moderne (OK i7) ont été dans les 501 Mo/s

Aides possibles (seulement) :

Je ne suis pas familier avec Robocopy.
J'utilise une version très ancienne (2001) de XXCOPY à des fins similaires car elle fonctionne bien et les termes de licence conviennent à mes besoins. XXCOPY a un drapeau "/nX0" qui désactive la fonction de préservation des noms courts dans certains cas. Dans certaines situations, cela accélère considérablement le taux de transfert. Un paramètre similaire dans Robocopy pourrait aider.

J'assigne également des chemins sources et de destination à des lettres de lecteur factices en utilisant la commande Ye Olde DOS Subst

        par exemple subst a: chemin_d'accès  

Cela permet la copie de certains fichiers qui autrement échouent à copier - y compris ceux avec des noms de fichiers extrêmement (stupidement) longs.

\============================

Intérêt possible.
La question concernait l'utilisation de Robocopy.
Le script suivant utilise XXCOPY pour effectuer une tâche similaire.
Les fichiers existants ne sont pas recopiés.
Y: et Z: sont utilisés à la place des paramètres source et destination directs pour éliminer certains erreurs de copie (nom de fichier troooooo long).
Je ne suis pas certain pourquoi cela fonctionne, mais c'est le cas.

    subst y: /D ; libérer le lecteur mappé
    subst y: Lecteur_Src:\chemin_source

    subst z: /D ; libérer le lecteur mappé
    subst z: Lecteur_Dest:\chemin_destination

    **xxcopy /bb /s /h /nx0 y:\*.*  z:\**

rem /bb - s'il n'existe pas
rem /s  - tous les sous-répertoires
rem /h  - inclure les fichiers cachés
rem nx0 - ne pas préserver le nom de fichier court