Checklist di verifica del genitore di Btrfs Send prima della pulizia degli snapshot

Eva Wong

IceWhale author

Eva Wong è la Technical Writer e smanettatrice residente di ZimaSpace. Una geek da sempre con una passione per homelab e software open-source, si specializza nel tradurre concetti tecnici complessi in guide accessibili e pratiche. Eva crede che l'auto-ospitare debba essere divertente, non intimidatorio. Attraverso i suoi tutorial, dà potere alla comunità di demistificare le configurazioni hardware, dalla costruzione del loro primo NAS al dominio dei container Docker.

Btrfs Send Parent Verification Checklist Before Snapshot Cleanup - Zima Store Online

Non eliminare un genitore Btrfs send solo perché sembra vecchio. Prima verifica che esista uno snapshot di sola lettura più recente su entrambi i lati e che possa essere utilizzato per il ciclo incrementale successivo.

Su un NAS domestico, gli snapshot di origine e di destinazione hanno spesso nomi simili, mentre i loro ruoli nella replica sono diversi. La pulizia diventa rischiosa quando un processo di rotazione considera solo l'età e non la coppia che fa da base al send successivo. Inizia con un inventario in sola lettura, identifica l'ultima coppia origine-destinazione completata correttamente, prova un figlio più recente rispetto a essa e conserva la destinazione precedente finché non viene completata un'altra ricezione incrementale.

Inventaria la coppia di genitori attuale su entrambi i sistemi

Elenca il sottovolume di origine, ogni snapshot di sola lettura per il send e ogni snapshot di destinazione ricevuto. Registra il percorso, l'ora di creazione, lo stato di sola lettura, l'ID del sottovolume, l'UUID, la relazione con il genitore e, quando disponibile, l'identità della ricezione. Abbina l'ultimo snapshot di origine completato correttamente alla copia effettivamente ricevuta, non semplicemente a una directory con un nome simile.

Una sequenza Btrfs di invio e ricezione funzionante mantiene disponibile lo snapshot precedente su entrambi i sistemi prima di utilizzarlo come genitore del successivo flusso incrementale.

Se la coppia è chiaramente presente ed è di sola lettura, contrassegnala come protetta. Se coincidono solo i nomi, esamina la relazione di ricezione e il registro della replica prima di continuare. Se manca la copia di destinazione, interrompi la pulizia e pianifica un nuovo invio completo o un'altra base verificata; eliminare lo snapshot di origine non può riparare la cronologia mancante sul ricevitore.

Dimostra che uno snapshot più recente può diventare il genitore successivo

Crea il successivo snapshot di origine in sola lettura dopo aver salvato l'inventario. Usa esplicitamente lo snapshot di origine protetto come genitore e invia il nuovo figlio alla destinazione prevista o a un percorso di staging. Registra il codice di uscita e il log, quindi confronta un campione di file modificati e non modificati nello snapshot ricevuto.

Gli script di replica incrementale dovrebbero rendere visibile la dipendenza. Un pratico flusso di lavoro per la rotazione degli snapshot funziona solo quando gli snapshot previsti dalla logica di send rimangono al loro posto.

Promuovi la nuova coppia a candidata per la pulizia solo quando la ricezione riesce e lo snapshot di destinazione è leggibile. Un errore di genitore non trovato, uno snapshot di origine scrivibile, un dataset errato o un flusso inaspettatamente equivalente a una copia completa indicano che il test è fallito. Lascia intatta la vecchia coppia mentre correggi il percorso o ricostruisci la base.

Esegui la pulizia solo dopo che il ruolo di genitore è avanzato

Aggiorna il registro della conservazione prima di eliminare qualsiasi elemento. Contrassegna i nuovi snapshot di origine e destinazione verificati come coppia attiva, mantieni la coppia immediatamente precedente come fallback a breve termine e visualizza in anteprima quali snapshot più vecchi verrebbero rimossi dal processo di pulizia. L'anteprima dovrebbe contenere solo gli antenati che non servono più al successivo invio o al piano di ripristino.

Una modifica a un file può essere trasferita a uno snapshot più recente e inviata da una base esistente, quindi la cronologia incrementale futura dipende dalle relazioni conservate tra gli snapshot, non dalla modifica di un vecchio snapshot di sola lettura.

Annulla la pulizia se nell'insieme da eliminare compare il genitore attivo, la coppia di fallback, lo snapshot ricevuto più recente o un elemento orfano non verificato. Rimuovi gli snapshot in piccoli gruppi e riepiloga entrambi i sistemi dopo ogni gruppo. Non permettere che processi di rotazione separati per origine e destinazione avanzino indipendentemente senza condividere lo stesso registro della coppia protetta.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

Esegui il ciclo incrementale successivo prima di dismettere il fallback

Dopo la pulizia, apporta una modifica controllata a un file e crea un nuovo snapshot di sola lettura. Esegui il successivo invio incrementale dal genitore appena promosso. Questo secondo ciclo dimostra che il registro della pulizia, lo script e lo stato della destinazione sono coerenti; il solo primo invio riuscito non ha verificato l'ambiente successivo alla pulizia.

Se non è possibile rimuovere uno snapshot perché è ancora in uso, separa la logica di conservazione dal percorso attivo di invio Btrfs prima di concludere che la mappa dei genitori sia errata.

La checklist è superata quando il secondo figlio viene ricevuto correttamente, i file previsti sono presenti, la coppia attiva rimane di sola lettura e l'esecuzione pianificata successiva la seleziona automaticamente. Dismettere il fallback solo dopo questo risultato. Interrompi e ripristina lo stato protetto della coppia precedente se il successivo invio segnala un genitore mancante, usa il sottovolume errato o propone un trasferimento completo inatteso.