Récupération de données
Récupération de données dans les Alpes-Maritimes
Dans les Alpes-Maritimes, arrêtez les écritures ZFS. Conservez les disques, les vdevs, les GUID, les étiquettes, les uberblocks, les jeux de données, les instantanés et les clés. Le laboratoire acquiert les supports, reconstruit la topologie et valide les fichiers sur des copies sans forcer l’import du pool source.
Diagnostic et devis
Diagnostiquer ZFS sans forcer l'import du pool
Le diagnostic distingue une panne mécanique, un défaut d'interface, un membre manquant, un contrôleur incohérent, des étiquettes endommagées, des uberblocks divergents, un vdev incomplet et des clés absentes. Ces causes se combinent parfois, mais elles ne justifient pas la même lecture ni la même reconstruction.
Les quatre zones d'étiquettes et les uberblocks sont relevés sur chaque copie afin d'identifier le GUID du pool, les GUID des vdevs, la valeur ashift, les groupes de transactions et l'historique. L'ordre physique reste associé aux identifiants pour éviter qu'une permutation ne soit interprétée comme la topologie d'origine.
- Disques durs membres de vdevs mirror, RAIDZ ou special
- SSD et NVMe utilisés comme données, SLOG, L2ARC ou special allocation class
- Serveurs hébergeant pool, cachefile, historique et clés
- NAS et appliances ZFS avec topologie et versions propres
Attention
Éviter import forcé, scrub et resilver
- Ne forcez pas l'import du pool source
- Ne lancez pas scrub ou resilver avant acquisition
- Ne remplacez, détachez ou effacez aucun membre
- Ne modifiez pas les labels ni le cachefile original
Un import ou une réécriture peut sélectionner une mauvaise génération et transformer les métadonnées encore disponibles. Les membres sont d'abord acquis séparément, puis les topologies sont testées sur des copies contrôlées.
Comment ça marche
Des membres figés aux jeux de données ZFS validés
- Stoppez applications, partages, réplications, imports automatiques, scrubs et resilvers. N'exécutez pas zpool import -f, rewind, replace, detach, clear, labelclear ou écriture. Notez l'heure, les erreurs, la version OpenZFS, le système et toutes les commandes déjà tentées.
- Inventoriez chaque membre sans changer son port ni son identité. Conservez les GUID, les étiquettes, les uberblocks, la valeur ashift, la topologie, le cachefile, l'historique, les propriétés, les jeux de données, les zvols, les snapshots, les signets, les clés de chiffrement, les fichiers de configuration et les sauvegardes disponibles.
- Le laboratoire qualifie la stabilité physique de chaque disque et interface. Un HDD instable, un SSD absent, un contrôleur défaillant, un vdev incomplet et une corruption de métadonnées imposent des lectures différentes. La salle blanche reste réservée à un HDD mécanique qui doit être ouvert.
- Si les supports répondent, des images bit à bit ou copies protégées sont créées séparément. Les erreurs, décalages et zones instables sont journalisés. Les originaux sont ensuite retirés des essais afin que les scans de labels, imports en lecture seule et reconstructions portent sur des duplications.
Nos expertises
Supports et composants examinés pour ZFS
Préparer le devis
Préparer les membres sans importer le pool
La préparation doit préserver les métadonnées et l'ordre des membres. Toute commande d'import ou de réparation est différée jusqu'à la création de copies.
- À arrêter: les applications, les partages, les imports et les réplications
- À noter: les messages, l’heure de la panne et les commandes déjà tentées
- À identifier: la version d’OpenZFS, le système d’exploitation, le pool et le nom d’hôte
- Étiqueter chaque baie, port, disque, spare et ancien membre
- À conserver: les SLOG, les caches L2ARC et les vdevs spéciaux avec leur rôle
Notre expertise
Une méthode centrée sur la topologie ZFS
ZFS protège les données par sommes de contrôle et redondance, mais sa cohérence dépend de la topologie et des métadonnées réparties sur les membres. Un disque lisible isolé n'offre pas nécessairement une vue complète. Le diagnostic commence par l'identification de chaque rôle et génération.
Les commandes déjà lancées sont consignées car un import forcé, un rewind, un scrub ou un resilver peut changer l'état observable. Les heures et messages aident à séparer la panne initiale des modifications produites pendant les tentatives de remise en service.
- Arrêt
- À suspendre: imports et écritures
- Topologie
- À conserver: GUID et vdevs
- Copies
- Scanner hors des sources
- Validation
- À contrôler: jeux de données et fichiers
Prise en charge
Préparer un pool ZFS depuis les Alpes-Maritimes
Cette page accompagne les demandes issues des Alpes-Maritimes sans inventer d'établissement local. Le territoire précise le parcours du dossier; le diagnostic et les opérations sont réalisés selon la nature du pool, les supports disponibles et les accès légitimes.
Laissez l'appliance ou le serveur arrêté. Étiquetez chaque baie, chaque port, chaque disque, chaque ancien membre, chaque disque de secours, chaque SLOG, chaque cache ou chaque vdev spécial. Joignez les messages, la version d'OpenZFS, le résultat antérieur de la commande zpool status, le cachefile et la chronologie des essais.
Topologie ZFS, membres et propriétés à préserver
Relier membres, métadonnées, snapshots et clés
La récupération couvre les membres de données, les miroirs, les groupes RAIDZ, les vdevs spéciaux, le SLOG, le cache, le cachefile, l'historique, les jeux de données, les zvols, les snapshots, les signets et les clés. Leur provenance reste attachée à chaque image afin de tester des combinaisons sans perdre le contexte.
Une redondance n'est pas une sauvegarde et un snapshot n'est pas une copie indépendante si le pool est perdu. Les réplications et exports externes sont donc inventoriés séparément, avec leurs GUID, dates et derniers transaction groups cohérents.
- Membres À conserver: les GUID, les rôles, les ports et les générations.
- Métadonnées Analyser les étiquettes, les uberblocks et les groupes de transactions.
- Jeux de données À préserver: les propriétés, les instantanés et les signets.
Carte
Orientation dans les Alpes-Maritimes selon le pool
FAQ
Questions fréquentes sur ZFS et la récupération
Faut-il forcer zpool import?
Non sur les membres sources. Un import forcé ou un rewind peut sélectionner et écrire une génération différente. Les disques sont acquis avant de tester ces options sur des duplications.
Un scrub peut-il réparer le pool?
Il vérifie et réécrit selon la redondance disponible, ce qui sollicite tous les membres. Sur un ensemble instable ou incomplet, il est différé jusqu'à l'acquisition et l'analyse de la topologie.
Peut-on remplacer immédiatement le disque absent?
Pas avant d'avoir identifié et copié les membres. Le replace déclenche un resilver et modifie le pool. L'ancien disque, même instable, peut encore contenir une génération utile.
Les snapshots suffisent-ils comme sauvegarde?
Non s'ils résident uniquement dans le même pool. Ils offrent des générations logiques, mais restent dépendants des vdevs. Les réplications ou copies externes sont conservées séparément.
Diagnostic et devis
Faire qualifier le pool avant toute reconstruction
Décrivez la topologie, les membres, les versions, les instantanés, les clés, les symptômes et les essais. Le diagnostic détermine ensuite les acquisitions, les imports de travail et les validations possibles, puis sert de base au devis sans annoncer de résultat avant examen.