Guida alla migrazione dei dataset ZFS: sposta i dati senza modificare i percorsi dei container

L’approccio sicuro consiste nel trattare la replica, la verifica e il passaggio atomico dal punto di mount originale a un dataset con rollback conservato come una sequenza di verifiche osservabili, non come un singolo comando.

Su dataset ZFS che supportano uno stack di container per home server, il rischio pratico consiste nel dover spostare un dataset ZFS preservando i percorsi dei bind mount usati dai container. Registra l’identità attuale e il punto di ripristino, inizia con il discriminante meno invasivo, interpreta i risultati positivi e negativi prima di modificare un’altra variabile e fermati quando lo storage diventa instabile o l’unica copia recuperabile rischia di essere esposta. Il flusso di lavoro seguente termina solo quando il carico di lavoro originale funziona correttamente o le evidenze raggiungono una soglia di escalation.

Inventaria il dataset e il contratto dei percorsi

Registra il dataset di origine, i relativi dataset figli, gli snapshot, il punto di mount, il valore di canmount, la radice di cifratura, le quote, le riserve, il comportamento degli ACL e ogni bind mount dei container che ricade al suo interno. Il contratto è il percorso host visualizzato dai container; il nome del pool e del dataset può cambiare senza modificare quel percorso.

La replica ZFS può preservare snapshot e proprietà, quindi un flusso ricorsivo richiede una revisione intenzionale delle proprietà anziché una ricezione alla cieca. Una migrazione indipendente tramite ZFS send e receive mostra come usare send e receive per la migrazione interna dei dataset e perché sia necessario ispezionare la gerarchia di destinazione prima del passaggio.

Crea un backup esterno aggiornato oppure dimostra l’esistenza di un ripristino funzionante prima della migrazione. Fermati se l’origine contiene dataset figli nascosti, una dipendenza sconosciuta da una chiave di cifratura o un punto di mount che si sovrappone a un altro dataset attivo; queste condizioni possono far montare correttamente un flusso nel posto sbagliato.

Ricevi la prima copia senza montarla sopra la produzione

Crea uno snapshot ricorsivo come zfs snapshot -r oldpool/apps@move-0, quindi invialo a un dataset di destinazione ricevuto con il montaggio disabilitato o con un punto di mount temporaneo. Usa i flag appropriati per i requisiti di cifratura e proprietà; non presumere che un flusso cifrato raw e una ricezione decifrata abbiano lo stesso comportamento per le chiavi.

Dopo la ricezione, confronta zfs list -r -t filesystem,snapshot e zfs get -r mountpoint,canmount,encryptionroot,quota,reservation su entrambe le gerarchie. Una discussione sul forum relativa alle proprietà dei punti di mount replicate illustra perché le proprietà dei punti di mount replicate possano sorprendere anche in una migrazione riuscita.

La prima copia è valida quando il dataset e la relativa discendenza degli snapshot corrispondono e la destinazione rimane isolata dal percorso di produzione. Se viene montata sopra l’origine o modifica i file visibili ai container, esporta o smonta la destinazione e correggi le proprietà prima di qualsiasi invio incrementale.

Chiudi la finestra di scrittura e cambia il punto di mount

Crea un altro snapshot dell’origine e invia la differenza incrementale mentre l’applicazione è ancora in esecuzione. Per il passaggio finale, arresta tutti i processi di scrittura, verifica che nessun processo abbia file aperti nel percorso del bind mount, crea uno snapshot finale e invia solo quella differenza. Mantieni il downtime limitato alla sincronizzazione finale e al cambio del percorso.

Imposta l’origine su un punto di mount non di produzione o su canmount=noauto, quindi assegna al target il percorso host originale e montalo. Non lasciare mai due dataset con lo stesso punto di mount. Avvia il database e i servizi dipendenti prima del front-end dell’applicazione, in modo che gli errori indichino il livello corretto.

Se l’invio finale non riesce, rimonta l’origine sul percorso originale e riavvia lo stack; non mescolare le nuove scritture tra le due copie. La condizione di rollback è esplicita: l’origine rimane intatta e nessuna scrittura di produzione viene accettata sulla destinazione finché il flusso finale e i controlli delle proprietà non hanno esito positivo.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

$799.00 - $2,499.00

Buy Now

Convalida i container sul percorso invariato

Ispeziona i bind mount dal runtime dei container, apri file rappresentativi, crea e rimuovi un file temporaneo tramite l’applicazione e verifica proprietari, ACL, attributi estesi e spazio libero disponibile. Riavvia lo stack due volte e verifica che i mount ZFS siano disponibili prima dell’avvio dei container.

Esegui uno scrub o un altro controllo dello stato del pool secondo il tuo piano di manutenzione, ma non usarlo come unica prova della migrazione. Confronta i GUID degli snapshot o un manifest di hash rappresentativo, ripristina un elemento di piccole dimensioni e usa il test di ZimaSpace per verificare se la replica ZFS possa riprendere dopo un’interruzione prima di dismettere la discendenza dell’origine.

Conserva l’origine in sola lettura finché non va a buon fine almeno un normale ciclo di backup e applicazione. Dismettila solo quando i container utilizzano i percorsi originali, i processi pianificati puntano al nuovo dataset, la replica continua dalla discendenza prevista e il rollback non è più necessario; altrimenti ripristina il punto di mount e conserva entrambe le cronologie.