Pourquoi la restauration d’un volume Docker recrée-t-elle le contenu des fichiers, mais supprime-t-elle les attributs étendus ?

La restauration d’un volume Docker peut recréer chaque octet de fichier tout en supprimant les attributs étendus lorsque le format de sauvegarde, les options, les privilèges ou la destination ne permettent pas de les préserver.

Les attributs étendus sont des paires nom-valeur de métadonnées stockées en dehors du contenu ordinaire des fichiers, de leur propriétaire, de leurs bits de mode et de leurs horodatages. Ils peuvent contenir des données ACL, des étiquettes SELinux, des capacités Linux, des marqueurs d’application ou des métadonnées Samba. Une simple sauvegarde de volume basée sur tar peut restaurer un répertoire qui semble complet, tandis que les applications se comportent différemment parce que l’archive n’a pas enregistré les attributs étendus ou que le processus de restauration n’a pas pu écrire dans un espace de noms protégé.

Inventoriez les attributs de la source avant de relancer la restauration

Sélectionnez des fichiers représentatifs et consignez leurs hachages, leur propriétaire, leur mode, leur ACL ainsi que le nom et la valeur de chaque attribut étendu. Incluez les fichiers qui ne fonctionnent plus correctement dans l’application après la restauration.

Le modèle xattr de Linux sépare les espaces de noms user, system, security et trusted, chacun ayant des exigences différentes en matière d’accès et de privilèges.

Si la source ne contient aucun attribut étendu, la restauration ne les a pas perdus. Si un seul espace de noms disparaît, concentrez-vous sur les privilèges, la politique de sécurité ou la prise en charge par la destination plutôt que sur la couche de contenu des fichiers de l’archive.

Vérifiez ce que la commande de sauvegarde Docker a réellement archivé

Enregistrez l’image exacte, la commande, le répertoire de travail, le format de l’archive, l’utilisateur, la source montée et la destination de sauvegarde montée utilisés par le conteneur de sauvegarde.

L’exemple de sauvegarde de volume de Docker utilise tar dans un conteneur auxiliaire, mais la préservation des métadonnées dépend toujours de l’implémentation de tar et des options sélectionnées.

La réussite de la création d’un fichier d’archive prouve que les entrées de répertoire et le contenu ont été lus, mais pas que chaque espace de noms d’attributs étendus a été inclus. Inspectez l’archive avec le même outil que celui utilisé pour la créer.

Activez les attributs étendus lors de la création et de l’extraction de l’archive

Comparez les options tar utilisées lors de la sauvegarde et de la restauration. Vérifiez que les attributs étendus étaient activés dans les deux directions et que les motifs d’inclusion ou d’exclusion n’ont pas supprimé les espaces de noms requis.

GNU tar indique que --xattrs enregistre et restaure les attributs étendus.

Ajouter cette option uniquement lors de l’extraction ne peut pas récupérer des attributs qui n’ont jamais été enregistrés. Créez une nouvelle petite archive à partir d’un fichier source contenant un attribut étendu de test connu, puis inspectez-la avant de modifier les sauvegardes de production.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Utilisez les bonnes options de métadonnées Rsync pour les sauvegardes basées sur des fichiers

Si la sauvegarde du volume utilise Rsync, examinez les options d’archive, d’ACL, d’attributs étendus, d’identifiants numériques, de fake-super et de privilèges sur l’émetteur comme sur le récepteur.

Le manuel officiel de Rsync documente -X pour préserver les attributs étendus et décrit le stockage fake-super lorsque les métadonnées privilégiées ne peuvent pas être appliquées directement.

L’option d’archive courante -a n’inclut pas automatiquement toutes les ACL et tous les attributs étendus nécessaires. Testez la commande exacte sur les véritables systèmes de fichiers source et de destination.

Vérifiez la prise en charge du système de fichiers et du montage de destination

Créez un fichier temporaire directement sur le volume restauré et essayez de définir, de lister puis de supprimer un attribut étendu utilisateur. Répétez l’opération depuis l’hôte et depuis le conteneur de sauvegarde.

Utilisez un utilitaire de listage des attributs dans l’hôte et dans le conteneur de restauration afin de vérifier que la destination accepte et renvoie les attributs étendus indépendamment de l’archive de sauvegarde.

Si la création directe d’un attribut étendu échoue, examinez le type de système de fichiers, les options de montage, le protocole réseau, le pilote de volume et la prise en charge par l’appareil de stockage. Aucune option d’archive ne peut restaurer des métadonnées que la destination est incapable de représenter.

Vérifiez les privilèges pour les espaces de noms security et trusted

Consignez l’utilisateur du conteneur de restauration, ses capacités, son espace de noms utilisateur, le mode rootless, la politique SELinux et vérifiez si le chemin du volume est monté par liaison depuis l’hôte.

Red Hat indique que les étiquettes SELinux peuvent nécessiter une restauration conforme à la politique après la copie ou la recréation des fichiers.

N’accordez pas définitivement de larges privilèges sur l’hôte à un conteneur de sauvegarde. Utilisez un environnement de restauration contrôlé ou restaurez d’abord les données ordinaires, puis réappliquez les étiquettes gérées par la politique avec les outils pris en charge.

Distinguez les ACL, les capacités et les attributs étendus propres aux applications

Comparez séparément les entrées ACL POSIX, les capacités des fichiers Linux, les étiquettes SELinux, les attributs étendus utilisateur ainsi que les métadonnées Samba ou macOS. Ils peuvent échouer pour des raisons différentes.

Le module xattr_tdb de Samba peut stocker séparément les attributs étendus du système de fichiers sous-jacent.

Une archive de volume au niveau des fichiers peut donc préserver l’arborescence visible sans préserver une base de données distincte de métadonnées Samba. Incluez chaque magasin de métadonnées dépendant ou recréez-le avec le processus pris en charge par l’application.

Restaurez un fichier de test et validez l’application

Créez un fichier source connu avec un hachage de contenu, une ACL, un attribut étendu utilisateur et toutes les métadonnées d’application nécessaires. Sauvegardez-le, puis restaurez-le dans un volume temporaire.

L’article de ZimaSpace consacré aux changements de permissions et de métadonnées lors d’une migration vers un NAS traite du comportement général des migrations ; cet article se concentre sur la sauvegarde et la restauration de volumes Docker.

Le problème est résolu lorsque les hachages de contenu, les noms et valeurs d’attributs étendus requis, les ACL, les étiquettes de sécurité et le comportement de l’application correspondent tous après une seconde sauvegarde et restauration contrôlées.

Questions fréquemment posées

Les attributs étendus sont-ils identiques aux ACL ?

Non. Les ACL peuvent être implémentées au moyen d’attributs étendus system sur certains systèmes de fichiers, mais les attributs étendus peuvent également stocker des étiquettes de sécurité, des capacités, des métadonnées utilisateur et des valeurs propres aux applications.

tar préserve-t-il les attributs étendus par défaut ?

Ne partez pas du principe que c’est le cas. GNU tar fournit des options explicites pour les attributs étendus, et l’archive doit les enregistrer lors de sa création avant que l’extraction puisse les restaurer.

Une restauration peut-elle perdre les attributs étendus même si elle est exécutée en tant que root ?

Oui. L’archive peut ne pas les contenir, la destination peut ne pas les prendre en charge, une politique de sécurité peut les refuser ou les métadonnées peuvent se trouver dans une base de données d’application distincte.