ReadyNas Duo e LVM

Qualche giorno fa è nata la necessità di espandere un ReadyNas Duo della Netgear dotato di disco da 500GB. L’intenzione era quella di sostituire il disco esistente con due dischi da 1TB. Il risultato è stato la perdita di tutti i dati (vedi post).

A questo punto ho deciso di fare a modo mio resettando il NAS non prima di aver fatto un backup del disco esistente da 500gb.

Per fare questo mi sono collegato in remoto al NAS ed ho impartito i comandi:

tar cvpzf /myshare/nas_pre_dsk_upg.tgz –exclude=/shareX –exclude=/shareY –exclude=/proc –exclude=/lost+found –exclude=/c –exclude=/tmp –exclude=/sys –exclude=/home /

Nel comando precendete le cartelle shareX e shareY sono condivisioni di rete.

Come vedremo in seguito questo backup non è strettamente necessario ma io ho sempre l’abitudine di salvare i files che mi servono in caso di necessità. Il comando prececedente serve sostanzialmente a preservare i files del NAS ad esclusione delle condivisioni (che possono essere tranquillamente copiate da un computer remoto). tar è utile perchè sul NAS oggetto di aggiornamento sono presenti diverse add-on per le quali non ho voglia di procedere alla reinstallazione tramite frontview.

Fatto il backup sostituisco il drive da 500GB con due dischi da 1TB e provvedo a resettare il NAS riportandolo alle impostazioni di fabbrica.
Segue la creazione di un nuovo RAID e l’installazione dell’unica add-on necessaria: ToggleSSH disponibile qui.

Sono riuscito a fare il ripristino del backup eseguendo sul NAS i comandi:

cd /
tar xzvf /nas_pre_dsk_upg.tgz

Il restore è andato liscio come l’olio.

Come dicevo prima, il ripristino dei rimanenti files può essere portato a termine mediante l’uso delle condivisioni di rete ma io ho deciso di ripristinare i files usando il disco da 500GB originale tramite porta USB ed un comune convertitore SATA/USB.

Chi volesse impiegare il metodo descritto di seguito ma non ha un convertitore può:

- usare un case esterno;
- clonare il disco di orinine usando dd su un HD esterno di capacità uguale o maggiore di quello sorgente;
- utilizzare una distribuzione live di linux che supporti LVM (ad esempio il disco di ripristino che accompagna fedora) ed un altro computer.

Ho diciso di pubblicare questo metodo perchè potrebbe sorgere la necessità di recuperare i dati da un volume non più utile.

Nel mio caso ad esempio, l’espansione del RAID portato a termine dal ReadyNAS Duo non è andato a buon fine, di conseguenza tutti i dati presenti nel vecchio RAID sono stati cancellati nel nuovo.

Potrebbe inoltre capitare di dover recuperare i dati da un NAS defunto.

I comandi che seguono sono utili anche per chi non possiede un ReadyNas Duo ma vuole recuperare file presenti in partizioni LVM di linux.

Chi volesse cimentarsi nel ripristino tramite altro computer (cioè smontando il disco dal NAS e montandolo su un altro PC dotato di Linux con supporto LVM) avrà una vita più comoda perchè non bisogna considerare alcuni aspetti come ad esempio la duplicazione dei Volume Group (VG).

Riprendendo il filo del discorso, dopo aver resettato il NAS è possibile collegare tramite porta usb il vecchio disco esterno; il NAS provvederà in piena autonomia a montare le partizioni trovate nella directory /USB.

Il comando mount dovrebbe produrre un output del tutto simile al seguente:

mount


/dev/hdc1 on / type ext2 (rw,noatime)
proc on /proc type proc (rw)
devpts on /dev/pts type devpts (rw)
sysfs on /sys type sysfs (rw)
tmpfs on /ramfs type ramfs (rw)
tmpfs on /USB type tmpfs (rw,size=16k)
/dev/c/c on /c type ext2 (rw,noatime,acl,user_xattr,usrquota,grpquota)
/c/home on /home/ftp/homes type bind (rw,bind)
usbfs on /proc/bus/usb type usbfs (rw)
/dev/sda1 on /USB/USB_HDD_1_1 type ext3 (rw,noatime,acl)
/USB/USB_HDD_1_1 on /home/ftp/USB_HDD_1_1 type none (rw,bind)

Viene montata solo la partizione ext3 (USB_HDD_1_1) contenente tutti i files del NAS ad esclusione di quelli presenti nelle condivisioni di rete. Se non avere fatto il backup descritto in precedenza tramite tar, potete tranquillamente copiare i file presenti in /USB/USB_HDD_1_1 avendo l’accortezza di utilizzare il parametro -p (che preserva gli attributi dei files copiati).

Quello che però a noi interessa adesso è il recupero dei dati presenti nel LVM del disco che il NAS non ha montato. Quindi procediamo a verificare la tabella delle partizioni presenti sul disco:

fdisk -l /dev/sda


Disk /dev/sda: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0×00000000


Device Boot Start End Blocks Id System
/dev/sda1 1 255 2048000 83 Linux
Partition 1 does not end on cylinder boundary.
/dev/sda2 255 287 256000 82 Linux swap / Solaris
Partition 2 does not end on cylinder boundary.
/dev/sda3 287 60800 486064152 5 Extended
/dev/sda5 287 60800 486064151+ 8e Linux LVM

Con fdisk sappiamo che il disco presenta una partizione ext3 (già mondata su USB_HDD_1_1) una partizione di swap (non usata) ed una LVM (che contiene i dati a noi necessari).

Per visualizzare con maggior dettaglio le informazioni legate a LVM è possibile usare il comando pvscan:

pvscan


PV /dev/md2 VG c lvm2 [929.03 GB / 0 free]
Total: 2 [1.36 TB] / in use: 2 [1.36 TB] / in no VG: 0 [0 ]

Non ci sono tracce della partizione /dev/sda5. Questo perchè la scansione delle partizioni LVM da parte del ReadyNAS Duo è stata disabilitata. Basta dare una occhiata al file di configurazione presente in /etc/lvm/lvm.conf per capire che è stato attivato un filtro che evita la scansione di partizioni presenti su porta USB:

filter = [ "a|^/dev/hd[cegikmoq][5-9]$|”, “a|^/dev/hd[cegikmoq]1[0-5]$|”, “a|^/dev/md[2-9]$|”, “r|.*|” ]

Per risolvere il problema suppongo sia sufficiente commentare il filtro ma per essere più precisi è sufficiente apportare le dovute modifiche sostituendo la riga precedente con questa:

filter = [ "a|^/dev/sd[abcegikmoq][5-9]$|”,”a|^/dev/hd[cegikmoq][5-9]$|”, “a|^/dev/hd[cegikmoq]1[0-5]$|”, “a|^/dev/md[2-9]$|”, “r|.*|” ]

Dopo aver modificato il file, l’output del comando pvscan è diverso:

pvscan

PV /dev/sda5 VG c lvm2 [463.53 GB / 0 free]
PV /dev/md2 VG c lvm2 [929.03 GB / 0 free]
Total: 2 [1.36 TB] / in use: 2 [1.36 TB] / in no VG: 0 [0 ]

Adesso siamo in grado di vedere due VG invece che uno ma c’è un problema: entrambi hanno lo stesso nome: “c“. Questo vuol dire che non è possibile montare il volume senza mettere mano ai VG.

Per avere un maggior dettaglio sui VG presenti è possibile fare un controllo con vgdisplay:

vgdisplay

— Volume group —
VG Name c
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 4
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 1
Open LV 1
Max PV 0
Cur PV 1
Act PV 1
VG Size 463.53 GB
PE Size 32.00 MB
Total PE 14833
Alloc PE / Size 14833 / 463.53 GB
Free PE / Size 0 / 0
VG UUID q9L5G9-7Uuv-mg9m-9aqK-cOML-QziN-KzizYv

— Volume group —
VG Name c
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 2
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 1
Open LV 1
Max PV 0
Cur PV 1
Act PV 1
VG Size 929.03 GB
PE Size 32.00 MB
Total PE 29729
Alloc PE / Size 29729 / 929.03 GB
Free PE / Size 0 / 0
VG UUID fOsBiY-2J8W-d2tC-K0Xe-lRtz-ZRuZ-20IkVB

Montare il volume presente in /dev/sda5 comporta il riconoscimento del relativo VG. Per poter maneggiare il VG è necessario rinominarlo e per rinominarlo è necessario portarlo offline.

Il primo problema è quello di portare offline il VG perchè in caso di duplicazione dei nomi LVM darà la priorità agli array creati sul NAS e questo vanifica il tentativo. Ad esempio, eseguendo il comando vgchange il risultato sarà simile al seguente:

vgchange -a n c


WARNING: Duplicate VG name c: fOsBiY-2J8W-d2tC-K0Xe-lRtz-ZRuZ-20IkVB (created here) takes precedence over q9L5G9-7Uuv-mg9m-9aqK-cOML-QziN-KzizYv
Can’t deactivate volume group “c” with 1 open logical volume(s)
Can’t deactivate volume group “c” with 1 open logical volume(s)

Il comando precente tenta di portare offline il VG c ma poichè la precendeza viene data al volume con UUID fOsBiY-2J8W-d2tC-K0Xe-lRtz-ZRuZ-20IkVB il comando fallisce perchè attualmente il volume è usato dal sistema operativo (vedi comando mount eseguito in precedenza).

La cosa più veloce da fare è quella di smontare la partizione /c in modo da poter portare temporaneamente offline entrambi i VG:

/etc/init.d/frontview stop
/etc/init.d/samba stop
/etc/init.d/nis stop
/etc/init.d/proftpd stop

I comandi riportati in alto servono a fermare temporaneamente quei servizi che potrebbero utilizzare la partizione /c inibendo di fatto la possibilità di smondare la partizione /dev/c/c.

Adesso proseguiamo con lo smontaggio:

umount /c/home
umount /dev/c/c

Se lo smontaggio non dovesse funzionare è possibile verificare quali processi fanno uso della partizione tramite il comando fuser:

fuser -m /dev/c/c

Per ogni processo individuato da fuser è necessario procedere con:

kill -9 pid

dove pid è il numero segnalato da fuser. Prima di procedere accertarsi di non escludere un programma essenziale (come ad esempio la shell bash alla quale siamo collegati per impartire i comandi). A volte l’unità non viene smontata perchè il prompt attuale è in “/c” (o magari nella cartella home dell’utente anche essa montata sotto “/c”).

Fatto questo possiamo finalmente portare offile tutti i VG:

vgchange -a n

Se tutto è andato liscio è possibile ora rinominare il VG del vecchio disco specificando il corretto uuid che contraddistingue il gruppo:

vgrename q9L5G9-7Uuv-mg9m-9aqK-cOML-QziN-KzizYv d

Anche questo comando non dovrebbe creare problemi e con vgchange possiamo riportare i VG online:

vgchange -a y

Prima di riavviare il NAS facciamo una verifica finale sul lavoro con vgdisplay:

vgdisplay


— Volume group —
VG Name d
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 4
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 1
Open LV 1
Max PV 0
Cur PV 1
Act PV 1
VG Size 463.53 GB
PE Size 32.00 MB
Total PE 14833
Alloc PE / Size 14833 / 463.53 GB
Free PE / Size 0 / 0
VG UUID q9L5G9-7Uuv-mg9m-9aqK-cOML-QziN-KzizYv

— Volume group —
VG Name c
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 2
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 1
Open LV 1
Max PV 0
Cur PV 1
Act PV 1
VG Size 929.03 GB
PE Size 32.00 MB
Total PE 29729
Alloc PE / Size 29729 / 929.03 GB
Free PE / Size 0 / 0
VG UUID fOsBiY-2J8W-d2tC-K0Xe-lRtz-ZRuZ-20IkVB

Finalmente i gruppi hanno nomi differenti ed la loro gestione diventa possibile.

Dopo aver riavviato il NAS è possibile finalmente montare la partizione:

pvscan
mount /dev/d/c /USB/USB_HDD_1_1/c

Per ripristinare i files possiamo procedere con:

cd /USB/USB_HDD_1_1/c
cp -Rpv . /c/

Spero che questa piccola guida possa tornare utile a chi ha problemi di recupero dati da partizioni LVM. A volte le cose non sono complicate come sembrano.

Alla prossima.

Leave a comment

6 Comments.

  1. Ciao.
    Ogg ho letto su http://forums.smallnetbuilder.com/showthread.php?t=548 che i ReadyNAS con firmware 4.x formattano i dischi in un modo non leggibile da pc normali. Il tuo disco da 500GB era forse formattato da un fw 3.x?

  2. A dire il vero scrivendo l’articolo non ci avevo pensato. Quello che si dice nel forum però non è proprio esatto al 100%. è vero che ci sono dei limiti su architetture x86, ma non sono dovuti ai 4k in se ma al limite del PAGE_SIZE. Questo vuol dire ad esempio che sui processori a 64 bit in realtà qualcosa si può fare. Leggi ad esempio l’articolo riportato su http://lwn.net/Articles/240914/. Inoltre molti controller raid supportano la lettura di blocchi oltre i 4k e in futuro lo standard ATA-8 dovrebbe risolvere anche questo problema. Comunque secondo me la riscrittura dei blocchi è possibile in qualche modo. Mi informerò meglio.

  3. Ciao, dopo meno di un mese dall’acquisto mi si e’ guastato il mio Duo. Prima di fare altre prove col supporto Netgear (che non e’ stato molto utile finora) e resettare il NAS, vorrei provare a recuperare i dati presenti sui due dischi del NAS in RAID1 (ci avevo messo delle foto e video di cui non ho altri backup).
    Cosa mi consiglieresti di fare? Ho letto nuovamente il tuo articolo, ma non sono molto pratico di Linux.
    Vedo che avrei queste due possibilita’:
    - clonare il disco di orinine usando dd su un HD ….
    - utilizzare una distribuzione live di linux che supporti ….
    Potrei quindi provare ad attaccare uno dei due dischi del NAS su un PC, oltre ad un secondo HD vuoto, ed avviare un Live CD di Fedora? In questo caso devo inserire dei comandi particolari oppure Fedora monta il disco e lo posso leggere direttamente? E’ meglio se lo monto in sola lettura, per non rischiare di perdere dati? Poi potrei procedere alla copia dei dati da LVM al secondo disco vuoto?
    Grazie mille per l’aiuto!

  4. Ciao, secondo me è meglio procedere con ordine. Di quale problema soffre il NAS? se puoi resettare il nas significa che l’hardware funziona. comunque sia, se hai rimosso i dischi il mio consiglio è quello di non metterli nuovamente dentro il Duo perchè rischi di ritrovarti con due dischi “vuoti”. Come avrai notato leggendo i post precedenti, per recuperare i dati dal nas potrebbe essere necessario avere un processore a 64 bit (ultrasparc o Itanium). Dipende da quale versione del firmware è stata usata per creare il raid. Se il tuo nas funziona ancora la mia proposta è quella di spostare uno dei due dischi su una usb esterna; a quel punto la mia guida dovrebbe andare bene. Fammi sapere qualcosa.

  5. Ciao, ho letto con attenzione l’articolo e i commenti ma essendo poco pratico di linux chiedo: avendo il ReadyNas Duo con un solo disco montato, vorrei poterlo leggere da pc. Quindi ho collegato il disco (sata) e con una chiavetta Linux Parted Magic ho avviato il pc, ma non mi legge il disco… esiste un programmino tipo “ontrack” anche sotto linux che mi permette di leggere (e copiarmi) i file di quella partizione? Spero di essere stato chiaro e dare risposta anche ad altri che vedo stanno chiedendo in giro per la rete domande simili alle mie senza trovare soluzione.

  6. Intanto è da capire la versione del firmware del ready nas duo utilizzata per formattare originariamente il disco. Se si tratta di una versione recente allora puoi tranquillamente montare la partizione lvm in linux. Il disco mi pare di capire che è sano e non soffre di difetti.

    Secondo me la cosa più sbrigativa è quella di usare un disco di ripristino di fedora (qualunque versione più o meno recente). Se non ricordo male è in grado di montare in piena autonomia le partizioni lvm all’avvio.

Leave a Reply


[ Ctrl + Enter ]