Panne de matrice RAID, pool de stockage NAS corrompu et sécurité de reconstruction¶

Lorsqu'un appareil de stockage en réseau (NAS) domestique ou d'une petite entreprise (tel qu'un Synology DiskStation, un QNAP Turbo NAS, un TrueNAS ou un serveur Unraid) commence à émettre un bip avec un voyant orange et signale ** « Pool de stockage dégradé » ** ou ** « Volume planté »**, le tout prochain clic du propriétaire détermine généralement si 20 téraoctets de photos de famille et de dossiers professionnels irremplaçables sont enregistrés ou détruits définitivement. Pendant des décennies, les utilisateurs ont appris que lorsqu'un disque d'une matrice RAID 5 ou RAID 1 devient rouge, il suffit de retirer le disque mort, d'y insérer un tout nouveau disque vierge et de cliquer sur "Réparer/Reconstruire".

Dans les pools de stockage modernes haute capacité construits avec des disques de 8 To à 24 To achetés auprès du même lot de fabrication, le démarrage aveugle d'une reconstruction RAID sur place est la première cause de mort totale et irrécupérable d'une baie multi-disques. La reconstruction d'une matrice RAID 5 de 16 To à 4 disques oblige chaque disque vieillissant restant à lire 100 % de ses secteurs sans interruption pendant 24 à 72 heures à une charge thermique et mécanique maximale. Lorsqu'un des disques frères survivants rencontre une erreur de lecture non corrigible (URE) ou subit une dégradation de la tête à mi-chemin de la reconstruction, le contrôleur RAID expulse ce deuxième disque du pool et fait planter l'ensemble de la matrice. Pour survivre à une urgence RAID, ZFS ou Btrfs, il faut suspendre immédiatement toutes les écritures et auditer S.M.A.R.T. télémétrie sur tous les disques survivants, sauvegarde des dossiers critiques avant de toucher à la topologie de la baie et imagerie des disques membres dégradés avec GNU ddrescue avant de tenter une reconstruction de parité ou un assemblage de métadonnées en lecture seule.

Fais ça maintenant¶

1. NE JAMAIS retirer plusieurs disques pour les « réinstaller » lorsque le NAS ou le serveur est sous tension, et NE JAMAIS échanger les disques sans étiqueter leurs numéros d'emplacement exacts. Avant de toucher un seul plateau de disque, prenez un Sharpie ou une étiqueteuse et marquez le dessus physique de chaque disque avec son numéro exact de baie (Bay 1 / sda, Bay 2 / sdb, Bay 3 / sdc). Bien que Linux moderne mdadm, LVM et ZFS stockent les superblocs UUID sur chaque disque, les contrôleurs RAID matériels (Dell PERC, HP Smart Array, Broadcom/LSI MegaRAID) lient souvent les métadonnées de configuration aux numéros physiques d'emplacement de fond de panier SAS/SATA.
2. Ne cliquez PAS immédiatement sur « Réparer » ou « Reconstruire » sur une matrice RAID 5/SHR-1 dégradée si vous ne disposez pas d'une sauvegarde externe à jour. Lorsqu'une matrice à parité unique (RAID 5, Synology SHR-1 ou ZFS RAIDZ1) est en Mode dégradé (1 disque mort, disques restants en ligne), tous vos fichiers sont toujours lisibles à 100 % à l'heure actuelle. Branchez un disque dur externe USB 3.0 directement sur le NAS et copiez vos dossiers les plus critiques et irremplaçables du pool dégradé avant de soumettre les disques survivants au test de résistance brutal de 48 heures d'une reconstruction de parité.
3. ** NE JAMAIS cliquer sur "Initialiser le disque", "Créer un nouveau pool", "Effacer la configuration" ou exécuter fsck -y / btrfs check --repair sur une matrice en panne.** Lorsque deux disques tombent simultanément d'une matrice RAID 5 (souvent en raison d'une brève baisse de l'alimentation ou d'un délai d'attente SATA plutôt que d'une véritable mort physique), l'interface graphique du NAS marquera le pool de stockage comme ** « Crashed » ** et proposera d'initialiser ou de recréer le volume. L'initialisation écrit de nouveaux superblocs et des zéros sur les bandes de parité, détruisant ainsi les données récupérables. De même, courir btrfs check --repair sur un volume Btrfs corrompu est connu dans la communauté du noyau Linux pour détruire l'arborescence des extensions au-delà de la récupération.
4. Arrêtez immédiatement tous les conteneurs Docker, les machines virtuelles, les serveurs multimédias Plex, les enregistrements de caméras de surveillance et les nettoyages RAID planifiés. Chaque opération d'écriture sur une matrice dégradée augmente le risque de trou d'écriture de parité ou de poussée d'un deuxième disque marginal par-dessus bord. Connectez-vous à l'interface Web du NAS ou au terminal SSH et arrêtez tous les services d'arrière-plan et les tâches nécessitant beaucoup d'E/S.
5. Si un disque du NAS émet des sons rythmiques de clics, de cognements, de grincements ou de cris, éteignez le NAS proprement dès maintenant. Un disque qui clique ou grince a subi un crash physique de la tête de lecture/écriture (voir Panne de disque dur et récupération de données). Le laisser tourner à l’intérieur du boîtier du NAS transformera les plateaux magnétiques en poussière en quelques minutes.
6. Vérifiez si la « panne du NAS » est en fait simplement une carte mère NAS morte ou une brique d'alimentation externe. Si votre NAS Synology, QNAP ou Asustor ne s'allume soudainement plus du tout, ou fait clignoter son voyant d'alimentation bleu sans fin (comme le célèbre bug de signal d'horloge Intel Atom C2000), vos disques durs et vos données sont presque certainement en bon état à 100 %. Vous pouvez migrer ces disques vers un NAS de remplacement ou les monter en lecture seule sur n'importe quel ordinateur de bureau Ubuntu Linux à l'aide de ports SATA standard.

flowchart TD
    A["Le bip du NAS/la matrice RAID signale un état dégradé ou en panne"] --> B{"Certains disques émettent-ils des bruits mécaniques de cliquetis, de grincement ou de grattage ?"}
    B -->|"Oui : accident physique de la tête"| C["Éteignez immédiatement le NAS, étiquetez chaque disque avec son numéro de baie et retirez le disque en cliquant"]
    B -->|"Non : Fonctionnement silencieux"| D{"Quel est l’état du pool de stockage ?"}
    D -->|"DÉGRADÉ (1 disque en panne, volume toujours lisible)"| E["ARRÊTEZ toutes les écritures Docker/VM/Surveillance et NE cliquez PAS encore sur Reconstruire"]
    E --> F["Vérifiez S.M.A.R.T. Attributs (ID 5, 187, 197, 198) sur tous les lecteurs SURVIVANTS"]
    F --> G["Branchez une clé USB externe et copiez EN PREMIER les fichiers critiques du pool dégradé."]
    G --> H{"Les disques survivants affichent-ils des secteurs défectueux (ID 5/197 > 0) ?"}
    H -->|"Oui : le deuxième disque est en panne"| I["Éteignez et clonez chaque lecteur avec GNU ddrescue avant de tenter une reconstruction"]
    H -->|"Non : Survivre conduit à 100 % en bonne santé"| J["Insérez le lecteur CMR de remplacement (jamais SMR) et exécutez la reconstruction de parité"]
    D -->|"CRASHED / OFFLINE (Plusieurs lecteurs abandonnés)"| K["Ne PAS initialiser ni exécuter fsck/btrfs --repair ; éteignez et étiquetez toutes les baies de lecteur"]
    C --> L["Clonez tous les lecteurs membres dégradés sur des lecteurs sains à l'aide de GNU ddrescue + mapfiles"]
    K --> L
    L --> M["Réassemblez les disques clonés en mode lecture seule via Linux mdadm/LVM, zpool import -o readonly=on ou UFS Explorer RAID"]

Comprendre pourquoi les reconstructions RAID échouent : les pièges « Sibling Drive Batch » et « SMR Drive »¶

Pour prendre des décisions sûres lors d'une urgence NAS, vous devez comprendre les deux pièges physiques qui tuent les matrices RAID lors de la récupération :

Piège 1 : échec de lot corrélé et erreurs de lecture non corrigibles (URE)¶

La plupart des propriétaires de NAS achètent les quatre ou six disques durs le même jour auprès du même détaillant. Ces disques sortent de la même chaîne d'assemblage en usine, partagent des révisions de micrologiciel identiques, tournent exactement dans le même environnement de vibration du châssis et accumulent exactement le même nombre d'heures de mise sous tension. * Lorsque le Drive 1 tombe en panne après 38 000 heures de fonctionnement, les Drives 2, 3 et 4 ont également 38 000 heures d'usure. * Si vous insérez un nouveau disque de remplacement dans la baie 1 et cliquez sur Reconstruire sur une matrice RAID 5, le contrôleur NAS doit lire chaque secteur sur les disques 2, 3 et 4 pour calculer par XOR les blocs de parité manquants pour la baie 1. * Si le lecteur 3 héberge discrètement 14 secteurs défectueux illisibles (** Secteurs en attente actuels, ID S.M.A.R.T. 197 ) dans un ancien dossier que vous n'avez pas ouvert depuis deux ans, le processus de reconstruction frappera tête première ces secteurs défectueux à l'heure 19. Sur de nombreuses cartes RAID matérielles et noyaux NAS plus anciens sans contrôle de récupération d'erreur SCT (TLER), un seul blocage de lecture de plusieurs secondes amène le contrôleur à ** marquer le lecteur 3 comme "Échec/En panne", supprimant un deuxième disque d'une matrice RAID 5 à parité unique et faisant planter l'intégralité du volume.

Piège 2 : n'insérez jamais de lecteur SMR (Shingled Magnetic Recording) dans une matrice RAID ou ZFS¶

Lorsque vous achetez un disque dur de remplacement d'urgence dans un magasin d'électronique local pour reconstruire votre NAS, vérifiez que le disque de remplacement utilise CMR (enregistrement magnétique conventionnel), JAMAIS SMR (enregistrement magnétique Shingled). * Disques durs de bureau économiques (tels que Western Digital Red standard non-Plus EFAX modèles de 2 To à 6 To, disques de bureau Seagate Barracuda Compute et de nombreux disques USB externes bon marché que les utilisateurs « retirent » de leurs boîtiers en plastique) utilisent Drive-Managed SMR, où les pistes magnétiques se chevauchent comme des bardeaux de toit. * Lors d'une écriture soutenue de plusieurs téraoctets RAID ou ZFS resilver, le cache multimédia interne d'un lecteur SMR se remplit complètement en 30 minutes. Une fois le cache plein, le lecteur SMR se bloque pendant 10 à 30+ secondes pendant la lecture et la réécriture en interne de bandes entières en bardeaux, ou renvoie un ATA. IDNF (Sector ID Not Found) délai d'attente. * Linux mdadm, Synology DSM, et surtout ZFS (zed) interprète ces blocages SMR de 20 secondes comme un disque dur mort, retirant le tout nouveau disque de remplacement de la baie au milieu de la reconstruction. Achetez toujours des disques CMR NAS/Enterprise (tels que WD Red Plus / WD Red Pro, Seagate IronWolf / IronWolf Pro / Exos ou Toshiba N300 / MG Enterprise).

Matrice de diagnostic : niveaux RAID, tolérance aux pannes et règles de survie¶

Triage étape par étape pour un pool NAS « dégradé » (1 disque en panne, données toujours accessibles)¶

Si votre NAS émet un bip parce que 1 disque dans un pool RAID 1, RAID 5, SHR-1, RAID 6 ou RAIDZ est en panne, suivez cette séquence exacte avant de remplacer le disque :

Étape 1 : Auditer S.M.A.R.T. les attributs sur tous les lecteurs SURVIVING en premier¶

Ouvrez ** Gestionnaire de stockage -> HDD/SSD -> Informations sur la santé -> S.M.A.R.T. Attribut** (sur Synology/QNAP) ou exécuter smartctl -a /dev/sdX via SSH sur chaque lecteur sain/en ligne encore laissé dans le pool. Regardez le RAW_VALUE colonne pour ces quatre attributs critiques : * ID 5 (Reallocated_Sector_Ct): Doit idéalement être 0. Si un disque survivant comporte des dizaines ou des centaines de secteurs réaffectés, la surface de son plateau ou ses têtes se dégradent activement. * ID 187 (Reported_Uncorrect): Doit être 0. * ID 197 (Current_Pending_Sector): CRITIQUE. Tout nombre supérieur à 0 signifie que le disque survivant contient actuellement des secteurs illisibles en attente de provoquer un crash au moment où une reconstruction RAID tente de les lire. * ID 198 (Offline_Uncorrectable): Doit être 0.

Règle de décision : * Si tous les lecteurs survivants affichent 0 sur les ID 5, 187, 197 et 198, vous pouvez sauvegarder en toute sécurité vos dossiers critiques sur un lecteur USB externe, puis procéder à une Réparation/Reconstruction de l'interface graphique NAS normale à l'aide d'un lecteur de remplacement CMR sain. * Si un disque survivant dans un pool RAID 5 / SHR-1 / RAIDZ1 à parité unique s'affiche Current_Pending_Sector > 0 ou escalade Reallocated_Sector_Ct, NE PAS LANCER DE RECONSTITUTION. Copiez immédiatement toutes les données du NAS dégradé sur des lecteurs USB externes pendant que le volume est encore monté ; si le volume rencontre déjà des difficultés, éteignez le NAS et clonez les disques membres défaillants sur un PC Linux à l'aide de GNU ddrescue d'abord.

Sauvetage étape par étape lorsqu'un volume RAID/NAS « plante » (plusieurs lecteurs abandonnés)¶

Que se passe-t-il si vous vous réveillez et que votre NAS RAID 5 à 4 baies indique « Pool de stockage 1 : Crashed » parce que le Drive 2 est tombé en panne mardi soir et le Drive 4 est tombé en panne mercredi matin ?

Pourquoi la plupart des « pannes de 2 disques » sont réellement récupérables : À moins que votre maison n'ait été frappée par la foudre ou que le NAS ne soit tombé dans un escalier, deux disques durs mécaniques ne subissent presque jamais de collisions catastrophiques totales exactement à la même seconde. Au lieu de cela, ce qui s’est réellement passé est séquentiel : 1. Le disque 2 a développé quelques secteurs défectueux et a été expulsé de la baie quelques jours ou heures plus tôt (laissant la baie fonctionner en mode dégradé sur les disques 1, 3 et 4). 2. Plus tard, Drive 4 a rencontré un seul secteur illisible (ou un bref délai d'attente SATA) alors que le NAS exécutait un nettoyage en arrière-plan. Étant donné que la baie ne disposait plus de redondance pour réparer ce seul secteur défectueux sur le lecteur 4, le pilote RAID a également expulsé le lecteur 4 et a marqué l'ensemble du pool ** Crashé **.

Dans ce scénario, Drive 4 dispose du compteur d'événements de raid le plus récent et le plus récent (Events count) et est sain à 99,9999 %, tandis que Drive 2 est légèrement obsolète ("périmé").

Comment récupérer un Synology, QNAP ou Linux en panne mdadm tableau en toute sécurité sur un PC Linux¶

Étape 1 : Éteignez le NAS, étiquetez chaque baie de lecteur et connectez les lecteurs à un ordinateur de bureau exécutant Ubuntu Linux Live USB¶

1. Arrêtez le NAS. Étiquetez chaque lecteur (Bay 1, Bay 2, Bay 3, Bay 4).
2. Connectez les disques aux ports SATA de la carte mère (ou à une carte HBA comme un LSI 9211-8i/9300-8i en mode informatique ; évitez les hubs USB bon marché qui se déconnectent sous charge) sur un ordinateur de bureau démarré sur un Ubuntu Linux Live USB.
3. Ouvrez un terminal et inspectez la disposition des partitions et mdadm superblocs strictement en mode diagnostic en lecture seule :

# List all connected drives and partitions without mounting anything
lsblk -o NAME,SIZE,MODEL,SERIAL,FSTYPE

# Inspect the Linux Software RAID (mdadm) superblock metadata on the data partitions
# Note: On Synology DSM, Partition 1 is Root OS, Partition 2 is Swap, and Partition 3 (or 5) is your User Data array (e.g., /dev/sda3, /dev/sdb3, /dev/sdc3, /dev/sdd3)
sudo mdadm --examine /dev/sd[a-d]3

Étape 2 : Lire le Events compteur et Array State sortie de mdadm --examine¶

Regardez attentivement la sortie de sudo mdadm --examine /dev/sd[a-d]3 pour chaque lecteur : * Vous verrez des lignes comme : * /dev/sda3: Events : 48210, Array State : A.AA (A = Actif, . = Manquant) * /dev/sdb3 (Drive 2, abandonné en premier) : Events : 47950, Array State : AAAA * /dev/sdc3: Events : 48210, Array State : A.AA * /dev/sdd3 (Drive 4, abandonné en dernier) : Events : 48209, Array State : A.AA * Remarquez ce que Events Le compteur vous indique : Les lecteurs 1, 3 et 4 (sda3, sdc3, sdd3) sont à 1 événement l'un de l'autre (48210 contre 48209), tandis que Drive 2 (sdb3) s'est brouillé beaucoup plus tôt lors de l'événement 47950. * Règle critique : Dans une matrice RAID 5 à 4 disques, vous n'avez besoin que de 3 disques pour reconstruire 100 % des données. Vous DEVEZ assembler la baie en utilisant les 3 disques les plus récents (sda3, sdc3, et sdd3) et laissez de côté le disque obsolète (sdb3). Si vous forcez accidentellement l'assemblage à l'aide de l'ancien disque obsolète (sdb3), les métadonnées du système de fichiers d'il y a deux jours ne correspondent pas aux bandes de données actuelles sur les autres lecteurs et corrompent vos dossiers.

Étape 3 : Cloner n'importe quel lecteur contenant des secteurs défectueux à l'aide de GNU ddrescue d'abord¶

Avant l'assemblage, clonez le disque récemment déposé (/dev/sdd) (et idéalement tous les lecteurs membres) vers un lecteur de remplacement sain en utilisant ddrescue (voir Panne de disque dur et récupération de données pour plein ddrescue syntaxe) :

# Clone the dropped drive (/dev/sdd) to a healthy new spare drive (/dev/sde) with a mapfile
sudo ddrescue -f -n /dev/sdd /dev/sde /root/drive4_clone.map
sudo ddrescue -d -f -r3 /dev/sdd /dev/sde /root/drive4_clone.map

Maintenant, débranchez l'original défaillant /dev/sdd et placez-le en toute sécurité sur une étagère pour pouvoir travailler avec le clone sain (/dev/sde).

Étape 4 : Réassemblez la matrice RAID, le groupe de volumes LVM et le système de fichiers en mode LECTURE SEULE stricte¶

Sur les systèmes Synology (SHR/RAID) et QNAP, la pile de stockage comporte jusqu'à trois couches : mdadm (RAID) -> LVM2 (Gestionnaire de volumes logiques) -> ext4 ou Btrfs (Système de fichiers). Voici la séquence de commandes exacte pour les monter en toute sécurité en mode lecture seule sur Ubuntu :

# Install mdadm, lvm2, and btrfs-progs inside the Ubuntu Live environment
sudo apt update && sudo apt install -y mdadm lvm2 btrfs-progs

# Stop any partial auto-assembled md arrays first
sudo mdadm --stop --scan

# Assemble the 3 freshest RAID 5 partitions in READ-ONLY mode (using --force ONLY if the 3rd drive's event count is off by 1-2 events, on the cloned drive)
sudo mdadm --assemble --readonly --run /dev/md127 /dev/sda3 /dev/sdc3 /dev/sde3

# Check that /dev/md127 is now active (even in degraded [UU_U] read-only state)
cat /proc/mdstat

# Activate the LVM Volume Group in read-only mode
sudo vgchange -ay --readonly

# List the discovered Logical Volumes (look for /dev/vg1000/lv or /dev/vg1/volume_1)
sudo lvs

# Create a mount point and mount the Logical Volume strictly READ-ONLY (-o ro,noload for ext4 or -o ro,norecovery for Btrfs)
sudo mkdir -p /mnt/nas_rescue

# For ext4 volumes:
sudo mount -o ro,noload /dev/vg1000/lv /mnt/nas_rescue

# OR for Btrfs volumes (such as Synology Btrfs pools):
sudo mount -o ro,norecovery /dev/vg1000/lv /mnt/nas_rescue

Une fois /mnt/nas_rescue supports, tous les dossiers partagés de votre NAS (photo, homes, video, documents) apparaîtra à l'intérieur /mnt/nas_rescue/ afin que vous puissiez les copier directement sur un lecteur de sauvegarde USB externe.

• Et si votre Synology NAS disposait d'un « Synology Hybrid RAID (SHR) » avec des tailles de disques mixtes ? Synology SHR divise simplement les disques plus grands en plusieurs partitions (sda5, sda6) et crée un mdadm tableau sur chaque niveau de partition, puis rejoint ceux-ci md tableaux ensemble au sein d'un seul ** groupe de volumes LVM (vg1000)**. Courir sudo mdadm --assemble --scan --readonly et sudo vgchange -ay réassemble automatiquement les volumes SHR multiniveaux sur Ubuntu.
• Alternative GUI commerciale (Windows/macOS/Linux) : Si vous n'êtes pas à l'aise avec les commandes du terminal Linux ou si vous disposez d'un pool LVM QNAP complexe à allocation dynamique, UFS Explorer RAID Recovery ou ReclaiMe Free RAID Recovery peut inspecter tous les disques NAS connectés sur un PC Windows ou Linux en mode logiciel 100 % lecture seule, détecter automatiquement la taille de bande, la rotation de parité et les décalages LVM, et copier vos dossiers sans modifier un seul secteur sur le NAS. conduit.

ZFS (zpool) et les commandes de secours d'urgence Btrfs¶

Les plates-formes NAS modernes (volumes TrueNAS SCALE/CORE, Proxmox, Ubuntu Server, Unraid et Synology Btrfs) utilisent de plus en plus de systèmes de fichiers de copie sur écriture (CoW) au lieu des systèmes de fichiers existants. ext4. Si un ZFS zpool ou Btrfs pool refuse de monter ou provoque une panique du noyau au démarrage après une panne de courant ou une panne de disque, le montage normal échouera car le système d'exploitation tente de rejouer les transactions d'écriture endommagées. Vous devez utiliser des paramètres d'annulation de transaction en lecture seule.

1.ZFS (zpool) Récupération d'urgence (TrueNAS / Proxmox / Linux ZFS)¶

Si un pool ZFS indique FAULTED, UNAVAIL, ou plante le serveur (panique du noyau) à l'instant où vous essayez de l'importer après une panne de courant impure :

# 1. Inspect all visible ZFS pools on the connected disks without importing them
sudo zpool import

# 2. ALWAYS attempt a Read-Only Import first (prevents ZFS from writing to disks or replaying the ZIL/SLOG)
sudo zpool import -f -o readonly=on -R /mnt/zfs_rescue <pool_name>

# 3. What if a normal import causes a kernel panic or says 'damaged pool metadata'?
# Use -F (Rollback/Recovery Mode) with -n (Dry Run ONLY) to see if ZFS can rewind the last few seconds of corrupted Transaction Groups (TXGs):
sudo zpool import -F -n <pool_name>

# 4. Combine Read-Only + Safe Transaction Group Rewind (-F -o readonly=on) so no disk sectors are altered while you copy your data off:
sudo zpool import -f -F -o readonly=on -R /mnt/zfs_rescue <pool_name>

# 5. For heavily damaged pools where Space Map allocation tables are corrupt, disable space map loading prior to read-only import:
echo 1 | sudo tee /sys/module/zfs/parameters/zfs_recover
sudo zpool import -f -F -o readonly=on -R /mnt/zfs_rescue <pool_name>

Une fois monté sous /mnt/zfs_rescue, copiez vos ensembles de données en utilisant rsync ou zfs send avant de tenter d'importer le pool en lecture-écriture.

2. Récupération d'urgence Btrfs (Synology Btrfs / Unraid Cache Pool / Linux Btrfs)¶

Essayez plutôt de monter ou d'extraire le volume Btrfs dans un ordre progressif strict, de l'analyse la moins invasive à l'analyse la plus approfondie :

# Stage 1: Mount Read-Only without replaying the corrupted Journal Log Tree (fixes 80% of power-loss Btrfs mount failures)
sudo mount -t btrfs -o ro,norecovery /dev/sdX1 /mnt/btrfs_rescue
# (Note: on newer Linux kernels 5.11+, use: -o ro,rescue=nologreplay)

# Stage 2: Mount Read-Only using the backup Root Tree + ignoring bad checksums (for multi-drive or bit-rot corruption)
sudo mount -t btrfs -o ro,rescue=all /dev/sdX1 /mnt/btrfs_rescue
# (On older kernels: sudo mount -t btrfs -o ro,usebackuproot,nologreplay,degraded /dev/sdX1 /mnt/btrfs_rescue)

# Stage 3: If the volume still refuses to mount in the kernel, extract files directly in userspace without mounting using 'btrfs restore'
# First, list available backup tree roots:
sudo btrfs-find-root /dev/sdX1

# Then run 'btrfs restore' (strictly read-only userspace extractor) to dump all files to an external healthy drive:
sudo btrfs restore -v -i -m -S /dev/sdX1 /mnt/external_usb_backup/

Urgences liées au contrôleur RAID matériel : "Configuration étrangère" et cartes RAID mortes¶

Les serveurs d'entreprise (Dell PowerEdge avec cartes PERC, HPE ProLiant avec Smart Array, Lenovo ThinkSystem ou stations de travail avec contrôleurs Broadcom/LSI MegaRAID) utilisent des cartes RAID matérielles avec NVRAM intégrée et cache de batterie/supercondensateur (BBU / CacheVault).

1. Importer une configuration étrangère ou effacer une configuration (CRITIQUE)¶

Lorsqu'un disque se déconnecte momentanément ou que vous déplacez des disques dans un châssis de serveur de remplacement, l'écran de démarrage du BIOS Dell PERC ou LSI MegaRAID s'arrête et annonce : ** "Configuration(s) étrangère(s) trouvée(s) sur l'adaptateur."** * TOUJOURS sélectionner Import Foreign Configuration (ou Preview Foreign Configuration -> Import). La balise « Foreign » signifie simplement que le contrôleur RAID voit les métadonnées RAID existantes valides écrites sur les disques durs eux-mêmes (le Disk Data Format / DDF ou les secteurs de configuration LSI à l'extrémité des disques) qui diffèrent de l'état NVRAM actuel de la carte. L'importation lit la disposition de la baie directement sur les disques et remet votre disque virtuel en ligne sans perdre un seul octet. * NE JAMAIS sélectionner Clear Foreign Configuration ou Initialize Virtual Disk. L'effacement ou l'initialisation efface les métadonnées de la baie ou remet à zéro les lecteurs. * Avertissement d'exception : Si un seul disque est tombé en panne il y a trois semaines, vous avez continué à écrire de nouvelles données sur la baie dégradée pendant trois semaines, puis vous rebranchez cet ancien disque unique périmé depuis 3 semaines, n'importez PAS la configuration étrangère de ce seul disque obsolète par-dessus vos disques actifs sains ; à la place, remplacez ou clonez le disque obsolète.

2. Que se passe-t-il si la carte RAID matérielle elle-même meurt ?¶

Si la carte mère de votre serveur ou la carte contrôleur RAID matérielle PCIe subit une panne électronique et ne démarre pas : * Vous n'avez PAS besoin d'acheter exactement la même révision de carte mère et vos données sont toujours intactes sur les disques. * Achetez un contrôleur RAID de remplacement de la même famille de chipsets de contrôleur (par exemple, toute carte LSI/Broadcom MegaRAID SAS 2108/2208/3108 ou Dell PERC H710/H730/H740 peut lire les métadonnées DDF d'une ancienne carte PERC). * Installez la carte RAID de remplacement sur un PC en état de marche, connectez vos disques étiquetés dans l'ordre d'origine des baies, démarrez dans le BIOS du contrôleur (Ctrl+R ou Ctrl+H ou le menu UEFI HII), puis sélectionnez Importer une configuration étrangère. Le contrôleur lira la configuration RAID sur les disques et montera votre volume immédiatement.

Questions fréquemment posées¶

Guides associés¶

• Panne de disque dur et récupération de données
• Suppression accidentelle de fichiers, lecteur formaté et récupération de photos
• Sauvegardes informatiques : stratégie 3-2-1 et reprise après sinistre
• Échec de démarrage du système Linux et réparation GRUB
• Réponse d'urgence aux ransomwares et aux malwares
• Numéros d'urgence mondiaux

Sources vérifiées¶

• Organisation du noyau Linux (internationale) : Linux RAID (mdadm) Wiki (raid.wiki.kernel.org), Récupération d'un RAID logiciel défaillant et documentation du noyau Btrfs (btrfs.readthedocs.io sur btrfs rescue et btrfs restore).
• Projet de documentation OpenZFS (international) : zpool import Lecture seule et restauration du groupe de transactions (-F -o readonly=on) Référence administrative.
• Synology Inc. (Taiwan/International) : article officiel de la base de connaissances Synology KB-1079 (Comment puis-je utiliser un PC pour récupérer des données lorsque mon Synology NAS fonctionne mal avec Ubuntu mdadm et lvm2).
• Projet GNU / Free Software Foundation (International) : GNU ddrescue Manuel d'imagerie non destructive au niveau bloc des disques membres RAID dégradés.
• National Institute of Standards and Technology (NIST) (États-Unis) : Publication spéciale 800-86 et Storage Reliability Guidance on RAID Rebuild Exposure Windows and Uncorrigable Read Error (URE) Probabilities.