rsync ne conserve pas la propriété du répertoire même avec -a

J'utilise cette invocation rsync pour sauvegarder mon répertoire personnel:

rsync -aARrx --info= --force --delete --info=progress2 -F "$USER_HOME" "$BACKUP_MNTPOINT"

La page de manuel de rsync indique que -a implique -g et -o (entre autres commutateurs), ce qui devrait préserver la propriété. Cependant, j'ai remarqué que si un répertoire n'existe pas sous $BACKUP_MNTPOINT/$USER_HOME, il est créé avec la propriété root: root au lieu du bon. (Cela ne se produit qu'avec les répertoires juste en dessous $BACKUP_MNTPOINT/$USER_HOME). Pourquoi donc?

$BACKUP_MNTPOINTest un lecteur monté localement. $BACKUP_MNTPOINT/$USER_HOMEa la propriété et les autorisations appropriées. Ni , $USER_HOMEni se $BACKUP_MNTPOINTterminer par une barre oblique.

Les systèmes de fichiers source et cible sont tous deux XFS et l'exécution mkdir $BACKUP_MNTPOINT/$USER_HOMEcrée un répertoire avec la propriété attendue.

— Kralyk
source

Qu'est-ce que le système de fichiers $BACKUP_MNTPOINTet avec quelles options est-il monté? Cela se produit-il uniquement pour le $BACKUP_MNTPOINT/$USER_HOMErépertoire parent ( ) ou pour tous les répertoires créés? Faites $BACKUP_MNTPOINTet $USER_HOMEterminez par un /?

— terdon

J'utilise XFS pour les deux /homeet le lecteur de sauvegarde. Jusqu'à présent, je pense que cela ne s'est produit que pour les répertoires parents. Ni , $BACKUP_MNTPOINTni se $USER_HOMEterminer par une barre oblique. EDIT: Je peux confirmer maintenant que cela n'arrive qu'aux répertoires juste en dessous$BACKUP_MNTPOINT/$USER_HOME

— kralyk

A donc $BACKUP_MNTPOINT/$USER_HOMEles bonnes autorisations mais pas tous les sous-répertoires? Veuillez modifier votre question et ajouter ces détails. Précisez également si mkdir $BACKUP_MNTPOINT/$USER_HOME/foocrée un répertoire appartenant à votre utilisateur si vous le faites manuellement.

— terdon

Oui, mkdir $BACKUP_MNTPOINT/$USER_HOME/foocrée un répertoire appartenant à l'utilisateur.

— kralyk

Ce serait vraiment bien de voir des informations pertinentes de strace(comme spécifié dans une pseudo réponse).

— Pavel Šimerda

Réponses:

J'ai eu un problème similaire lors de l'utilisation rsyncpour sauvegarder mon système sur mon serveur. J'ai utilisé:

rsync -aAXSHPr \
-e ssh \
--rsync-path="sudo /usr/bin/rsync/" \
--numeric-ids \
--delete \
--progress \
--exclude-from="/path/to/file/that/lists/excluded/folders.txt" \
--include-from="/path/to/file/that/lists/included/folders.txt" \
/ USER@SERVER:/path/to/folder/where/backup/should/go/

La solution est qu'il n'y a pas vraiment de problème. Je soupçonne que vous avez abandonné le rsyncprocessus une fois que vous avez vu qu'il crée des dossiers avec un mauvais ensemble d'autorisations. Le nœud est que rsyncne définit les autorisations d'un dossier parent qu'une fois qu'il a terminé la synchronisation de tous les sous-dossiers et fichiers de celui-ci.

— lord.garbage
source

Wow, cela ne m'est pas venu du tout à l'esprit, bien repéré, merci.

— kralyk

Peut-être exécutez rsync via strace / truss et voyez si vous obtenez une erreur de retour du syscall chown (), et aussi pour confirmer que chown () a le bon chemin et UID / GID.

— Jez
source

Un bon commentaire mais pas une réponse.

— Pavel Šimerda