Pourquoi un contrôle d’intégrité du dépôt peut-il réussir alors qu’un fichier ne parvient toujours pas à être restauré ?
La vérification d’un dépôt peut réussir alors qu’un fichier ne peut pas être restauré si la vérification valide les métadonnées ou un échantillon de données au lieu de tester précisément ce chemin de récupération.
La vérification des sauvegardes n’est pas une opération universelle. Certaines vérifications confirment la structure du dépôt, les index, les manifestes et les blocs référencés sans lire chaque octet stocké. D’autres échantillonnent les données, ignorent les fichiers qui n’ont jamais été capturés ou ne disent rien sur les noms, les permissions, les ACL, les étiquettes, l’espace libre et les verrous d’application du système de fichiers de destination. Considérez le fichier en échec comme un parcours allant de la sélection de l’instantané aux objets stockés, puis à la création de la destination.
Identifiez exactement ce que la vérification réussie a validé
Enregistrez la commande de vérification, les options, la version de l’outil de sauvegarde, le backend du dépôt, l’ID de l’instantané et le journal final. Déterminez si la vérification a porté sur la structure du dépôt, les métadonnées de l’archive, les blocs référencés, les données stockées ou une extraction réelle.
Borg indique que sa vérification d’archive standard lit les métadonnées, mais pas les données des fichiers par défaut, sauf si la vérification des données est explicitement demandée.
Un résultat positif peut donc prouver que les références sont cohérentes en interne, tout en laissant certains blocs de contenu non lus. Ne considérez pas le dépôt comme entièrement restaurable tant que des fichiers représentatifs n’ont pas été extraits.
Déterminez si les données stockées du fichier ont réellement été lues
Localisez le fichier dans l’instantané prévu et identifiez les packs, blocs ou objets nécessaires à sa reconstruction. Comparez l’échec de la restauration avec le périmètre de lecture des données couvert par la vérification du dépôt.
Restic documente les vérifications read-data et read-data-subset, montrant qu’une vérification structurelle courante et une lecture complète du contenu correspondent à deux niveaux de vérification différents.
Si seule une partie des données a été lue, le fichier en échec peut dépendre d’un pack non vérifié. Effectuez une vérification ciblée ou complète des données, selon les possibilités prises en charge, avant toute tentative de réparation.
Confirmez que le fichier était inclus dans cet instantané
Listez le chemin relatif exact dans l’instantané sélectionné. Vérifiez les filtres, les exclusions, les avertissements concernant les sources illisibles, les règles relatives aux liens symboliques, les limites des points de montage et l’éventualité que l’interface de restauration ait sélectionné une autre version.
Kopia avertit que les règles d’exclusion omettent les chemins correspondants. La cohérence du dépôt peut donc être validée même si le fichier souhaité n’a jamais été capturé.
Un chemin factice ou une entrée de répertoire parent ne prouve pas que le contenu du fichier existe. Comparez l’inventaire de l’instantané, la taille, le hachage et l’horodatage avec l’enregistrement source attendu.
Vérifiez les contraintes liées au nom de fichier et au chemin de destination
Restaurez le même fichier vers un chemin local court et vide, en utilisant un nom simple. Comparez les caractères invalides, les noms réservés, les collisions de casse, les espaces en fin de nom, la longueur du chemin et la normalisation Unicode.
Les recommandations de Microsoft relatives aux noms de fichiers documentent les restrictions concernant les noms de fichiers et les chemins Windows, qui peuvent rejeter un seul chemin restauré alors que le dépôt lui-même reste sain.
Si le fichier est restauré vers un chemin temporaire court, son contenu stocké est disponible. Corrigez l’organisation de la destination ou la règle de renommage au lieu de réparer le dépôt.
Vérifiez la restauration des ACL, des attributs étendus et de la propriété
Répétez la restauration avec la conservation des métadonnées désactivée, uniquement dans une destination jetable, puis comparez-la à la restauration normale tenant compte des métadonnées. Notez le premier attribut qui échoue.
GNU tar documente séparément la restauration des ACL et des attributs étendus, ce qui montre pourquoi les données d’un fichier peuvent être lisibles alors que l’application des métadonnées échoue.
N’acceptez pas une restauration sans métadonnées comme solution de production lorsque les applications dépendent des ACL, de la propriété, des plages creuses ou des attributs étendus. Utilisez-la uniquement pour identifier la couche défaillante.
Vérifiez les étiquettes de sécurité et la politique de destination
Inspectez les étiquettes SELinux, l’antivirus ou la protection des terminaux, les contrôles anti-ransomware, les indicateurs d’immutabilité, les permissions du partage et les verrous d’application sur la cible de restauration.
Red Hat documente la restauration des contextes de sécurité par défaut lorsque les fichiers arrivent avec des étiquettes manquantes ou inappropriées.
Un fichier qui s’extrait mais ne peut pas être ouvert peut signaler un problème de politique de destination plutôt qu’un problème du dépôt. Testez-le avec le même utilisateur et la même application que ceux qui doivent utiliser le fichier restauré.
Effectuez une restauration isolée avant toute réparation
Restaurez le fichier en échec, les métadonnées de son parent et plusieurs fichiers voisins dans un jeu de données vide ou un répertoire temporaire. Enregistrez les hachages, les journaux et l’état du dépôt avant d’exécuter des commandes de réparation.
Le guide ZimaSpace consacré à la vérification des sommes de contrôle et des métadonnées explique la distinction entre l’intégrité du contenu stocké et une récupération exploitable par l’application.
Le problème est résolu lorsque le fichier sélectionné est restauré depuis l’instantané prévu, correspond à son contenu attendu, reçoit les métadonnées requises et s’ouvre via le chemin de l’application de production.
Questions fréquentes
Une vérification réussie du dépôt prouve-t-elle que chaque fichier peut être restauré ?
Non. Cela dépend du fait que la vérification ait lu toutes les données stockées et de la capacité de la destination à recréer chaque chemin ainsi que ses métadonnées.
Dois-je lancer immédiatement une réparation après un seul échec de restauration ?
Non. Testez d’abord une autre destination, confirmez que le fichier existe dans l’instantané et exécutez une vérification des données prise en charge. Une réparation peut supprimer des métadonnées ou des objets endommagés.
Une restauration de test réussie est-elle plus probante qu’un rapport de vérification ?
Oui, pour le chemin de récupération testé. Elle prouve la sélection, le déchiffrement, la lecture du contenu, la création de la destination et la gestion des métadonnées pour cet échantillon précis.
Produits recommandés
Assistance et conseils
Plus à lire
Guide de stockage pour l’enregistrement de la télévision en direct : capacité, conservation et nettoyage
Mesurez les enregistrements réels, prévoyez une marge de sécurité, combinez les limites d’ancienneté et de capacité, et vérifiez que le programme admissible le plus...
Flux de récupération des métadonnées multimédias à domicile après la restauration d’une base de données
Protégez l’état restauré, vérifiez l’identité et les chemins des médias, puis corrigez les illustrations ou les correspondances manquantes dans une bibliothèque pilote avant d’appliquer...
Liste de contrôle de compatibilité du client Jellyfin pour l’audio, la vidéo et les sous-titres
Testez des fichiers représentatifs en ne faisant varier qu’un paramètre à la fois, puis consignez pour chaque client la lecture directe, le remuxage, la...
