J'ai utilisé rsync commande pour copier un répertoire utilisateur particulier d'un périphérique de stockage à un autre. L'opération s'est terminée avec succès sans générer d'avertissement/d'erreur. Mais à ma grande surprise, les données à copier étaient d'environ 167 Go et les données copiées n'étaient que de 1,4 Go ! J'ai utilisé la commande 'du' pour calculer la taille du disque des dossiers source et de destination et je me suis assuré que "du" n'affiche pas de résultats erratiques en suivant ce didacticiel :comment corriger les statistiques d'utilisation erratiques du disque à partir de du. Vous trouverez ci-dessous un instantané expliquant le scénario.
Scénario : Supposons que l'ancien point de montage de stockage soit "/sata1/home/ramya" et que le nouveau point de montage de stockage soit "/tmp/home/ramya". Comme indiqué précédemment, j'ai utilisé rsync pour copier le répertoire comme indiqué ci-dessous :
usr/bin/rsync -avzlh /sata1/home/ramya/* /tmp/home/ramya/ | tee /tmp/$(date+"%F_%R")-backup.log
Faites attention à l'"astérisque" dans la commande ci-dessus (c'était le problème et j'expliquerai la raison sous le pli)
résultats d'écart de commande :
du sortie de la commande du répertoire source (/sata1/home/ramya/) :
# du -chs /sata1/home/ramya/167G /sata1/home/ramya/167G total
du sortie de la commande du répertoire de destination (/tmp/home/ramya) :
# du -chs /tmp/home/ramya/1.4G /tmp/home/ramya/1.4G total
À partir des instantanés ci-dessus, vous pouvez voir que le répertoire source a une taille de 167 Go et que le répertoire copié a une taille de 1,4 Go. Alors, où sont les données restantes ? Laissez-moi vous expliquer comment j'ai résolu le problème.
Solution :
Pour déboguer le problème, j'ai utilisé du commande pour vérifier la taille de chaque fichier dans les dossiers source et destination comme indiqué ci-dessous :En répertoriant les fichiers et en comparant la taille du fichier.
bash-3.2#du -h -x /sata1/home/ramya 15G /sata1/home/ramya/.g448M /sata1/home/ramya/1SVC13G /sata1 /home/ramya/.g8120M /sata1/home/ramya/techg/.techla90G /sata1/home/ramya/.openVAS.tar-gz16G /sata1/home/ramya/.VSL.zip...... | bash-3.2#du -h -x /tmp/home/ramya 1G /tmp/home/ramya/samplejobtoec48M /tmp/home/ramya/1SVC41M /tmp/home/ramya/M1512K /tmp/home /ramya/techglimpse/openvas.txt134M /tmp/home/ramya/etc/pki264K /tmp/home/ramya/NAMD_CV...... |
D'après la sortie ci-dessus, j'ai compris que les fichiers cachés n'étaient pas copiés et que cela était dû à "*" (asterisk) utilisé dans le rsync commande. L'astérisque développera tous les fichiers dans le travail en cours répertoire sauf les fichiers dont le nom commence par un point (fichiers cachés). Ainsi, rsync ne reçoit jamais les fichiers cachés comme arguments. La solution consiste donc à utiliser le nom complet du répertoire (au lieu de l'astérisque) comme argument de rsync commande.
rsync -avzlh --ignore-existing /sata1/home/ramya/ /tmp/home/ramya/ | tee /tmp/$(date+"%F_%R")-backup.log
Remarque :Les barres obliques à la fin des deux chemins. Toute autre syntaxe peut conduire à des résultats inattendus !
Voilà! Cela a fonctionné.