[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: rsync et cp-al => corruption ext3 (inode)



Damien wrote:
Hello,



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
/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...


Bon, il semblerait que le système de fichiers sur ce NAS (Synology) ne gère pas correctement la casse:

syno# touch TRUC
syno# touch truc
syno# touch TRuc
syno# ls -l
-rw-r--r-- 1 root root 0 Jan 13 23:42 truc



Si quelqu'un a un retour d'expérience là-dessus, je suis preneur!

Cordialement,
Damien


Reply to: