Mon pool ZFS ne s'importe plus. Les données sont-elles perdues ?

Pas forcément. Souvent, seul l'état le plus récent du pool est endommagé, alors que les anciennes versions de la structure et les données elles-mêmes sont encore là. N'essayez pas d'options de réparation qui écrivent sur les disques, et demandez d'abord une analyse.

Quelle taille peut avoir un volume ?

Notre approche est justement conçue pour des volumes de centaines de téraoctets. Indiquez la capacité totale et la configuration dans votre demande, nous établissons un plan.

Où arrivent les données récupérées ?

Sur un stockage suffisamment grand pour les données récupérées. Vous pouvez le fournir vous-même, ou nous le prévoyons pour vous.

La récupération peut-elle se faire chez nous ?

Oui. Si les données ne peuvent pas quitter le bâtiment, nous travaillons chez vous, avec notre armoire salle blanche mobile.

Combien de temps dure la récupération d'un tel volume ?

Cela dépend de la taille, de l'état des disques et des dommages au système de fichiers. Après l'analyse, vous recevez un planning et un prix, avant toute intervention.

Notre système est virtualisé et fait tourner Exchange. Pouvez-vous le traiter ?

Oui. Dans une telle installation multicouche, avec virtualisation, disques virtuels et fichiers d'application comme une base de données Exchange, nous utilisons les informations d'une couche pour reconstruire une autre couche endommagée.

Récupération de très grands volumes : ZFS et systèmes de centaines de téraoctets • Datarecuperatie

Pourquoi les grands volumes sont différents

Un volume de plusieurs centaines de téraoctets ne se traite pas comme un grand disque dur. Les données sont réparties sur des dizaines de disques, le système de fichiers conserve sa structure dans des arbres et des références eux-mêmes dispersés sur tout le volume, et avec des systèmes copy-on-write comme ZFS et Btrfs, plusieurs versions d'une même structure coexistent souvent.

Les logiciels de récupération ordinaires tentent de lire et de comprendre un tel volume en une seule fois. À cette échelle, ils se heurtent au temps, à la mémoire ou à la quantité de résultats intermédiaires.

De quels systèmes il s'agit

Systèmes de fichiers et volumes pouvant atteindre des centaines de téraoctets, par exemple :

Pools ZFS (TrueNAS, Solaris, Proxmox et autres), y compris en RAID-Z1, Z2 ou Z3.
Btrfs, XFS et ext4 sur de grands serveurs Linux et systèmes NAS.
NTFS et ReFS sur des serveurs Windows.
Grands volumes sur stockage SAN et dans des environnements virtualisés.

Vous doutez que votre système soit concerné ? Contactez-nous avec les caractéristiques de votre installation.

Notre approche : trois processus

Nous avons donc développé notre propre logiciel, qui divise la récupération en trois processus successifs :

Les trois processus Find, Link et Save et le coordinateur dans le moniteur — Les trois processus et le coordinateur dans le moniteur, pendant la liaison et l'enregistrement. Exemple avec des données simulées.

Processus 1 : trouver (Find)

Nous parcourons le volume à la recherche des éléments du système de fichiers : nœuds, fragments et extraits (nodes, fragments, snippets) de métadonnées et de données, où qu'ils se trouvent.

Processus 2 : relier (Link)

Les éléments trouvés sont cartographiés, enchaînés, assemblés et triés (mapping, chaining, stitching, sorting), jusqu'à ce que la structure des dossiers et fichiers soit à nouveau cohérente.

Processus 3 : rassembler (Save)

Les fichiers reconstruits sont consolidés et transférés vers le stockage de destination (consolidate, transfer).

Pourquoi ainsi : en divisant la récupération en trois processus, aucun processus ne doit contenir tout le volume en une fois, et chacun fournit son propre résultat sur lequel le suivant s'appuie.

Le logiciel : Three-Tier Recovery

Les trois processus tournent dans notre propre logiciel, Three-Tier Recovery. Un coordinateur (coordinator) répartit le travail et conserve en mémoire les clés trouvées ; le traitement proprement dit est effectué par des workers, par processus : les workers Find analysent le volume, les workers Link relient les éléments entre eux, les workers Save enregistrent les fichiers.

Un moniteur montre à tout moment le déroulement d'un dossier :

Moniteur de Three-Tier Recovery pendant l'analyse d'un pool ZFS — Le moniteur complet pendant l'analyse (processus 1). Exemple avec des données simulées : un pool ZFS RAIDZ2 de 24 × 18 To, avec 12 workers Find sur 3 nœuds.

par processus, la progression, le débit (throughput) et le nombre de workers actifs ;
l'utilisation mémoire du coordinateur, ainsi que le nombre de clés et d'opérations par seconde ;
les totaux : données analysées, structures trouvées, fichiers reliés, données lues et écrites, checksums contrôlés et réparés, et erreurs de lecture ;
par worker, l'état, l'utilisation mémoire et processeur, le débit et les erreurs.

Technique : ajuster pendant la tâche

Les paramètres de performance, comme la fenêtre d'analyse (scan window), la taille des lots, la taille de lecture maximale et le nombre de threads de liaison, peuvent être modifiés pendant une tâche en cours, et une tâche peut être mise en pause. Nous adaptons ainsi la charge à l'état des disques et aux machines disponibles.

Pour les systèmes de fichiers avec checksums, comme ZFS, le logiciel contrôle les checksums des données lues et comptabilise les blocs corrects et ceux qui ont été réparés.

Réparti sur plusieurs machines (nœuds)

Les workers ne doivent pas tourner sur une seule machine. L'analyse est répartie sur plusieurs nœuds, qui traitent chacun une partie du volume. Pour un volume de centaines de téraoctets, nous engageons autant de workers que le dossier l'exige, et les suivons séparément.

Vue des workers par nœud pendant l'analyse — Workers pendant l'analyse : workers Find répartis sur trois nœuds, pendant que Link et Save attendent. Exemple avec des données simulées.

ZFS en particulier

ZFS n'écrase jamais les données existantes (copy-on-write) : il écrit de nouvelles versions et y renvoie depuis un arbre de pointeurs de blocs. Au sommet se trouve toujours l'état le plus récent du pool. Si celui-ci est endommagé, par exemple par un disque défectueux, une erreur d'importation ou une coupure de courant, le pool refuse souvent de s'importer, alors que les données elles-mêmes sont toujours là.

Comme ZFS n'écrase pas immédiatement les anciennes versions de sa structure, une récupération peut souvent revenir à un état antérieur cohérent. C'est précisément ce genre de recherche que sert le premier processus.

Technique : labels, uberblocks et groupes de transactions (TXG)

Chaque disque d'un pool ZFS possède quatre labels : deux au début et deux à la fin. Chaque label contient un anneau d'uberblocks, et chaque uberblock renvoie à l'état du pool après un groupe de transactions (transaction group, TXG). L'état actif est l'uberblock valide portant le numéro de TXG le plus élevé.

Comme ZFS fonctionne en copy-on-write, les blocs auxquels renvoient d'anciens uberblocks restent souvent intacts pendant un certain temps. Un TXG plus ancien et cohérent peut ainsi devenir le point de départ de la reconstruction.

Récupération multicouche (multi-layer recovery)

Autre chose que les trois processus, mais souvent dans le même dossier : des installations où les données sont empilées en plusieurs couches. Par exemple :

le partitionnement
le système de fichiers du disque ou du volume (native file system), éventuellement avec déduplication (deduplication)
la virtualisation, comme VMware ou Hyper-V
les disques virtuels (virtual disk images, comme VMDK ou VHDX), souvent répartis en fragments
le système de fichiers à l'intérieur de ce disque virtuel (guest file system), éventuellement à nouveau avec déduplication
les fichiers d'application, comme une base de données Exchange, eux-mêmes parfois fragmentés

Si l'une de ces couches est endommagée, nous utilisons les informations des autres couches pour la reconstruire. Ainsi, le système de fichiers d'une partition révèle où celle-ci commençait et se terminait, la structure à l'intérieur d'un disque virtuel aide à remettre ses fragments dans le bon ordre, et l'organisation interne d'une base de données permet de rassembler des morceaux séparés.

Tout sur la récupération multicouche →

Technique : exemples d'aide venant d'autres couches

Partitionnement : GPT conserve une copie de secours de l'en-tête et de la table de partitions à la fin du disque. Et même sans table de partitions, le secteur de démarrage ou le superblock d'un système de fichiers révèle où commence une partition.

Déduplication (deduplication) : les données sont stockées sous forme de blocs uniques (chunks), avec un index qui détermine quels blocs forment ensemble un fichier. Si cet index est endommagé, la structure de la couche supérieure, comme un disque virtuel ou un système de fichiers, aide à réordonner les blocs.

Fichiers d'application : une base de données Exchange (ESE) se compose de pages de taille fixe, chacune avec sa propre somme de contrôle (checksum). Cela aide à les reconnaître parmi d'autres données.

Ce qu'il vaut mieux faire

À faire

Arrêtez d'écrire sur le pool ou le volume.
Conservez la sortie des commandes d'administration, comme zpool status et zpool import, et les derniers messages.
Notez la configuration : nombre de disques, niveau RAID ou organisation des vdevs, et éventuels disques de cache et de log.
Retrouvez les clés ou mots de passe de chiffrement si le pool ou le volume est chiffré.

À éviter

N'essayez pas d'importation forcée ni d'options de réparation qui écrivent sur les disques.
Ne créez pas de nouveau pool ou volume sur les mêmes disques.
Ne remplacez pas de disques et ne lancez pas de reconstruction sans connaître la cause.

Déroulement d'un dossier

Analyse. Nous examinons l'installation, l'état des disques et ce qui s'est passé, et établissons un plan.
Copies. Nous faisons une copie complète de chaque disque ; les disques physiquement endommagés sont d'abord réparés dans notre laboratoire Class 1.
Trois processus. Trouver, relier et rassembler, avec notre propre logiciel.
Contrôle. Vous voyez la liste des fichiers récupérés avant de payer.
Livraison. Les données sont transférées vers un stockage suffisamment grand, fourni par vous ou par nous.

Si les données ne peuvent pas quitter le bâtiment, la récupération peut aussi se faire chez vous, avec notre armoire salle blanche mobile.

Récupération de très grands volumes