Récupération des données perdues dans un NAS RAID-1

Un «NAS» (Network Attached Storage) est un mini-ordinateur dans un boitier contenant plusieurs disques dûrs et permettant l'accès partagé à des fichiers via un protocole réseau (SMB, FTP...). C'est une solution clé en main, assez facile d'installation, très pratique pour mettre en commun les fichiers d'une famille, et elle propose souvent des fonctionnalités supplémentaires telles que des copies périodiques, un serveur FTP, un client torrent, etc...

Cet article explique comment les données du NAS ci-dessous ont failli disparaître et pourquoi avoir un NAS n'est paradoxalement pas l'endroit le plus sûr pour vos données. La situation exposée est un peu extrême mais elle est suffisamment vraie pour poser de sérieuses questions.

Remise en contexte

Commençons par quelques sempiternelles maximes d'érudits digitaux. «Je ne veux pas perdre toutes mes photos» implique que vos données sont précieuses. «Le stockage cloud est pratique et gratuit, donc je mets tout dedans» sans savoir où, ni comment, ni combien de temps, ni pourquoi tout au même endroit. Après tout, «je n'ai rien à cacher» donc «DropBox ne fera rien de mes données». Jennifer et Edward ne sont pas d'accords. Enfin, quand un service s'arrête, vous avez souvent 30 jours pour réagir, si vous réagissez.

Le cloud est très présent en 2020 et fait l'objet, à raison, de vives débats géo-politiques concernant les pratiques des géants du numérique essentiellement américains. Mais il est toujours possible de s'auto-héberger pour contrôler totalement ses données. Les NAS font partie des solutions disponibles et ça ne coûte pas si cher jusqu'au jour de la panne inattendue.

Nature de la panne

Le NAS est configuré en RAID-1 et sans cryptage. Autrement dit, les deux disques contiennent les mêmes données, et la lecture sur les deux disques à la fois est plus rapide que l'écriture simultanée sur les deux disques.

Un NAS comporte un bouton pour le lancer. Il a démarré puis au bout de cinq secondes, le système s'est coupé et les disques dûrs sont partis en roue libre jusqu'à leur arrêt. Il n'y a aucun signe extérieur de panne, pas d'odeur, pas de bruit, pas de lumière, mais surtout il ne démarre plus...

Je l'ai démonté sans voir de condensateur mort par exemple. Tout semble «normal».

Les disques dûrs branchés en SATA sont amovibles. Dans un précédent article, nous avions vu comment il fallait faire pour lire le contenu d'un disque nu. Évidemment, le NAS ne tourne pas sur Windows, car sa licence payante renchérirait le prix du produit et ce n'est pas nécessairement la meilleure solution technique. Il est donc malin d'utiliser un LiveCD Linux pour pouvoir lire les partitions Linux (formattées en EXT4 par exemple) et Windows éventuellement (FAT32 et NTFS sont a minima disponibles en lecture).

En USB, sans surprise, les disques ne sont pas reconnus par Windows :

En mode Linux, on retrouve des informations laissant penser que le matériel est techniquement accessible, donc non défaillant :

• Analyse du disque droit :

[root@localhost ecrucru]# fdisk -l
Disque /dev/sdb: 1000.2 Go, 1000204886016 octets
255 heads, 63 sectors/track, 121601 cylinders
Units = cylindres of 16065 * 512 = 8225280 bytes
Disk identifier: 0x00086a53

Périphérique Amorce    Début         Fin      Blocs    Id  Système
/dev/sdb1               1         254     2040254   83  Linux
/dev/sdb2             255      121602   974722329   83  Linux

Disque /dev/dm-0: 998.1 Go, 998114328576 octets
255 heads, 63 sectors/track, 121347 cylinders
Units = cylindres of 16065 * 512 = 8225280 bytes
Disk identifier: 0x00000000

Disque /dev/dm-0 ne contient pas une table de partition valide

• Analyse du disque gauche :

[root@localhost ecrucru]# fdisk -l
Disque /dev/sdc: 1000.2 Go, 1000204886016 octets
255 heads, 63 sectors/track, 121601 cylinders
Units = cylindres of 16065 * 512 = 8225280 bytes
Disk identifier: 0x000d3a8d

Périphérique Amorce    Début         Fin      Blocs    Id  Système
/dev/sdc1               1         254     2040254   83  Linux
/dev/sdc2             255      121602   974722329   83  Linux


[root@localhost ecrucru]# blkid -c /dev/null
/dev/sdc1: UUID="ac102e95-1ea8-06d5-8265-24cfa34cd30b" TYPE="mdraid"

Il est clairement évident que la panne est électrique au niveau du boitier. La solution est de mettre les deux disques dans un autre boitier, encore faut-il en avoir un sous la main. Qui aurait pensé à la perte de données via la perte du boîtier hôte ?

Échec du spécialiste

Chez disque chronométré, les experts en récupération de données passés au JT de Claire Chazal ont peut-être ce qu'il faut pour reconstruire le boitier. Après tout, c'est leur métier et les disques dûrs sont sans défaut. Un PC, deux prises SATA, leur magie et hop, je retrouve mes données brutes dans un nouveau disque dûr sans aucun Linux/NAS intégré. Tel est l'objectif souhaité.

Première déconvenue, le devis pour des disques dûrs RAID est payant. Et il coûte 125€ par disque ! Par chance, c'était gratuit grâce à une offre promotionnelle pendant l'été.

Deuxième déconvenue, le devis final affiche 500€ mais surtout il propose le démontage en salle blanche pour reconstruire le système RAID. Ils n'ont donc absolument rien écouté de mes explications (panne électrique du boîtier). Je ne suis pas spécialiste, mais je serais bien curieux de savoir ce qui les a poussé à vouloir faire de la chirurgie électronique. Si un disque est défaillant, il suffit d'en mettre un neuf vide pour qu'il se reconstruise tout seul. Autrement dit, j'aurais deux disques dûrs simultanément en panne. Une hérésie statistique.

Troisième déconvenue, les montants sont exprimés en hors taxe, donc ajouter +20%.

Résumons : 300€ pour un devis qui ne correspond pas au problème + 600€ de réparations inutiles + 125€ pour un nouveau disque SATA/USB = 1025€ TTC de soucis. C'est facilement trois fois le prix original du produit... Le besoin est de relancer un système pour le rendre fonctionnel et pouvoir extraire les données comme à l'accoutumée. Rien de plus, le but n'est pas de récupérer un fichier LVM par chirurgie.

À ce moment là, je ne savais pas vraiment comment étaient organisées les données. Certains NAS ont peut-être le Linux à part, mais ici tout est mélangé. Il est donc certain que démonter les disques est l'erreur à ne pas faire. Si le disque est mal récupéré, les données seront foutues et ce n'est pas acceptable.

Solution retenue : se débrouiller comme un grand

Le NAS est basé sur plein de logiciels open-source, car il y a une obligation d'afficher les licences au sein du produit. Je suis convaincu qu'il y a un Linux dedans sans surcouche propriétaire Iomega/EMC/Dell (et tant mieux !). Il faut donc brancher les disques de façon à ce que les partitions soient «montées», c'est-à-dire chargées dans la configuration permettant de les utiliser.

J'ai la chance d'avoir un vieux PC avec 2 prises SATA libres, car le PC boote habituellement sur des disques IDE ! Je crois même que c'est en changeant la pile bouton de la carte mère que j'ai vu l'inscription salvatrice à côté des prises.

Il ne reste plus qu'à acheter de la connectique SATA et électrique, puis de tout monter.

Les disques sont montés à l'extérieur du PC hôte, car il n'y a plus d'emplacement libre à l'intérieur. Techniquement, ce n'est pas un problème. Il faut simplement que ça ne tire pas sur les fils, d'où ce cocasse échaffaudage.

Pour avoir un Linux hôte sans l'installer, j'utilise Lubuntu en version 16.04.1 LiveCD. Il est léger en mémoire et dispose de paquets intéressants au besoin, notamment ceux-là :

• mdadm
• smartmontools
• gsmartcontrol
• gnome-screenshot
• samba
• vim
• SeaGate tools (Windows)

Dans la liste des matériels identifiés par le système, on retrouve nos deux disques dûrs SeaGate du NAS branchés en SATA, ce qui est bien la preuve encore de leur parfait fonctionnement.

Les disques sont identifiés par les devices /dev/sdb et /dev/sdc, le chiffre terminal servant à dénombrer les partitions. Dans GParted, on voit qu'ils sont identiques avec une partition de 2 Go pour Linux et le reste pour stocker les données au format Linux Raid Member.

Dans l'éventualité où vous souhaiteriez copier ou restaurer une partition, il faut utiliser respectivement les commandes modèles suivantes :

sfdisk -d /dev/sdb1 > /votre/chemin/partition.sdb1

sfdisk /dev/sdb1 < /votre/chemin/partition.sdb1

Il faut savoir que le NAS propose de sélectionner le mode RAID depuis son interface web. Il y a RAID-0 pour l'espace (2 To non redondants) ou RAID-1 pour la configuration en miroir (1 To redondant). Ainsi, il n'y a pas de partition à nouveau, tout est encapsulé par cette partition LVM qui traduit un fonctionnement en «volumes logiques».

Installez le paquet «mdadm».

Initialement, j'avais incorrectement voulu créer un montage RAID alors qu'il existait déjà. Un message m'avertissement m'en a dissuadé. Dans l'éventualité où vous aimeriez mettre deux disques en RAID à partir de zéro, il faudrait lancer la commande suivante :

sudo su
mdadm --create --verbose /dev/md1 --level=mirror --raid-devices=2 /dev/sdb1 /dev/sdc1
mdadm --create --verbose /dev/md2 --level=mirror --raid-devices=2 /dev/sdb2 /dev/sdc2
mdadm --detail --scan >> /etc/mdadm/mdadm.conf

Comme la configuration a toujours été faite, il faut simplement assembler les volumes pour les rendre utilisables par le pilote Raid de Linux. Montez les volumes sur un nouveau point de montage nommé /dev/md*. Les partitions des deux disques sont mises en vis-à-vis :

mdadm --assemble /dev/md1 /dev/sdb1 /dev/sdc1
mdadm --assemble /dev/md2 /dev/sdb2 /dev/sdc2

Ces commandes font apparaître des icônes sur le bureau. L'espoir de retrouver les fichiers ne fait que croître.

Dans le gestionnaire de disques, on voit apparaître les miroirs RAID comme des disques individuels. Les partitions /dev/sd*1 devenues /dev/md1 sont le Linux du NAS (format EXT2) et les partitions /dev/sd*2 devenues /dev/md2 sont toutes mes données (format LVM). On comprend alors que le NAS est capable de se mettre à jour sans toucher aux données.

On peut vérifier le bon fonctionnement du RAID :

# cat /proc/mdstat
Personalities : [raid1]
md2 : active raid1 sdb2[0] sdc2[1]
974722192 blocks super 1.0 [2/2] [UU]

md1 : active raid1 sdb1[0] sdc1[1]
2040128 blocks [2/2] [UU]

unused devices: <none>

On investigue les dossiers et on trouve les fichiers dans un dossier Samba. C'est le logiciel qui permet le partage de fichiers sur le réseau sous Linux. Il ne s'agit donc bien pas d'un logiciel propriétaire.

/media/lubuntu/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/samba

Configurer Samba est assez simple. Les problèmes à l'usage viennent surtout des autorisations :

sudo su
vim /etc/samba/smb.conf
systemctl restart smbd.service nmbd.service
exit

La configuration à définir est :

[restore]
path = /media/lubuntu/
read only = yes
browseable = yes
guest ok = yes
force user = lubuntu
force group = lubuntu

Il faut également configurer l'adresse IP du Linux hôte si elle n'a pas été attribuée par votre box Internet sur le réseau local. Sur l'exemple suivant, l'IP locale est 192.168.0.12 :

Pour tester que tout va bien, il faut aller sur un autre PC et taper \\192.168.0.12 dans l'explorateur de fichiers. Le contenu du dossier Samba est alors ouvert à tous les vents. En effet, le Linux hôte s'est substitué à tout ce qu'il y avait dans la partition /dev/md1 originale du NAS sur laquelle nous n'avons pas booté. Les accès sont larges pour tout récupérer.

Heureusement que le cryptage n'a pas été utilisé. Ça aurait été un niveau de complexification bien encombrant.

Petite remarque importante : les noms de fichiers Windows sont tronqués lorsqu'ils sont trop longs. Ainsi, si vous copiez tous les fichiers, les plus profonds se présentront de la façon suivante sans aucune alerte. La solution est d'améliorer vos fichiers ou de déplacer la racine de Samba dans le fichier de configuration.

La copie consomme toute la bande passante de votre réseau, ou plûtot toute la vitesse de lecture/écriture de vos disques selon le principe du maillon faible. 100 Mbps à 80%, ça fait du 9.5 Mo/s. Ainsi, pour copier 500 Go par exemple, il faut... 15 heures !

Morale de l'histoire

Avec ce protocole de récupération de données, on voit que créer un NAS maison est finalement assez facile dès lors que vous avez une machine sous Linux et deux disques dûrs libres. Mais avoir un petit NAS portable est plus pratique, plus discret et plus économe en énergie.

Les données étaient profondémment enfuies, sous un NAS, un Linux embarqué, une couche RAID et heureusement pas de cryptage. Le coût exhorbitant de la réparation fait qu'il est mieux d'avoir des disques dûrs nus, dockables en USB, synchronisés en plusieurs exemplaires de marques différentes et stockés en plusieurs lieux géographiques différents. J'ai invité quelqu'un qui a le même NAS à faire une copie sur disque nu avant qu'il ne lui arrive la même tragédie.

Cette démonstration est la preuve que le démontage en salle blanche était une parfaite ineptie au tarif prohibitif, mais qui n'en demeure pas moins une opération longue nécessitant une honnête rémunération. Espérons que cette procédure deviendra une de leur prestation, car il est peu probable que des personnes «lambda» se soient cassé le nez pendant autant d'heures sans rien y connaître a priori. Il y a comme une barrière technologique avec ce genre d'outils.

J'espère enfin que cet article vous aura intéressé. N'hésitez pas à m'en faire part via le formulaire de contact situé tout en haut de la page.

Documentation additionnelle

Voici enfin des articles pour prolonger l'expérience :

• https://raid.wiki.kernel.org/index.php/Why_RAID%3F
• https://raid.wiki.kernel.org/index.php/Introduction
• https://raid.wiki.kernel.org/index.php/RAID_setup
• https://raid.wiki.kernel.org/index.php/Detecting,_querying_and_testing
• https://raid.wiki.kernel.org/index.php/Recovering_a_failed_software_RAID
• http://www.gnu.org/software/ddrescue/ddrescue.html

Dernière modification le 18 octobre 2020 à 01:18