Préservation des liens symboliques de destination existants avec rsync

J'utilise rsync (1) pour maintenir à jour un dépôt Debian local. Récemment, le disque que j'utilise pour le stocker a commencé à manquer d'espace, j'ai donc décidé d'utiliser des liens symboliques pour me permettre de déplacer certains des répertoires vers un autre disque de taille similaire.

Malheureusement, il semble que rsync supprime les liens symboliques et remplisse le disque presque plein. Après quelques recherches, j'ai découvert l' --keep-dirlinksoption de rsync, qui semble sur mesure pour résoudre mon problème.

Mais ce n'est pas le cas. Les liens symboliques sur la cible sont toujours supprimés.
Voici ma commande rsync:

rsync --recursive --keep-dirlinks --links --hard-links --times --verbose \
 --delete --delete-excluded $EXCLUDE $SOURCE_EXCLUDE \
 $RSYNC_HOST::$RSYNC_DIR/pool/ $TO/pool/

Les EXCLUDE s'étendent pour éliminer un grand nombre d'architectures qui ne m'intéressent pas, dans le sens de --exclude binary-alpha/ --exclude disks-alpha .... Avant le lancement de rsync, mon répertoire de pool ressemble à ceci:

lrwxrwxrwx  1 root root   23 2014-09-22 13:58 contrib -> /u2/debian/pool/contrib
drwxrwxr-x 62 root root 4096 2012-04-09 03:02 main
lrwxrwxrwx  1 root root   24 2014-09-22 13:58 non-free -> /u2/debian/pool/non-free

Une fois que le rsync entre en action, j'obtiens ceci:

receiving incremental file list
deleting non-free
deleting contrib
./
contrib/
contrib/a/

Et ainsi de suite, et les liens symboliques sont remplacés par des répertoires remplis de fichiers.

Certaines des autres options de rsync interfèrent-elles --keep-dirlinks? Lesquels ne puis-je pas combiner? Ou est-ce l'ordre des options qui cause mon problème?

linux rsync symbolic-link

— unkilbeeg
source

Les options --deleteet --delete-excludedinterfèrent avec votre plan, car elles remarquent que le lien symbolique n'est pas là sur la source et le supprime donc.

Cela ne se produit que lorsque vous dites rsyncde copier tout le répertoire avec la source/ targetnotation (la barre oblique de fin après la source). Si vous utilisez à la source/* targetplace, le shell étendra la liste des fichiers et répertoires à copier et cela ne se produira pas (mais essayez d' --dry-runabord).

Cependant, au lieu de cette configuration fragile, je recommanderais de combiner les deux disques avec l'aide de LVM pour former un grand volume ne nécessitant pas ce genre de ruse.

— Sven
source

Merci! J'ai changé le script et il semble fonctionner. Cela me laissera un peu de temps - le disque aura toujours tendance à se remplir, mais j'ai le temps de changer les choses. Vous avez raison de combiner les deux avec LVM. J'y avais déjà pensé, mais en me traînant les pieds car cela signifie déplacer les choses puis les remettre en place. Mieux vaut tôt que tard, cependant, je suppose.

— unkilbeeg

J'ai eu un problème similaire qui a été résolu en utilisant --keep-dirlinks sans l'option -a que j'utilisais. Gêne "mineure" comme pour le troisième paragraphe, les systèmes de fichiers que j'utilise sont des "disques SAN" de 64 octets. Bien qu'il soit possible que des multiples puissent être combinés en des disques encore plus grands, disons 256 téraoctets, je m'attends à ce que les administrateurs aient des raisons pour les tailles que nous avons. Parfois, ce qui ressemble à une «supercherie» consiste simplement à savoir comment vivre avec ce que vous avez.

— user1683793

Ma solution ultime était un nouveau matériel. La machine d'origine était assez ancienne pour ne prendre en charge que les disques IDE, et le plus gros disque que vous pouviez obtenir à l'époque était 512G.

— unkilbeeg