Ho diversi TB di dati personali molto preziosi in uno zpool a cui non posso accedere a causa della corruzione dei dati. Il pool è stato originariamente creato nel 2009 circa su un sistema FreeBSD 7.2 in esecuzione all'interno di una macchina virtuale VMWare su un sistema Ubuntu 8.04. La VM di FreeBSD è ancora disponibile e funziona correttamente, solo il sistema operativo host è ora cambiato in Debian 6. I dischi rigidi sono resi accessibili alla VM guest tramite dispositivi SCSI generici VMWare, 12 in totale.
Ci sono 2 piscine:
- zpool01: 2x 4x 500 GB
- zpool02: 1x 4x 160 GB
Quello che funziona è vuoto, quello rotto contiene tutti i dati importanti:
[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
Sono stato in grado di accedere alla piscina un paio di settimane fa. Da allora, ho dovuto sostituire praticamente tutto l'hardware del computer host e installare diversi sistemi operativi host.
Il mio sospetto è che una di queste installazioni del sistema operativo abbia scritto un bootloader (o qualsiasi altra cosa) su una (la prima?) Delle unità da 500 GB e abbia distrutto alcuni metadati di zpool (o qualunque altra cosa) - "o qualunque cosa", il che significa che questa è solo un'idea molto vaga e quel soggetto non è esattamente il mio lato forte ...
Ci sono molti siti Web, blog, mailing list, ecc. Su ZFS. Pubblico questa domanda qui nella speranza che mi aiuti a raccogliere informazioni sufficienti per un approccio sano, strutturato, controllato, informato e ben informato per recuperare i miei dati e, si spera, aiutare qualcun altro nella stessa situazione.
Il primo risultato della ricerca quando si cerca su Google "zfs recovery " è il capitolo Risoluzione dei problemi e recupero dati di ZFS dalla Guida all'amministrazione di Solaris ZFS. Nella prima sezione Modalità di errore ZFS , nel paragrafo "Dati ZFS danneggiati" è indicato:
Il danneggiamento dei dati è sempre permanente e richiede un'attenzione particolare durante la riparazione. Anche se i dispositivi sottostanti vengono riparati o sostituiti, i dati originali vengono persi per sempre.
Un po 'scoraggiante.
Tuttavia, il secondo risultato della ricerca su Google è il blog di Max Bruning e lì ho letto
Di recente, mi è stata inviata un'e-mail da qualcuno che aveva 15 anni di video e musica archiviati in un pool ZFS da 10 TB che, dopo un'interruzione di corrente, è diventato difettoso. Sfortunatamente non aveva un backup. Stava usando ZFS versione 6 su FreeBSD 7 [...] Dopo aver trascorso circa 1 settimana a esaminare i dati sul disco, sono stato in grado di ripristinare praticamente tutto.
e
Per quanto riguarda ZFS che perde i tuoi dati, ne dubito. Ho il sospetto che i tuoi dati siano lì, ma devi trovare il modo giusto per ottenerli.
(sembra molto più simile a qualcosa che voglio sentire ...)
Primo passo : qual è esattamente il problema?
Come posso diagnosticare perché esattamente lo zpool viene segnalato come corrotto? Vedo che c'è zdb che non sembra essere ufficialmente documentato da Sun o Oracle da nessuna parte sul web. Dalla sua pagina man:
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.
Inoltre, Ben Rockwood ha pubblicato un articolo dettagliato e c'è un video di Max Bruning che ne parla (e mdb) all'Open Solaris Developer Conference di Praga il 28 giugno 2008.
L'esecuzione di zdb come root su zpool rotto fornisce il seguente output:
[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
Suppongo che l'errore "argomento non valido" alla fine si verifichi perché in realtà zpool01 non esiste: non si verifica su zpool02 funzionante, ma non sembra esserci alcun ulteriore output ...
OK, in questa fase, è probabilmente meglio pubblicarlo prima che l'articolo diventi troppo lungo.
Forse qualcuno può darmi qualche consiglio su come andare avanti da qui e mentre aspetto una risposta, guarderò il video, passerò attraverso i dettagli dell'output zdb sopra, leggo l'articolo di Bens e cerco di capire cosa c'è che cosa...
20110806-1600 + 1000
Aggiornamento 01:
Penso di aver trovato la causa principale: Max Bruning è stato così gentile da rispondere a una mia e-mail molto rapidamente, chiedendo l'output di zdb -lll. Su uno dei 4 hard disk nella "buona" raidz1 metà del pool, l'output è simile a quello che ho pubblicato sopra. Tuttavia, sulle prime 3 delle 4 unità nella metà "danneggiata", zdbriporta le failed to unpack labeletichette 2 e 3. La quarta unità nel pool sembra OK, zdbmostra tutte le etichette.
Cercare su Google quel messaggio di errore fa apparire questo post . Dalla prima risposta a quel post:
Con ZFS, che sono 4 etichette identiche su ogni vdev fisico, in questo caso un singolo disco rigido. L0 / L1 all'inizio del vdev e L2 / L3 alla fine del vdev.
Tutte le 8 unità del pool sono dello stesso modello, Seagate Barracuda da 500 GB . Tuttavia, ricordo di aver avviato il pool con 4 unità, quindi una è morta ed è stata sostituita in garanzia da Seagate. Più tardi, ho aggiunto altre 4 unità. Per tale motivo, gli identificatori di unità e firmware sono diversi:
[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
Ricordo però che tutte le unità avevano le stesse dimensioni. Guardando le unità ora, mostra che la dimensione è cambiata per tre di loro, si sono ridotti di 2 MB:
[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)
Quindi, a quanto pare, non era una delle installazioni del sistema operativo che "scriveva un bootloader su una delle unità" (come avevo ipotizzato prima), era in realtà la nuova scheda madre (un ASUS P8P67 LE ) che creava un host da 2 MB area protetta alla fine di tre delle unità che hanno incasinato i miei metadati ZFS.
Perché non ha creato un HPA su tutte le unità? Credo che questo sia perché la creazione HPA è fatto solo su unità più grandi con un bug che è stato fissato in seguito da un aggiornamento del disco rigido Seagate BIOS: Quando questo intero incidente è iniziato un paio di settimane fa, mi sono imbattuto di Seagate SeaTools per verificare se v'è qualcosa di fisicamente sbagliato con le unità (ancora sul vecchio hardware) e ho ricevuto un messaggio che mi diceva che alcune delle mie unità hanno bisogno di un aggiornamento del BIOS. Poiché ora sto provando a riprodurre i dettagli esatti di quel messaggio e il link per il download dell'aggiornamento del firmware, sembra che da quando la scheda madre ha creato l'HPA, entrambe le versioni di SeaTools DOS non riescano a rilevare i dischi rigidi in questione - un veloce invalid partitiono qualcosa di simile lampeggia quando iniziano, tutto qui. Ironia della sorte, però, trovano un set di unità Samsung.
(Ho saltato i dettagli dolorosi, dispendiosi in termini di tempo e in ultima analisi infruttuosi di frugare in una shell FreeDOS su un sistema non in rete.) Alla fine, ho installato Windows 7 su un computer separato per eseguire SeaTools Windows versione 1.2.0.5. Solo un'ultima osservazione su DOS SeaTools: non preoccuparti di provare ad avviarli autonomamente - invece, investi un paio di minuti e crea una chiavetta USB avviabile con il fantastico Ultimate Boot CD - che oltre a DOS SeaTools ti porta anche molti altri strumenti utili.
All'avvio, SeaTools per Windows visualizza questa finestra di dialogo:
I collegamenti portano al Controllo numeri di serie (che per qualche motivo è protetto da un captcha - il mio era "Utenti invasivi") e un articolo della knowledge base sull'aggiornamento del firmware. Probabilmente ci sono ulteriori collegamenti specifici al modello del disco rigido e alcuni download e cosa no, ma per il momento non seguirò quel percorso:
Non mi affretterò ad aggiornare il firmware di tre unità alla volta che hanno troncato le partizioni e fanno parte di un pool di archiviazione rotto. Chiede problemi. Per i principianti, l'aggiornamento del firmware molto probabilmente non può essere annullato e ciò potrebbe irrevocabilmente rovinare le mie possibilità di recuperare i miei dati.
Pertanto, la prima cosa che farò dopo è l'immagine delle unità e il lavoro con le copie, quindi c'è un originale a cui tornare se qualcosa va storto. Ciò potrebbe introdurre un'ulteriore complessità, poiché ZFS noterà probabilmente che le unità sono state scambiate (tramite il numero di serie dell'unità o ancora un altro UUID o qualsiasi altra cosa), anche se è copie dd bit-esatte sullo stesso modello di disco rigido. Inoltre, lo zpool non è nemmeno in diretta. Ragazzo, potrebbe essere complicato.
L'altra opzione sarebbe comunque quella di lavorare con gli originali e mantenere le unità con mirroring come backup, ma probabilmente mi imbatterò in una complessità superiore quando qualcosa andasse storto con gli originali. Naa, non va bene.
Al fine di cancellare i tre dischi rigidi che serviranno come sostituti delle immagini per le tre unità con il BIOS difettoso nel pool rotto, ho bisogno di creare un po 'di spazio di archiviazione per le cose che sono lì ora, quindi scaverò in profondità la scatola dell'hardware e assemblare uno zpool temporaneo da alcune vecchie unità - che posso anche usare per testare come ZFS gestisce lo scambio di unità dd'd.
Questo potrebbe richiedere del tempo ...
20111213-1930 + 1100
Aggiornamento 02:
Ci è voluto del tempo. Ho trascorso mesi con diverse custodie per computer aperte sulla mia scrivania con varie quantità di pile di dischi rigidi in sospensione e ho anche dormito un paio di notti con tappi per le orecchie, perché non potevo spegnere la macchina prima di andare a letto perché stava eseguendo una lunga operazione critica . Tuttavia, alla fine ho prevalso! :-) Ho anche imparato molto nel processo e vorrei condividere queste conoscenze qui per chiunque si trovi in una situazione simile.
Questo articolo è già molto più lungo di quanto chiunque abbia un file server ZFS fuori azione abbia il tempo di leggere, quindi entrerò nei dettagli qui e creerò una risposta con i risultati essenziali più avanti.
Ho scavato in profondità nella scatola hardware obsoleta per assemblare abbastanza spazio di archiviazione per spostare il materiale dalle singole unità da 500 GB su cui erano speculari le unità difettose. Ho anche dovuto estrarre alcuni dischi rigidi dalle loro custodie USB, in modo da poterli collegare direttamente tramite SATA. Ci sono stati alcuni altri problemi non correlati coinvolti e alcune delle vecchie unità hanno iniziato a fallire quando le ho rimesse in azione richiedendo una sostituzione di Zpool, ma salterò su quello.
Suggerimento: a un certo punto, c'erano circa 30 dischi rigidi coinvolti in questo. Con così tanto hardware, è di grande aiuto impilarli correttamente; i cavi che si allentano o il disco rigido che cade dalla scrivania sicuramente non aiuterà nel processo e potrebbe causare ulteriori danni all'integrità dei dati.
Ho trascorso un paio di minuti a creare alcuni dispositivi per il disco rigido in cartone per il cambio di marcia che hanno davvero contribuito a mantenere le cose ordinate:
Ironia della sorte, quando ho collegato le vecchie unità per la prima volta, ho capito che c'era un vecchio zpool lì che dovevo aver creato per il test con una versione precedente di alcuni, ma non tutti i dati personali sono andati persi, quindi mentre la perdita di dati era in qualche modo ridotto, questo significava ulteriori spostamenti avanti e indietro dei file.
Infine, ho rispecchiato le unità problematiche su unità di backup, ho usato quelle per zpool e ho lasciato quelle originali disconnesse. Le unità di backup hanno un firmware più recente, almeno SeaTools non segnala alcun aggiornamento del firmware richiesto. Ho fatto il mirroring con un semplice dd da un dispositivo all'altro, ad es
sudo dd if=/dev/sda of=/dev/sde
Credo che ZFS noti il cambiamento dell'hardware (da un UUID del disco rigido o altro), ma non sembra importare.
Lo zpool tuttavia era ancora nello stesso stato, repliche insufficienti / dati danneggiati.
Come menzionato nell'articolo di HPA Wikipedia menzionato in precedenza, la presenza di un'area protetta dall'host viene segnalata all'avvio di Linux e può essere investigata usando hdparm . Per quanto ne so, non esiste uno strumento hdparm disponibile su FreeBSD, ma a quel punto avevo FreeBSD 8.2 e Debian 6.0 installati come sistema a doppio avvio, quindi ho avviato 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
...
Quindi il problema ovviamente era che la nuova scheda madre ha creato un HPA di un paio di megabyte alla fine del disco che ha "nascosto" le due etichette ZFS superiori, impedendo così a ZFS di vederle.
Giocherellare con l'HPA sembra un affare pericoloso. Dalla pagina man di hdparm, parametro -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.
...
Nel mio caso, l'HPA è stato rimosso in questo modo:
user@host:~$ sudo hdparm -Np976773168 /dev/sde
/dev/sde:
setting max visible sectors to 976773168 (permanent)
max sectors = 976773168/976773168, HPA is disabled
e allo stesso modo per le altre unità con un HPA. Se si ottiene l'unità sbagliata o qualcosa riguardo al parametro size specificato non è plausibile, hdparm è abbastanza intelligente da capire:
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.
Successivamente, ho riavviato la macchina virtuale FreeBSD 7.2 su cui era stato originariamente creato zpool e lo stato di zpool ha riportato di nuovo un pool funzionante. SÌÌ! :-)
Ho esportato il pool sul sistema virtuale e reimportato sul sistema FreeBSD 8.2 host.
Alcuni aggiornamenti hardware più importanti, un altro scambio della scheda madre, un aggiornamento del pool ZFS a ZFS 4/15, una pulizia approfondita e ora il mio zpool è composto da 8x1TB più 8x500GB di parti 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
Come ultima parola, mi sembra che i pool ZFS siano molto, molto difficili da uccidere. I ragazzi di Sun che hanno creato quel sistema hanno tutte le ragioni per chiamarlo l'ultima parola nei filesystem. Rispetto!