Rsync: problème d'exclusion

Support Debian
#1

Bonjour,
j’entreprends de réaliser une sauvegarde totale de mon portable encore neuf, sur un SDD externe également neuf.

Je constate que ma commande rsync (lancée avec sudo) ne fait pas ce que j’attends:

J’observe les 2 problèmes suivant (sans en avoir cherché d’autres similaires):
(1) le répertoire /home/work/eric/tmp
n’est pas sauvegardé, à l’exception de 2 sous-répertoires (l’un vide, l’autre portant une arborescence profonde)
Les permissions et le propriétaire (eric) sont les même.

(2) malgré la ligne /tmp/ du fichier d’exclusion, l’arborescence de /tmp/ est sauvegardée

La commande rsync (produite par un script maison minimal) est la suivante:

time sudo rsync -auHAXi --stats --delete --exclude-from=/media/eric/Tosh2T_2024/ExcludeFile.txt --backup --backup-dir=/media/eric/Tosh2T_2024/24-03-02_14h_28 / /media/eric/Tosh2T_2024/Racine/

et le fichier d’exclusion le suivant: (il n’y a pas de blanc en début de ligne)

/media/eric/Tosh2T_2024/ExcludeFile.txt:
    # ce fichier a une copie sur /usr/local/etc/ExcludeFile_-_Tosh2T_2024.txt
    # Fichier d'exclusion minimale, sur le disque Tosh2T_2024
    #jeu. 29 févr. 2024 12:14:19 CET: (vide)
    #ven. 01 mars 2024 10:58:39 CET : 14 lignes
    /media/
    /mnt/
    /cdrom/
    /dev/
    /proc/
    /tmpfs/
    /tmp/
    *.bak
    *.bkp
    *.BKP
    *.BAK
    .cache/
    .Cache/
    .CACHE/
    /sys/
    /home/work/photos/liensImages/**

Le système sur «/» est ext4:

/dev/mapper/vg_mirror_root-lv_root on / type ext4 (rw,relatime,errors=remount-ro)

Le répertoire /usr/local/ est ext4:

/dev/mapper/vg_mirror_local-lv_local on /usr/local type ext4 (rw,noatime)

le répertoire /home/work/ est XFS:

/dev/mapper/vg_mirror_work-lv_work on /home/work type xfs (rw,noatime,attr2,inode64,logbufs=8,logbsize=32k,noquota)

La partition sur le disque USB est ext4:

/dev/sdb1 on /media/eric/Tosh2T_2024 type ext4 (rw,nosuid,nodev,relatime,errors=remount-ro,uhelper=udisks2)

Où est l’erreur ?

PS
rsync affiche ces lignes:

cannot delete non-empty directory: home/work/eric/tmp/vim/.vim
cannot delete non-empty directory: home/work/eric/tmp/vim/.vim
cannot delete non-empty directory: home/work/eric/tmp/vim
cannot delete non-empty directory: home/work/eric/tmp/vim
cannot delete non-empty directory: home/work/eric/tmp
cannot delete non-empty directory: home/work/eric/tmp
cannot delete non-empty directory: home/work/eric
#2

Bonjour,
Il faut distinguer sauvegarde et synchronisation.
rsync est un outil de synchronisation que l’on évoque souvent à tord comme un outil de sauvegarde.

L’option --delete implique la suppression dans le receveur. S’il s’agit d’un répertoire et que celui-ci ,'est pas vide cette suppression génère un message.
L’option --backup renomme les fichier existant sur la destination (le receveur). je ne suis pas certain que cela n’ai pas une interférence avec --delete.
Dans ton fichier d’exclusion est tu sur qu’il n’y a pas une différence de traitement entre /tmp et /tmp/.
Un certain nombre de commande font une différences entre le fait d’avoir le « / » terminal ou pas.

#4

est-ce à dire qu’il existe mieux pour lancer une sauvegarde (avec bkp pour une sorte de sauvegarde incrémentale) à partir d’un script bash?

J’ai bien vu timeshift, mais je n’ai pas réussi à le configurer pour cet usage (sauvegarde totale sur un sdd externe)

PS
«Il est largement utilisé pour la sauvegarde et la création de miroirs ainsi
que comme commande améliorée de copie.» dit l’info sur le package DEB

#5

Il me semblait au contraire que ces 2 options étaient complémentaires:
ce qui est effacé le sera sur le receveur, mais après avoir été sauvegardé dans le répertoire de BKP, comme les fichiers remplacés.
Mais je lis très mal l’anglais, (bien plus mal que DeepL) peut-être ais-je fais un contresens.

j’ai fais l’essai avec et sans «/» final, sans différence.

#6

sauvegarde totale c’est à définir déjà.
Personnellement je ne sauvegarde que mon/mes /home.
Comme j’ai un NAS, pour mon home usuel, je synchronise.
Les autres sont des /home spécifique pour lequel je fais une sauvegarde uniquement de ce que je considère comme nécessaire.
Je ne sauvegarde jamais mon système car j’utilise des iso d’installation qui permettent de faire une installation clef en main directement sans aucune manipulation postérieure.
Pour les serveurs avec des applications, soit j’ai une tâche de dump des bases de données vers mon NAS, soit ce sont les données propres de l’application qui sont sauvegardées.
Pour les packages installés, je maintiens une liste sur mes serveurs qui est inclue dans ce que je sauvegarde sur le NAS. Mais il y a peu de variation, sauf applications serveurs bien évidement.

Je suis en train de faire des tests avec zbackup et borg pour mieux industrialiser le tout. L’idée est de ne pas avoir de script « maison » pour le faire, car cela implique une maintenance que je n’ai pas envie de faire.
Borg va avoir ma préférence car je peux l’avoir sur mon NAS (Borg tourne sur l’OS synology) et il supporte aussi bien la déduplication que la compression.

#7

Merci Zargos,
mais ces solutions plus professionnelles dépassent le niveau raz de plancher de mes compétences.
à 50 ans, quand j’ai débuté avec linux, j’aurais eu plaisir à y mettre le temps et les neurones nécessaires, mais j’ai passé la limite et entammé la descente inexorable.

Jusqu’à présent, je sauvegardai (avec des script basées sur rsync) « /home», «/usr/local», «/etc/» et la liste donnée par dpkg -get–selections

Ici, j’ai simplement voulu aller vite, car l’ordinateur est pour moi un simple outil de travail d’écriture principalement, et non d’ingénieur informatique, même amateur.
Je me demande souvent si je n’ai pas eu trop d’ambition en choisissant Debian plutôt qu’une distrib dérivée comme Ubuntu.

Mais je vous aime bien, (même s’il m’arrive, comme ici ,de ne pas toujours me sentir à ma place), ce qui me fait encore bien aimer Debian (malgré une évolution que je déplore parfois en vieux crouton grincheux…)

1 J'aime
#8

J’ai supprimé le filtre /tmp/ du fichier d’exclusion: en vain (ce qui sauvegarde /tmp/ qui encombre inutilement)

J’ai trouvé une raison (mais pas vraiment l’explication- surtout concernant les 2 seuls répertoires présents):

L’utilisateur s’appelle /laguilde/, mais j’utilise un lien symbolique de ce répertoire vers /eric/, car j’ai craint d’avoir trop de choses à modifier (alias, script, config etc.) en renommant simplement laguilde en eric.

le répertoire /laguilde/tmp/ est bien sauvegardé par rsync, avec l’exclusion de /tmp/

dirdiff -a /home/work/laguilde/tmp /home/work/eric/tmp

ne montrent (évidemment) aucune différence.

Reste à apprendre - si c’est possible - quelle option de rsync utiliser pour reproduire le même shema sur le SSD de sauvegarde.

#9

Ce n’est pas un bon plan. Si ton user est suffisamment propre tu n’as pas besoin de faire tout un tas de manip à part.
Déjà quand tu développe quelque chose propre à un utilisateur et que potentiellement tu peux l’utiliser pour un autre, plutôt que de faire /home/theuser, tu utilise soit la variable $HOME soit ~/ ça t’évites d’avoir à réécrire quoique ce soit.
Pour avoir le nom du user plutôt que de le mettre en dur, récupère le avec whoami, etc…

#10

Merci Zargos pour ces excellents conseils.
Mais depuis des années avec Debian, je suis persuadé de ne pas avoir fait les choses «proprement», et évidemment ça se sent.

Si je tiens à être sur de ma sauvegarde avec rsync, c’est bien dans l’intention de corriger ce genre de bévues en toute sécurité, mais sans risquer d’y passer trop de temps.
J’ai mieux à faire avec mon ordinateur, qu’à trop m’occuper de lui, mais il faut tout de même en prendre soin, (sans parler des dérives où il m’envoie avec ma complicité coupable et parfois gourmande).

1 J'aime