3 votes

Comment détecter l'échec de robocopy à supprimer depuis la source?

Sur mon instance SQL Server, j'utilise SQL Agent pour exécuter une tâche de sauvegarde quotidienne en deux étapes.

Une des étapes utilise Robocopy pour déplacer les fichiers de sauvegarde locaux vers le stockage réseau.

La commande pour déplacer les fichiers ressemble à ceci:

robocopy M:\backups \\NAS\backups$\Database /MOV /MIR /XJ /NP /COPY:DT

La sortie de la commande dans l'historique de l'étape de la tâche ressemble à ceci:

-------------------------------------------------------------------------------     
ROBOCOPY     ::     Robust File Copy for Windows                                
-------------------------------------------------------------------------------      
Started : ven. 20 juil. 00:55:42 2012     
Source : M:\backups\       
Dest : \\NAS\backups$\Database        
Files : *.*            
Options : *.* /S /E /COPY:DT /MOV /PURGE /MIR /NP /XJ /R:1000000 /W:30     
------------------------------------------------------------------------------  
3  M:\backups\
      *EXTRA File       15.5 m  GeoDisplay_Full_2012-07-19-000004.bak
      *EXTRA File       41.3 m  GeoDisplay2_Full_2012-07-19-000004.bak
      *EXTRA File      264.1 g  Webstore_Full_2012-07-19-000004.bak
      New File          15.5 m  GeoDisplay_Full_2012-07-20-000002.bak
      New File          41.4 m  GeoStore_Full_2012-07-20-000002.bak
      New File         302.1 g  Webstore_Full_2012-07-20-000002.bak

      2012/07/20 04:34:50 ERROR 32 (0x00000020) Deleting Source File M:\backups\Webstore_Full_2012-07-20-000002.bak  The process cannot access the file because it is being used by another process.       
------------------------------------------------------------------------------
      Total    Copied   Skipped  Mismatch    FAILED    Extras
Dirs :         1         0         1         0         0         0     
Files :         3         3         0         0         0         3     
Bytes : 302.187 g 302.187 g         0         0         0 264.181 g     
Times :   3:38:57   3:38:45                       0:00:00   0:00:11         
Speed :            24720063 Octets/sec.     
Speed :            1414.493 MégaOctets/min.       
Ended : ven. 20 juil. 04:34:50 2012.  
Code de sortie du processus 3.

La sortie textuelle montre clairement ERREUR 32. Robocopy n'a pas réussi à respecter l'interrupteur /MOV (supprimer du source après copie) parce qu'un autre processus avait un handle sur un fichier lorsque robocopy a essayé de le supprimer.

Robocopy a retourné code de sortie 3 (nouveaux fichiers copiés vers la destination et fichiers supplémentaires supprimés de la destination). C'est correct mais incomplet car il n'y a aucun moyen de savoir à partir du code erreur si une opération a échoué.

SQL Agent ne prend en compte que le code de retour, pas la sortie de la commande, pour déterminer le succès d'une opération shell. Je pourrais modifier la commande Robocopy pour sauvegarder la sortie sur le disque et analyser la sortie dans une étape de tâche supplémentaire, mais cela nécessite une programmation supplémentaire et ajoutera une autre dépendance à la tâche de sauvegarde.

Existe-t-il un moyen de détecter ce type d'échec sans rechercher dans la sortie textuelle de Robocopy pour la chaîne ERREUR 32?

0 votes

Ce genre de message d'erreur malveillant rend la prétention de Robocopy à la robustesse un peu incertaine. Existe-t-il des options plus robustes disponibles, de préférence un utilitaire livré avec Windows?

0 votes

Quelle méthode autre que la recherche dans la sortie texte (log) cherchez-vous pour détecter une erreur? Mon cerveau revient toujours à comment vous détecteriez une erreur si vous n'avez pas vérifié le log d'une manière ou d'une autre... mais j'ai été moins performant cette semaine, donc cela pourrait aussi en être la raison.

1 votes

Je réfléchirais à deux fois avant d'utiliser quelque chose comme Robocopy seul pour les sauvegardes.

5voto

John Gardeniers Points 27097

Que ce soit RoboCopy ou une autre méthode, je préfère enregistrer toutes les sorties puis traiter le journal. Personnellement, je préfère Perl pour cette tâche mais utilisez ce avec quoi vous êtes à l'aise. J'aime aussi que le script de vérification du test m'envoie par e-mail les résultats, montrant simplement s'il a réussi ou, en cas d'échec, les lignes pertinentes du journal.

À mon avis, toute opération de sauvegarde qui ne comprend pas de rapport sur les résultats est un désastre en attente de se produire, simplement parce que vous ne pouvez pas avoir confiance en une opération qui n'est pas vérifiée. Les humains font un travail extrêmement médiocre en vérifiant les journaux, donc faites l'effort supplémentaire d'écrire le script. Sans cela, vous pouvez être presque assuré qu'une opération critique échouera un jour et vous ne le saurez même pas, risquant peut-être bien plus que simplement les données.

0 votes

Merci, John. Si nous devions continuer à utiliser Robocopy, nous traiterions les journaux. Nous avons réfléchi à l'effort nécessaire pour mettre en œuvre une solution de traitement des journaux par rapport à la simplification de notre architecture système. En fin de compte, nous avons cartographié le stockage réseau en tant que lecteur local afin d'utiliser uniquement les fonctionnalités intégrées de SQL Server. Nous avons déjà des solutions de traitement des journaux pour SQL Server, donc nous avons réduit le risque de passer à côté de quelque chose.

0 votes

Je considère cela comme un bug dans Robocopy et l'ai signalé ici : github.com/MicrosoftDocs/windowsserverdocs.de-de/issues/49

4voto

Thecamelcoder Points 11

La description de code de sortie "de nouveaux fichiers copiés vers la destination et des fichiers supplémentaires supprimés de la destination" n'est pas techniquement exacte. Vous ne devriez pas vous fier uniquement à la description.

Le code de sortie 0x3 est un indicateur binaire. Le message convivial devrait être interprété comme suit :

"Un ou plusieurs fichiers ont été copiés avec succès"

PLUS

"Des fichiers ou répertoires supplémentaires ont été détectés. Examinez le fichier journal pour plus d'informations."

Code    Signification
0   Aucune erreur ne s'est produite et aucun fichier n'a été copié.
1   Un ou plusieurs fichiers ont été copiés avec succès.
2   Des fichiers ou répertoires supplémentaires ont été détectés. Examinez le fichier journal pour plus d'informations.
4   Des fichiers ou répertoires discordants ont été détectés. Examinez le fichier journal pour plus d'informations.
8   Certains fichiers ou répertoires n'ont pas pu être copiés et la limite de réessai a été dépassée.
16  Robocopy n'a copié aucun fichier. Vérifiez les paramètres de ligne de commande et vérifiez que Robocopy a suffisamment de droits pour écrire dans le dossier de destination.

Codes de sortie de Robocopy
https://blogs.technet.com/b/deploymentguys/archive/2008/06/16/robocopy-exit-codes.aspx

En fin de compte, John a raison. Il n'y a aucun moyen d'éviter l'examen des journaux si vous voulez avoir un fonctionnement de sauvegarde robuste. De plus, vous voudrez peut-être avoir un script qui s'exécute après l'opération Robocopy qui supprime la poignée des fichiers pendantes, puis supprime les fichiers.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X