probleme hard links avec rsync

Le
Lulu
[XP : fcolc, fcou ; fu2 fcolc]

Bonjour,

Je viens de découvrir un problème avec mon script de sauvegarde qui
utilise rsync.

Je l'utilise pour sauvegarder notamment mes scripts bash, présents dans
/usr/local/scripts_bash/ dont chacun des fichiers possède un lien dur
dans /usr/local/bin/

Mes options d'appel de rsync : -vrpoglHxuzs
-v : verbose
-r : résursif sur les répertoires
-p : préserver les permissions
-o ; préserver l'owner
-g : préserver le group
-l : copy symlinks as symlinks
-H : preserve hard links
-x : ne pas sortir du système de fichier
-u : skip files that are newer on the receiver
-z : compression pendant le transfert
-s : no space-splitting; wildcard chars only

Et pourtant, un fichier transféré vers le /usr/local/scripts_bash/ qui
était un lien dur vers un fichier de /usr/local/bin/ (donc en fait le
même fichier référencé deux fois dans le système de fichier ext3), après
la sauvegarde de /usr/local/scripts_bash/ depuis un autre PC, en
utilisant rsync avec ces options voit son lien cassé : après la
sauvegarde les deux fichiers ne sont plus hard-linkés.

(Ceci est un exemple très simple : sur toutes mes linuxettes, les
scripts contenus dans /usr/local/scripts_bash/ sont hard-linkés dans
/usr/local/bin/ Mais comme le contenu de /usr/local/bin/ n'est pas
forcéménent le même sur toutes les machines, je ne sauvegarde que
/usr/local/scripts_bash)

Se pourrait-il que j'ai mal lu (et relu) la page de man de rsync et
qu'une des options passées rende inactive l'option '-H' ?

Ou peut-être cela vient-il de ma nouvelle machine principale, celle
depuis laquelle je lance les sauvegardes, dont les partitions sont
formatées en ext4 alors que mes autres machines sont en ext3 ?


Merci de vos avis.
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Pascal Hambourg
Le #26546117
Le 11/05/2020 à 01:37, Lulu a écrit :
Je viens de découvrir un problème avec mon script de sauvegarde qui
utilise rsync.
Je l'utilise pour sauvegarder notamment mes scripts bash, présents dans
/usr/local/scripts_bash/ dont chacun des fichiers possède un lien dur
dans /usr/local/bin/
Mes options d'appel de rsync : -vrpoglHxuzs

Quelle est la commande complète ?
Et pourtant, un fichier transféré vers le /usr/local/scripts_bash/ qui
était un lien dur vers un fichier de /usr/local/bin/ (donc en fait le
même fichier référencé deux fois dans le système de fichier ext3), après
la sauvegarde de /usr/local/scripts_bash/ depuis un autre PC, en
utilisant rsync avec ces options voit son lien cassé : après la
sauvegarde les deux fichiers ne sont plus hard-linkés.
(Ceci est un exemple très simple : sur toutes mes linuxettes, les
scripts contenus dans /usr/local/scripts_bash/ sont hard-linkés dans
/usr/local/bin/ Mais comme le contenu de /usr/local/bin/ n'est pas
forcéménent le même sur toutes les machines, je ne sauvegarde que
/usr/local/scripts_bash)

Tu veux dire que la commande rsync copie /usr/local/scripts_bash/ mais
pas /usr/local/bin ?
Se pourrait-il que j'ai mal lu (et relu) la page de man de rsync et
qu'une des options passées rende inactive l'option '-H' ?

Peut-être ceci :
"Note that rsync can only detect hard links between files that are
inside the transfer set. If rsync updates a file that has extra
hard-link connections to files outside the transfer, that linkage will
be broken. If you are tempted to use the --inplace option to avoid this
breakage, be very careful that you know how your files are being updated
so that you are certain that no unintended changes happen due to
lingering hard links (and see the --inplace option for more caveats)."
Vu ton cas d'utilisation, ne serait-il pas préférable de faire des liens
symboliques dans /usr/local/bin plutôt que des liens physiques ?
Sergio
Le #26546118
Le 11/05/2020 à 09:04, Pascal Hambourg a écrit :
Peut-être ceci :
"Note that rsync can only detect hard links between files that are inside the transfer set. If rsync updates a file that has extra hard-link connections to files outside the transfer, that linkage
will be broken. If you are tempted to use the --inplace option to avoid this breakage, be very careful that you know how your files are being updated so that you are certain that no unintended changes
happen due to lingering hard links (and see the --inplace option for more caveats)."
Vu ton cas d'utilisation, ne serait-il pas préférable de faire des liens symboliques dans /usr/local/bin plutôt que des liens physiques ?

Surtout que dans un "hard link", les deux fichiers liés sont physiquement les mêmes et il est impossible de les distinguer. D'où l'intérêt de faire des liens symboliques.
D'ailleurs je n'ai jamais compris pourquoi le concepteur de la commande "ln" n'a pas mis l'option "-s" par défaut (raisons historiques ?).
--
Serge http://cahierdesergio.free.fr/
Soutenez le libre: http://www.framasoft.org
Marc SCHAEFER
Le #26546125
Sergio
D'ailleurs je n'ai jamais compris pourquoi le concepteur de la commande "ln" n'a pas mis l'option "-s" par défaut (raisons historiques ?).

J'ai eu travaillé sur des UNIX où les liens symboliques n'existaient pas (oui,
ça doit faire 30+ ans). Je suppose que la compatibilité POSIX prescrit
certains arguments de certaines commandes.
Les liens durs sont pratiques pour faire ce qu'il font, par exemple pour
plusieurs container en chroot partageant des exécutables en lecture seulement
(ok, on peut le faire aujourd'hui avec un bind mount), ou pour des droits
d'accès complexes (ok, on peut le faire avec des acl aujourd'hui).
Bref, oui, sur un Linux moderne, j'ai de la peine à comprendre à quoi peuvent
servir les liens durs (sinon pour implémenter . et ..).
PS: j'avais tendance à faire un mount NFS quelque part et mettre des symlinks
depuis /usr/local; aujourd'hui j'ai un mini cluster de containers et j'ai
un répertoire /data répliqué en glusterfs: même certaines finitions de
/etc/rc.local sont en fait dans un script partagé; bien sûr si on a horreur
des dépendances entre systèmes, services et processus, on peut utiliser
rsync à la place.
PS/2: je ne sait pas ce que dit le LFS, mais pour moi /opt c'est uniquement
pour les logiciels propriétaires, s'il y en a.
Philippe Michel
Le #26546165
On 2020-05-10, Lulu
Je viens de découvrir un problème avec mon script de sauvegarde qui
utilise rsync.
[...]
je ne sauvegarde que /usr/local/scripts_bash)
Se pourrait-il que j'ai mal lu (et relu) la page de man de rsync

Il semble que vous ayez manqué cette partie, dans la description de
l'option -H :
Note that rsync can only detect hard links between files that
are inside the transfer set. If rsync updates a file that has
extra hard-link connections to files outside the transfer, that
linkage will be broken.
Lulu
Le #26546173
Le 11-05-2020, Philippe Michel
On 2020-05-10, Lulu
Je viens de découvrir un problème avec mon script de sauvegarde qui
utilise rsync.
[...]
je ne sauvegarde que /usr/local/scripts_bash)
Se pourrait-il que j'ai mal lu (et relu) la page de man de rsync

Il semble que vous ayez manqué cette partie, dans la description de
l'option -H :
Note that rsync can only detect hard links between files that
are inside the transfer set. If rsync updates a file that has
extra hard-link connections to files outside the transfer, that
linkage will be broken.

0K. Merci à toi et Pascal, j'avais effectivement survolé un peu
rapidement cette partie. Et comme je ne transfère effectivement pas
/usr/local/bin entre deux machines, ceci explique cela.
Je ne sais d'ailleurs pas pourquoi j'ai mis des liens durs à la place de
liens symboliques puisque ça remonte à très loin. Je vais remplacer ces
liens durs par des liens symboliques.
Merci de votre aide.
Pascal Hambourg
Le #26546189
Le 11/05/2020 à 22:06, Lulu a écrit :
Je ne sais d'ailleurs pas pourquoi j'ai mis des liens durs à la place de
liens symboliques puisque ça remonte à très loin.

Les liens symboliques ont des inconvénients qui les rendent impropres à
certains cas d'utilisation. Par exemple :
- Un lien symbolique occupe plus d'espace disque (un inode supplémentaire).
- L'accès à un fichier via un lien symbolique est moins performant à
cause de l'indirection supplémentaire.
- Un lien symbolique est cassé si la cible est supprimée, déplacée ou
renommée.
- Un lien symbolique pointant vers un chemin relatif est cassé s'il est
déplacé (sauf cas particulier).
- un lien symbolique pointant vers un chemin absolu est cassé si le
système de fichiers est monté sur un autre point de montage.
Christophe PEREZ
Le #26546279
Le Tue, 12 May 2020 09:19:39 +0200, Pascal Hambourg a écrit :
Les liens symboliques ont des inconvénients qui les rendent impropres à
certains cas d'utilisation. Par exemple :

Je rajouterai par exemple aussi que certains softs sous Wine ne
fonctionnent pas (plus) avec un lien symbolique.
Lulu
Le #26546367
Le 12-05-2020, Pascal Hambourg
Le 11/05/2020 à 22:06, Lulu a écrit :
Je ne sais d'ailleurs pas pourquoi j'ai mis des liens durs à la place
de liens symboliques puisque ça remonte à très loin.

Les liens symboliques ont des inconvénients qui les rendent impropres
à certains cas d'utilisation. Par exemple :
- Un lien symbolique occupe plus d'espace disque (un inode
supplémentaire).
- L'accès à un fichier via un lien symbolique est moins performant à
cause de l'indirection supplémentaire.
- Un lien symbolique est cassé si la cible est supprimée, déplacée ou
renommée.
- Un lien symbolique pointant vers un chemin relatif est cassé s'il
est déplacé (sauf cas particulier).
- un lien symbolique pointant vers un chemin absolu est cassé si le
système de fichiers est monté sur un autre point de montage.

Un autre cas où la création d'un lien dur est préférable à la copie du
fichier (et où le lien symbolique ne convient évidemment pas) est le
renommage en masse de fichiers (typiquement des photos ou des mp3) : on
créé des liens durs dans un répertoire temporaire pour vérifier que le
one-liner a correctement fait son job, puis on peut supprimer les
originaux.
Lulu
Le #26546468
Le 10-05-2020, Lulu
[XP : fcolc, fcou ; fu2 fcolc]
Bonjour,
Je viens de découvrir un problème avec mon script de sauvegarde qui
utilise rsync.
Je l'utilise pour sauvegarder notamment mes scripts bash, présents dans
/usr/local/scripts_bash/ dont chacun des fichiers possède un lien dur
dans /usr/local/bin/
Mes options d'appel de rsync : -vrpoglHxuzs
-v : verbose
-r : résursif sur les répertoires
-p : préserver les permissions
-o ; préserver l'owner
-g : préserver le group
-l : copy symlinks as symlinks
-H : preserve hard links
-x : ne pas sortir du système de fichier
-u : skip files that are newer on the receiver
-z : compression pendant le transfert
-s : no space-splitting; wildcard chars only
Et pourtant, un fichier transféré vers le /usr/local/scripts_bash/ qui
était un lien dur vers un fichier de /usr/local/bin/ (donc en fait le
même fichier référencé deux fois dans le système de fichier ext3), après
la sauvegarde de /usr/local/scripts_bash/ depuis un autre PC, en
utilisant rsync avec ces options voit son lien cassé : après la
sauvegarde les deux fichiers ne sont plus hard-linkés.
(Ceci est un exemple très simple : sur toutes mes linuxettes, les
scripts contenus dans /usr/local/scripts_bash/ sont hard-linkés dans
/usr/local/bin/ Mais comme le contenu de /usr/local/bin/ n'est pas
forcéménent le même sur toutes les machines, je ne sauvegarde que
/usr/local/scripts_bash)
Se pourrait-il que j'ai mal lu (et relu) la page de man de rsync et
qu'une des options passées rende inactive l'option '-H' ?
Ou peut-être cela vient-il de ma nouvelle machine principale, celle
depuis laquelle je lance les sauvegardes, dont les partitions sont
formatées en ext4 alors que mes autres machines sont en ext3 ?
Merci de vos avis.

On m'a répondu dans fcolc que j'avais mal lu la section relative à la
section "-H : hard link"
Note that rsync can only detect hard links between files that
are inside the transfer set. If rsync updates a file that has
extra hard-link connections to files outside the transfer, that
linkage will be broken.
Et comme de fait /usr/local/bin était en dehors du 'scope' de ma
commande rsync, mes fichiers dans /usr/local/scripts_bash se
retrouvaient "désynchronisés" de ceux dans /usr/local/bin/
Pourquoi mes scripts persos étaient-ils des liens durs dans
/usr/local/bin ?
J'en sais rien, ça remonte à ... (ouh-là...),, y'a prescription.
Pour éviter ce problème, il suffit que mes scripts perso dans
/usr/local/bin pointent vers des liens symboliques dans /usr/local/bin/
Merci de votre attention.
Christophe PEREZ
Le #26546530
Le Thu, 14 May 2020 23:31:40 +0200, Lulu a écrit :
Pour éviter ce problème, il suffit que mes scripts perso dans
/usr/local/bin pointent vers des liens symboliques dans /usr/local/bin/

Presque
Publicité
Poster une réponse
Anonyme