[RESOLU+TUTO solution] RSYNC ne préserve pas le propriétaire et le groupe

[oracle7]

Bonjour,

Le but : Réaliser la sauvegarde un dossier d'une machine sous Linux dans un dossier partagé du NAS pour si besoin en est, pouvoir restaurer ce dossier tel qu'à l'origine.

Le contexte :

Pour réaliser la sauvegarde du dossier Linux, dans un shell script, j'utilise la commande "rsync" (depuis la machine Linux) telle que :

SOURCE_DIR="/opt/docker/homeassistant/config"
BACKUP_DIR="oracle7@192.168.2.10:/volume1/Sauvegardes/SV_HomeAssistant"
BACKUP_PATH="${BACKUP_DIR}/SV_HA_$(date '+%FT%H%M')"
sshpass -f /home/oracle7/.synology/.password sudo rsync -a --delete "${SOURCE_DIR}/" "${BACKUP_PATH}"

Constat :

Les fichiers sont bien copiés avec les bons droits mais les propriétaires et groupes restent figés sur mon utilisateur du NAS et son groupe sur le NAS. Par exemple :

drwxr-xr-x 1 oracle7 users    960 Apr  5 21:26 ./
drwxr-xr-x 1 oracle7 users    554 Apr  5 21:26 ../
-rw------- 1 oracle7 users   8672 Apr  5 11:51 auth
-rw------- 1 oracle7 users    417 Mar  8 16:34 auth_provider.homeassistant
-rw-r--r-- 1 oracle7 users    339 Mar  9 12:27 camera
-rw-r--r-- 1 oracle7 users    275 Feb 25 19:59 core.analytics
-rw-r--r-- 1 oracle7 users    452 Feb 25 18:44 core.area_registry
-rw------- 1 oracle7 users    389 Mar  9 12:58 core.config

alors que la source est telle que :

drwxr-xr-x  2 oracle7 root   4096  5 avril 21:29 ./
drwxr-xr-x 17 oracle7 root   4096  5 avril 21:26 ../
-rw-------  1 root    root   8672  5 avril 11:51 auth
-rw-------  1 root    root    417  8 mars  16:34 auth_provider.homeassistant
-rw-r--r--  1 root    root    339  9 mars  12:27 camera
-rw-r--r--  1 root    root    275 25 févr. 19:59 core.analytics
-rw-r--r--  1 oracle7 root    452 25 févr. 18:44 core.area_registry
-rw-------  1 root    root    389  9 mars  12:58 core.config

Questions :

• Qu'est-ce que je rate selon vous ?
• Pourquoi les propriétaires et groupes ne sont-ils pas conservés lors de ma copie des fichiers sur le NAS ?
• Ai-je omis une option de paramétrage de rsync ?

Donc messieurs les "barbus" si vous avez une ou des idées, je suis vivement preneur.

MERCI d'avance de vos réponses.

Cordialement

oracle7😉

Modifié le 6 avril 2023 par oracle7
Résolu

[MilesTEG1]

@oracle7 Bonsoir 👋🏻

As-tu essayé avec ces options ?

 -avXh --syno-acl 

Quand j'ai copié un dossier dans un autre emplacement, j'ai utilisé cette commande sur le Syno :

rsync -avXh --progress --syno-acl --stats --exclude={'@eaDir','#recycle','~$*.*','~*','~*.tmp','desktop.ini','.DS_Store'} --log-file=/volume2/TEMP/rsync_transfer.log /volume1/Sossier/ /volume1/Dossier_dest/

Après, je n'ai pas trop poussé le détail à regarder les permissions... Mais je n'ai pas eu de soucis particulier.

[oracle7]

@MilesTEG1

Bonjour,

Merci de ta réponse.😀

J'ai donc essayé tout à tour avec les options suivantes : -aX , -aA (-A = --acls) mais sans effet sur les propriétaires et groupes.

Je n'ai pas utilisé les options -v et -h car elles n'apportent que le mode verbose lors de l'exécution pour la première et la seconde rend seulement  "human readable" les infos de l'option --stats dans le progress.

Pour ton information l'option --syno-acl n'existe pas (voir le man rsync) avec rsync sur Linux :

rsync: --syno-acl: unknown option
rsync error: syntax or usage error (code 1) at main.c(1749) [client=3.2.3]

cette option n'existe qu'avec le rsync "propre" à Synology (voir rsync --help) quand on le lance depuis un NAS donc pour une sauvegarde du NAS vers un système externe.

Je te l'accorde, je n'avais pas précisé que je lançais le script depuis la machine Linux d'où ta réponse pour cette option. Désolé. J'ai donc édité mon post pour le préciser.

Je continue donc à chercher ...😥

Cordialement

oracle7😉

[MilesTEG1]

@oracle7 Ma maitrise de la commande rsync est assez limitée, et effectivement le rsync du syno est un peu modifié par rapport à la version linux. Tu fais bien de préciser que tu cherches à lancer le rsync depuis une machine linux.

Mais du coup, j'ai peur que ce que tu cherches à faire ne soit pas possible car les users du Syno sont inconnus par ton linux... donc comment pourrait-il préserver ces permissions... ? Après je ne connais pas le fonctionnement des permissions, ni comment elles sont stockées dans le fichier ou dans le système de fichier... 

[.Shad.]

J'utilise Borgbackup pour tous mes périphériques Linux. Ça marche nickel, ça gère le versioning, le chiffrement et la préservation des permissions et la propriété des fichiers.

[MilesTEG1]

il y a 7 minutes, .Shad. a dit :

J'utilise Borgbackup pour tous mes périphériques Linux. Ça marche nickel, ça gère le versioning, le chiffrement et la préservation des permissions et la propriété des fichiers.

Tu voudrais pas faire un tuto comme tu sais bien les faire ? 😁

installation, configuration et utilisation 😉

[oracle7]

@MilesTEG1

Bonjour,

Finalement j'ai testé une autre méthode d'usage de rsync pour réaliser ma sauvegarde de dossier Linux vers/sur le NAS.

J'ai tout simplement utilisé rsync en mode daemon et la BINGO !!! cela marche nickel. Tous les droits, propriétaires et groupes sont conservés. Je peux donc envisager un restore des fichiers de la sauvegarde sans aucuns problèmes.

Autre gros avantage de ce mode, c'est qu'il n'y a pas non plus besoin de s'embêter à faire un montage de dossier partagé du NAS (nfs, cifs, sshfs, etc ...) sur la machine Linux (ou inversement) avec tous les problèmes qu'il faut gérer à cause d'UID/GID différents entre NAS et machine Linux pour un même username.

Donc je donne ici la solution, i.e. la commande à lancer dans un script shell sur la machine Linux pour le mode rsync daemon (exemple à adapter bien évidemment) :

SOURCE_DIR="/opt/docker/homeassistant/config"
BACKUP_DIR="oracle7@192.168.2.10::SV_HomeAssistant"
BACKUP_PATH="${BACKUP_DIR}/SV_HA_$(date '+%FT%H%M')"
sudo rsync -a --rsync-path="sudo rsync" --password-file=/root/.password --delete "${SOURCE_DIR}/" "${BACKUP_PATH}"

L'usage de sudo est obligatoire car rsync s'exécute en root bien que le script est lancé par un utilisateur avec droit d'admin (même nom sur le NAS et la machine Linux). Bien évidemment, il faut aussi mettre en place un échange de clés privé/publique SSH pour chaque utilisateur du NAS (root et oracle7 dans mon cas).

Le fichier /root/.password (à créer) comporte sur une seule ligne le MdP de root et est protégé (chmod 600 + chown root:root).

On remarquera aussi la nuance dans l'appel au serveur NAS --> les " :: " suivant l'@IP du NAS suivi du nom du module qui est défini dans /etc/rsyncd.conf .

cela aussi implique d 'ajouter ceci sur le NAS dans le fichier /etc/rsyncd.conf :

#-------------------------------------------
# Ajout oracle7 20230406 pour Sauvegarde dossier config HomeAssistant (sur la Machine Linux)
# Id de l'utilisateur qui execute rsync
uid = root
# Id du groupe d'utilisateurs qui execute rsync
gid = root

# Creation du module
[SV_HomeAssistant]
# Chemin vers le dossier partage du NAS recepteur de la sauvegarde
path = /volume1/Sauvegardes/SV_HomeAssistant
comment = Module de sauvegarde configuration HomeAssistant
# Utilisateurs pouvant se connecter au daemon rsync
auth users = root, oracle7
# Masque <username:passwd> utilise pour l'authentification du module
secrets file = /etc/rsyncd.secrets
# Par defaut : read only = yes : doit etre 'no' pour pouvoir ecrire
read only = no
# Rendre le module "listable"
list = yes
# Liste des hotes autorises à se connecter au module (séparateur = " , " ou " ")
# @IP machine Linux
hosts allow = 192.168.2.60

et dans le fichier /etc/rsyncd.secret les mots de passe des utilisateurs (username:password) :

root:MotDePasseTresTresLong_1
oracle7:MotDePasseTresTresLong_2

En espérant que cette solution servira pour d'autres membres qui veulent faire "simple" !

@.Shad.

Oui j'avais vu cette possibilité ainsi que celle avec un duplicati en docker, mais dans un premier temps je souhaite faire simple et pas trop me prendre la tête déjà que là, j'y ai passé quelques heures de recherche et lecture en tous genres sur la toile où il faut trier en permanence le bons grains de l'ivraie, tout et son contraire en somme ...

Cordialement

oracle7😉

[.Shad.]

@MilesTEG1 Le meilleur tutoriel est là : https://borgbackup.readthedocs.io/en/stable/installation.html, en suivant dans l'ordre des catégories. C'est hyper simple à suivre. Je ne pourrais pas mieux l'expliquer.

@oracle7 Cool, il faudra que tu vérifies quand même lors des mises à jour si tes modifications sont persistantes. Parce que là tu écris directement dans le fichier conf, pas dans un conf.d qui est inclus depuis un fichier maître.

[MilesTEG1]

il y a 2 minutes, .Shad. a dit :

Le meilleur tutoriel est là : https://borgbackup.readthedocs.io/en/stable/installation.html, en suivant dans l'ordre des catégories. C'est hyper simple à suivre. Je ne pourrais pas mieux l'expliquer.

Oué, mais si toi tu fais un tuto, ce sera en FR, et surtout on aura tes petites astuces, en FR aussi 😁
Aller, steuplé ? 😘

 

Blague à part, borg backup, ça fonctionne en mode client/serveur, ou bien, c'est juste une application qui va sauvegarder sur différents supports ? C'est plus performant que Duplciati ? Plus fiable ?
En tout cas, ça pourrait m'intéresser pour les macs de la maison, car autant j'aime beaucoup Carbon Copy Cloner, autant ça ne fait pas de vrai versionning...

 

 

[.Shad.]

il y a 11 minutes, MilesTEG1 a dit :

Oué, mais si toi tu fais un tuto, ce sera en FR, et surtout on aura tes petites astuces, en FR aussi 😁
Aller, steuplé ? 😘

Bien tenté mais nop 🙂 j'ai vraiment rien à apporter sur ce sujet, leur doc est parfaite, et Google Trad fait le travail pour les allergiques à la langue de Shakespeare.
Au vu du temps qu'un tutoriel nécessite pour le rédiger correctement, je le réserve pour ce qui je trouve n'est pas suffisamment développé par ailleurs, sinon à quoi bon redire ce que d'autres ont déjà dit ? 😉

Et si c'est pour faire des tutoriels à la Mariushosting, je passe mon tour. 😄 😄 

J'ai deux tutos sur le feu que je développerai quand quelques petits bugs gênants auront été corrigés. 🙂 

Modifié le 6 avril 2023 par .Shad.

[oracle7]

@.Shad.

Bonjour,

il y a 13 minutes, .Shad. a dit :

Cool, il faudra que tu vérifies quand même lors des mises à jour si tes modifications sont persistantes.

Ah que voilà une remarque plus que pertinente ! Dans le feu de l'action, je n'ai pas pensé à cet aspect et du coup cela pourrait effectivement devenir problématique.

Cela dit, je me dis que les utilisateurs rsync sur le NAS peuvent aussi être amenés à modifier ces fichiers et eux aussi perdraient indirectement leur configuration de sauvegarde. Aussi, j'espère que Synology a envisagé ce cas et lorsqu'ils fournissent une màj de DSM il n'y a pas d'impact sur ces fichiers. Je croise les doigts...

Mais tu as parfaitement raison, je vais surveiller cela de près lors d'une prochaine MàJ de DSM.

Cordialement

oracle7😉