[mac]

Grazie per aver condiviso questa esperienza in modo così dettagliato.
Sarà utile a molti.

ciao

[aventuri]

mi autorispondo per aggiornarvi sullo stato.

intanto confermo che il disco e' stato cambiato con uno identico (anche se diverso vedi dopo..) ma tutto OK per ora (e toccando ferro!)

in pratica quali passaggi ho fatto per ripristinare il RAID1 delle due partizioni (root e home)

partiamo da qualche istante prima del cambio disco fisico (programmato con tecnici OVH asciutti ma gentili e precisi), quando il server girà ancora da boot da hard disk anche se "degradato".

come ho scritto sopra in altro post, ho fatto questi passi:
ho messo in fail tutte le partizioni sul disco da cambiare (mdadm /dev/mdX --fail /dev/sdaX)
le ho rimosse dal raid (mdadm /dev/mdX --remove /dev/sdaX)
poi da pannello di controllo ho messo in "rescue pro" il successivo reboot del server.
sul server ho dato il comando di "reboot" ed il server e' passato in boot da rete,
ho ricevuto le pwd via email e loggatomi in ssh come root (la chiave cambia quindi c'e' un alert!) ho visto che i dischi erano quelli di prima (con smartcl -i /dev/sda).
a parte ho messo su una shell del mio pc un ping all'ip del server per vedere quando cominciava l'intervento (avrebbe smesso di rispondere ovviamente)
mi sono sloggato dal server prima del momento dell'appuntamento e sono rimasto in attesa..
al momento concordato il server e' andato giu' (l'ho visto dal ping che e' terminato..); l'intervento al cervello (mezzo..) era in corso!!
sono andato a prendermi un bel caffe' (ne avevo proprio bisogno..)
son tornato dopo 15 minuti, il ping era tornato su. (server ancora in modalità rescue pro)
sono entrato con le credenziali temporanee ricevute per posta
ho visto che /dev/sda era nuovo con smartctl -i /dev/sda

=== START OF INFORMATION SECTION ===
Device Model: HGST HUS724020ALA640
Serial Number: PN2134P6KRWULX
LU WWN Device Id: 5 000cca 22df4af21
Firmware Version: MF6OAA70
User Capacity: 2,000,398,934,016 bytes [2.00 TB]
Sector Size: 512 bytes logical/physical

questo era il vecchio /dev/sdb..

=== START OF INFORMATION SECTION ===
Device Model: TOSHIBA DT01ACA200
Serial Number: Z2L9B21GS
LU WWN Device Id: 5 000039 ff3c440e1
Firmware Version: MX4OABB0
User Capacity: 2,000,398,934,016 bytes [2.00 TB]
Sector Sizes: 512 bytes logical, 4096 bytes physical

uguali ma non cosi uguali.. da Toshiba a HSGST.. devo dire che qui ho avuto un brivido di sudore nella schiena.

mah. procediamo mi son detto..

da dmesg ho controllato che non c'erano partizioni..
anche con gdisk /dev/sda (e poi p per print).
ho copiato le partizioni dal nuovo al vecchio: sgdisk -R=/dev/sda /dev/sdb
poi ho letto un post che mi ha messo una pulce nell'orecchio.
ho dato sgdisk --randomize-guids /dev/sda per randomizzare gli identificatori dl nuovo disco..
poi ho copiato il bios_grub che era in /dev/sdb1 con dd if=/dev/sdb1 of=/dev/sda1 sperando che cosi' il bootloader sia funzionante in entrambe le partizioni. (qui la cosa non mi e' tanto chiara, ma in ogni caso poi il sistema e' ripartito. penso che dovro' fare dei test su una macchina in ufficio..)
a questo punto avrei potuto fare la rebuild del raid in modalità "rescue pro" come consigliatomi da OVH ma d'altra parte sapevo che la partizione home da 2TB ci avrebbe messo una decina di ore e non potevo lasciare gli utenti senza servizio, per cui ho deciso di prendermi un rischio e passare in esercizio..
da pannello di controllo ho messo il boot mode in "da hard disk" al prossimo riavvio.
son tornato sulla shell di rescue pro ed ho dato il comando reboot. qui si giocava tutta la mia speranza che l'OS sarebbe ripartito senza fare casino col disco nuovo (avevo tolto le partizioni /dev/sdaX dal raid)
mi son messo a guardare il ping. si e' interrotto e poi... e' ripreso! almeno un kernel era partito.
mi son loggato come utente (da SSH ho disabilitato il login da root) e EVVIVA.. la chiave SSH era tornata quella di prima e sono entrato. almeno la partizione /home/ era stata montata.
ho guardato un po' in giro con dmesg, cat /proc/mdstata df ed in effetti stavo girando col raid degradato ma il nuovo disco era li bello pronto per tornare in linea.
ho dato i comandi previsti: mdadm --manage /dev/md2 --add /dev/sda2 e poi mdadm --manage /dev/md3 --add /dev/sda3 e difatti il raid si e' riattivato (in rebuild mode), vedi $ cat /proc/mdstat

Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] [multipath] [faulty]
md2 : active raid1 sda2[0] sdb2[1]
20478912 blocks [2/2] [UU]

md3 : active raid1 sda3[2] sdb3[1]
1932506048 blocks [2/1] [_U]
[=>...................] recovery = 9.0% (174971136/1932506048) finish=532.4min speed=55010K/sec

unused devices:

i servizi sono ripartiti come prima. la partizione home ci mettera' 10 ore circa.. ma intanto il server e' ok. la partizione / (root) ci ha messo 10 minuti. solo 30GB.
aspettiamo che termini prima di fare un eventuale altro reboot di test.

questo e' tutto, per ora. recuperare da un fail di un RAID1 si puo' fare.. per quello che costano i dischi oggi, il RAID1 e' d'obbligo IMHO per un server dedicato (o meglio uno virtualizzato da un'operatore serio..)

ricordarsi comunque di avere sempre un backup[*].. cintura e bretelle!!

[*] PS un backup se non e' stato testato per davvero (ad es. su un server clone o similare..) non vale molto di piu' di zero. perche' si scopre sempre troppo tardi che mancavano delle informazioni importanti! :-)

[aventuri]

innanzitutto grazie per la sollecita risposta..

Ciao,
prima di tutto (anche se sicuramente lo hai fatto) ti consiglio di fare un backup completo della tua macchina, magari usando lo spazio apposito che OVH mette a disposizione. Si sa mai.

difatti!! ho proceduto al backup di /home sul disco nfs di ovh, devo dire che non e' tanto performante, come scrittura. siamo sui 10MB al secondo, pensavo meglio. mi domando se abbia senso il backup della / ma vista la funzione di netboot presente, direi di si se, come spero, si puo' montare nfs in netboot.

Per rispondere alle tue domande, se grub è configurato per avere il device md come partizione di root, sei apposto. parte anche con un disco solo. Lo puoi facilmente verificare guardando /boot/grub/grub.cfg , ma dovrebbe essere il default. Nel caso non lo fosse, puoi sempre configurarlo tu o installare grub anche in sdb.

in grub c'e' questo che boot dal /dev/md2 e mi sembra ok:

menuentry "Ubuntu 12.04, OVH kernel 3.8.13-xxxx-grs-ipv6-64" {
insmod raid
insmod mdraid09
insmod part_gpt
insmod part_gpt
insmod ext2
set root='(mduuid/739d3bcaee30ee2aa4d2adc226fd5302)'
search --no-floppy --fs-uuid --set=root 755d9389-6cca-456c-a3f5-0d786149cfac
linux /boot/bzImage-3.8.13-xxxx-grs-ipv6-64 root=/dev/md2 ro
}

qua sotto le partizioni GPT, tra cui la /dev/sda1 chiamata bios_grub

# parted -l
Model: ATA TOSHIBA DT01ACA2 (scsi)
Disk /dev/sda: 2000GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number Start End Size File system Name Flags
1 20.5kB 1049kB 1029kB primary bios_grub
2 2097kB 21.0GB 21.0GB ext4 primary raid
3 21.0GB 2000GB 1979GB ext4 primary raid
4 2000GB 2000GB 536MB linux-swap(v1) primary

l'ho confrontata con /dev/sdb1 con un diff ed e' uguale, e dentro tra le stringhe vedo che c'e' riferimento a GRUB a GPT ed EFI.. direi che quindi il "grub-install" ha scritto su entrambe..

l'unico mio dubbio/speranza e' che con un disco vergine su /dev/sda ed un disco con bootloader ok su /dev/sdb, il "bios" della motherboard li provi entrambi in cascata. sono convinto che sia cosi' se no lo avrebbero scritto in queste guide su soft-raid quando si cambia un disco che e' "teoricamente" prima di un altro nella sequenza di boot..

Per quanto riguarda il ripristino del raidsw, ti rimando alla documentazione ufficiale di mdadm, che è molto esaustiva ed aggiornata.
oltre a questo https://raid.wiki.kernel.org/index.php/RAID_Recovery
e questo http://docs.ovh.ca/en/guides-raid-soft.html
Ci vuole un po' di prudenza, ma sostanzialmente i passi da seguire sono quelli che hai indicato tu.

il secondo link che hai scritto mi sembra quello che mi interessa. e' abbastanza spiccio. mi meraviglio che nella parte in cui parla della sostituzione del disco rotto di un RAID1 che e' il mio caso, non parli dei due passi che mi sembrano utili:

1. rimozione dal raid mdadm delle la partizioni del disco che viene cambiato.
2. ri-installazione del grub bootloader sulla bios_grub partizione del disco nuovo, che altrimenti rimane senza boot loader

per completezza di informazione aggiungo che OVH mi informa sul pannello che la motherboard e' una Intel DH67BL che leggo dal sito web ha l'impostazione EFI/EUFI opzionale, non saprei pero' dire che differenza faccia non avendo mai messo le mani su un PC UEFI con config GPT! ho paura che sia arrivato il momento di aggiornarsi tecnologicamente.. :-)

[mac]

Ciao,
prima di tutto (anche se sicuramente lo hai fatto) ti consiglio di fare un backup completo della tua macchina, magari usando lo spazio apposito che OVH mette a disposizione. Si sa mai.
Per rispondere alle tue domande, se grub è configurato per avere il device md come partizione di root, sei apposto. parte anche con un disco solo. Lo puoi facilmente verificare guardando /boot/grub/grub.cfg , ma dovrebbe essere il default. Nel caso non lo fosse, puoi sempre configurarlo tu o installare grub anche in sdb.
Per quanto riguarda il ripristino del raidsw, ti rimando alla documentazione ufficiale di mdadm, che è molto esaustiva ed aggiornata.
oltre a questo https://raid.wiki.kernel.org/index.php/RAID_Recovery
e questo http://docs.ovh.ca/en/guides-raid-soft.html
Ci vuole un po' di prudenza, ma sostanzialmente i passi da seguire sono quelli che hai indicato tu.

[aventuri]

buongiorno, scrivo per un problema di disco rotto in un server dedicato.

e' un problema che puo' sempre capitare, visto che il disco e' una parte in movimento sottoposta ad usura, per questo esistono le configurazioni RAID!

i miei dubbi sono sotto, per chi ha un po' di esperienza con linux mdadm, softraid, grub paritizioni GPT .

in ogni caso spero di aggiungere al thread come evolve l'esperienza specifica perche' penso che possa essere di aiuto anche ad altri.

in sintesi questo server ha OS linux Ubuntu 12.04 (sono un paio d'anni che gira..) 64 bit (la distribuzione stock di OVH) e due dischi da 2TB ciascuno partizionati GPT (qui parte dei miei dubbi in merito al reboot dopo il cambio disco) in soft RAID1 con partizioni / e /home in RAID.

partizione
1 : grub-boot
2 : partizione root / /dev/sda2 + /dev/sdb2 = /dev/md2
3 : partizione home /dev/sda3 + /dev/sdb3 = /dev/md3
4 : swap sia /dev/sda4 che /dev/sdb4

il disco /dev/sda e' da cambiare perche' rotto. ora il servizio funziona perche' il raid1 e' operativo anche se in modalità degradata.


1. la partizione /dev/md2 per root e /dev/md3 per /home e' uno standard OVH da quando i dischi sono partizionati GPT (e non MBR), vero?
il disco che prende il posto di /dev/sda pero' sara' partizionato da OVH o no? ho sentito di no; qualcuno ha gia' recuperato un softraid cosi' configurato ? purtroppo non ho seguito l'installazione dell'OS all'inizio, io ho preso in carico il server da 1 anno circa..

2. ho letto la guida OVH http://guida.ovh.it/RaidSoft ma non mi sembra aggiornata alle config. attuali (/dev/md2 e /dev/md3) e sottovaluta l'aspetto del "bootloader" secondo me. ora si legge che io, con "sgdisk -R=/dev/sda /dev/sdb" dovrei riuscire ad installare le stesse partizioni di /dev/sdb sul NUOVO disco /dev/sda (intanto il sistema sta funzionando per gli utenti.. anche se col raid degradato), e' vero? anche se il disco ha geometria diversa (ovviamente maggiore. ma non mi interessa di sprecare lo spazio in piu'..) ?

3. prima di mettere in shutdown il computer per fare il cambio disco, leggo in giro che devo "togliere" dal raid le partizioni che sono sul disco da cambiare (questo non c'e' sulla guida OVH, mi pare..) con questi comandi:

To put in fault..
# mdadm --manage /dev/md2 --fail /dev/sda2
# mdadm --manage /dev/md3 --fail /dev/sda3 // questo e' gia' in fault, attualmente

To remove the partitions from the RAID array:
# mdadm --manage /dev/md2 --remove /dev/sda2
# mdadm --manage /dev/md3 --remove /dev/sda3

4. dopo il cambio disco, secondo voi il server ripartirà perche' il boot loader e' presente anche su /dev/sdb ? qualcuno ha idea come si verifica prima ?

5. dopo che ho partizionato il nuovo disco (con "sgdisk -R".. ), posso gia' dare i comandi di aggiungere le nuove partizioni a /dev/md2 e /dev/md3?
mdadm /dev/md2 --manage --add /dev/sda2
mdadm /dev/md3 --manage --add /dev/sda3
questo mi sembra il momento critico numero 2 , se va tutto bene, qui si ricomincia a vedere il rebuilding del mirror (che ci metter'a qualche ora, immagino..), se no..

6. infine, come devo operare per aggiornare il boot loader grub anche sulla nuova partizione /dev/sda1?
non vorrei rischiare di compromettere un prossimo eventuale boot.

7. esiste una virtual console per poter fare il controllo dello stato del server anche in assenza di qualunque OS? sul pannello di controllo non ho visto niente. od eventualmente la modalità di accesso per ricostruire il Raid e' attraverso il netboot e RescuePRO http://guida.ovh.it/ModeRescue

questo e' tutto quanto mi viene in mente, come problemi potenziali.

per aumentare la mia confidenza, dovrei veramente provare un fault di questo tipo su un ambiente virtualizzato, tanto per capire gli errori principali, purtroppo non conosco pero' come e' stato configurato all'inizio e farei una simulazione poco significativa (a parte perder tempo).