J'ai plusieurs TB dans des données personnelles très précieuses dans un zpool, auxquelles je ne peux pas accéder en raison de la corruption des données. Le pool a été initialement créé en 2009 ou à peu près sur un système FreeBSD 7.2 s'exécutant dans une machine virtuelle VMWare au-dessus d'un système Ubuntu 8.04. La machine virtuelle FreeBSD est toujours disponible et fonctionne correctement, seul le système d'exploitation hôte a été remplacé par Debian 6. Les disques durs sont rendus accessibles à la machine virtuelle invitée au moyen de périphériques SCSI génériques VMWare, soit 12 au total.
Il y a 2 piscines:
- zpool01: 2x 4x 500GB
- zpool02: 1x 4x 160GB
Celui qui fonctionne est vide, celui qui est cassé contient toutes les données importantes:
[user@host~]$ uname -a
FreeBSD host.domain 7.2-RELEASE FreeBSD 7.2-RELEASE #0: \
Fri May 1 07:18:07 UTC 2009 \
root@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64
[user@host ~]$ dmesg | grep ZFS
WARNING: ZFS is considered to be an experimental feature in FreeBSD.
ZFS filesystem version 6
ZFS storage pool version 6
[user@host ~]$ sudo zpool status
pool: zpool01
state: UNAVAIL
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
zpool01 UNAVAIL 0 0 0 insufficient replicas
raidz1 UNAVAIL 0 0 0 corrupted data
da5 ONLINE 0 0 0
da6 ONLINE 0 0 0
da7 ONLINE 0 0 0
da8 ONLINE 0 0 0
raidz1 ONLINE 0 0 0
da1 ONLINE 0 0 0
da2 ONLINE 0 0 0
da3 ONLINE 0 0 0
da4 ONLINE 0 0 0
pool: zpool02
state: ONLINE
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
zpool02 ONLINE 0 0 0
raidz1 ONLINE 0 0 0
da9 ONLINE 0 0 0
da10 ONLINE 0 0 0
da11 ONLINE 0 0 0
da12 ONLINE 0 0 0
errors: No known data errors
J'ai pu accéder à la piscine il y a quelques semaines. Depuis lors, j'ai dû remplacer à peu près tout le matériel de la machine hôte et installer plusieurs systèmes d'exploitation hôtes.
Je soupçonne qu'une de ces installations d'OS a écrit un chargeur de démarrage (ou autre) sur l'un (le premier?) Des 500 disques et a détruit des métadonnées de zpool (ou autre) - "ou autre", ce qui signifie qu'il ne s'agit que d'une idée très vague et ce sujet n'est pas vraiment mon fort côté ...
Il existe de nombreux sites Web, blogs, listes de diffusion, etc. sur ZFS. Je poste cette question ici dans l’espoir que cela m’aide à rassembler suffisamment d’informations pour une approche saine, structurée, contrôlée, informée et informée afin de récupérer mes données - et d’aider, espérons-le, une autre personne dans la même situation.
Le premier résultat de recherche lors de la recherche de 'zfs recover' dans Google est le chapitre Dépannage et récupération de données ZFS du Guide d'administration Solaris ZFS. Dans la première section relative aux modes de défaillance ZFS, le paragraphe "Données corrompues ZFS" indique:
La corruption de données est toujours permanente et nécessite une attention particulière lors de la réparation. Même si les périphériques sous-jacents sont réparés ou remplacés, les données d'origine sont définitivement perdues.
Quelque peu décourageant.
Cependant, le deuxième résultat de la recherche sur Google est le blog de Max Bruning, et là-bas, je lis
Récemment, j'ai reçu un courrier électronique d'une personne qui stockait 15 années de vidéo et de musique dans un pool ZFS de 10 To qui, après une panne de courant, est devenue défectueuse. Il n'avait malheureusement pas de sauvegarde. Il utilisait ZFS version 6 sur FreeBSD 7 [...] Après avoir passé environ une semaine à examiner les données sur le disque, j'ai pu restaurer la quasi-totalité de celles-ci.
et
Quant à la perte de vos données par ZFS, j'en doute. Je soupçonne que vos données sont là, mais vous devez trouver le bon moyen de les obtenir.
(ça ressemble tellement plus à quelque chose que je veux entendre ...)
Première étape : quel est exactement le problème?
Comment puis-je diagnostiquer pourquoi exactement le zpool est corrompu? Je vois qu'il existe une zdb qui ne semble pas officiellement documentée par Sun ou Oracle sur le Web. De sa page de manuel:
NAME
zdb - ZFS debugger
SYNOPSIS
zdb pool
DESCRIPTION
The zdb command is used by support engineers to diagnose failures and
gather statistics. Since the ZFS file system is always consistent on
disk and is self-repairing, zdb should only be run under the direction
by a support engineer.
If no arguments are specified, zdb, performs basic consistency checks
on the pool and associated datasets, and report any problems detected.
Any options supported by this command are internal to Sun and subject
to change at any time.
En outre, Ben Rockwood a publié un article détaillé et une vidéo de Max Bruning en parle (et de mdb) lors de la conférence des développeurs Open Solaris à Prague le 28 juin 2008.
L'exécution de zdb en tant que root sur le zpool cassé donne le résultat suivant:
[user@host ~]$ sudo zdb zpool01
version=6
name='zpool01'
state=0
txg=83216
pool_guid=16471197341102820829
hostid=3885370542
hostname='host.domain'
vdev_tree
type='root'
id=0
guid=16471197341102820829
children[0]
type='raidz'
id=0
guid=48739167677596410
nparity=1
metaslab_array=14
metaslab_shift=34
ashift=9
asize=2000412475392
children[0]
type='disk'
id=0
guid=4795262086800816238
path='/dev/da5'
whole_disk=0
DTL=202
children[1]
type='disk'
id=1
guid=16218262712375173260
path='/dev/da6'
whole_disk=0
DTL=201
children[2]
type='disk'
id=2
guid=15597847700365748450
path='/dev/da7'
whole_disk=0
DTL=200
children[3]
type='disk'
id=3
guid=9839399967725049819
path='/dev/da8'
whole_disk=0
DTL=199
children[1]
type='raidz'
id=1
guid=8910308849729789724
nparity=1
metaslab_array=119
metaslab_shift=34
ashift=9
asize=2000412475392
children[0]
type='disk'
id=0
guid=5438331695267373463
path='/dev/da1'
whole_disk=0
DTL=198
children[1]
type='disk'
id=1
guid=2722163893739409369
path='/dev/da2'
whole_disk=0
DTL=197
children[2]
type='disk'
id=2
guid=11729319950433483953
path='/dev/da3'
whole_disk=0
DTL=196
children[3]
type='disk'
id=3
guid=7885201945644860203
path='/dev/da4'
whole_disk=0
DTL=195
zdb: can't open zpool01: Invalid argument
Je suppose que l'erreur 'argument invalide' à la fin se produit parce que le zpool01 n'existe pas réellement: cela ne se produit pas sur le zpool02 en fonctionnement, mais il ne semble pas y avoir d'autre sortie ...
OK, à ce stade, il vaut probablement mieux poster ceci avant que l'article ne devienne trop long.
Peut-être que quelqu'un pourra me donner des conseils sur la manière d'avancer à partir d'ici et en attendant une réponse, je regarderai la vidéo, passerai en revue les détails de la sortie zdb ci-dessus, lirai l'article de Bens et essaierai de comprendre ce qui se passe. quoi...
20110806-1600 + 1000
Mise à jour 01:
Je pense avoir trouvé la cause fondamentale: Max Bruning a eu la gentillesse de répondre à un de mes mails très rapidement, demandant le résultat zdb -lll. Sur l’un des 4 disques durs de la «bonne» moitié de la réserve, la sortie est similaire à celle que j’ai affichée ci-dessus. Cependant, sur les 3 premiers des 4 lecteurs de la moitié «cassée», les zdbrapports failed to unpack labeldes étiquettes 2 et 3. Le quatrième lecteur du pool semble OK, zdbaffiche toutes les étiquettes.
Googler ce message d'erreur fait apparaître ce post . De la première réponse à ce post:
Avec ZFS, il y a 4 étiquettes identiques sur chaque vdev physique, dans ce cas un seul disque dur. L0 / L1 au début de vdev et L2 / L3 à la fin de vdev.
Les 8 disques de la piscine sont du même modèle, Seagate Barracuda 500GB . Cependant, je me souviens d’avoir démarré la piscine avec 4 disques, puis l’un d’eux est mort et a été remplacé sous garantie par Seagate. Plus tard, j'ai ajouté 4 autres lecteurs. Pour cette raison, les identificateurs de lecteur et de microprogramme sont différents:
[user@host ~]$ dmesg | egrep '^da.*?: <'
da0: <VMware, VMware Virtual S 1.0> Fixed Direct Access SCSI-2 device
da1: <ATA ST3500418AS CC37> Fixed Direct Access SCSI-5 device
da2: <ATA ST3500418AS CC37> Fixed Direct Access SCSI-5 device
da3: <ATA ST3500418AS CC37> Fixed Direct Access SCSI-5 device
da4: <ATA ST3500418AS CC37> Fixed Direct Access SCSI-5 device
da5: <ATA ST3500320AS SD15> Fixed Direct Access SCSI-5 device
da6: <ATA ST3500320AS SD15> Fixed Direct Access SCSI-5 device
da7: <ATA ST3500320AS SD15> Fixed Direct Access SCSI-5 device
da8: <ATA ST3500418AS CC35> Fixed Direct Access SCSI-5 device
da9: <ATA SAMSUNG HM160JC AP10> Fixed Direct Access SCSI-5 device
da10: <ATA SAMSUNG HM160JC AP10> Fixed Direct Access SCSI-5 device
da11: <ATA SAMSUNG HM160JC AP10> Fixed Direct Access SCSI-5 device
da12: <ATA SAMSUNG HM160JC AP10> Fixed Direct Access SCSI-5 device
Je me souviens cependant que tous les lecteurs avaient la même taille. En regardant les disques maintenant, cela montre que la taille a changé pour trois d'entre eux, ils ont été réduits de 2 Mo:
[user@host ~]$ dmesg | egrep '^da.*?: .*?MB '
da0: 10240MB (20971520 512 byte sectors: 255H 63S/T 1305C)
da1: 476940MB (976773168 512 byte sectors: 255H 63S/T 60801C)
da2: 476940MB (976773168 512 byte sectors: 255H 63S/T 60801C)
da3: 476940MB (976773168 512 byte sectors: 255H 63S/T 60801C)
da4: 476940MB (976773168 512 byte sectors: 255H 63S/T 60801C)
da5: 476938MB (976771055 512 byte sectors: 255H 63S/T 60801C) <--
da6: 476938MB (976771055 512 byte sectors: 255H 63S/T 60801C) <--
da7: 476938MB (976771055 512 byte sectors: 255H 63S/T 60801C) <--
da8: 476940MB (976773168 512 byte sectors: 255H 63S/T 60801C)
da9: 152627MB (312581808 512 byte sectors: 255H 63S/T 19457C)
da10: 152627MB (312581808 512 byte sectors: 255H 63S/T 19457C)
da11: 152627MB (312581808 512 byte sectors: 255H 63S/T 19457C)
da12: 152627MB (312581808 512 byte sectors: 255H 63S/T 19457C)
Donc, à première vue, ce n’était pas l’une des installations du système d’exploitation qui «a écrit un chargeur de démarrage sur l’un des disques» (comme je l’avais supposé auparavant), c’était en fait la nouvelle carte mère (un ASUS P8P67 LE ) créant un hôte de 2 Mo zone protégée à la fin de trois des lecteurs qui ont foiré mes métadonnées ZFS.
Pourquoi n'a-t-il pas créé de HPA sur tous les lecteurs? Je crois que c'est parce que la création de HPA se fait uniquement sur les lecteurs plus âgés avec un bug qui a été corrigé par la suite par une mise à jour du BIOS disque de Seagate: Lorsque tout cet incident a commencé il y a quelques semaines, j'ai couru de Seagate de SeaTools pour vérifier s'il y a tout ce qui ne va pas physiquement avec les disques (toujours sur l'ancien matériel) et j'ai reçu un message me disant que certains de mes disques ont besoin d'une mise à jour du BIOS. Alors que je tente maintenant de reproduire les détails exacts de ce message et le lien vers le téléchargement de la mise à jour du microprogramme, il semble que, depuis que la carte mère a créé le HPA, les deux versions de SeaTools DOS ne parviennent pas à détecter les disques durs en question - rapide invalid partitionou quelque chose de similaire. clignote quand ils commencent, c'est tout. Ironiquement, ils trouvent un ensemble de disques Samsung.
(J'ai sauté sur les détails douloureux, longs et finalement infructueux de maquiller dans un shell FreeDOS sur un système non mis en réseau.) Finalement, j'ai installé Windows 7 sur un ordinateur séparé pour pouvoir exécuter Windows SeaTools. version 1.2.0.5. Une dernière remarque à propos de DOS SeaTools: Ne vous donnez pas la peine d’essayer de les démarrer en mode autonome; investissez quelques minutes et créez une clé USB amorçable avec l’impressionnant CD Ultimate Boot , qui, en plus de DOS SeaTools, vous offre également de nombreux autres outils utiles.
Une fois démarré, SeaTools pour Windows affiche cette boîte de dialogue:
Les liens mènent au vérificateur de numéro de série (qui, pour une raison quelconque, est protégé par un captcha - "Utilisateurs invasifs") et à un article de la base de connaissances sur la mise à jour du microprogramme. Il y a probablement d'autres liens spécifiques au modèle de disque dur et à certains téléchargements, mais je ne suivrai pas ce chemin pour le moment:
Je ne vais pas me précipiter pour mettre à jour le micrologiciel de trois disques à la fois qui ont des partitions tronquées et qui font partie d'un pool de stockage cassé. C'est demander des ennuis. Pour commencer, il est fort probable que la mise à jour du firmware ne pourra pas être annulée - et cela pourrait irrémédiablement ruiner mes chances de récupérer mes données.
Par conséquent, la toute première chose que je vais faire ensuite est de créer une image des lecteurs et de travailler avec les copies. Il est donc possible de retrouver un original en cas de problème. Cela pourrait introduire une complexité supplémentaire, car ZFS remarquera probablement que des lecteurs ont été échangés (au moyen du numéro de série du lecteur ou encore d'un autre UUID ou autre), même s'il s'agit de copies dd très précises sur le même modèle de disque dur. De plus, le zpool n'est même pas en direct. Boy, cela pourrait devenir difficile.
L’autre option consisterait toutefois à utiliser les originaux et à conserver les disques en miroir comme sauvegarde, mais je risquerai d’être dépassé par la complexité lorsque les originaux ne fonctionnaient pas correctement. Naa, pas bon.
Afin de nettoyer les trois disques durs qui serviront de remplaçants imagés pour les trois disques avec le BIOS buggy dans le pool endommagé, je dois créer un espace de stockage pour les éléments qui y figurent maintenant, je vais donc aller au fond des choses la boîte de matériel et assemblez un zpool temporaire à partir de certains anciens lecteurs - que je peux également utiliser pour tester la façon dont ZFS traite l’échange de lecteurs DDD.
Cela pourrait prendre un certain temps ...
20111213-1930 + 1100
Mise à jour 02:
Cela a effectivement pris un certain temps. J'ai passé plusieurs mois avec plusieurs boîtiers d'ordinateurs ouverts sur mon bureau avec des piles de disques durs suspendus et j'ai également dormi quelques nuits avec des bouchons d'oreilles, car je ne pouvais pas éteindre la machine avant de me coucher, car elle exécutait une longue opération critique. . Cependant, j'ai finalement vaincu! :-) J'ai aussi beaucoup appris au cours du processus et j'aimerais partager cette connaissance avec tous ceux qui se trouvent dans une situation similaire.
Cet article est déjà beaucoup plus long que quiconque avec un serveur de fichiers ZFS inactif a le temps de le lire. Je vais donc entrer dans les détails ici et créer une réponse avec les constatations essentielles plus loin.
J'ai plongé dans la boîte de matériel obsolète pour rassembler suffisamment d'espace de stockage pour pouvoir déplacer les éléments hors des disques de 500 Go sur lesquels les disques défectueux étaient mis en miroir. Je devais également extraire quelques disques durs de leurs boîtiers USB afin de pouvoir les connecter directement via SATA. Il y avait d'autres problèmes non liés en jeu et certains des anciens disques ont commencé à tomber en panne lorsque je les ai remis en service, ce qui nécessitait le remplacement de zpool, mais je vais sauter à ce sujet.
Conseil: À un moment donné, environ 30 disques durs ont été impliqués. Avec autant de matériel, les empiler correctement est une aide énorme. Les câbles qui se détachent ou le disque dur qui tombe de votre bureau ne vous aideront sûrement pas et pourraient endommager davantage l’intégrité de vos données.
J'ai passé quelques minutes à créer des montages de disque dur en carton Make-Shift qui ont vraiment aidé à garder les choses en ordre:
Ironiquement, lorsque j'ai connecté les anciens disques pour la première fois, j'ai réalisé qu'il y avait un ancien zpool sur lequel j'avais dû créer pour tester avec une version plus ancienne de certaines, mais toutes les données personnelles disparues ne sont pas toutes disparues. quelque peu réduit, cela signifiait un décalage supplémentaire des fichiers.
Enfin, j'ai imité les lecteurs problématiques avec les lecteurs de sauvegarde, utilisé ceux de zpool et laissé ceux d'origine déconnectés. Les disques de sauvegarde ont un micrologiciel plus récent, au moins SeaTools ne signale aucune mise à jour du micrologiciel requise. J'ai fait la mise en miroir avec un simple dd d'un appareil à l'autre, par exemple
sudo dd if=/dev/sda of=/dev/sde
Je pense que ZFS a remarqué le changement de matériel (par un UUID de disque dur ou autre), mais ne semble pas s'en soucier.
Cependant, le zpool était toujours dans le même état, avec des répliques insuffisantes / des données corrompues.
Comme mentionné dans l'article HPA Wikipedia mentionné précédemment, la présence d'une zone protégée par l'hôte est signalée lors du démarrage de Linux et peut être examinée à l'aide de hdparm . Autant que je sache, il n'y a pas d'outil hdparm disponible sur FreeBSD, mais à ce moment-là, j'avais quand même FreeBSD 8.2 et Debian 6.0 installés en tant que système à double amorçage. J'ai donc démarré sous Linux:
user@host:~$ for i in {a..l}; do sudo hdparm -N /dev/sd$i; done
...
/dev/sdd:
max sectors = 976773168/976773168, HPA is disabled
/dev/sde:
max sectors = 976771055/976773168, HPA is enabled
/dev/sdf:
max sectors = 976771055/976773168, HPA is enabled
/dev/sdg:
max sectors = 976771055/976773168, HPA is enabled
/dev/sdh:
max sectors = 976773168/976773168, HPA is disabled
...
Le problème était donc évidemment que la nouvelle carte mère créait un HPA de quelques mégaoctets à la fin du lecteur, qui «masquait» les deux étiquettes ZFS supérieures, c'est-à-dire empêchait ZFS de les voir.
Traîner avec la HPA semble une entreprise dangereuse. Dans la page de manuel hdparm, paramètre -N:
Get/set max visible number of sectors, also known as the Host Protected Area setting.
...
To change the current max (VERY DANGEROUS, DATA LOSS IS EXTREMELY LIKELY), a new value
should be provided (in base10) immediately following the -N option.
This value is specified as a count of sectors, rather than the "max sector address"
of the drive. Drives have the concept of a temporary (volatile) setting which is lost on
the next hardware reset, as well as a more permanent (non-volatile) value which survives
resets and power cycles. By default, -N affects only the temporary (volatile) setting.
To change the permanent (non-volatile) value, prepend a leading p character immediately
before the first digit of the value. Drives are supposed to allow only a single permanent
change per session. A hardware reset (or power cycle) is required before another
permanent -N operation can succeed.
...
Dans mon cas, le HPA est supprimé comme suit:
user@host:~$ sudo hdparm -Np976773168 /dev/sde
/dev/sde:
setting max visible sectors to 976773168 (permanent)
max sectors = 976773168/976773168, HPA is disabled
et de la même manière pour les autres disques avec HPA. Si vous obtenez le mauvais lecteur ou que le paramètre de taille que vous spécifiez ne soit pas plausible, hdparm est suffisamment intelligent pour comprendre:
user@host:~$ sudo hdparm -Np976773168 /dev/sdx
/dev/sdx:
setting max visible sectors to 976773168 (permanent)
Use of -Nnnnnn is VERY DANGEROUS.
You have requested reducing the apparent size of the drive.
This is a BAD idea, and can easily destroy all of the drive's contents.
Please supply the --yes-i-know-what-i-am-doing flag if you really want this.
Program aborted.
Après cela, j'ai redémarré la machine virtuelle FreeBSD 7.2 sur laquelle zpool avait été créé à l'origine et zpool status a signalé à nouveau un pool de travail. YAY! :-)
J'ai exporté le pool sur le système virtuel et l'ai réimporté sur le système hôte FreeBSD 8.2.
Quelques mises à niveau matérielles plus importantes, une autre permutation de carte mère, une mise à jour de pool ZFS vers ZFS 4/15, un nettoyage en profondeur et maintenant mon zpool se compose de 8 x 1 To plus de 8 x 500 Go de pièces raidz2:
[user@host ~]$ sudo zpool status
pool: zpool
state: ONLINE
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
zpool ONLINE 0 0 0
raidz2 ONLINE 0 0 0
ad0 ONLINE 0 0 0
ad1 ONLINE 0 0 0
ad2 ONLINE 0 0 0
ad3 ONLINE 0 0 0
ad8 ONLINE 0 0 0
ad10 ONLINE 0 0 0
ad14 ONLINE 0 0 0
ad16 ONLINE 0 0 0
raidz2 ONLINE 0 0 0
da0 ONLINE 0 0 0
da1 ONLINE 0 0 0
da2 ONLINE 0 0 0
da3 ONLINE 0 0 0
da4 ONLINE 0 0 0
da5 ONLINE 0 0 0
da6 ONLINE 0 0 0
da7 ONLINE 0 0 0
errors: No known data errors
[user@host ~]$ df -h
Filesystem Size Used Avail Capacity Mounted on
/dev/label/root 29G 13G 14G 49% /
devfs 1.0K 1.0K 0B 100% /dev
zpool 8.0T 3.6T 4.5T 44% /mnt/zpool
En dernier mot, il me semble que les pools ZFS sont très, très difficiles à tuer. Les gars de Sun qui ont créé ce système ont toutes les raisons de l'appeler comme le dernier mot des systèmes de fichiers. Le respect!