Iniziare oggi con un’unica unità NVMe e passare in seguito al RAID è un piano ragionevole per un server domestico, ma il percorso di migrazione sicuro non consiste nel «fare clic su Converti JBOD in RAID». Il thread di origine del febbraio 2026 raccomandava una procedura controllata backup → crea un nuovo array → ripristina → verifica, invece di presumere che ZimaOS potesse trasformare in loco lo spazio di archiviazione esistente su un solo disco.
Da quel post, gli strumenti di migrazione di ZimaOS sono migliorati. Impostazioni > Migrazione dati ora consente di spostare Immagini Docker, Dati delle applicazioni Docker e database utente di ZimaOS tra gli spazi di archiviazione. Questo semplifica la migrazione dello stato delle applicazioni, ma non trasforma comunque un disco singolo già utilizzato in una configurazione RAID 1/5 ridondante senza un array di destinazione separato.
L’utente di origine ha iniziato con un NVMe e un disco USB per i backup
Il sistema utilizzava l’eMMC integrata per ZimaOS, un SSD NVMe configurato come spazio di archiviazione JBOD e un HDD USB per i backup. L’utente voleva aggiungere in seguito altri dispositivi NVMe e spostare tutto in RAID 1 o RAID 5.
Questa è esattamente la situazione in cui è importante conservare un backup indipendente verificato, perché la modifica della topologia di archiviazione può comportare l’inizializzazione di nuovi dischi e, alla fine, la cancellazione del vecchio layout su un solo disco.
Non dare per scontato che un JBOD su un solo disco possa essere convertito in loco
La risposta della community affermava che l’interfaccia Archiviazione di ZimaOS non offriva una procedura supportata per convertire in loco un JBOD su un solo disco in RAID. Raccomandava invece di creare un nuovo array da unità inutilizzate.
La documentazione pubblica attuale di Archiviazione supporta ora l’aggiunta di unità a determinati layout RAID esistenti, in particolare l’espansione RAID 5, ma ciò è diverso dal convertire in loco uno spazio di archiviazione non ridondante su un solo disco in RAID.
Esegui il backup di più delle sole cartelle condivise più ovvie
Prima di modificare l’archiviazione, proteggi:
- i normali file condivisi;
- i dati delle applicazioni Docker;
- le cartelle associate tramite bind mount personalizzati;
- i database delle applicazioni;
- le definizioni Compose/YAML per le applicazioni personalizzate;
- le configurazioni importanti che non vengono ricreate automaticamente.
Un backup deve essere verificato aprendo effettivamente file rappresentativi o eseguendo un ripristino di prova, non semplicemente controllando che lo stato dell’attività risulti completato.
Crea il nuovo RAID prima di cancellare il vecchio disco
L’architettura di migrazione più sicura consiste nel lasciare intatto l’NVMe originale mentre il nuovo RAID viene creato sulle unità appena aggiunte. In questo modo lo spazio di archiviazione originale rimane un’ulteriore fonte di ripristino finché il nuovo array non è stato convalidato.
ZimaOS gestisce attualmente la creazione degli array tramite Impostazioni > Archiviazione. Usa la procedura attuale di configurazione dell’archiviazione di ZimaOS invece di riprodurre le vecchie procedure manuali con mdadm.
Scegli RAID 1 o RAID 5 in base al numero di unità e alla crescita prevista
RAID 1 è il semplice mirroring a due unità. RAID 5 richiede almeno tre unità e sacrifica la capacità equivalente a un’unità per tollerare il guasto di una singola unità.
La documentazione attuale di ZimaOS presenta RAID 5 come un’opzione per librerie in crescita e afferma che le unità possono essere aggiunte nel tempo. Questo può rendere RAID 5 interessante se prevedi di espandere il pool dopo la migrazione iniziale.
La migrazione dati attuale può spostare i dati gestiti da ZimaOS
La documentazione attuale di IceWhale afferma che Impostazioni > Migrazione dati può spostare:
- le immagini Docker;
- i dati delle applicazioni Docker;
- i database utente come Galleria, Download, Documenti, Media e Backup.
Usa la procedura attuale di migrazione dati di ZimaOS dopo aver creato lo spazio di archiviazione di destinazione.
I bind mount personalizzati richiedono comunque una verifica manuale
Le categorie di migrazione integrate non garantiscono che ogni percorso host personalizzato in ogni stack Compose venga riscritto automaticamente. Controlla le applicazioni che montano cartelle insolite al di fuori delle posizioni gestite normalmente da ZimaOS.
Dopo la migrazione, esamina la mappatura dei volumi di ogni applicazione importante e conferma che la cartella sul lato host punti al nuovo spazio di archiviazione.
Verifica il nuovo RAID prima di riutilizzare l’NVMe originale
Conferma che:
- il RAID risulti integro;
- le condivisioni importanti contengano i file previsti;
- le applicazioni Docker si avviino e i relativi database siano integri;
- i permessi funzionino dai client normali;
- i processi di backup puntino all’origine e alla destinazione corrette.
Solo a quel punto dovresti cancellare o riutilizzare l’NVMe originale.
Conserva il backup USB anche dopo il passaggio al RAID
Il RAID protegge la disponibilità dopo il guasto di un disco membro. Non protegge da cancellazioni accidentali, ransomware, danneggiamento delle applicazioni, furto o perdita dell’intero server.
Il backup USB del piano originale rimane utile anche dopo la migrazione al RAID e può diventare parte di una strategia 3-2-1 più ampia.
Domande frequenti sul passaggio da JBOD a RAID
Lo ZimaOS attuale può spostare AppData tra gli spazi di archiviazione?
Sì. Lo strumento attuale di Migrazione dati include i dati delle applicazioni Docker e le immagini Docker.
Significa che un disco JBOD singolo può essere convertito in RAID 1 in loco?
No. Lo spostamento dei dati e la modifica della topologia di archiviazione sono operazioni separate.
Quando bisogna cancellare il disco originale?
Solo dopo aver verificato il nuovo array, i file, lo stato delle applicazioni, i permessi e i backup.
