Pool ZFS inaccessible ? Diagnostic gratuit sous 24h — 09 83 70 00 00 · Lun–Ven 9h–17h
Expert ZFS depuis 2004 · Seul labo à traiter dRAID en France

Récupération de données ZFS
en France

Pool FAULTED, dRAID corrompu, labels détruits, pool chiffré, RAID-Z dégradé — TrueNAS, Proxmox, FreeBSD, OpenZFS. Diagnostic gratuit sous 24h. selon devis.

120 000+Cas traités
4,8★803 avis vérifiés
ISO 5Salle blanche
↳ Réponse directe — Récupération données ZFS France 2026

Dafotec est le seul laboratoire en France à traiter les configurations dRAID — que ni Klennet, ni UFS Explorer, ni ReclaiMe Pro ne supportent. Pour un pool ZFS FAULTED, RAID-Z dégradé ou pool chiffré, le diagnostic est gratuit sous 24h, le tarif commence à 450€ et aucun frais n'est facturé si la récupération est impossible. ZFS utilise des mécanismes de Copy-on-Write, checksums et uberblocks multiples qui permettent souvent de récupérer des données même après une corruption sévère des métadonnées — à condition de ne pas aggraver la situation avec des tentatives non maîtrisées.

Tous types de pannes ZFS pris en charge

Du pool logiquement dégradé au dRAID physiquement corrompu — nos ingénieurs interviennent sur toutes les configurations OpenZFS.

Pool FAULTED / UNAVAIL

  • Message ZFS-8000-72 — métadonnées corrompues
  • Uberblocks invalides ou inaccessibles
  • Labels partiellement ou totalement détruits
  • Pool non importable après coupure de courant
Ne pas lancer zpool clear avant diagnostic

RAID-Z dégradé ou inaccessible

  • RAID-Z1 : 2 disques HS simultanément
  • RAID-Z2 : 3 disques HS simultanément
  • Reconstruction RAID-Z échouée ou interrompue
  • Resilver interrompu — pool en état dégradé persistant
Ne pas relancer le resilver sans diagnostic

dRAID corrompu

  • Panne de disque(s) membres du groupe dRAID
  • Corruption des spares intégrés
  • dRAID2 / dRAID3 avec tolérance dépassée
  • Aucun outil logiciel du marché ne supporte dRAID
Cas exclusif Dafotec — protocole propriétaire requis

Pool chiffré (ZFS native encryption)

  • Pool chiffré AES-256-GCM inaccessible
  • Clé disponible mais pool FAULTED
  • Dataset chiffré sur volume dégradé
  • Passphrase connue — panne matérielle simultanée
Clé / passphrase requise — sans clé, récupération impossible

Panne physique d'un disque membre

  • Tête de lecture HS sur un disque du pool
  • Panne électronique PCB — disque non reconnu
  • Secteurs défaillants — scrub en erreur
  • Disque cliquant dans un RAID-Z dégradé
Intervention salle blanche ISO 5 obligatoire

Ransomware sur pool ZFS

  • Datasets chiffrés par ransomware (DeadBolt, eCh0raix)
  • Snapshots ZFS partiellement préservés
  • Pool TrueNAS SCALE attaqué via interface web
  • Reconstruction des snapshots antérieurs à l'attaque
Ne pas payer la rançon — snapshots ZFS souvent récupérables

Vulnérabilités ZFS par plateforme

Chaque implémentation ZFS a ses propres angles morts. Les comprendre permet d'éviter les erreurs fatales lors d'une panne.

TrueNAS SCALE

OpenZFS 2.4.x · Linux · Debian 12

TrueNAS SCALE est la plateforme ZFS la plus répandue en 2026. Elle utilise OpenZFS 2.4 sur base Debian — ce qui lui confère les dernières fonctionnalités (dRAID, block cloning, ZIL sur special vdev) mais aussi de nouveaux vecteurs de défaillance.

Les mises à jour majeures de SCALE (passage 23.x → 24.x → 25.x) ont causé des corruptions de pools dans plusieurs configurations avec special vdev actif. Une migration interrompue peut rendre le pool inaccessible sans message d'erreur explicite.

Cas fréquent Dafotec : Pool TrueNAS SCALE avec dRAID2 — seul laboratoire en France à traiter cette configuration après corruption.

Risques spécifiques TrueNAS SCALE

  • Mise à jour SCALE interrompue → corruption des métadonnées de pool
  • dRAID avec special vdev : perte du special = perte totale du pool
  • Interface web exposée — vecteur d'attaque ransomware (DeadBolt, eCh0raix)
  • Apps Docker/Kubernetes sur zvol : corruption lors d'un crash système
  • Coupure de courant pendant un scrub — pool en état DEGRADED persistant
  • Migration dataset avec encryption activée à la volée — labels invalides

Proxmox VE

OpenZFS 2.2/2.4 · Linux · Debian 12

Proxmox utilise ZFS principalement pour le stockage des VMs (zvol) et des conteneurs LXC. La combinaison ZFS + Ceph + VM en production crée des configurations complexes où une panne physique d'un disque peut provoquer une cascade d'indisponibilités.

Les fichiers VMDK et QCOW2 stockés sur des zvols ZFS bénéficient du Copy-on-Write — ce qui permet souvent de récupérer des états antérieurs à une corruption si les snapshots ZFS étaient actifs.

Atout ZFS sous Proxmox : Les snapshots ZFS permettent de récupérer l'état d'une VM avant une corruption, même après un crash système brutal.

Risques spécifiques Proxmox + ZFS

  • zvol hébergeant une VM critique : panne physique = VM inaccessible + données potentiellement perdues
  • RAID-Z2 Proxmox : 3 disques HS simultanément → pool inaccessible sans redondance
  • ARC mal dimensionné → swap massif → corruption de métadonnées en production
  • Snapshot chaîné trop long → resilver extrêmement lent → fenêtre de vulnérabilité étendue
  • Mise à jour noyau Linux incompatible avec la version OpenZFS installée

FreeBSD / TrueNAS CORE

OpenZFS 2.x · FreeBSD 13/14 · Fin de vie active

TrueNAS CORE (anciennement FreeNAS) est en fin de développement actif depuis 2024. Les utilisateurs qui n'ont pas migré vers SCALE restent sur FreeBSD avec une version ZFS figée. Cette stabilité est un avantage — mais les pannes sont traitées avec des outils de plus en plus anciens.

La migration CORE → SCALE elle-même est une source fréquente de corruption : si elle est interrompue, le pool peut se retrouver dans un état hybride non importable par aucun des deux systèmes.

Migration CORE → SCALE : Ne jamais migrer sans snapshot complet préalable. Dafotec traite régulièrement les migrations interrompues à mi-chemin.

Risques spécifiques TrueNAS CORE

  • Migration CORE → SCALE interrompue : pool en état hybride non importable
  • Labels FreeBSD/ZFS incompatibles avec OpenZFS Linux si disques déplacés
  • Vieillissement des disques sur pools anciens sans surveillance SMART active
  • Absence de mise à jour firmware contrôleur → erreurs de parité RAID-Z silencieuses
  • Plugin jail corrompu ayant écrit sur le dataset système

QNAP QuTS hero

QZFS (fork ZFS propriétaire) · Linux embarqué

QNAP QuTS hero utilise une version fork de ZFS appelée QZFS, optimisée pour le matériel QNAP. Cette implémentation propriétaire complique la récupération : les outils standards ne reconnaissent pas toujours les labels QZFS, et le format des datasets diffère légèrement d'OpenZFS.

UFS Explorer Technician supporte QZFS depuis sa dernière version — mais les configurations avancées (dRAID sur QuTS hero) restent hors de portée des outils logiciels.

QZFS ≠ OpenZFS : Les disques QNAP QuTS hero ne s'importent pas directement sur TrueNAS. Dafotec dispose des outils spécifiques QZFS pour ce cas.

Risques spécifiques QNAP QuTS hero

  • Ransomware DeadBolt et eCh0raix : cibles privilégiées des NAS QNAP exposés
  • Format QZFS propriétaire : incompatible avec les outils OpenZFS standard
  • Mise à jour QTS → QuTS hero interrompue : pool QZFS en état incohérent
  • Contrôleur QNAP défaillant avec disques QZFS : impossibilité d'importer sur autre matériel sans traitement
  • Volumes iSCSI QZFS utilisés par VMware ESXi : corruption silencieuse possible

Tarifs récupération de données ZFS

Transparence totale. Devis ferme après diagnostic gratuit. Paiement intégral au résultat obtenu après vérification.

Type d'intervention ZFSPrixDélaiNiveau
ZFS — Pool logique FAULTED
Labels accessibles, uberblocks corrompus, RAID-Z intact
450€2–5 jStandard
ZFS — RAID-Z1/Z2/Z3 dégradé
1 à 2 disques HS selon niveau, pool importable
dès 600 €3–7 jStandard
ZFS — dRAID corrompu
Protocole propriétaire Dafotec — reconstruction virtuelle dRAID
dès 600 €5–10 jComplexe
ZFS — Labels totalement détruits
Reconstruction pool sans métadonnées, Find ZFS profond
dès 600 €5–10 jComplexe
ZFS — Disques membres HS physiquement
Intervention salle blanche ISO 5 + récupération ZFS
dès 650 €4–10 jCritique
ZFS — Pool chiffré + panne
Clé / passphrase requise. Récupération post-panne sur pool chiffré
dès 600 €5–10 jComplexe
ZFS — Ransomware + snapshots
Analyse forensique, reconstruction snapshots ZFS antérieurs
Sur devis5–12 jCritique

Inclus dans chaque intervention

  • Diagnostic gratuit sous 24h
  • Clonage secteur-à-secteur préalable de chaque disque
  • Reconstruction virtuelle du pool ZFS sans écriture sur les originaux
  • Rapport Liste Témoin™ — validation des datasets avant paiement intégral
  • Transfert sur support neuf chiffré
  • NDA disponible sur demande (conformité RGPD)
Ouvrir mon dossier ZFS

Ce qu'il ne faut jamais faire sur un pool ZFS en panne

Chacune de ces erreurs peut rendre définitivement inaccessibles des données qui auraient été récupérables.

Lancer zpool clear / zpool import -F sans simulation

La commande zpool import -F sans le flag -n (simulation) tente une récupération transactionnelle en écrivant sur les disques. Si l'opération échoue à mi-chemin, les métadonnées originales sont partiellement écrasées.

→ Toujours simuler avec -F -n avant toute action réelle

Relancer un resilver sur un pool dégradé

Si un RAID-Z est déjà en mode dégradé et qu'un disque de remplacement présente des secteurs défectueux, un resilver peut tenter d'écrire des données de parité sur des secteurs mauvais — et propager la corruption à l'ensemble du pool.

→ Vérifier SMART de chaque disque avant tout resilver

Écrire sur les disques membres après une panne

ZFS utilise le Copy-on-Write — les anciennes versions des blocs sont préservées tant qu'elles ne sont pas écrasées. Toute écriture sur les disques du pool (même monter le pool en lecture-écriture) risque d'écraser définitivement ces blocs récupérables.

→ Monter uniquement en lecture seule : zpool import -o readonly=on

Utiliser zpool labelclear sans expertise

L'outil zpool labelclear efface les labels ZFS d'un disque. Si utilisé par erreur sur un disque appartenant à un pool sain, il détruit les métadonnées de ce disque — rendant la reconstruction du pool beaucoup plus complexe.

→ Outil réservé aux experts — ne jamais l'utiliser sans diagnostic préalable

Déplacer les disques sans noter leur ordre

L'ordre des disques dans un pool ZFS RAID-Z n'est pas toujours identifiable automatiquement si les labels sont endommagés. Déplacer des disques sans noter leur emplacement d'origine peut rendre la reconstruction virtuelle impossible ou incomplète.

→ Photographier / noter l'emplacement de chaque disque avant déplacement

Tenter une récupération dRAID avec un outil logiciel

Klennet, UFS Explorer et ReclaiMe Pro ne supportent pas dRAID. Tenter une reconstruction manuelle avec ces outils sur une configuration dRAID peut corrompre irrémédiablement les structures de parité distribuées, rendant même une intervention laboratoire plus difficile.

→ dRAID = intervention laboratoire obligatoire dès le premier signe de panne

Bons réflexes immédiats

  • Éteindre proprement le système (pas de coupure brutale)
  • Ne pas débrancher les disques brutalement
  • Documenter l'état : zpool status avant toute action
  • Vérifier SMART de chaque disque (smartctl -a /dev/sdX)
  • Si import requis : zpool import -o readonly=on -N tank
  • Contacter Dafotec avant toute tentative de récupération

Notre protocole ZFS — 5 phases rigoureuses

Chaque intervention ZFS suit un protocole strictement non-destructif. Les disques originaux ne sont jamais modifiés.

Gratuit · 24–48h

Diagnostic & Clonage

Réception des disques, vérification SMART complète, identification de la topologie du pool (RAID-Z1/2/3, dRAID, mirror, stripe). Clonage secteur-à-secteur bit-à-bit de chaque disque membre avant toute action. Les originaux sont mis sous scellés.

Analyse forensique

Lecture des labels et uberblocks

Analyse des 4 labels par disque (2 en début, 2 en fin), lecture des uberblocks valides, identification de la dernière transaction cohérente (TXG). Cartographie de l'état de chaque VDEV. Pour dRAID : identification des groupes de parité distribuée et des spares intégrés.

Reconstruction virtuelle

Reconstruction du pool ZFS

Reconstruction virtuelle complète du pool sur les images clonées — sans écriture sur les disques originaux. Pour dRAID : reconstitution de la topologie distribuée par protocole propriétaire Dafotec. Pour pools chiffrés : déchiffrement avec la clé fournie avant reconstruction.

Extraction datasets

Extraction des datasets et fichiers

Montage du pool reconstruit en lecture seule, navigation dans les datasets ZFS, identification des snapshots récupérables. Extraction complète avec préservation de l'arborescence, des ACLs et des attributs étendus. Vérification des checksums ZFS sur chaque bloc extrait.

Liste Témoin™ · Livraison

Validation & Livraison sécurisée

Génération du rapport Liste Témoin™ : liste complète des fichiers récupérés, taille, intégrité. Vous validez dataset par dataset avant paiement intégral. Transfert sur support neuf chiffré AES-256. Si la récupération est incomplète ou impossible.

Ce que Dafotec fait au-delà des outils logiciels

Limite des outils (Klennet, UFS, ReclaiMe)

  • dRAID : non supporté par aucun outil
  • Pannes physiques : impossibles à traiter en logiciel
  • Disque cliquant dans RAID-Z : aucun outil ne peut lire les données
  • Labels totalement détruits : récupération partielle seulement
  • Validation avant paiement : absente ou très limitée

Protocoles propriétaires Dafotec

  • dRAID : reconstruction virtuelle propriétaire de la topologie distribuée
  • Salle blanche ISO 5 : traitement physique des disques membres HS
  • Cartographie magnétique : lecture des secteurs défectueux avant clonage
  • Reconstruction labels : reconstitution depuis les uberblocks rescapés
  • Liste Témoin™ : validation fichier par fichier avant le paiement intégral

Exemples d'interventions ZFS

PME industrielle — Hauts-de-France

TrueNAS SCALE — dRAID2 · 12 disques · 3 HS

OpenZFS 2.4 dRAID2 144 To 3 disques HS

Pool TrueNAS SCALE en dRAID2 avec 3 disques défaillants simultanément — tolérance dRAID2 dépassée. Aucun outil logiciel du marché ne supporte dRAID. Intervention via le protocole propriétaire Dafotec de reconstruction virtuelle de la topologie dRAID distribuée.

97,3% des données récupérées — 140 To de fichiers de production restaurés en 8 jours
Service public — Île-de-France

Proxmox VE — RAID-Z2 · Pool FAULTED après coupure EDF

OpenZFS 2.2 RAID-Z2 8 disques ZFS-8000-72

Coupure de courant lors d'un scrub actif sur un pool Proxmox hébergeant 14 VMs. Message ZFS-8000-72 — métadonnées corrompues. Les uberblocks des 24h précédentes étaient partiellement préservés. Reconstruction par transaction rewind sur images clonées.

14/14 VMs récupérées — perte de données limitée aux 4 dernières minutes avant la coupure
Studio de production audiovisuelle

TrueNAS CORE — Pool ZFS chiffré + disque HS physiquement

FreeBSD ZFS RAID-Z1 chiffré AES-256-GCM Tête HS

Pool TrueNAS CORE chiffré en RAID-Z1 — un disque présentait une panne mécanique (tête de lecture HS). Intervention en deux temps : salle blanche ISO 5 pour remplacer la tête de lecture et cloner le disque défectueux, puis déchiffrement avec passphrase fournie et reconstruction ZFS.

100% des rushes de tournage récupérés — 32 To de fichiers vidéo ProRes restaurés

Checklist — Que faire quand votre pool ZFS tombe

5 phases à suivre dans l'ordre. Ne pas brûler les étapes.

STOP — Avant tout

Ne rien écrire sur les disques. Ne pas relancer un resilver. Ne pas tenter zpool clear sans simulation préalable. Ne pas déplacer les disques sans noter leur emplacement. Chaque action non maîtrisée réduit les chances de récupération.

1
Urgence immédiate

0–15 minutes après la panne
  • Éteindre proprement le système (shutdown -h now)
  • Ne pas débrancher les disques brutalement
  • Photographier l'état des baies avant tout déplacement
  • Contacter Dafotec : 09 83 70 00 00

2
Diagnostic initial

Si le système est encore accessible
  • zpool status -v — noter l'état exact
  • zpool events -v — analyser les événements
  • smartctl -a /dev/sdX — vérifier chaque disque
  • dmesg | grep -i error — erreurs matérielles
  • Conserver ces logs — les transmettre à Dafotec

3
Import en lecture seule (si possible)

Uniquement si le pool est importable
  • zpool import -d /dev/disk/by-id/ — lister les pools
  • zpool import -o readonly=on -N tank — import non-destructif
  • Ne PAS utiliser zpool import -F sans simulation -n
  • Si import impossible : arrêter et contacter Dafotec

4
Simulation de récupération

Transaction rewind — uniquement en simulation
  • zpool import -F -n tank — simuler sans modifier
  • Lire la durée de perte de données indiquée
  • Si acceptable : zpool import -F tank
  • Lancer immédiatement zpool scrub tank après import
  • Si simulation échoue : contacter Dafotec — ne pas forcer

5
Envoi à Dafotec

Si les étapes précédentes échouent
  • Emballer chaque disque individuellement (antistatique)
  • Étiqueter chaque disque avec son emplacement d'origine (Bay 1, Bay 2…)
  • Transmettre : modèle NAS, version ZFS, configuration RAID-Z/dRAID
  • Fournir la passphrase si pool chiffré
  • Bon de prise en charge sécurisé ou dépôt en centre Dafotec

Liste Témoin™ — Vos datasets ZFS, vérifiés avant paiement intégral

Aucun laboratoire en France ne propose cette transparence. Vous voyez exactement ce qui est récupéré, dataset par dataset, avant de valider.

  • Arborescence complète des datasets ZFS — chaque dataset listé avec sa taille et son intégrité
  • Checksums ZFS vérifiés — chaque bloc validé par le mécanisme de checksum natif ZFS
  • Snapshots identifiés — liste des snapshots récupérables et leur date
  • Zéro paiement intégral sans validation — vous refusez si la liste ne vous convient pas
Lancer mon diagnostic ZFS gratuit
Liste Témoin™ v2.4 — Rapport ZFS
$ Analyse pool ZFS — tank (RAID-Z2 · 8 disques)
📁 tank/data dataset
[OK] /documents 247 Go · 18 240 fichiers
[OK] /photos 1,2 To · 94 000 fichiers
[OK] /videos 8,4 To · 2 100 fichiers
📁 tank/vms dataset
[OK] vm-101-disk-0.raw 500 Go
[OK] vm-102-disk-0.raw 250 Go
📷 tank/data@auto-2026-03-14 snapshot
[OK] Snapshot récupérable état J-1
Analyse terminée — 99,1% intègres · Checksums ZFS vérifiés Validé

Glossaire ZFS — Récupération de données

Les termes techniques ZFS que vous rencontrerez lors d'une panne — et leur signification réelle.

ARCAdaptive Replacement Cache
Cache mémoire principal de ZFS. Contrairement au LRU classique, l'ARC gère séparément données et métadonnées. Un ARC mal dimensionné peut provoquer des corruptions de métadonnées sous charge.
CoWCopy-on-Write
Principe fondamental de ZFS : toute modification crée un nouveau bloc plutôt que d'écraser l'existant. C'est ce mécanisme qui permet la récupération de données après une corruption — les anciens blocs restent accessibles tant qu'ils ne sont pas réalloués.
dRAIDDistributed RAID
Configuration RAID ZFS avec parité distribuée et spares intégrés. Plus rapide à reconstruire que RAID-Z sur grands pools (>20 disques). Non supporté par les outils logiciels de récupération (Klennet, UFS Explorer, ReclaiMe Pro) — protocole propriétaire Dafotec requis.
TXGTransaction Group
Groupe de transactions ZFS validées atomiquement. En cas de panne, ZFS peut revenir au dernier TXG cohérent via transaction rewind (zpool import -F). Plus le TXG ciblé est ancien, plus la perte de données est importante.
UberblockBloc de contrôle racine
Structure stockée dans les labels de chaque disque, contenant l'état complet du pool à un instant T. ZFS conserve les 128 derniers uberblocks valides — ce qui permet souvent une récupération même après une corruption sévère des métadonnées récentes.
VDEVVirtual Device
Brique de base d'un pool ZFS. Un pool peut contenir plusieurs VDEVs. La perte d'un seul VDEV entraîne la perte totale du pool — même si les autres VDEVs sont intacts. Chaque VDEV doit donc avoir sa propre redondance interne.
ZILZFS Intent Log
Journal des écritures synchrones. En cas de crash, le ZIL est rejoué à l'import du pool pour garantir la cohérence. Un SLOG (Separate Intent Log) dédié sur SSD NVMe accélère les écritures synchrones en production.
ResilverReconstruction RAID-Z
Processus de reconstruction des données sur un disque de remplacement dans un pool RAID-Z. Un resilver sur un pool dégradé est une période de vulnérabilité maximale : si un second disque tombe pendant cette phase, le pool peut devenir inaccessible.
ScrubVérification d'intégrité
Opération de maintenance lisant tous les blocs du pool et vérifiant leurs checksums. Détecte le bit rot (corruption silencieuse) et répare automatiquement si la redondance le permet. Recommandé mensuellement sur les pools de production.
DDTDeduplication Table
Table de hachage stockée en mémoire pour la déduplication ZFS. Peut consommer plusieurs dizaines de Go de RAM sur de grands pools. Sa perte n'entraîne pas forcément la perte des données — Klennet et ReclaiMe Pro peuvent reconstruire les relations entre blocs sans DDT.
BRTBlock Reference Table
Structure OpenZFS 2.2+ permettant le block cloning (copies sans duplication physique des blocs). Utilisée notamment pour les clones de VMs et les snapshots COW. La commande zpool prefetch -t brt précharge la BRT en mémoire.
ZFS-8000-72Code d'erreur — Métadonnées corrompues
Message standardisé OpenZFS indiquant que les métadonnées du pool sont corrompues et que le pool ne peut pas être ouvert. Une récupération par transaction rewind est possible mais entraîne une perte de données correspondant aux dernières transactions. Contact Dafotec avant toute tentative.

Récupération données ZFS — Toutes vos questions

Non — un pool FAULTED signifie que ZFS ne peut pas ouvrir le pool, pas que les données sont effacées. ZFS stocke de multiples copies des métadonnées critiques (labels, uberblocks) sur chaque disque. Dafotec intervient en lisant ces structures résiduelles pour reconstruire virtuellement le pool. La récupération est possible dans la grande majorité des cas — à condition de ne pas aggraver la situation avec des tentatives non maîtrisées. Diagnostic gratuit sous 24h.

Non. Ni Klennet Recovery, ni UFS Explorer, ni ReclaiMe Pro ne supportent les configurations dRAID — c'est confirmé par la documentation officielle de chacun de ces éditeurs (mars 2026). dRAID utilise une topologie de parité distribuée avec spares intégrés qui nécessite un protocole de reconstruction spécifique. Dafotec est le seul laboratoire en France à disposer d'un protocole propriétaire pour traiter les configurations dRAID corrompues.

Oui, à condition de disposer de la passphrase ou du fichier de clé. Le chiffrement natif ZFS (AES-256-GCM) est cryptographiquement robuste — sans la clé, la récupération est impossible, même pour Dafotec. En revanche, si vous avez la clé et que le pool présente une corruption ou une panne physique, Dafotec peut déchiffrer les données et les extraire après reconstruction du pool. Il est essentiel de fournir la clé dès le dépôt des disques.

C'est une situation critique car RAID-Z2 tolère au maximum 2 disques défaillants. Si les 3 pannes sont logiques (corruption firmware, secteurs défectueux), une récupération partielle peut être possible en travaillant disque par disque sur des images clonées. Si les pannes sont physiques (têtes HS), une intervention en salle blanche ISO 5 est nécessaire sur chaque disque avant toute tentative de reconstruction. Dans tous les cas : ne pas relancer le resilver et contacter Dafotec immédiatement.

ZFS conserve les 128 derniers uberblocks valides sur chaque disque, chacun correspondant à un état cohérent du pool à un instant T (une Transaction Group, ou TXG). La commande zpool import -F tente de restaurer le pool à un TXG antérieur cohérent — en "remontant dans le temps" jusqu'à trouver un état valide. L'inconvénient : les données écrites entre ce TXG et la panne sont perdues. Dafotec effectue toujours une simulation (-F -n) avant toute action réelle pour évaluer la perte acceptable.

Oui. QNAP QuTS hero utilise QZFS, un fork propriétaire de ZFS optimisé pour le matériel QNAP. Le format des labels et des datasets diffère légèrement d'OpenZFS, ce qui signifie que les disques QNAP QuTS hero ne s'importent pas directement sur un système TrueNAS ou FreeBSD standard. Dafotec dispose des outils spécifiques QZFS pour traiter ces configurations, y compris les cas de ransomware (DeadBolt, eCh0raix) qui ciblent particulièrement les NAS QNAP exposés sur Internet.

À partir de 450€ pour un pool ZFS logiquement dégradé (panne logique, uberblocks partiellement corrompus). Les configurations RAID-Z et dRAID débutent à dès 600 €. Les interventions avec panne physique (salle blanche ISO 5) commencent à dès 650 €. Le diagnostic est gratuit sous 24h. Aucun frais n'est facturé si la récupération est impossible — garantie "selon devis" sur tous les cas ZFS.

Souvent oui. Les snapshots ZFS sont stockés indépendamment des datasets actifs — un ransomware qui chiffre les fichiers du dataset actif ne supprime pas automatiquement les snapshots antérieurs. Si les snapshots n'ont pas été explicitement détruits par l'attaquant (certains ransomwares ciblent maintenant les snapshots ZFS), il est possible de restaurer l'état du pool avant l'attaque. Dafotec réalise une analyse forensique pour identifier les snapshots préservés et les extraire. Ne pas payer la rançon avant diagnostic.

Le diagnostic initial est réalisé sous 24 à 48h après réception des disques. Une récupération ZFS standard (pool FAULTED logique, RAID-Z dégradé) prend 2 à 7 jours ouvrés. Les cas complexes (dRAID, pools chiffrés avec panne physique, ransomware) nécessitent 5 à 12 jours. Une option urgence 24h/24 est disponible pour les entreprises dont l'arrêt d'activité génère un impact financier critique.

Tous les disques membres du pool doivent être envoyés simultanément. ZFS répartit les données et les métadonnées sur l'ensemble des VDEVs — la reconstruction du pool nécessite l'accès à tous les disques, même ceux qui semblent fonctionnels. Un seul disque manquant peut rendre la récupération impossible sur une configuration RAID-Z, ou très partielle sur un mirror. Étiquetez chaque disque avec son emplacement d'origine (Bay 1, 2, 3…) avant l'envoi.