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

Le
Damien
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



Merci d'avance pour votre aide
Damien


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Sylvain Sauvage
Le #9645481
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
Publicité
Poster une réponse
Anonyme