RAID 5, RAID 6 ou ZFS Multiple Drive Drop : récupération d'une baie Synology, QNAP ou TrueNAS en panne sans détruire la parité¶

Audition d'un Synology DiskStation, d'une série QNAP TS, d'un serveur TrueNAS ou de Linux mdadm Le serveur de stockage émet un bip continu tout en signalant Volume en panne, Pool dégradé/en panne ou Plusieurs lecteurs déconnectés est une urgence de stockage à enjeux élevés. Lorsqu'un seul disque tombe en panne RAID 5, RAID hybride Synology (SHR-1), ou ZFS RAIDZ1 pool, la baie fonctionne sans redondance (degraded state), reconstruisant les blocs manquants à la volée en lisant chaque disque restant en parallèle. Si un deuxième lecteur tombe hors ligne quelques heures plus tard ou génère une erreur de lecture irrécupérable (URE) à mi-chemin d'une reconstruction sur un disque de remplacement, le calcul de parité échoue et le pool de stockage est complètement hors ligne. Les administrateurs paniqués détruisent souvent des téraoctets de données récupérables dans les soixante secondes suivantes en cliquant sur Initialiser, recréant ainsi la baie avec mdadm --create, ou forcer une reconstruction en ligne immédiate sur un matériel défaillant. Si votre carte contrôleur RAID matériel elle-même est morte plutôt que les disques, passez à Mort de la carte contrôleur RAID, importation de configuration étrangère et raison pour laquelle vous ne devez jamais initialiser les disques; si un disque dur individuel clique ou refuse de démarrer, consultez panne de disque dur et récupération de données ou Baie RAID NAS dégradée, panne de plusieurs disques et récupération ZFS/Btrfs. Si cette panne de stockage désactive l’imagerie médicale hospitalière (PACS), une répartition d'urgence ou une infrastructure de sécurité des personnes, appelez votre numéro d'urgence local (911 aux États-Unis et au Canada, 112 dans toute l'Union européenne, 999 au Royaume-Uni) ou consultez notre annuaire des numéros d'urgence.

Fais ça maintenant¶

1. ARRÊTEZ et NE cliquez PAS sur "Initialiser", "Créer un pool", "Réparer" ou exécuter mdadm --create sur les disques déposés : en cliquant sur Initialiser dans Synology DSM ou QNAP QTS, ou en exécutant mdadm --create sous Linux, écrit de nouveaux superblocs et commence à remettre à zéro les bandes de parité sur tous les disques membres. Un disque tombé tient généralement toujours la route 99.99% de vos fichiers intacts, uniquement marqués comme désynchronisés par son compteur d'événements.
2. Éteignez proprement le NAS ou le serveur (ou coupez l'alimentation s'il est en cours de reconstruction sur les lecteurs en cliquant) pour geler les compteurs d'événements : Chaque seconde, la baie reste en ligne dans un état partiellement dégradé, le système d'exploitation incrémente le superbloc Update Time et Events sur les disques survivants tandis que le disque supprimé reste gelé à un numéro d'événement plus ancien. Si le NAS tente une reconstruction automatique sur un disque comportant des secteurs défectueux, continuer à lire ce disque peut retirer le revêtement du plateau magnétique (head crash).
3. Étiquetez chaque emplacement de baie de lecteur avec un marqueur physique ou une bande (Bay 1, Bay 2, Bay 3, Bay 4) avant de faire glisser un plateau : sous Linux mdadm, LVM2, et ZFS suivre l'ordre des lecteurs par UUID à l'intérieur de chaque superbloc de partition, les anciens contrôleurs matériels et le manuel dmsetup les reconstructions de table nécessitent l'ordre physique exact des emplacements (0, 1, 2, 3...).
4. Ne tentez jamais une récupération, un assemblage forcé ou fsck directement sur les disques des membres d'origine ; cloner chaque lecteur bit par bit en utilisant ddrescue premier : avant de courir mdadm --assemble --force ou zpool import -F, connectez chaque disque membre à un poste de travail Linux via SATA/SAS direct (jamais un pont USB bon marché qui cache SMART ou SCT ERC timeouts) et clonez-le avec ddrescue sur des disques de rechange sains ou des fichiers image.
5. Forcer l'assemblage du tableau cloné strictement en mode LECTURE SEULE (--readonly ou -o readonly=on) : Lors de l’assemblage mdadm les tableaux dont les compteurs d'événements se sont éloignés lors d'une chute simultanée de plusieurs lecteurs réussissent toujours --readonly (mdadm --assemble --force --readonly /dev/md0 ...). En mode lecture seule, ni mdadm, LVM2, ext4, Btrfs, ni ZFS peut écraser les bandes de parité ou rejouer un journal destructeur.
6. Copiez vos données les plus critiques sur un disque de sauvegarde externe indépendant immédiatement une fois montés en lecture seule : évacuez d'abord vos documents, bases de données, machines virtuelles et photos sur un disque séparé, puis effacez et testez les disques à partir de zéro.

Arbre de décision : triage d'urgence des pools RAID multi-disques et ZFS¶

Utilisez cet organigramme pour déterminer si votre baie a subi une perte de délai logique (TLER / ERC incompatibilité), une véritable panne de secteur défectueux sur plusieurs disques lors de la reconstruction ou un groupe de transactions ZFS (TXG) défaut :

flowchart TD
    Start["Le pool RAID 5 / RAID 6 / SHR / ZFS est tombé en panne après la chute de plus de 2 disques"] --> StopIO["ARRÊTEZ toutes les reconstructions et éteignez immédiatement le NAS"]
    StopIO --> Label["Étiquetez chaque plateau de disque par numéro de baie (baie 1 à baie N)"]
    Label --> ConnectLinux["Connectez les lecteurs membres à l'hôte de secours Ubuntu Linux via Direct SATA / HBA"]

    ConnectLinux --> CheckSmart["Inspecter SMART et les métadonnées en lecture seule : smartctl -a / mdadm --examine / zdb -l"]
    CheckSmart --> PhysicalHealth{"Y a-t-il des lecteurs qui cliquent, refusent de tourner ou se déconnectent dans dmesg ?"}

    PhysicalHealth -->|"Oui : panne mécanique/tête sur plus de 2 disques en RAID 5"| Cleanroom["ARRÊTER d'alimenter les disques -> Envoyer au laboratoire de récupération de données en salle blanche"]
    PhysicalHealth -->|"Non : tous les lecteurs démarrent (peut avoir des secteurs défectueux en attente ou des délais d'attente)"| CloneAll["Cloner chaque lecteur membre à l'aide de GNU ddrescue (Forward Pass -> Reverse Scrape)"]

    CloneAll --> DisconnectOrig["Déconnectez les disques d'origine et travaillez strictement sur des disques/images clonés"]
    DisconnectOrig --> ArrayType{"Quelle architecture de stockage est utilisée ?"}

    ArrayType -->|"Synology DSM (SHR / RAID classique)"| SynologyFlow["Inspecter les événements via mdadm --examine -> Forcer l'assemblage en lecture seule -> Activer LVM2 / Btrfs en lecture seule"]
    ArrayType -->|"QNAP QTS (HAL LVM RAID mince/épais)"| QnapFlow["Assemblez mdadm en lecture seule -> Activez la couche DRBD si présente -> Analysez les superblocs QNAP LVM2 personnalisés"]
    ArrayType -->|"TrueNAS / ZFS (RAIDZ1 / RAIDZ2 / Miroir)"| ZfsFlow["Exécutez zpool import -d /dev/disk/by-id -> Importer en lecture seule avec restauration : zpool import -f -o readonly=on -F"]
    ArrayType -->|"Mdadm Linux standard"| LinuxFlow["Comparez les compteurs d'événements -> Exécutez mdadm --assemble --force --readonly -> Montez le système de fichiers avec -o ro,noload"]

Phase 1 : Pourquoi forcer une reconstruction détruit les données (l'URE et la cascade Same-Batch)¶

Pour comprendre pourquoi cliquer sur Réparer/Reconstruire ou remplacer un disque et attendre 36 heures provoque souvent une panne totale de la baie, vous devez comprendre comment la reconstruction par parité met l'accent sur le vieillissement des supports magnétiques et pourquoi les disques de bureau grand public abandonnent les boîtiers NAS.

1. La réalité mathématique des erreurs de lecture irrécupérables (UREs) lors d'une reconstruction RAID 5 ou RAIDZ1¶

En 4x4 RAID 5 ou ZFS RAIDZ1 pool, blocs de données et de parité (P) sont répartis sur les quatre disques à l'aide d'un OU exclusif (XOR) calcul (D1 XOR D2 XOR D3 = P). Si Drive 2 meurt complètement, la baie n'a plus aucune redondance restante. Pour reconstruire le Drive 2 sur un tout nouveau disque de remplacement, le NAS doit lire chaque secteur de l'octet 0 jusqu'à la fin du disque sur le Drive 1, le Drive 3 et le Drive 4 simultanément (Reconstructed D2 = D1 XOR D3 XOR P).

Considérez ce qui se passe lorsque ces disques sont quatre disques durs de 12 téraoctets (12 000 gigaoctets) achetés auprès du même lot de fabrication il y a quatre ans : - La reconstruction de 12 téraoctets nécessite une lecture 36 terabytes (2.88 x 1014 bits individuels) en continu pendant 24 à 48 heures à charge thermique et mécanique maximale. - Les disques durs grand public comportent généralement une erreur de lecture irrécupérable (URE) spécification de 1 error in 1014 bits (12.5 terabytes), et les disques vieillissants développent des erreurs de secteur latentes silencieuses (Current_Pending_Sector) dans les zones froides du disque qui n'ont pas été lues depuis des années. - Au moment où Drive 3 rencontre un seul secteur défectueux illisible de 4 kilo-octets (0,004 mégaoctet) alors que Drive 2 est toujours manquant ou à moitié reconstruit, le XOR l'équation a deux inconnues (D2 et D3).

2. Pourquoi l'ordinateur de bureau fonctionne sans TLER / SCT ERC se faire expulser entièrement pour 1 secteur défectueux¶

Voici le piège qui provoque des chutes catastrophiques de plusieurs disques sur Synology, QNAP et Linux mdadm:

+-------------------------------------------------------------------------+
| WHY A SINGLE BAD SECTOR DROPS AN ENTIRE DRIVE DURING REBUILD            |
|                                                                         |
| 1. Drive 2 is dead/rebuilding. NAS reads Sector 849,102,400 on Drive 3. |
| 2. Drive 3 hits a weak magnetic spot (Current_Pending_Sector).          |
| 3. Consumer Drive Behavior (No TLER / SCT ERC):                         |
|    - Drive 3 enters deep internal error recovery for 30 to 120 seconds, |
|      stopping all SATA responses while retrying head positioning.       |
| 4. Linux Kernel / NAS Controller Timeout (Default 7 to 30 seconds):     |
|    - Kernel sees Drive 3 unresponsive for >30s -> Issues SATA bus reset |
|    - mdadm assumes Drive 3 is COMPLETELY DEAD and kicks it from array   |
| 5. RESULT: Both Drive 2 and Drive 3 are now marked FAULTY/REMOVED.      |
|    The entire RAID 5 array crashes offline immediately.                 |
+-------------------------------------------------------------------------+

Remarquez ce qui s'est réellement passé : Le lecteur 3 n'est pas mort. Il a 99.999999% secteurs sains et seulement 1 ou 2 secteurs illisibles de 4 kilo-octets (8 kilobytes hors de 12 terabytes). Pourtant parce que mdadm a expulsé le lecteur 3 de la baie en raison d'un délai d'attente de commande de 30 secondes, le volume entier s'affiche comme ** Crashed **. Si vous clonez Drive 3 avec ddrescue (qui ignore gracieusement les 8 kilo-octets de secteurs défectueux et copie les 12 téraoctets restants) et forcez l'assemblage du tableau en lecture seule, vous récupérez pratiquement 100 % de vos fichiers.

3. Pourquoi il ne faut JAMAIS courir mdadm --create ou cliquez sur "Initialiser"¶

Lorsqu’un réseau tombe en panne, deux mythes destructeurs circulent en ligne : - Mythe 1 : « Recréez la baie avec exactement le même ordre de disques en utilisant mdadm --create. " Même avec --assume-clean, versions modernes de mdadm par défaut à différent Data Offset valeurs en fonction du noyau et mdadm libération (2048 sectors contre 262144 sectors). Quand mdadm --create écrit une nouvelle version 1.2 superbloc avec un décalage incorrect ou avec une taille de morceau incompatible, il écrase le LVM2 en-tête de volume physique ou ext4 superbloc à l'avant du volume. - Mythe 2 : « Retirez le deuxième disque qui vient de tomber, rebranchez-le et cliquez sur Réparer. » Si le Drive 1 a été abandonné il y a trois jours (donc ses données sont obsolètes depuis 3 jours) et le Drive 3 est tombé il y a 10 minutes (donc ses données sont à jour), extraire et réinsérer le mauvais disque ou forcer une reconstruction avec Drive 1 marqué « actif » et Drive 3 marqué « de rechange » amène le NAS à écraser la baie à jour avec des bandes de parité obsolètes datant de 3 jours, corrompant chaque répertoire et fichier modifié. au cours des 72 dernières heures.

Phase 2 : Inspection des superblocs et Event compteurs en toute sécurité sur un hôte de secours Linux¶

Pour sauver en toute sécurité une baie Synology, QNAP, TrueNAS ou Linux en panne, retirez tous les lecteurs membres (après avoir étiqueté leurs numéros de baie) et connectez-les à un ordinateur de bureau ou à un serveur exécutant Ubuntu 22.04 LTS / 24.04 LTS (même démarré à partir d'une clé USB Live).

Étape 1 : Installez la boîte à outils de sauvetage médico-légal dans Ubuntu¶

Ouvrez un terminal sur votre machine de secours Ubuntu et installez les utilitaires requis :

sudo apt-get update
sudo apt-get install -y gddrescue smartmontools mdadm lvm2 btrfs-progs xfsprogs zfsutils-linux

Étape 2 : Mappez chaque lettre de lecteur, numéro de série et disposition des partitions¶

Répertoriez tous les périphériques bloc connectés et leurs numéros de série matériels afin de ne jamais confondre un disque de secours avec un disque NAS source :

lsblk -o NAME,SIZE,MODEL,SERIAL,FSTYPE,TYPE,MOUNTPOINTS

Examinez la table de partition d'un lecteur Synology DSM, QNAP ou TrueNAS typique :

Étape 3 : Vérifiez mdadm --examine pour voir pourquoi le tableau s'est écrasé (The Event Counter Matrix)¶

Sur un Synology, QNAP ou Linux mdadm baie, examinez les métadonnées RAID sur les partitions de données utilisateur (par exemple, la partition 3 sur /dev/sdb3, /dev/sdc3, /dev/sdd3, /dev/sde3) sans rien monter ni modifier :

sudo mdadm --examine /dev/sd[b-e]3 | grep -E "Filename|Magic|Update Time|Events|Array State|Device Role"

Comparez la sortie sur les quatre lecteurs :

/dev/sdb3:
    Update Time : Sat Oct 31 14:12:09 2026
         Events : 482190
   Device Role : Active device 0
   Array State : A.AA ('A' == active, '.' == missing, 'R' == replacing)

/dev/sdc3:
    Update Time : Thu Oct 29 03:44:11 2026
         Events : 479012
   Device Role : Active device 1
   Array State : AAAA ('A' == active, '.' == missing, 'R' == replacing)

/dev/sdd3:
    Update Time : Sat Oct 31 14:12:04 2026
         Events : 482188
   Device Role : Active device 2
   Array State : A.AA ('A' == active, '.' == missing, 'R' == replacing)

/dev/sde3:
    Update Time : Sat Oct 31 14:12:09 2026
         Events : 482190
   Device Role : Active device 3
   Array State : A.AA ('A' == active, '.' == missing, 'R' == replacing)

Lisez attentivement cette histoire médico-légale : 1. /dev/sdc3 (Device Role 1) a un Events compte de 479012 de il y a deux jours (Oct 29). Ce disque a été abandonné en premier, il y a deux jours, et est depuis hors ligne. 2. /dev/sdb3 (Role 0) et /dev/sde3 (Role 3) les deux ont Events : 482190 à 14:12:09. 3. /dev/sdd3 (Role 2) a Events : 482188 à 14:12:04, juste 5 secondes et 2 événements derrière sdb3 et sde3. 4. Conclusion : Vous devez reconstruire le tableau en utilisant sdb3 (Role 0), sdd3 (Role 2), et sde3 (Role 3) (dont les compteurs d'événements ne sont espacés que de 2 ticks), tout en ** quittant sdc3 (Role 1) complètement**.

Phase 3 : Clonage de chaque lecteur bit par bit avec GNU ddrescue¶

Avant de courir mdadm --assemble --force ou zpool import -F, clonez chaque disque requis (en particulier le disque qui a abandonné en dernier en raison de secteurs défectueux, tels que /dev/sdd dans l'exemple ci-dessus) sur un disque vide sain de capacité égale ou supérieure, ou dans un disque brut .img fichier sur un volume de stockage important.

Étape 1 : Pourquoi ddrescue avec un mapfile est obligatoire¶

Norme dd abandonne au premier secteur défectueux, ou avec conv=noerror,sync perd des heures à broyer ses têtes de lecture sur une piste endommagée tout en remplissant à zéro des mégaoctets de bonnes données adjacentes. GNU ddrescue fonctionne en passes intelligentes à plusieurs étapes : 1. Pass 1 (phase de copie) : copie toutes les régions saines et à réponse rapide du disque à pleine vitesse séquentielle (150 MB/s à 250 MB/s), en sautant immédiatement par-dessus tout bloc lent ou illisible afin que le disque ne surchauffe pas ou ne meure pas avant d'obtenir le 99.99% bonnes données. 2. Pass 2 (phase de découpage) : lit jusqu'aux bords exacts de chaque bloc défectueux, à la fois de l'avant et de l'arrière (reverse direction) pour isoler la zone endommagée jusqu'au secteur matériel exact de 4 kilo-octets. 3. Pass 3 (Phase de grattage) : Réessaye les secteurs endommagés en douceur sans réinitialiser inutilement le bus.

Étape 2 : exécutez les 2 étapes ddrescue commande de clonage¶

Spécifiez toujours un mapfile (sdd_rescue.map). Si le lecteur source en train de mourir se déconnecte et nécessite un cycle d'alimentation, ddrescue lit le fichier mapfile et reprend à l'octet exact où il s'est arrêté sans relire un seul secteur déjà copié :

# Stage 1: Fast forward pass skipping bad/slow blocks immediately (-n = no-scrape)
sudo ddrescue -f -n -b 4096 /dev/sdd /dev/sdh /root/sdd_rescue.map

# Stage 2: Targeted trimming and 3-retry scrape of the skipped bad sectors
sudo ddrescue -f -d -r 3 -b 4096 /dev/sdd /dev/sdh /root/sdd_rescue.map

Phase 4 : Reconstruction de Synology DSM (SHR-1 / SHR-2 / RAID classique), QNAP et Linux mdadm¶

Une fois que vos disques clonés (ou périphériques en boucle en lecture seule) sont prêts et que les disques NAS d'origine sont débranchés en toute sécurité, suivez la séquence d'assemblage non destructive exacte de votre plate-forme.

Scénario A : Linux standard mdadm ou Synology Classic RAID (RAID 5 / RAID 6)¶

1. Arrêtez tout partiel md tableau qu'Ubuntu aurait pu essayer de démarrer :

   cat /proc/mdstat
   sudo mdadm --stop /dev/md127
   

2. Forcer l'assemblage des partitions clonées (sdb3, sdd3, sde3, en omettant les morts depuis longtemps sdc3) en mode strictement lecture seule :

   sudo mdadm --assemble --force --readonly --verbose /dev/md2 /dev/sdb3 /dev/sdd3 /dev/sde3
   

   Regardez le résultat : mdadm fera rapport forcing event count in /dev/sdd3(2) from 482188 up to 482190 et mdadm: /dev/md2 has been started with 3 drives (out of 4).
3. Vérifiez que la baie est active et marquée (auto-read-only) ou (read-only):

   cat /proc/mdstat
   

Scénario B : RAID hybride Synology (SHR-1 et SHR-2) avec LVM2 et Btrfs / ext4¶

SHR de Synology (Synology Hybrid RAID) est 100 % Linux standard mdadm + LVM2 (Logical Volume Manager) : - Lorsque tous les disques d'un pool SHR ont la même taille (par exemple, quatre disques de 8 téraoctets), Synology crée un seul mdadm Partition RAID 5 (md2 sur la partition 3 de chaque disque) et place un LVM2 groupe de volumes (vg1000 ou vg1) au-dessus de md2. - Lorsque les disques d'un pool SHR ont des tailles mixtes (par exemple, deux disques de 8 téraoctets et deux disques de 16 téraoctets), Synology crée deux disques distincts. mdadm tableaux : md2 sur la partition 5 (8 TB tranche sur les 4 disques en RAID 5) et md3 sur la partition 6 (le reste 8 TB slice sur les deux disques de 16 To en RAID 1), puis rejoint md2 + md3 en un seul LVM2 Groupe de volumes (vg1000).

Pour monter un volume Synology SHR en lecture seule sur Ubuntu après l'assemblage forcé /dev/md2 (et /dev/md3 si SHR de tailles mixtes) : 1. Recherchez les volumes physiques et les groupes de volumes Synology LVM2 :

sudo pvscan
sudo vgscan
sudo lvscan

sudo vgchange -ay /dev/vg1000

sudo mkdir -p /mnt/synology_rescue
sudo mount -t ext4 -o ro,noload /dev/vg1000/lv /mnt/synology_rescue

sudo mkdir -p /mnt/synology_rescue
sudo mount -t btrfs -o ro,norecovery /dev/vg1000/lv /mnt/synology_rescue

sudo mount -t btrfs -o ro,norecovery,usebackuproot /dev/vg1000/lv /mnt/synology_rescue

Scénario C : Chiffrement de volume Synology DSM 7+ ou chiffrement de dossiers partagés (eCryptfs)¶

• Cryptage des dossiers partagés (@sharename@ dossiers contenant ECRYPTFS_FNEK_ENCRYPTED... noms de fichiers) : Copiez l'intégralité @encrypted_share@ dossier désactivé /mnt/synology_rescue d'abord, puis montez-le et déchiffrez-le sur Ubuntu en utilisant votre mot de passe de cryptage Synology ou .key fichier :

  sudo apt-get install -y ecryptfs-utils
  sudo mkdir -p /mnt/decrypted_share
  sudo mount -t ecryptfs -o ro /mnt/synology_rescue/@encrypted_share@ /mnt/decrypted_share
  

• DSM 7.2+ Chiffrement du volume complet (LUKS) : Si /dev/vg1000/lv montre TYPE="crypto_LUKS" dans blkid, déverrouillez-le en lecture seule à l'aide du .rkey Fichier de clé de récupération téléchargé lors de la création du volume :

  sudo cryptsetup open --readonly --key-file /path/to/Volume1.rkey /dev/vg1000/lv synology_crypt
  sudo mount -o ro,norecovery /dev/mapper/synology_crypt /mnt/synology_rescue
  

Scénario D : QNAP QTS (LVM2 Thin Provisioning et DRBD couche)¶

Unités NAS QNAP modernes (QTS 4.3+ / 5.x) insérer un nœud unique interne DRBD appareil (/dev/drbd1) entre /dev/md1 et le LVM2 Groupe de volumes (vg1). 1. Commencez par assembler de force les partitions de données QNAP (/dev/sd[b-e]3) en lecture seule dans /dev/md1:

sudo mdadm --assemble --force --readonly /dev/md1 /dev/sdb3 /dev/sdd3 /dev/sde3

Phase 5 : Sauver TrueNAS et Linux ZFS piscines (RAIDZ1, RAIDZ2, RAIDZ3)¶

Si votre serveur de stockage exécute TrueNAS CORE, TrueNAS SCALE, Proxmox VE ou Ubuntu ZFS, la récupération n'utilise pas mdadm. Au lieu de cela, ZFS combine le gestionnaire de volumes et la copie sur écriture (CoW) système de fichiers en une architecture transactionnelle unique construite autour de Uberblocks et de Groupes de transactions séquentiels (TXGs).

Étape 1 : Inspectez les 4 étiquettes vdev ZFS (L0, L1, L2, L3) sur chaque disque cloné¶

Chaque partition membre ZFS stocke quatre copies identiques de la configuration du pool et un tableau des 128 derniers Uberblocks (deux étiquettes à l'avant de la partition, L0 et L1, et deux étiquettes à la toute fin, L2 et L3). Courir zdb -l sur chaque partition clonée pour inspecter l'état du pool et le groupe de transactions validé le plus élevé (txg) :

sudo zdb -l /dev/sdb2 | grep -E "name:|state:|txg:|guid:" | head -n 20

Comparez les txg: numéros sur tous les lecteurs clonés. Tout comme mdadmc'est Events compteur, si un disque tombe en panne 5 minutes avant une panne de courant ou une deuxième chute de disque, son txg sera légèrement inférieur à celui des disques restants.

Étape 2 : Importez le pool ZFS en mode strictement lecture seule (-o readonly=on)¶

Vérifiez d’abord les pools importables sans rien monter via sudo zpool import -d /dev/disk/by-id. N'importez jamais un pool ZFS endommagé ou supprimé sur plusieurs disques en mode lecture-écriture. Lorsqu'il est importé avec -o readonly=on, ZFS ne tente pas de lancer un réargent, n'écrit pas de nouveaux Uberblocks et ne peut pas paniquer le noyau si une carte spatiale est corrompue (spacemap) est rencontré lors de l'allocation d'écriture :

sudo mkdir -p /mnt/zfs_rescue
sudo zpool import -f -o readonly=on -R /mnt/zfs_rescue tank

Étape 3 : Si zpool import échoue avec I/O error ou corrupted data, utilisez la restauration TXG (-F et -T)¶

Si deux disques tombent en panne à quelques secondes d'intervalle lors d'une rafale d'écriture importante, le tout dernier groupe de transactions (TXG N) peut être incomplet sur les bandes de parité survivantes, tandis que TXG N-1 ou TXG N-2 (écrit 5 à 15 secondes plus tôt) est intact à 100 pour cent à l’intérieur du tampon annulaire Uberblock.

1. ** Testez un aperçu non destructif de la restauration à sec (-F -n)** :

   sudo zpool import -f -o readonly=on -R /mnt/zfs_rescue -F -n tank
   

   Si ZFS rapporte Would be able to return pool to its state as of <timestamp>, exécutez l'importation de restauration en lecture seule sans -n:

   sudo zpool import -f -o readonly=on -R /mnt/zfs_rescue -F tank
   

2. Si -F ne peut toujours pas monter les derniers Uberblocks, répertoriez les numéros Uberblock TXG historiques avec zdb et importez un ancien TXG spécifique (-T) :

   sudo zdb -e -ul /dev/sdb2 | grep -E "Uberblock|txg =|timestamp ="
   

   Choisissez un txg nombre de 30 à 60 secondes avant l'accident (par exemple, txg = 9481020) et importez le pool gelé à ce moment précis en mode lecture seule :

   sudo zpool import -f -o readonly=on -R /mnt/zfs_rescue -T 9481020 tank
   

Phase 6 : Vérification post-récupération et prévention de futures cascades de reconstruction¶

Une fois que vous avez copié 100 pour cent de vos données récupérées depuis /mnt/synology_rescue ou /mnt/zfs_rescue sur une cible de sauvegarde indépendante, suivez cette liste de contrôle du matériel et de la configuration avant de remettre votre NAS en service :

• N'achetez jamais tous les disques NAS auprès du même détaillant le même jour : les disques du même lot de fabrication partagent des lots de tête et un micrologiciel identiques, ce qui entraîne leur défaillance à quelques heures d'intervalle lors d'une reconstruction. Mélanger des lots ou des fabricants (Seagate IronWolf / Exos, WD Red Plus / Ultrastar, Toshiba N300 / MG).
• Utilisez uniquement des disques NAS/Enterprise avec TLER / SCT ERC activé (ou augmentez Linux mdadm Délais d'expiration SCSI pour les lecteurs de bureau) : pour les lecteurs grand public sous Linux mdadm, utilisez un udev règle pour augmenter /sys/block/sdX/device/timeout de 30 secondes pour 180 secondes donc mdadm attend le remappage du secteur interne au lieu de laisser tomber le lecteur.
• ** Migrez les baies comportant des disques de taille supérieure à 8 TB de RAID 5 / SHR-1 / RAIDZ1 à RAID 6 / SHR-2 / RAIDZ2** : Avec 12 TB à 24 TB disques, les temps de reconstruction à parité unique dépassent 30 heures, ce qui rend la double parité (RAID 6 / SHR-2 / RAIDZ2) important pour survivre à un secteur défectueux lors de la réargenture.
• Horaire mensuel Data Scrubbing (mdadm check / zpool scrub) et étendu SMART tests : le nettoyage mensuel répare les erreurs latentes du secteur (Current_Pending_Sector) alors que tous les lecteurs sont en ligne.
• N'oubliez pas que le RAID est une haute disponibilité, jamais une sauvegarde : suivez les Stratégie de sauvegarde 3-2-1 avec une copie hors ligne.

Numéros d'urgence régionaux et protocoles des agences¶

Les pannes de stockage affectant les réseaux de santé, les communications d’urgence ou les dossiers personnels statutaires nécessitent une escalade immédiate :

• États-Unis et Canada : Composez 911 si un crash de stockage désactive les systèmes cliniques de l'hôpital (EHR / PACS) ou expédition. Signaler un ransomware ciblant le NAS (DeadBolt, LockBit, Akira) à CISA (1-844-Say-CISA / cisa.gov/report), FBI IC3 (ic3.gov), ou le Centre canadien pour la cybersécurité (1-833-CYBER-88).
• Royaume-Uni : Composez 999 pour les urgences affectant la sécurité des personnes ou les soins aigus du NHS. En vertu du RGPD britannique, évaluez si la perte permanente de données personnelles non sauvegardées nécessite d'en informer l'ICO (0303 123 1113) dans les 72 heures.
• Union européenne : Composez 112 dans toute l'UE. Les entités relevant de la Directive NIS2 doivent signaler les pannes opérationnelles majeures à leur CSIRT national dans les 24 heures, et la perte permanente de disponibilité des données personnelles déclenche un rapport Article 33 du RGPD dans les 72 heures.
• Australie et Nouvelle-Zélande : Composez 000 en Australie ou 111 en Nouvelle-Zélande ; signaler les incidents d'infrastructure ou de ransomware NAS à l'ACSC (1300 CYBER1) ou CERT NZ (0800 237 869).
• Inde et Asie-Pacifique : Composez 112 en Inde pour les interventions d'urgence ; signaler les incidents de stockage de l'infrastructure à CERT-In (incident@cert-in.org.in) dans la fenêtre obligatoire de 6 heures.

Questions fréquemment posées¶

Pourquoi mdadm --assemble --force refuser de démarrer ma matrice RAID 5 avec not enough to start the array?¶

En 4x4 RAID5 tableau, au moins 3 disques sur 4 doit être transmis à mdadm --assemble --force. Courir sudo mdadm --examine /dev/sd[a-z]3 pour vérifier pourquoi le troisième disque a été rejeté : soit vous avez passé le disque entier au lieu de la partition (/dev/sdd au lieu de /dev/sdd3), son superbloc était marqué comme un De rechange par une reconstruction interrompue, ou l'auto-assembleur d'Ubuntu a verrouillé un lecteur dans un disque inactif /dev/md127 appareil (exécuter sudo mdadm --stop --scan d'abord, puis réexécutez mdadm --assemble --force --readonly).

Que se passe-t-il si un lecteur commence à se reconstruire (Recovery = 12%) avant que le deuxième disque ne s'arrête ?¶

Si le lecteur 2 est mort, vous avez inséré un lecteur 2 de remplacement et, à 12% progression de la reconstruction Le lecteur 3 a été mis hors ligne en raison d'un secteur défectueux, n'utilisez pas le lecteur 2 de remplacement reconstruit à 12 %. Au lieu de cela, clonez l'original Conduire 3 avec sauvetage. Étant donné que le lecteur 3 était complètement à jour jusqu'à ce que la reconstruction s'arrête à 12 %, forçant l'assemblage de la baie en lecture seule à l'aide du lecteur 1, le sauvetage Le clone du Drive 3 et du Drive 4 (en laissant le Drive 2 de côté) vous offre un tableau cohérent.

Puis-je installer mes disques Synology ou QNAP dans un tout nouveau châssis NAS si l'alimentation ou la carte du NAS tombe en panne ?¶

Oui, les deux Synology (Migration du disque dur) et QNAP (Migration directe du NAS) stockez la configuration RAID sur les disques eux-mêmes. Cependant, si deux disques ou plus étaient déjà tombés en panne (`Volume Crashed`) avant la mort du châssis, ne les démarrez pas dans un nouveau châssis NAS, car l'assistant de migration peut écraser les partitions ou déclencher une reconstruction destructrice. Sauvez d'abord les données en lecture seule sur Ubuntu.

Comment savoir si un disque abandonné peut être cloné en toute sécurité avec ddrescue versus avoir besoin d'un laboratoire en salle blanche ?¶

Connectez le disque à SATA, allumez-le et écoutez pendant 10 secondes tout en regardant sudo dmesg -w. Si le disque émet des clics, des grattages ou des bourdonnements rythmés, s'accélère et redescend, ou signale la capacité comme 0B / 4,1 Go dans lsblk, les têtes de lecture/écriture sont physiquement tombées en panne : coupez immédiatement le courant et utilisez un laboratoire en salle blanche. Si le disque tourne correctement, il affiche sa pleine capacité en lsblk, et uniquement les journaux Secteur_en attente_actuel ou des erreurs de délai d'attente, clonez-le avec sauvetage.

Qu'est-ce que le « trou d'écriture RAID 5 » et comment fonctionne-t-il ? ZFS ou Btrfs l'éviter lors d'une panne de courant ?¶

En traditionnel RAID5 / RAID6 sans journal, la mise à jour d'une bande nécessite l'écriture simultanée du bloc de données et du bloc de parité sur deux disques. En cas de panne de courant en cours d'écriture, les données et la parité ne correspondent plus (le Trou d'écriture). ZFS (`RAIDZ`) et Btrfs éliminez le trou d'écriture à l'aide de la copie sur écriture (`CoW`), en écrivant chaque nouvelle bande dans des blocs inutilisés et en mettant à jour le pointeur Uberblock/root uniquement une fois la bande complète sur le disque.

Puis-je utiliser dmsetup des superpositions pour tester les paramètres RAID sans modifier les disques clonés ?¶

Oui, vous pouvez créer une copie sur écriture (`CoW`) se superpose au-dessus des périphériques de boucle en lecture seule (`losetup --read-only`) sous Linux configuration dm (`snapshot` cible) soutenu par des fichiers clairsemés dans /tmp. Tout écrit de mdadm --assemble --force ou fsck -y passer au jetable /tmp fichier de superposition, vous permettant de réinitialiser en 1 seconde si nécessaire.

Guides associés¶

• Baie RAID NAS dégradée, panne de plusieurs disques et récupération ZFS/Btrfs
• Mort de la carte contrôleur RAID, importation de configuration étrangère et raison pour laquelle vous ne devez jamais initialiser les disques
• Panne de disque dur et récupération de données
• Mode lecture seule soudaine SSD et NVMe, 0 % de blocs de rechange et TRIM désactivant le sauvetage
• rm -rf ou Shift+Delete accidentel sous Linux, macOS ou Windows : remontage immédiat en lecture seule
• Sauvegardes informatiques, stratégie 3-2-1 et reprise après sinistre
• Numéros d'urgence par pays

Sources et directives officielles¶

• Wiki Raid Linux (raid.wiki.kernel.org) & L'organisation du noyau Linux : Récupération d'un RAID logiciel défaillant (mdadm --assemble --force --readonly et incompatibilités de compteur d'événements).
• Fondation du logiciel libre (GNU Project) : GNU ddrescue Manuel : Récupération de données médico-légales à partir d'un support défaillant.
• Documentation OpenZFS (openzfs.github.io): Récupération d'importation de pool ZFS (zpool import -F, Importations en lecture seule et zdb Contrôle).
• Synology Inc. : Synology Knowledge Center : Comment puis-je utiliser un PC pour récupérer des données en cas de dysfonctionnement de mon Synology NAS (mdadm + LVM2 Montage).
• Institut national des normes et de la technologie (NIST) (États-Unis) : Publication spéciale 800-209 : Directives de sécurité pour l'infrastructure de stockage.