Pourquoi un instantané NAS domestique peut-il préserver des données déjà corrompues ?

Un instantané de NAS domestique peut conserver des données corrompues car sa fonction est de retenir un état de système de fichiers, pas de décider si chaque fichier dans cet état est sain. Si une base de données, un document, une photo ou un fichier média est déjà endommagé lors de la création de l’instantané, restaurer cet instantané peut reproduire la même version endommagée.

Le moment de la corruption est important. Un instantané peut protéger une version antérieure d’un écrasement ultérieur, mais il ne peut pas créer une version propre qui n’a jamais été capturée. Le partage de blocs en copie sur écriture crée aussi un second cas : un dommage physique à un bloc peut affecter plus d’une vue du système de fichiers qui référence encore ce bloc.

Un instantané préserve un état de système de fichiers, pas une copie connue comme saine

Un instantané de système de fichiers enregistre un état de stockage à un moment donné. Dans OpenZFS, par exemple, un instantané est une version en lecture seule d’un système de fichiers ou d’un volume, et il partage initialement les données avec l’ensemble de données actif plutôt que de dupliquer chaque fichier. La documentation OpenZFS sur les instantanés décrit comment l’instantané conserve les données qui resteraient autrement partagées jusqu’à ce que l’ensemble de données actif change.

Cette opération ne détermine pas si le contenu stocké est sémantiquement correct. Un système de fichiers peut préserver un fichier structurellement lisible même lorsqu’une application a écrit des enregistrements invalides, un outil de synchronisation a copié la mauvaise version, ou un ransomware a remplacé les octets originaux par un contenu chiffré. Le succès d’un instantané signifie donc qu’un état a été conservé ; cela ne certifie pas que cet état était bon.

La corruption présente au moment de l’instantané devient partie intégrante du point de récupération

Considérez un instantané programmé à minuit. Si une application corrompt une base de données à 22h00, l’instantané de minuit enregistre l’état du système de fichiers après la corruption. Revenir à cet instantané ramène la base de données à minuit, mais minuit est déjà trop tard pour fournir une copie saine.

La même séquence peut se produire après une synchronisation défectueuse, une importation incomplète, une sauvegarde accidentelle ou un chiffrement non autorisé. L’instantané ne « fige » pas la corruption comme une propriété spéciale ; il conserve simplement la version qui existait au moment de la capture. Un instantané plus ancien peut encore contenir une version utilisable, mais chaque instantané créé après le dommage peut contenir la même erreur logique.

Le moment de la corruption détermine si un instantané peut aider

Un instantané est le plus utile lorsque la modification logique indésirable se produit après le point de récupération. Si l’instantané de lundi contient un fichier sain et que le fichier en direct est écrasé mardi, la vue de lundi peut toujours révéler les données antérieures. Si le fichier était déjà corrompu lundi, ce même point de récupération ne peut pas résoudre le problème.

Les dommages au stockage sous-jacent créent un chemin différent. Un instantané pouvait être sain lors de sa création, mais devenir illisible plus tard si un bloc physique qu’il référence encore est endommagé et que le système de fichiers ne peut pas reconstruire une copie vérifiée. C’est pourquoi le moment de la corruption doit être considéré conjointement avec le partage des blocs et la redondance du stockage.

Le partage de blocs en copy-on-write peut exposer un bloc endommagé à travers les instantanés

Les instantanés copy-on-write sont économes en espace car les données inchangées sont partagées. La documentation du modèle de stockage Btrfs explique qu’un instantané et son sous-volume source partagent leurs données communes non modifiées. Un instantané est donc une vue historique du système de fichiers, pas automatiquement une seconde copie physique sur un support séparé.

Lorsque le fichier en cours est modifié normalement, le copy-on-write alloue un nouveau stockage pour la modification tandis que l'instantané continue de référencer les blocs antérieurs. Cette séparation rend la restauration possible. Cependant, si un bloc inchangé est toujours partagé et que ce bloc stocké devient illisible ou renvoie des données incorrectes, toutes les vues qui en dépendent peuvent rencontrer la même défaillance.

Les sommes de contrôle et le stockage redondant peuvent changer le résultat en détectant la discordance et en fournissant une autre copie, mais l'instantané lui-même ne crée pas cette protection. Le copy-on-write assure la séparation des versions ; il ne crée pas un domaine de défaillance matériel indépendant.

Les sommes de contrôle et les vérifications testent l'intégrité ; les instantanés ne le font pas

Les instantanés, sommes de contrôle et vérifications appartiennent à différentes parties de la pile de protection. Un instantané conserve l'historique, une somme de contrôle aide à déterminer si les octets stockés ont changé de manière inattendue, et une vérification lit de manière proactive les données stockées pour détecter des erreurs. Considérer ces fonctionnalités comme interchangeables conduit à une fausse confiance quant à ce qu'un point de récupération peut prouver.

Les sommes de contrôle peuvent détecter des modifications inattendues de blocs

La documentation Btrfs sur les sommes de contrôle indique que les sommes de contrôle sont calculées avant les écritures et vérifiées après la lecture des blocs depuis le stockage. Une discordance peut révéler que le bloc récupéré n’est pas le même que celui que le système de fichiers s’attendait à stocker.

Une somme de contrôle correspondante ne prouve pas qu’un document, une base de données ou un fichier média est logiquement correct. Si une application écrit de mauvaises données via le chemin d’écriture normal, le système de fichiers peut calculer une somme de contrôle valide pour ces mauvais octets. Le bloc est intact du point de vue du système de fichiers même si le contenu au niveau de l’application est inutilisable.

La redondance détermine si un scrub peut réparer les dommages

Un scrub peut détecter des erreurs de somme de contrôle, des erreurs de lecture et certains problèmes de métadonnées, mais la détection n’est pas la même chose que la réparation. La documentation Btrfs sur le scrub explique que la réparation automatique sur un stockage répliqué utilise des données vérifiées provenant d’une autre réplique. Sans copie alternative valide, le système de fichiers peut identifier le bloc endommagé sans pouvoir le reconstruire.

Une étude USENIX sur l’intégrité des données ZFS distingue de même la détection basée sur les sommes de contrôle de la récupération via la redondance. La leçon pratique est plus restreinte que « les scrubs corrigent la corruption » : un scrub ne peut réparer que les défaillances pour lesquelles le système de stockage peut localiser ou reconstruire des données de remplacement fiables.

La rétention des instantanés n’aide que si un état sain existe encore

La corruption n’est pas toujours détectée immédiatement. Une photo, une archive ou un fichier de projet rarement ouvert peut rester endommagé pendant des semaines avant que quelqu’un ne tente de l’utiliser. Si la rotation des instantanés a déjà supprimé toutes les versions antérieures aux dommages, une grande collection d’instantanés récents peut ne contenir aucun point de récupération sain.

La rétention doit donc refléter la fenêtre de détection probable, pas seulement la fréquence de création des instantanés. Les instantanés horaires fournissent un historique récent détaillé, tandis que les points journaliers, hebdomadaires ou mensuels plus durables prolongent la période pendant laquelle une erreur non détectée peut être corrigée. Il n’existe pas de calendrier universel : l’intervalle utile dépend du taux de changement, de la capacité disponible et de la rapidité avec laquelle les fichiers importants sont généralement vérifiés.

Vérifiez un instantané avant de remplacer les données NAS en direct.

Choisir un instantané par date n’est que la première étape. Avant de revenir en arrière sur un ensemble de données entier ou de remplacer le fichier en direct, restaurez une version candidate dans un emplacement séparé lorsque la plateforme NAS domestique le permet. Cela évite qu’une tentative de récupération non vérifiée écrase des données plus récentes qui peuvent encore être utiles.

1. Estimez quand la corruption est apparue pour la première fois.
2. Sélectionnez un instantané antérieur à ce moment.
3. Restaurez la version candidate dans un dossier ou clone alternatif.
4. Ouvrez, validez ou comparez le contenu récupéré avant de remplacer les données en direct.

La validation doit correspondre au type de données. Une somme de contrôle connue peut vérifier une archive inchangée, tandis qu’une base de données peut nécessiter sa propre vérification de cohérence et une photo ou une vidéo peut devoir être décodée. Pour la relation plus large entre les points de récupération, les copies indépendantes et la protection hors appareil, voir cette stratégie de sauvegarde NAS domestique.

FAQ

Un instantané pris avant la corruption peut-il devenir illisible ?

Oui. Un instantané protège un état logique antérieur des modifications ultérieures des fichiers, mais il peut toujours partager le même pool de stockage et les mêmes blocs physiques. Si l’un de ces blocs est endommagé et qu’aucune copie redondante vérifiée n’est disponible, l’instantané antérieur peut devenir illisible même s’il précède la corruption logique en cours d’investigation.

Un instantané réussi signifie-t-il que chaque fichier qu’il contient est sain ?

Non. Un instantané réussi indique que le système de fichiers a créé le point de récupération. Cela ne signifie pas que chaque fichier a été ouvert, décodé, vérifié par rapport à une version fiable, ou validé par l’application qui l’a créé.

Un nettoyage des données peut-il réparer une corruption écrite par une application ?

Généralement non, lorsque l’application a écrit le contenu incorrect normalement. Dans ce cas, le système de fichiers peut stocker les mauvais octets avec une somme de contrôle valide, ne laissant aucune incohérence au niveau des blocs que le nettoyage pourrait détecter. La récupération nécessite une version saine antérieure, un processus de réparation conscient de l’application, ou une copie indépendante.

Le remplacement d’un fichier en direct corrompu répare-t-il les instantanés plus anciens ?

Non. Le remplacement des écritures de fichiers en direct ou des références concerne des données saines pour l'ensemble de données actif, mais les instantanés plus anciens continuent de représenter leurs états historiques. Un instantané qui a conservé la version corrompue reste normalement corrompu jusqu'à son expiration ou sa suppression.