Récupération de données
Récupération de données dans le Rhône
Dans le Rhône, arrêtez les imports ZFS. Conservez l’ordre des vdevs, les étiquettes, les uberblocks, les groupes de transactions, les jeux de données, les instantanés, les SLOG et les clés. Le laboratoire clone chaque membre, reconstruit la topologie sur des copies et valide les données sans écrire sur les originaux.
Diagnostic et devis
Diagnostiquer le pool ZFS sans modifier les sources
Le diagnostic distingue le membre physiquement défaillant, le vdev incomplet, l'uberblock incohérent et la clé indisponible. L'ordre des acquisitions dépend de la topologie du pool et des groupes de transactions encore lisibles.
Les supports sont examinés pour dresser l’inventaire technique: les vdevs, les étiquettes ZFS, les uberblocks, les groupes de transactions, les jeux de données, les instantanés, les SLOG, les caches L2ARC et les clés de chiffrement. Cette lecture replace la panne, les sauvegardes, les copies et les essais dans une chronologie commune.
- Disques durs concernés: vdevs, labels ZFS, ainsi que des données historiques du pool ZFS
- SSD internes ou externes concernés: uberblocks, transaction groups, avec les composants actifs de ZFS
- Disques externes utilisés dans le Rhône pour les sauvegardes, les exports ou les copies hors ligne du pool ZFS
- Serveurs physiques concernés: jeux de données, snapshots, ainsi que la configuration principale de ZFS
Attention
Éviter les écritures qui aggravent l’état du pool ZFS
- Ne redémarrez pas le pool ZFS pour tester
- Sur les supports d'origine, évitez de forcer zpool import, resilver, scrub ou clear sur les originaux
- Ne modifiez aucun des composants concernés: vdevs ni labels ZFS
- Ne supprimez aucun des composants concernés: uberblocks ou transaction groups
Dans le Rhône, toute opération susceptible de forcer zpool import, resilver, scrub ou clear sur les originaux attend l'acquisition. Les supports et versions de ZFS restent séparés jusqu'à leur rapprochement.
Comment ça marche
Du support figé au résultat vérifié pour ZFS
- Exportez le pool uniquement s'il répond encore sans erreur, puis arrêtez l'hôte et empêchez tout nouvel import. Relevez le message ZFS, l'heure du dernier accès réussi et les commandes déjà tentées.
- Inventoriez séparément chaque support et ses composants: les vdevs, les étiquettes ZFS, les uberblocks, les groupes de transactions, les jeux de données, les instantanés, les SLOG, les caches L2ARC et les clés de chiffrement. Leur provenance et leur rôle restent attachés à chaque copie.
- Le laboratoire qualifie chaque membre du pool avant de lire les étiquettes et les uberblocks. Les disques stables sont imagés dans leur ordre d'origine; seule la panne d'un disque dur mécanique peut justifier une ouverture en salle blanche.
- Chaque membre lisible est cloné avec son numéro de baie, son GUID et son rôle supposé. La topologie ZFS est reconstruite à partir de ces images; les disques sources ne sont jamais importés dans le pool de travail.
Nos expertises
Supports et composants examinés autour du pool ZFS
Préparer le devis
Préparer le pool ZFS sans relancer les écritures
L'ordre des baies, les GUID et la séparation entre les vdevs, le SLOG et le cache doivent être préservés avant le transport des membres ZFS.
- Arrêter le pool ZFS et ses tâches automatiques
- Noter l'incident et les essais déjà réalisés
- Identifier les versions, les systèmes et les machines
- Photographier et étiqueter les supports
- À conserver: les vdevs et les étiquettes ZFS
Notre expertise
Reconstruire la topologie ZFS à partir des membres clonés
Dans le Rhône, le pool ZFS ne se résume pas à un fichier isolé: les vdevs, les étiquettes ZFS, les uberblocks et les groupes de transactions portent des relations qui déterminent la cohérence de l'ensemble.
Un incident peut préserver la lisibilité de certains jeux de données tout en dissociant les instantanés, les SLOG, les caches L2ARC ou les clés de chiffrement. Un état récent n'est donc pas automatiquement le plus complet ni le plus sûr.
- ZFS
- Figer les écritures
- Vdevs
- Conserver la source
- Transaction groups
- Comparer les états
- Validation
- Ouvrir sur des copies
Prise en charge
Préparer le pool ZFS dans le Rhône
Le Rhône est une zone desservie; Datastrophe n'y déclare ni agence ni laboratoire. Les membres ZFS sont acheminés vers le laboratoire, où l'équipe qualifie directement les supports, recompose la topologie et contrôle les jeux de données retenus.
Si un membre du pool claque, ralentit ou disparaît, laissez l'ensemble hors tension. Photographiez les baies, numérotez les disques et notez le rôle des SLOG avant toute nouvelle tentative d'importation.
Vdevs et uberblocks à préserver
Relier les dépendances du pool ZFS
Le périmètre technique couvre notamment les vdevs, les étiquettes ZFS, les uberblocks, les groupes de transactions, les jeux de données, les instantanés, les SLOG, les caches L2ARC et les clés de chiffrement. Chaque pièce garde sa provenance, son support et sa période.
La copie la plus récente de ZFS peut être moins cohérente si une panne multiple ou un import partiel a laissé les vdevs, les étiquettes et les groupes de transactions en désaccord. Les identifiants, les dates et les journaux servent à choisir une base de travail.
- Vdevs Conserver le rôle et la provenance.
- Labels ZFS Documenter la version observée.
- Transaction groups Comparer les états disponibles.
Carte
Orientation dans le Rhône selon le système et les médias
FAQ
Questions fréquentes sur le pool ZFS
Faut-il redémarrer le pool ZFS pour tester?
Non. Un nouvel import peut sélectionner un autre uberblock, rejouer des transactions ou marquer un membre défaillant. Le pool reste hors ligne jusqu'au clonage de chaque disque disponible.
Un composant lisible de ZFS garantit-il un ensemble complet?
Non. Les vdevs, les étiquettes ZFS, les uberblocks et les groupes de transactions doivent correspondre. La validation porte sur des éléments ouverts depuis une copie.
Peut-on supprimer les anciens fichiers du pool ZFS?
Non. Un ancien instantané ou un groupe de transactions antérieur peut contenir la seule version cohérente du jeu de données. Les destructions et les nettoyages attendent l'acquisition des membres.
Pourquoi conserver les journaux de ZFS?
Ils documentent les opérations, leur ordre et leur période. Ils complètent les jeux de données et les instantanés sans remplacer les données elles-mêmes.
Les métadonnées du pool ZFS peuvent-elles être recréées automatiquement?
Pas sur les sources. Dans le Rhône, leur structure est relevée sur duplication avant toute reconstruction de SLOG et L2ARC ou clés de chiffrement.
Diagnostic et devis
Faire qualifier le pool ZFS avant toute remise en service
Indiquez l'ordre des disques, la composition des vdevs, les SLOG, les caches, les clés disponibles et la dernière importation réussie. Ces repères guident la recherche d'un groupe de transactions cohérent sans annoncer des jeux de données encore non vérifiés.