Un NAS Synology ou QNAP qui signale un disque défaillant n’est pas encore une perte de données. Ce qui décide souvent du résultat, ce n’est pas la panne elle-même mais ce qui est fait dans les heures qui suivent. Entre une réinitialisation qui efface les métadonnées RAID, une reconstruction lancée sans vérifier l’état des disques restants et un contrôle de fichiers relancé sur un volume déjà fragile, chaque décision prise dans la précipitation réduit les chances de récupération. Voici les erreurs qui transforment le plus souvent une panne récupérable en perte définitive.
Ce qui se passe réellement quand un disque tombe en panne
Un NAS Synology ou QNAP repose sur une grappe RAID logicielle gérée par le système du boîtier (DSM chez Synology, QTS ou QuTS hero chez QNAP). Quand un disque tombe en panne, le NAS passe en mode dégradé : il continue de fonctionner en recalculant à la volée les données manquantes, grâce à la parité (SHR, RAID 5, RAID 6) ou à la copie miroir (RAID 1, RAID 10). Le volume reste accessible, mais toute la charge repose désormais sur les disques survivants.
C’est précisément dans cette fenêtre de vulnérabilité que la majorité des pertes définitives se produisent — pas à cause de la panne initiale, mais à cause d’une manipulation effectuée dans la précipitation. Une part des NAS qui arrivent en laboratoire avec des données perdues auraient été récupérables si aucune action n’avait été tentée après la panne.
Les erreurs qui aggravent la situation
- Relancer une reconstruction sans sauvegarde préalable. Remplacer le disque et cliquer sur « Réparer » semble simple, mais une reconstruction impose à chaque disque survivant une lecture intégrale de tous ses secteurs, parfois pendant plusieurs jours. Si un second disque présente déjà des secteurs défectueux, il peut tomber en panne pendant l’opération et faire basculer le volume de l’état « dégradé » à l’état « crashé », c’est-à-dire inaccessible. Le réflexe correct est de sauvegarder toutes les données encore accessibles avant de lancer la moindre reconstruction, même si l’interface invite à réparer immédiatement.
- Confondre réinitialisation et reformatage. Chez QNAP, plusieurs options coexistent : réinitialisation logicielle (les données sont conservées), restauration des paramètres d’usine, et réinitialisation complète avec reformatage des volumes (les données sont détruites). Chez Synology, le risque équivalent survient quand un pool de stockage « crashé » est supprimé puis recréé sur les mêmes disques en pensant « réparer » le volume : cette opération écrase les métadonnées RAID (le superbloc mdadm) nécessaires à la reconstitution de la grappe.
- Retirer ou intervertir des disques sans précaution. Sur un RAID logiciel (mdadm pour DSM et QTS, ZFS pour QuTS hero), l’ordre physique des disques n’est en principe pas critique. Mais dès qu’un disque est retiré pendant que le NAS fonctionne, le système le marque comme absent et toute écriture ultérieure crée un écart de synchronisation. Le réinsérer plus tard déclenche alors une resynchronisation, avec les risques que cela comporte sur des disques déjà sollicités — seule une réinsertion immédiate, sans aucune écriture entre-temps, évite ce déclenchement.
- Utiliser un disque de remplacement incompatible. Deux erreurs reviennent régulièrement : insérer un disque de capacité inférieure à celle des autres membres de la grappe (le NAS refuse alors la reconstruction), ou utiliser un disque SMR à la place d’un disque CMR. Les disques SMR, optimisés pour la densité de stockage plutôt que pour l’écriture soutenue, saturent rapidement leur cache pendant une reconstruction RAID intensive — ce qui provoque des timeouts et peut faire éjecter le disque en pleine opération. La distinction CMR/SMR n’étant pas toujours explicite dans la désignation commerciale, la référence exacte doit être vérifiée auprès du fabricant avant tout remplacement.
- Lancer un contrôle de fichiers sur un volume dégradé. Un contrôle d’intégrité (équivalent d’un FSCK ou d’un CHKDSK) est bénin sur un volume sain. Sur un volume dégradé, il interprète les données manquantes comme des corruptions : il peut supprimer des entrées de répertoire, tronquer des fichiers ou réécrire des arbres de métadonnées — des modifications irréversibles qui éliminent les traces nécessaires à une récupération ultérieure. Le système de fichiers Btrfs, utilisé par défaut sur les modèles Synology récents, y est particulièrement sensible.
- Laisser le NAS tourner en mode dégradé sans agir. À l’inverse de la précipitation, l’inaction prolongée est tout aussi risquée. Les disques restants subissent une charge accrue, ce qui accélère leur usure et augmente la probabilité d’une seconde panne — fatale en RAID 5 ou SHR-1. Le risque ne se limite pas à une panne mécanique : chaque lecture en mode dégradé oblige le système à recalculer les données absentes à partir de la parité, et une erreur de lecture non récupérable (URE) rencontrée pendant ce recalcul rend le bloc concerné définitivement perdu.
Le cas particulier des NAS chiffrés
Quand le chiffrement est actif, une panne change de nature : les disques peuvent être physiquement intacts et pourtant totalement inexploitables sans la clé. Sur Synology DSM, le chiffrement des dossiers partagés repose sur une clé exportable (.key) ; si elle a été confiée uniquement au gestionnaire de clés intégré et jamais sauvegardée sur un support externe, elle disparaît avec le boîtier en panne. Les modèles récents proposent aussi un chiffrement de volume basé sur LUKS, soumis à la même logique. Sur QNAP QTS, le fonctionnement est comparable ; sur QuTS hero, le chiffrement natif ZFS ajoute une couche de gestion de clés distincte.
La première question à se poser face à un NAS chiffré en panne est simple : le chiffrement était-il activé, et la clé existe-t-elle en dehors du NAS ? Cette information conditionne toute la stratégie de récupération et doit être communiquée dès le premier contact avec un laboratoire.
Ce qu’il faut faire concrètement
La marche à suivre dépend de la criticité des données et de l’existence d’une sauvegarde. Si une sauvegarde récente et vérifiée existe, la situation reste maîtrisée : on peut remplacer le disque défaillant et lancer la reconstruction en suivant la procédure du fabricant, en vérifiant au préalable l’état S.M.A.R.T. des disques survivants. Si aucune sauvegarde exploitable n’existe, la prudence s’impose : copier ce qui reste accessible sur un support externe avant toute manipulation. Si le volume est déjà en état « crashé » et inaccessible, la meilleure décision reste souvent de ne rien faire de plus — éteindre proprement le NAS, étiqueter chaque disque avec son numéro de baie d’origine, et contacter un laboratoire spécialisé. Toute réinitialisation, recréation de pool ou reconstruction tentée sur un volume déjà crashé risque d’écraser les métadonnées nécessaires à la récupération.
Quand faire appel à un laboratoire spécialisé
Plus le nombre de tentatives de réparation est élevé avant l’arrivée en laboratoire, plus la récupération devient longue, complexe et incertaine — certains NAS reçus en atelier contenaient des données intégralement récupérables à l’origine, mais sont arrivés après deux ou trois tentatives ayant progressivement détruit les structures logiques du volume. Dès qu’un NAS ou un serveur RAID passe en état d’erreur avec des données critiques et sans copie de secours, chaque manipulation supplémentaire réduit les chances de récupération : mieux vaut couper l’alimentation et attendre un diagnostic professionnel que de multiplier les tentatives sur des données sans filet.
Une panne de NAS Synology ou QNAP n’est presque jamais définitive au moment où elle se produit. Elle le devient souvent une ou deux manipulations plus tard.