Ripristinare un RAID 1 di ZimaOS dopo aver reinstallato il sistema

Se ZimaOS viene reinstallato e un RAID 1 esistente appare come dischi inutilizzati, non fare subito clic su Crea RAID. Ricreare o formattare l'array può distruggere i dati ancora presenti sui dischi membri.

Il primo percorso di recupero dovrebbe essere il metodo ufficiale attuale di ZimaOS: ripristinare il file salvato local-storage.db file dalla precedente installazione di sistema. Il tutorial della community alla base di questa pagina documenta una soluzione alternativa più invasiva per il caso più complesso in cui il database non sia stato sottoposto a backup. Questa soluzione è stata testata su ZimaOS 1.6.1, ma include operazioni distruttive sul RAID e dovrebbe essere presa in considerazione solo dopo aver copiato e verificato i dati di origine in modo indipendente.

Prima scelta: ripristinare local-storage.db

ZimaOS conserva le informazioni sulla configurazione dell'archiviazione in:

/ZimaOS-HD/.casaos/db/local-storage.db

L'attuale guida ufficiale al recupero consiglia di scaricare questo file prima di reinstallare il sistema, quindi di ripristinarlo nella stessa directory dopo la nuova installazione di ZimaOS e il riavvio.

Recupero ufficiale del RAID di ZimaOS dopo la reinstallazione

Se hai ancora accesso al vecchio disco di sistema, prova a recuperare questo database prima di intervenire sui dischi membri del RAID.

Perché l'array di dati potrebbe essere ancora integro

ZimaOS utilizza il RAID software di Linux. I dischi membri possono conservare i metadati RAID anche quando la nuova installazione di ZimaOS non dispone più del vecchio database di archiviazione. Per questo i dischi possono risultare fisicamente presenti mentre l'interfaccia non riconosce più il pool originale.

ZimaOS 1.6 ha inoltre introdotto miglioramenti nel recupero dei metadati RAID e nel comportamento di riconoscimento dei dischi, quindi non si deve presumere che un problema riscontrato originariamente su un sistema si verifichi nello stesso modo in ogni versione più recente.

Non creare un nuovo RAID prima di aver deciso come procedere con il recupero

Se i dischi contengono dati necessari, evita:

• formattare uno dei dischi membri;
• creare un nuovo RAID sugli stessi dischi;
• eseguire wipefs oppure mdadm --zero-superblock prematuramente;
• indovinare quale /dev/sdX quale dispositivo è.

Prima di qualsiasi intervento di recupero, identifica i dischi tramite modello, numero di serie e capacità, invece di affidarti solo alle lettere dei dispositivi.

Verifica i metadati RAID in sola lettura

L'autore della guida della community ha iniziato con un'ispezione in sola lettura per confermare che entrambi i membri del RAID 1 appartenessero ancora allo stesso array.

lsblk -o NAME,SIZE,TYPE,MOUNTPOINT,FSTYPE,MODEL,SERIAL

mdadm --examine /dev/sda
mdadm --examine /dev/sdb

Per un RAID 1 integro, entrambi i membri dovrebbero riportare lo stesso UUID dell'array e metadati RAID compatibili. Se un membro è mancante, degradato o riporta metadati diversi, fermati e richiedi assistenza per il recupero invece di seguire una procedura generica di ricostruzione.

Assembla e monta il vecchio array in sola lettura

Per un ripristino avanzato, l'assemblaggio in sola lettura riduce il rischio di modificare la sorgente mentre verifichi che i file siano accessibili:

mdadm --assemble --readonly /dev/md127 /dev/sda /dev/sdb

mkdir -p /DATA/oldraid
mount -o ro /dev/md127 /DATA/oldraid

Quindi ispeziona il filesystem:

df -h /DATA/oldraid
ls -la /DATA/oldraid
du -sh /DATA/oldraid/*

I nomi dei dispositivi riportati sopra sono solo esempi. Non incollarli mai senza modificarli, a meno che tu non abbia verificato che corrispondano al tuo hardware.

Crea una copia offload completa prima di qualsiasi operazione distruttiva

Il flusso di lavoro originale utilizzava un'unità ext4 esterna abbastanza grande da contenere tutti i dati RAID utilizzati. Per i dati delle applicazioni Linux, ext4 è utile perché può preservare proprietari, autorizzazioni, collegamenti, ACL e attributi estesi normali.

Una tipica copia in stile archivio è:

rsync -aHAX --info=progress2   /DATA/oldraid/   /DATA/offload/

Esegui la copia in tmux o un altro terminale persistente, se una disconnessione SSH interrompesse altrimenti l'operazione.

Verifica il backup prima di procedere

Non affidarti solo alla riga di uscita di rsync. Confronta il numero di file e controlla le dimensioni delle directory principali:

find /DATA/oldraid -xdev -type f | wc -l
find /DATA/offload -xdev -type f | wc -l

du -sh /DATA/oldraid/*
du -sh /DATA/offload/*

Per i dati insostituibili, è preferibile un secondo backup indipendente. Il RAID non è di per sé un backup.

Ultima risorsa: esegui l'offload, rimuovi i vecchi metadati RAID e ricrea l'array nell'interfaccia

L'autore originale della community voleva riportare l'array ripristinato alla normale gestione tramite l'interfaccia ZimaOS. Il suo metodo di ultima istanza era:

1. verifica il vecchio array in sola lettura;
2. copia tutti i dati su un'unità esterna;
3. verifica la copia;
4. arresta il vecchio array md;
5. rimuovi i vecchi metadati RAID;
6. crea un nuovo RAID 1 utilizzando l'interfaccia Archiviazione di ZimaOS;
7. ripristina i file copiati;
8. verifica i dati ripristinati.

Questa procedura distrugge intenzionalmente i vecchi metadati RAID. Una volta eseguito questo passaggio, la copia offload diventa la fonte per il ripristino. Non usare questo approccio se la copia è incompleta o se non sei sicuro dell'identità dei dispositivi.

Il comando irreversibile nel flusso di lavoro originale

La procedura utilizzata dalla community:

mdadm --zero-superblock /dev/sda /dev/sdb

Non è un comando di risoluzione dei problemi. Rimuove i metadati RAID dai dischi specificati. Un percorso del dispositivo errato può causare una grave perdita di dati.

Per questo motivo, questa pagina non consiglia di eseguirlo solo perché l'interfaccia ZimaOS non riconosce un RAID. Ripristina local-storage.db, verifica il comportamento attuale del ripristino di ZimaOS e contatta prima l'assistenza quando l'array contiene dati importanti.

Perché ricreare l'array tramite l'interfaccia ZimaOS?

Lo scopo del flusso di lavoro di origine era terminare con un pool di storage gestito normalmente da ZimaOS, anziché con un dispositivo md assemblato manualmente in modo permanente al di fuori dell’interfaccia di storage.

Dopo aver trasferito al sicuro i vecchi dati e reimpostato intenzionalmente i dischi, usa l’interfaccia Storage corrente per creare RAID 1 e lascia completare la sincronizzazione iniziale.

Ripristina i file nel nuovo pool

Dopo aver creato e montato il nuovo pool, ripristina i dati dal disco di trasferimento:

rsync -aHAX --info=progress2   /DATA/offload/   /media/Storage/

Sostituisci /media/Storage con il percorso di destinazione effettivo mostrato dal tuo sistema.

Verifica il pool ripristinato

find /DATA/offload -xdev -type f | wc -l
find /media/Storage -xdev -type f | wc -l
du -sh /media/Storage/*
cat /proc/mdstat

Tieni intatto il disco di trasferimento finché la sincronizzazione RAID non è completata e non avrai verificato il normale accesso tramite l’interfaccia File di ZimaOS e le applicazioni che dipendono dai dati.

Esegui il backup di local-storage.db prima della prossima reinstallazione

Il recupero più semplice è quello preparato in anticipo. Conserva una copia aggiornata di:

/ZimaOS-HD/.casaos/db/local-storage.db

fuori dal disco di sistema. La documentazione ufficiale ora fornisce una procedura diretta di ripristino usando questo file.

Quale percorso di recupero dovresti scegliere?

Domande frequenti sul recupero RAID di ZimaOS

La reinstallazione di ZimaOS cancella automaticamente i dati RAID?

No. Reinstallare il disco di sistema è diverso dal formattare i dischi membri del RAID. La configurazione dello storage può andare persa mentre i metadati RAID e i dati rimangono sui dischi membri.

Devo fare clic su «Crea RAID» se i vecchi dischi risultano inutilizzati?

Non finché non hai confermato che non sia necessario recuperare dati esistenti. La creazione di un nuovo RAID può essere distruttiva.

Qual è il recupero più sicuro se ho eseguito il backup di local-storage.db?

Usa la procedura ufficiale corrente di ZimaOS per ripristinare quel database e riavviare.

È sicuro azzerare il superblocco mdadm?

È intenzionalmente distruttivo per i metadati RAID. Usalo solo nell’ambito di un piano di recupero verificato, dopo aver copiato i dati al sicuro altrove.