Questo thread è un rapporto avanzato su un errore di migrazione dello storage, non una procedura di importazione supportata. L’array di origine è stato assemblato a livello del kernel Linux, ma il livello Storage di ZimaOS non lo ha adottato correttamente e l’utente ha riscontrato un errore persistente nell’interfaccia.
Il rilevamento dell’array a livello del kernel non equivale alla gestione da parte di ZimaOS
Un sistema Linux può riconoscere i metadati RAID o un file system, mentre un gestore dello storage di tipo appliance può non disporre ancora dello stato del ciclo di vita necessario per gestire il pool in sicurezza. Il flusso di ripristino RAID mostra il principio più sicuro di ZimaOS per gli array già supportati: preservare i metadati RAID esistenti ed evitare di ricreare l’array come primo passaggio.
OpenZFS ha un ciclo di esportazione e importazione esplicito
La documentazione ufficiale sull’esportazione dei pool OpenZFS spiega che l’esportazione di un pool smonta i relativi dataset e contrassegna i dispositivi come esportati, così da poterli spostare e importare in seguito. La documentazione sull’importazione dei pool OpenZFS spiega come un altro host individua e importa i pool disponibili.
La documentazione per sviluppatori di ZimaOS attualmente disponibile espone anche operazioni CLI per ZFS, tra cui zpool export. Questo non equivale a una procedura guidata grafica generale per importare pool arbitrari mdadm+Btrfs, Btrfs nativi e ZFS.
La documentazione pubblica attuale non descrive una procedura guidata universale per pool esterni
La procedura guidata Storage attuale si concentra sulla creazione e sulla gestione dello storage di ZimaOS, mentre la guida pubblica per sviluppatori ZFS documenta le operazioni ZFS manuali. Se il tuo obiettivo effettivo è spostare i dati gestiti da ZimaOS su un nuovo storage, anziché adottare un array esterno, la migrazione dei dati di ZimaOS è il percorso attuale più sicuro. Il flusso di backup di ZimaOS dovrebbe essere parte del piano prima di eseguire operazioni distruttive sullo storage.
Non forzare i flag di ripristino dell’importazione sull’unica copia
OpenZFS avverte che le importazioni forzate o di ripristino possono eliminare transazioni recenti o comportare altri rischi. Non sperimentare con i flag di ripristino né con la riformattazione distruttiva sull’unica copia dei dati importanti.
In sintesi
Il problema riscontrato dalla community nella versione 1.6.1 mostra perché un array esterno riconosciuto dal kernel non diventa automaticamente un pool gestito da ZimaOS. ZFS dispone di un ciclo di esportazione/importazione definito, ma la documentazione pubblica attuale di ZimaOS non descrive una procedura grafica universale per adottare ogni combinazione esterna di RAID e file system.
