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