Contenu | Rechercher | Menus

Annonce

Si vous avez des soucis pour rester connecté, déconnectez-vous puis reconnectez-vous depuis ce lien en cochant la case
Me connecter automatiquement lors de mes prochaines visites.

À propos de l'équipe du forum.

#1 Le 09/12/2013, à 12:43

Jobs

Récupérer données sur une partition GUID/GPT/ext4 plantée

Bonjour à tous, je vous lis et consulte cette mine d'information qu'est ubuntu-fr quotidiennement et je trouve en général réponse à mes questions, mais là je butte.
C'est ce qui m'a incité à m'inscrire et à solliciter la communauté pour essayer de sortir d'un problème de données à récupérer.

Voici le contexte :
Un MacMini Serveur avec 2 DD 500Go identiques et avec un formatage et schémas de partitions clonés (mais pas en RAID) de sda sur sdb.
Ça ressemble à ça :

GPT fdisk (gdisk) version 0.5.1

Partition table scan:
  MBR: hybrid
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with hybrid MBR; using GPT.
Disk /dev/sda: 976773168 sectors, 465.8 GiB
Disk identifier (GUID): 00001DD3-4477-0000-BD3B-00001C530000
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 976773134
Total free space is 5076 sectors (2.5 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1              40          409639   200.0 MiB   EF00  EFI system partition
   2          409640        83473739   39.6 GiB    AF00  Customer
   3        83473740       184892084   48.4 GiB    0700  
   4       184892085       203864849   9.0 GiB     8200  
   5       203864850       976768064   368.5 GiB   0700  

Le contenu de la partition sda5 est partagé via NFS à un autre ordi et un rsync (via cron) du contenu est effectué sur sdb5 plusieurs fois par jour.
Cette partition contient environ 190Go de données (moitié plein, donc), principalement web (html/php/jpeg), donc plusieurs centaines de milliers de fichiers.

Historique :
Rsync (cron à 0h00) de sda5 sur sdb5 fait tomber le serveur NFS sur sda5 > Retour à la normale sans intervention (la nuit)
Rsync (cron 6h00) de sda5 sur sdb5 fait re-tomber le serveur NFS sur sda5 > Constat du problème (serveur web planté) : redémarrage d'apache sur connecté au NFS > retour à la normale
Rsync (cron 10h00) de sda5 sur sdb5 fait re-tomber le serveur NFS sur sda5 > Tentative de redémarrage serveur NFS : Fail > Redémarrage machine : Ne redémarre pas.
Message à l'écran du petit serveur : sdb5 annoncée irrécupérable au boot => ignorer

Le problème :
Je me retrouve avec sdb5 en panne, ce qui en soi n'est pas bien méchant puisque c'est un disque de backup… mais au redémarrage quelque chose de très bizarre s'est produit :
La partition sda5 se retrouve avec le même contenu qu'en février 2012 (oui, on est en décembre 2013 ! Soit des données strictement telles que 20 mois plus tôt, ce qui pourrait correspondre avec l'installation de GIT sur la machine). Bilan : plusieurs 10aines de Go de données (principalement des petites photos) disparues. Le graph' d'occupation volume de Cacti est formel également sur ce point. La machine avait pourtant déjà été redémarrée plusieurs fois depuis 2012 au moins en mai 2013, sans problème.
Bref, pour une raison qui m'échappe totalement, je me retrouve avec beaucoup de données en moins sur mon disque de travail et la partition de backup sdb5 est en panne.

Tentatives de résolution :
J'ai fait appel à un ami plus calé que moi, et voici ce qu'il a tenté (historique terminal, je n'ai pas le résultat des commandes)

sudo apt-get install smartmontools
sudo smartctl -t short /dev/sdb
sudo smartctl -l selftest /dev/sdb
sudo smartctl -a /dev/sdb
sudo apt-get install gtp-fdisk
sudo apt-get install gdisk
sudo tune2fs -l /dev/sdb5 | grep Block
sudo debugfs
sudo e2fsck -f -c -v /dev/sdb5
sudo fsck /dev/sdb5
sudo mke2fs -n /dev/sdb
sudo mke2fs -n /dev/sdb5
sudo fsck -y -b 32768 /dev/sdb5
sudo mke2fs -n /dev/sdb5
sudo fsck -y -b 78675968 /dev/sdb5
sudo e2fsck -f -c -v /dev/sdb5

> Aucune amélioration, et j'espère que trop d'erreurs n'ont pas été faites…

À la lecture des posts de sauvetage sur le forum (notamment celui de rmy), j'ai donc décidé de ne pas risquer plus et de suivre une procédure plus sure avant de faire appel à vous.

Où j'en suis :
- Démontage du disque dur
- Montage en USB sur une autre machine en démarrage live USB
- Clonage de l'ex /dev/sdb5 (qui est désormais /dev/sdc5 en USB) sur un fichier .img dans DD externe, via ddrescue 1.16
- J'avais hésité à cloner tout le disque… Mais me suis dit que je pourrai le faire dans un second temps si nécessaire
- Le clonage se termine, après plus de 5 jours de copie (à ±1Mo/s) et affiche 261 erreurs pour une taille d'erreur de 9505kb (ce qui me paraît peu étant donné la taille de la partition)).

Les messages affichés par gparted à date sont :

File System : ext4
Size : 368,55GiB
Flags : msfdata
Path : /dev/sdc5
Status : Not mounted
Label :
UUID : 3edd4819-eb11-4c83-9311-f37f2683b36
First sector : 203864850
Last sector : 976768064
Total sectors : 772903215

Warning:
e2label: Attempt to read block from filesystem resulted in short read while trying to open /dev/sdc5
Couldn't find valid filesystem superblock.

Couldn't find valid filesystem superblock.

dumpe2fs 1.42.8 (20-Jun-2013)
dumpe2fs: Attempt to read block from filesystem resulted in short read while trying to open /dev/sdc5

Unable to read the contents of this filesystem!
Because of this some of operations may be unavailable.

The cause might be a missing software package.
The following list of software packages is required for ext4 filesystem support: e2fsprogs v1.41+.

J'en arrive donc à pouvoir tenter d'intervenir sur l'image clonée de la partition sdb5… et les pistes me semblent nombreuses.
Peut-être puis-je récupérer le format de partition de la /dev/sda5 qui fonctionne toujours et le restaurer sur la sdc5 actuelle qui ne monte pas ? Les superblocks étaient-ils à la même place sur le clone initial sda/sdb ?

Bref, je m'en remets aux spécialistes du forum pour avancer dans le meilleur sens possible. Je suis donc à l'écoute de vos recommandations.

Merci pour votre aide.

Hors ligne