Ridimensionare un array RAID degradato (/dev/md1) su Linux

Perché e panoramica rapida

Ridimensionare un array degradato è possibile, ma richiede cautela. L’operazione tipica è:

• assicurarsi che il disco guasto sia marcatamente rimosso dall’array;
• avviare un ambiente rescue con i moduli necessari;
• ridurre il filesystem, poi il logical volume (LV), poi il physical volume (PV) e infine l’array RAID;
• riconfigurare LVM dopo la crescita/ricreazione; infine riaggiungere il disco sostituito.

Importante: eseguire sempre backup aggiornati prima di operazioni distruttive. La sequenza qui sotto è un metodo pratico e testato su sistemi con LVM su RAID1.

Prerequisiti

• Backup completo dei dati o snapshot funzionante.
• Accesso fisico o console KVM per il boot in rescue.
• Familiarità con mdadm, lvm2, e strumenti di controllo filesystem (resize2fs, e2fsck).
• Il disco fallito deve essere effettivamente rimosso dall’array prima di procedere.

Stato iniziale - output di esempio

I seguenti output sono inclusi come esempio del sistema di partenza. Conservare gli output reali del proprio sistema.

cat /proc/mdstat

server1:~# cat /proc/mdstat
Personalities : [raid1]
md1 : active raid1 sdb5[1]
4988032 blocks [2/1] [_U]

md0 : active raid1 sda1[0] sdb1[1]
248896 blocks [2/2] [UU]

unused devices: 
server1:~#

df -h

server1:~# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/server1-root
4.5G  741M  3.5G  18% /
tmpfs                 126M     0  126M   0% /lib/init/rw
udev                   10M   68K   10M   1% /dev
tmpfs                 126M     0  126M   0% /dev/shm
/dev/md0              236M   18M  206M   8% /boot
server1:~#

pvdisplay

server1:~# pvdisplay
— Physical volume —
PV Name               /dev/md1
VG Name               server1
PV Size               4.75 GB / not usable 0
Allocatable           yes (but full)
PE Size (KByte)       4096
Total PE              1217
Free PE               0
Allocated PE          1217
PV UUID               Ntrsmz-m0o1-WAPD-xhsb-YpH7-0okm-qfdBQG

server1:~#

vgdisplay

server1:~# vgdisplay
— Volume group —
VG Name               server1
System ID
Format                lvm2
Metadata Areas        1
Metadata Sequence No  9
VG Access             read/write
VG Status             resizable
MAX LV                0
Cur LV                2
Open LV               2
Max PV                0
Cur PV                1
Act PV                1
VG Size               4.75 GB
PE Size               4.00 MB
Total PE              1217
Alloc PE / Size       1217 / 4.75 GB
Free  PE / Size       0 / 0
VG UUID               X3ZYTy-39yq-20k7-GCGk-vKVU-Xe0i-REdEu0

server1:~#

lvdisplay

server1:~# lvdisplay
— Logical volume —
LV Name                /dev/server1/root
VG Name                server1
LV UUID                3ZgGnd-Sq1s-Rchu-92b9-DpAX-mk24-0aOMm2
LV Write Access        read/write
LV Status              available

LV Size                4.50 GB
Current LE             1151
Segments               1
Allocation             inherit
Read ahead sectors     0
Block device           253:0

— Logical volume —
LV Name                /dev/server1/swap_1
VG Name                server1
LV UUID                KM6Yq8-jQaQ-rkP8-6f4t-zrXA-Jk13-yFrWi2
LV Write Access        read/write
LV Status              available

LV Size                264.00 MB
Current LE             66
Segments               1
Allocation             inherit
Read ahead sectors     0
Block device           253:1

server1:~#

Questi output confermano che md1 è degradato (solo sdb5 attivo) e che LVM usa tutto lo spazio disponibile sul PV associato a /dev/md1.

Sequenza completa di riduzione (procedura passo‑passo)

Di seguito la procedura concreta usata sull’esempio. Adattare le dimensioni e i nomi degli LV/PV al vostro caso.

1. Marcare e rimuovere il disco fallito dall’array (eseguito sul sistema normale prima del reboot in rescue):

mdadm --manage /dev/md1 --fail /dev/sda5
mdadm --manage /dev/md1 --remove /dev/sda5

2. Azzerare il superblock del disco rimosso. Questo è essenziale se si vuole riutilizzare il dispositivo o riaggiungerlo più tardi senza conflitti:

mdadm --zero-superblock /dev/sda5

Nota: se ometti questo comando il kernel/udev potrebbe tentare di riusare il dispositivo come membro dell’array e causare conflitti al boot.

3. Avviare un sistema di rescue (live CD/USB) e caricare i moduli necessari:

modprobe md
modprobe linear
modprobe multipath
modprobe raid0
modprobe raid1
modprobe raid5
modprobe raid6
modprobe raid10

4. Ricostruire temporaneamente la configurazione mdadm e attivare gli array:

cp /etc/mdadm/mdadm.conf /etc/mdadm/mdadm.conf_orig
mdadm --examine --scan >> /etc/mdadm/mdadm.conf
mdadm -A --scan

5. Avviare LVM nel rescue:

/etc/init.d/lvm start

6. Controllare e forzare il filesystem prima di ridurlo (esempio su ext4):

e2fsck -f /dev/server1/root

7. Ridurre il filesystem del LV. Prima di ridurre un filesystem, scegliere una dimensione sufficiente a contenere tutti i dati. Nell’esempio il filesystem viene ridotto a 2G:

resize2fs /dev/server1/root 2G

8. Ridurre il Logical Volume in modo coerente con il filesystem (nell’esempio a 2.5G):

lvreduce -L2.5G /dev/server1/root

9. Se necessario, rimuovere l’LV di swap che si trova alla fine del PV (solo se è sicuro farlo). Nell’esempio questo LV era alla fine del disco:

lvremove /dev/server1/swap_1

10. Ridurre il PV (physical volume) per adattarlo allo spazio desiderato sul dispositivo RAID. Nell’esempio il PV viene impostato a 3G:

pvresize --setphysicalvolumesize 3G /dev/md1

11. Ridurre l’array RAID (/dev/md1). La dimensione di –size è espressa in KiB; per 4 GiB:

mdadm --grow /dev/md1 --size=4194304

Assicurarsi che il valore sia divisibile per 64 (requisito di allineamento interno di mdadm).

12. Ora aggiornare il PV al massimo spazio disponibile sul nuovo array:

pvresize /dev/md1

13. Verificare vgdisplay per vedere PE libere e ricreare l’LV di swap o ridistribuire lo spazio:

vgdisplay

Esempio di comandi per ricreare swap e riallocare spazio:

lvcreate --name swap_1 -l 66 server1
mkswap /dev/server1/swap_1
lvextend -l +317 /dev/server1/root
resize2fs /dev/server1/root
e2fsck -f /dev/server1/root

14. Riavviare normalmente. Dopo il boot, ripulire il superblock e riaggiungere il disco ricondizionato (o nuovo) al RAID:

mdadm --zero-superblock /dev/sda5
mdadm -a /dev/md1 /dev/sda5

15. Controllare lo stato di sync:

cat /proc/mdstat

Dovreste vedere /dev/sdb5 e /dev/sda5 sincronizzarsi.

Criteri di accettazione

• Il filesystem non deve presentare errori dopo e2fsck.
• LVM (vgdisplay) mostra le dimensioni attese del VG e degli LV.
• /proc/mdstat indica che l’array è attivo e in sync dopo la reintegrazione del disco.
• Il sistema si avvia normalmente e i servizi critici sono operativi.

Playbook rapido (SOP) per l’operatore

• Verificare e salvare backup.
• Informare stakeholder e pianificare downtime se necessario.
• Eseguire i comandi di fail/remove sul disco fallito.
• Azzerare superblock del device rimosso.
• Boot in rescue → caricare moduli → attivare md e LVM.
• Controllare filesystem, ridurre filesystem, ridurre LV, rimuovere LV di coda se serve.
• pvresize con setphysicalvolumesize → mdadm –grow → pvresize.
• Ricreare LV di swap, espandere LV root, resize2fs.
• e2fsck finale, reboot e riaggiungere disco.

Ruoli e checklist (Operator, Sysadmin)

• Operatore (esegue i comandi sotto supervisione):
  • Verifica backup, cattura output iniziali (cat /proc/mdstat, lvdisplay, vgdisplay, pvdisplay).
  • Esegue fail/remove su richiesta.
  • Esegue mdadm –zero-superblock quando indicato.
• Sysadmin (responsabile delle decisioni):
  • Decide le nuove dimensioni target di LV/PV/RAID.
  • Supervisiona il resize del filesystem e la ricreazione di swap.
  • Verifica l’integrità e approva il reboot.

Modelli mentali e suggerimenti rapidi

• Pensare dal basso verso l’alto: disco → RAID → PV → VG → LV → filesystem.
• Non ridurre mai un LV sotto la dimensione necessaria al filesystem. Controllare uso reale con du -sh o tune2fs -l.
• Quando possibile, sostituire il disco fallito e ricostruire l’array invece di ridurlo: più sicuro per i dati.

Quando questa procedura fallisce (controesempi)

• Filesystem troppo grande rispetto alla nuova dimensione scelta: il resize2fs fallirà o causerà perdita dati.
• LV di swap o altri LV non sono posizionati in ordine fisico atteso: non puoi ridurre il PV se esistono LVs fisicamente dopo.
• Disco nuovo con metadata residui: dimenticare mdadm –zero-superblock può provocare sostituzioni indesiderate.
• Problemi hardware aggiuntivi su sdb5 durante l’operazione: rischio di corruzione.

Alternative

• Aumentare lo spazio invece di ridurre: aggiungere un nuovo disco e fare pvcreate + vgextend + lvextend.
• Ricostruire il sistema in un nuovo array, copiare dati e switchare: più lungo ma più pulito.

Piccola metodologia: come decidere le dimensioni target

1. Misurare uso attuale: du -sh / (o usare strumenti di capacità).
2. Aggiungere buffer di sicurezza (almeno 10-20% per crescita a breve termine).
3. Ridurre filesystem a una dimensione coerente, poi ridurre LV qualche centinaio di MB in più come margine.
4. Non modificare simultaneamente più LV critici senza checkpoint e backup.

Mappa decisionale (flowchart)

flowchart TD
  A'Verificare backup?' -->|No| Z[Effettua backup]
  A -->|Sì| B'Disco fallito rimosso?'
  B -->|No| C'mdadm --manage --fail/remove'
  C --> D'Azzerare superblock'
  B -->|Sì| D
  D --> E'Boot in rescue & attiva moduli'
  E --> F'Controllare filesystem'
  F --> G'Ridurre filesystem & LV'
  G --> H'PV resize con setphysicalvolumesize'
  H --> I'mdadm --grow con nuova size'
  I --> J'pvresize'
  J --> K'Ricreare LV/swap e ridimensionare'
  K --> L'e2fsck finale'
  L --> M'Riavvio e reintegro disco'

Test e casi di verifica (acceptance)

• Test 1: dopo lvreduce e pvresize, lvdisplay riflette le nuove dimensioni.
• Test 2: resize2fs senza parametri estende il FS al massimo disponibile.
• Test 3: dopo reintegrazione disco, cat /proc/mdstat mostra syncing e alla fine [UU] per RAID1.

Rischi e mitigazioni

• Rischio: perdita dati per errore di dimensionamento. Mitigazione: backup, snapshot, validazione uso disco.
• Rischio: disco con metadata residui. Mitigazione: sempre mdadm –zero-superblock prima di riusare un device.
• Rischio: operazioni su sistemi in produzione. Mitigazione: pianificare downtime o eseguire su replica/test.

Glossario (1 riga per termine)

• RAID: raggruppamento di dischi per ridondanza o performance.
• LVM: Logical Volume Manager, astrae volumi logici da volumi fisici.
• PV: Physical Volume, entità LVM su cui si poggia il VG.
• LV: Logical Volume, volume usato da filesystem o swap.
• mdadm: strumento per gestire array software RAID in Linux.

Note di sicurezza e consigli finali

• Non improvvisare dimensioni: verificare uso reale e lasciare margine.
• Tenere un piano di rollback: snapshot/backup e un modo per riattivare l’array originale.
• Documentare ogni comando eseguito; salvare output di controllo per eventuali indagini.

Riepilogo

Hai visto una procedura completa per ridurre un array RAID1 degradato e riallocare lo spazio in LVM in modo coerente. Segui la sequenza: rimuovi il disco guasto, azzera superblock, boot in rescue, riduci filesystem → LV → PV → RAID, poi ricrea LV e reintegra il disco. Verifica sempre con e2fsck, vgdisplay e /proc/mdstat prima di tornare in produzione.

Importante: eseguire sempre backup e, se possibile, testare la procedura su una copia o in ambiente di laboratorio prima di applicarla in produzione.