Re: rsync et cp-al => corruption ext3 (inode)
Damien, dimanche 13 janvier 2008, 21:38:42 CET
>
> Hello,
’soir,
> Je mets en place un petit serveur de backup sur un serveur
> NAS: le DS-107 de Synology.
>
> Mon système de backup est à base de rsync et de cp -al :
> - le PC-client met à jour son dépôt sur le serveur (rsync)
> - régulièrement, le serveur copie l'état courant du dépot et
> fait une sauvegarde incrémentale (à base de cp -al)
>
> J'ajoute que sur le serveur, les données sont sauvées sur un
> volume en ext3.
>
>
> Bref, c'est grosso-modo la même chose que du rsnapshot (paquet
> du même nom).
>
> Voici mon problème:
>
> La mise à jour via rsync se passe sans pb, sauf que dès que
> deux fichiers *dont le nom ne diffère que par la casse* se
> trouvent dans le même répertoire, par exemple:
>
> client$ ls -l /etc/cups/ppd/
> total 80
> -rw-r--r-- 1 root root 22781 2007-06-15 20:04 hp5150.ppd
> -rw-r--r-- 1 root root 52395 2008-01-08 20:18 HP5150.ppd
>
> Un des deux fichiers (ici /etc/cups/ppd/hp5150.ppd) est
> réécrit à chaque fois sur le serveur.
>
> Cela n'est pas bien gênant en soi, sauf que cela génère des
> erreurs de copie sur le serveur qui corrompent le système de
> fichier:
>
>
> backup-server # ./rotate_backup.sh
> /opt/bin/mv /volume1/backup/0 /volume1/backup/1
> /opt/bin/cp -ap /volume1/backup_depot /volume1/backup/0
(au passage, -p est déjà dans -a)
Tu n’effaces pas …/0 avant de copier dedans ?
> /opt/bin/cp: cannot create link
> `/volume1/backup/0/maisonLnx/etc/cups/ppd/hp5150.ppd': File
> exists
>
> backup-server # ls -l /volume1/backup_depot/maisonLnx/etc/ppd
> ls: cannot access /volume1/backup_depot/maisonLnx/etc/ppd: No
> such file or directory
>
>
> Un fsck me confirme bien le système de fichier corrompu:
>
> backup-server # e2fsck -l -v /dev/hda3
> [...]
>
> 1.39-Mar162007: recovering journal
> Pass 1: Checking inodes, blocks, and sizes
> Pass 2: Checking directory structure
> Entry 'HP5150.ppd' in /backup_depot/maisonLnx/etc/cups/ppd
> (40501249) has deleted/unused inode 40501265. Clear<y>? yes
>
> Pass 3: Checking directory connectivity
> Pass 4: Checking reference counts
> Inode 40501264 ref count is 2, should be 1. Fix<y>? yes
>
> Pass 5: Checking group summary information
> [...]
>
>
>
> J'avoue que cette erreur me laisse perplexe... Cela fait
> plusieurs années que mes scripts sont utilisés sans soucis!!!
> Je ne vois plus par quel bout prendre les choses, ni quel mot
> clé utiliser pour googliser tout ça....
>
> Je pense que cela vient du fait que c'est un Linux batardisé
> qui est installé sur le NAS, mais j'ai fait quelques test via
> un chroot Debian (avec les outils ssh et rsync de la branche
> Debian stable), le problème est le même...
Ils ont peut-être patché ext3 pour ne plus différencier les
noms par la casse ?
Ça doit poser moins de problèmes pour ceux qui sont habitués
à des fs antédiluviens…
Ça semble cohérent avec le chroot : il utilise toujours le
noyau et le fs d’origine.
J’avais regardé les Synology il y a quelques mois, ils
filaient les images de leur système (un gros tar.gz). Tu as
vérifié ce qu’ils font ?
--
Sylvain Sauvage
Reply to: