Récupération de très grands volumes

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.

Pourquoi Three-Tier Recovery fait la différence ici

La force de Three-Tier Recovery est de traiter de très grands volumes de stockage sans tenter de reconstruire tout le système de fichiers en une seule opération. Sur des volumes de centaines de téraoctets, la quantité de données brutes n'est qu'une partie du problème : le logiciel doit aussi traiter de très grands nombres de structures du système de fichiers, de références et de fragments candidats.

Cela concerne surtout les systèmes de fichiers copy-on-write (CoW) arborescents comme ZFS et Btrfs. Chez ZFS, la structure est littéralement un arbre de références de blocs (block-pointer tree) ; Btrfs utilise un autre format sur disque, avec ses propres tree roots, nœuds B-tree, extents et informations de génération. Leur point commun : une modification n'écrase pas la structure existante, mais écrit de nouveaux tree nodes et blocs de données et crée de nouvelles références. Des blocs de différentes générations de l'arbre peuvent ainsi rester présents simultanément sur le stockage.

Find (processus 1, voir ci-dessous) parcourt la source à la recherche des éléments du système de fichiers et réduit des centaines de téraoctets de stockage brut à un ensemble bien plus restreint de structures pertinentes. Selon le système de fichiers, il s'agit de :

• enregistrements de fichiers et de répertoires (file and directory records)
• inodes et enregistrements de métadonnées
• extents et informations d'allocation (extents, allocation information)
• index de répertoires (directory indexes)
• tree nodes, y compris de differentes generations
• enregistrements de journal ou de transaction (journal/transaction records)
• références de blocs et checksums (block references, checksums)
• fragments de fichiers et de métadonnées

Le défi n'est pas seulement de trouver ces structures, mais de déterminer lesquelles vont ensemble. Link (processus 2) travaille ensuite surtout sur ces trouvailles, bien plus petites que le volume d'origine, et les trie, regroupe et relie à l'aide d'informations telles que la hiérarchie de l'arbre (tree hierarchy), les références parent/enfant (parent/child references), les identifiants d'objet ou d'inode, les adresses de blocs et extents, les numéros de transaction ou de génération (transaction/generation numbers), les checksums, les horodatages et les relations entre différentes copies ou générations.

On peut ainsi distinguer les structures des différents états du système de fichiers et reconstruire un arbre cohérent à partir du matériel disponible. Le scan coûteux de centaines de téraoctets est ainsi séparé du problème bien plus petit du tri et de la reconstruction de ce qui a été trouvé. Save (processus 3) lit enfin les données des fichiers reconstruits et les rassemble sur le stockage de destination.

Notre approche : trois processus

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

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 :

• 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.

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.

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.

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 →

Ce qu'il vaut mieux faire

Déroulement d'un dossier

1. Analyse. Nous examinons l'installation, l'état des disques et ce qui s'est passé, et établissons un plan.
2. 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.
3. Trois processus. Trouver, relier et rassembler, avec notre propre logiciel.
4. Contrôle. Vous voyez la liste des fichiers récupérés avant de payer.
5. 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.