La pagina 2 di questo tutorial della community sposta la decisione da «come eseguo dd?» a «che cosa vale davvero la pena proteggere?». L’utente disponeva già di un ampio NVMe in uso e si preoccupava molto più di perdere i DATI che di perdere il sistema operativo avviabile. Il consiglio di gelbuilding era di evitare di ripartizionare l’NVMe di avvio in uso, proteggere prima DATI e AppData e conservare un clone grezzo del sistema solo se il vantaggio in termini di tempo di ripristino giustifica lo spazio aggiuntivo necessario per il backup.
Questa priorità è coerente con l’architettura attuale di ZimaOS. Il sistema operativo dispone di slot di sistema A/B per un ripristino rapido, mentre i dati utente insostituibili, AppData e i metadati dello spazio di archiviazione risiedono al di fuori di queste immagini di sistema immutabili. Un clone dell’intero disco può riportare rapidamente la macchina a uno stato preciso, ma non sostituisce backup indipendenti e versionati dei DATI.
dd clona l’intero dispositivo, non solo i piccoli slot del sistema operativo
Il tutorial originale usa un comando concettualmente simile a:
dd if=/dev/NVME_DEVICE | gzip > USB_BACKUP.img.gzSe il sistema risiede su un NVMe da 1 TB, il processo di creazione dell’immagine grezza legge comunque l’intero dispositivo a blocchi. La compressione può ridurre le dimensioni del file, ma la destinazione e il processo di backup rimangono legati alla struttura fisica del disco, non solo ai pochi gigabyte utilizzati dalle partizioni di sistema di ZimaOS.
Non ripartizionare un sistema in uso e integro solo per ridurre le dimensioni di dd
gelbuilding ha definito la ripartizione dell’NVMe di avvio in uso come un’operazione ad alto rischio, poiché un errore può causare tempi di inattività o perdita di dati. Se la struttura attuale funziona, crea backup verificati dei dati prima di modificare i limiti delle partizioni.
Proteggi DATI e AppData prima del clone del sistema operativo
Se la tua priorità è la possibilità di ripristino, esegui il backup di:
- file utente e pool di archiviazione;
- AppData, database e configurazioni che non possono essere ricreati facilmente;
- esportazioni importanti specifiche delle applicazioni;
- metadati dello spazio di archiviazione di ZimaOS, come
local-storage.db, quando pertinenti; - poi, facoltativamente, dell’intero disco di sistema.
Le attuali indicazioni 3-2-1 di ZimaOS supportano backup pianificati verso destinazioni indipendenti e punti di ripristino versionati.
Usa il modello di backup 3-2-1 attuale di ZimaOS.
ZimaOS dispone già del ripristino del sistema A/B
ZimaOS utilizza due slot di sistema da circa 6 GB ciascuno. Se uno slot non funziona, l’attuale guida al ripristino consente all’utente di avviare lo slot alternativo da GRUB.
Usa il percorso attuale di ripristino del sistema A/B.
Una reinstallazione pulita può ricreare il sistema operativo, ma non automaticamente la configurazione esatta
Come ha osservato constgen, un sistema operativo immutabile può spesso essere semplicemente reinstallato. Il punto sollevato da gelbuilding riguardava invece il tempo di ripristino: un clone del disco può ripristinare esattamente applicazioni, configurazione e stato del sistema così come erano stati acquisiti, mentre una reinstallazione può richiedere la rimappatura di AppData, la reinstallazione delle applicazioni e il ricollegamento dei metadati dello spazio di archiviazione.
Entrambe sono strategie di ripristino valide; ottimizzano aspetti diversi.
Un piccolo disco di avvio dedicato semplifica la clonazione dell’intero disco
gelbuilding ha consigliato di spostare eventualmente ZimaOS su un dispositivo dedicato di piccole dimensioni, da 32-64 GB, mantenendo l’archiviazione NVMe/RAID di grandi dimensioni per DATI e AppData. Il minimo esatto per l’installazione dell’attuale ZimaOS è di almeno 25 GB.
In questo modo il sistema operativo, sacrificabile, viene separato dall’archiviazione dei dati di grandi dimensioni e un’immagine completa del sistema risulta molto più piccola.
I comandi di ripristino grezzo sono distruttivi
Il ripristino di un’immagine dd scrive direttamente sul disco di destinazione. Selezionare il dispositivo /dev/... sbagliato può distruggere un’altra unità. Il tutorial originale è stato condiviso esplicitamente a scopo di test e questi comandi dovrebbero essere utilizzati solo dopo aver identificato i dischi tramite modello e numero di serie e aver conservato altrove i DATI.
Testa il percorso di ripristino, non solo la creazione del backup
Un backup è utile solo se sai come ripristinarlo. Per i DATI, ripristina file rappresentativi. Per un’immagine grezza del sistema, se possibile testa il flusso di lavoro su supporti di riserva, invece di scoprire le ipotesi relative a dispositivi e percorsi durante un’interruzione reale.
Domande frequenti su clone e backup di ZimaOS
È necessario un clone completo del disco di sistema per proteggere i dati di ZimaOS?
No. I backup di DATI e AppData e i metadati dello spazio di archiviazione sono separati dalle partizioni di sistema A/B e hanno la priorità maggiore per le informazioni insostituibili.
Perché dovrei comunque conservare un clone grezzo del sistema operativo?
Può ridurre il tempo di ripristino, riportando il sistema e la configurazione delle applicazioni allo stato esatto acquisito, invece di doverli ricostruire manualmente.
Dovrei ripartizionare un NVMe in uso solo per ridurre le dimensioni del clone?
La raccomandazione originale era negativa: esegui prima il backup dei DATI ed evita modifiche non necessarie alle partizioni in uso.
