Restic: La restauration avec --include crée des répertoires avec de mauvaises autorisations en descendant.

Créé le 31 oct. 2017  ·  5Commentaires  ·  Source: restic/restic

Sortie de restic version

restique 0.7.3
compilé avec go1.9 sur linux / amd64

Comment avez-vous géré restic exactement?

Voir les détails ci-dessous

Quel backend / serveur / service avez-vous utilisé?

Client: Debian Stable (9.2)
Serveur: serveur FreeBSD 11.1 sur le LAN utilisant OpenSSH (OpenSSH_7.2p2, OpenSSL 1.0.2k-freebsd 26 janv.2017)

Comportement attendu

Tous les répertoires doivent être créés avec les autorisations et la propriété d'origine, même si vous ne restaurez que les fichiers situés en profondeur dans la hiérarchie.

Comportement réel

Lors de la restauration de fichiers situés profondément dans la hiérarchie, les répertoires en descente sont restaurés avec un utilisateur et une autorisation différents de ceux de l'original.

Étapes pour reproduire le comportement

mkdir testdir # create directory
touch testdir / testfile # créer un fichier dedans
chmod 755 testdir testdir / testfile # assurez-vous que les permissions sont 755
su # passer à la racine
restic -r sftp: rakor @ SERVER : / usr / home / rakor / resticbackuptest backup testdir # faire la sauvegarde
restic -r sftp: rakor @ SERVER : / usr / home / rakor / resticbackuptest restaurer le dernier -t testrestore -i testfile # restaurer le fichier (pas tout le répertoire)
ls -lR testrestore # le fichier est restauré avec le propriétaire et les autorisations appropriés. Mais les répertoires en descendant vers le fichier sont restaurés avec l'utilisateur 'root' et les permissions 700.
testrestore /:
insgesamt 4
drwx ------ 2 racine racine 4096 Okt 31 21:30 testdir

testrestore / testdir:
insgesamt 0
-rwxr-xr-x 1 rakor rakor 0 Okt 31 21:25 fichier de test

Avez-vous une idée de ce qui a pu causer cela?

Je pense que les répertoires en descente ne sont pas "restaurés" mais simplement "créés" avec des "valeurs par défaut sécurisées".

Avez-vous une idée de la façon de résoudre le problème?

restaurez les répertoires vides au lieu de simplement les créer.

restore bug

Commentaire le plus utile

Pour moi, cela ressemble vraiment à un bug / problème dans la fonctionnalité de restauration. Si je restaure des données qui appartenaient à l'origine à un utilisateur dans un répertoire accessible par cet utilisateur, je m'attends à ce que cet utilisateur puisse accéder aux données restaurées, même si seule une partie a été restaurée. La restauration des attributs de répertoire (propriétaire / accès / etc) semble être un moyen naturel d'y parvenir.

De plus, le comportement actuel est perçu comme une "demi-restauration" réticulée de ces répertoires intermédiaires (leur existence est restaurée, mais leurs attributs ne le sont pas), ce qui semble incohérent / illogique.

Tous les 5 commentaires

Merci d'avoir soulevé ce problème. Je ne suis pas sûr que la définition des droits d'accès précédents sur les répertoires intermédiaires de la bonne manière, permettez-moi d'y réfléchir un peu.

Avez-vous d'autres réflexions à ce sujet?

Pour moi, cela ressemble vraiment à un bug / problème dans la fonctionnalité de restauration. Si je restaure des données qui appartenaient à l'origine à un utilisateur dans un répertoire accessible par cet utilisateur, je m'attends à ce que cet utilisateur puisse accéder aux données restaurées, même si seule une partie a été restaurée. La restauration des attributs de répertoire (propriétaire / accès / etc) semble être un moyen naturel d'y parvenir.

De plus, le comportement actuel est perçu comme une "demi-restauration" réticulée de ces répertoires intermédiaires (leur existence est restaurée, mais leurs attributs ne le sont pas), ce qui semble incohérent / illogique.

Je pense que c'est un bug. Si je souhaite restaurer une partie d'une sauvegarde, la copie restaurée doit être utilisable. Actuellement, il est inutilisable sans effectuer d'opérations de relance pour découvrir les autorisations, le propriétaire et le groupe appropriés de chaque élément de chemin créé automatiquement. Cela rend vraiment les restaurations de fichiers / répertoires difficiles.

Je suis d'accord que ce qui est restauré par restic doit être restauré de manière cohérente (c'est-à-dire avec les autorisations "par défaut" de l'utilisateur exécutant la restauration, ou avec les autorisations, etc. des fichiers et dossiers d'origine qui ont été sauvegardés, pas un combinaison des deux).

Je peux cependant voir un cas d'utilisation dans les deux types d'autorisations:

  • Certains utilisateurs ont besoin / veulent restaurer les données dans un nouveau contexte, et avec cela, ils veulent que les droits de propriété et les permissions soient "par défaut", tout comme s'ils avaient créé à nouveau les mêmes répertoires et fichiers eux-mêmes.
  • Certains utilisateurs doivent / veulent restaurer les données dans le même contexte ou dans le même contexte dans lequel elles ont été sauvegardées, et avec cela, veulent que le résultat ait la même propriété et / ou les mêmes autorisations que les fichiers d'origine qui ont été sauvegardés.
  • Certains utilisateurs souhaitent conserver uniquement les autorisations, mais pas les propriétaires (ils peuvent cependant facilement corriger eux-mêmes les droits de propriété).

Je pense que la manière raisonnable d'aller de l'avant est que l'on peut contrôler la propriété et / ou les autorisations restaurées par certaines options de la commande de restauration.

Quelqu'un peut-il confirmer que c'est toujours un problème? Depuis la publication de la version 0.7.3, nous avons apporté quelques modifications à la gestion des autorisations (et de l'horodatage) pour les répertoires intermédiaires ...

Cette page vous a été utile?
0 / 5 - 0 notes