Lista di controllo per la revisione della conservazione degli snapshot per un NAS domestico

L’approccio più sicuro consiste nel trattare gli snapshot dell’inventario, associarli agli obiettivi e alle dipendenze di ripristino, quindi modificare la conservazione con un progetto pilota reversibile, procedendo attraverso una sequenza di controlli osservabili anziché impartire un unico comando.

Su un NAS domestico ZFS o Btrfs, il rischio concreto è che la cronologia degli snapshot, l’utilizzo della capacità e la copertura del ripristino non corrispondano più alle esigenze attuali. Registra l’identità attuale e il punto di ripristino, inizia con il discriminatore meno invasivo, interpreta i risultati positivi e negativi prima di modificare un’altra variabile e fermati quando lo spazio di archiviazione diventa instabile o quando l’unica copia recuperabile verrebbe esposta. Il flusso di lavoro riportato di seguito termina solo quando il carico di lavoro originale viene completato correttamente o quando le evidenze raggiungono una soglia di escalation.

Inventaria pianificazioni, responsabili e snapshot effettivi

Elenca ogni attività di snapshot, dataset o sottovolume, frequenza, regola di denominazione, regola di conservazione, responsabile e ultima esecuzione riuscita. Poi elenca gli snapshot effettivamente presenti. Le differenze rivelano pianificazioni disabilitate, eccezioni conservate manualmente, strumenti duplicati o snapshot che non sono più gestiti da alcuna policy.

Uno snapshot è una vista del filesystem in un determinato momento, mentre il suo costo in termini di spazio cresce man mano che cambiano i dati attivi. La guida allo storage di Princeton spiega il comportamento dello spazio degli snapshot e perché i blocchi conservati vengono conteggiati nella capacità disponibile anche quando l’albero attivo non li mostra più.

Non eliminare nulla durante l’inventario. Contrassegna gli snapshot sconosciuti come protetti finché non ne siano noti il creatore, il ruolo nella replica e il valore per il ripristino. La fase è superata quando ogni snapshot appartiene a una policy documentata o a un’eccezione esplicita.

Associa ogni livello a una domanda di ripristino

Per ogni dataset, scrivi le domande di ripristino a cui deve rispondere: annullare una modifica a un file effettuata oggi, recuperare una cartella eliminata la settimana scorsa, ripristinare un aggiornamento di un’app o inizializzare la replica fuori sede. Crea livelli orari, giornalieri, settimanali e mensili solo quando queste finestre corrispondono a reali esigenze di ripristino.

Conta i punti di ripristino completati correttamente, non le etichette pianificate. Un livello ad alta frequenza che ha smesso di funzionare tre giorni fa non può soddisfare un obiettivo di ripristino a breve termine, e uno snapshot mensile di dati applicativi soggetti a frequenti modifiche potrebbe essere troppo poco dettagliato anche se è recente. Considera separatamente i backup immutabili o fuori host, perché gli snapshot locali non sono copie indipendenti.

Rimuovi un livello proposto dal piano se nessuno sa indicare un caso di ripristino per cui utilizzarlo. Aggiungi copertura quando un dataset critico non dispone di uno snapshot o di un backup adeguato alla sua frequenza di modifica, ma non compensare l’assenza di backup conservando per sempre gli snapshot locali.

Controlla lo spazio e le dipendenze della replica prima della potatura

Misura lo spazio occupato dagli snapshot, i dati attivi referenziati, lo spazio libero del pool e la frequenza delle modifiche recenti allo stesso istante. Su ZFS, controlla i valori di spazio utilizzato e referenziato per ogni snapshot; su Btrfs, confronta l’inventario dei sottovolumi, i dati dei qgroup quando sono affidabili e l’allocazione del filesystem. Non prevedere lo spazio recuperato basandoti soltanto sulla dimensione apparente di uno snapshot.

Usa il flusso di lavoro ZimaSpace per stabilire se gli snapshot o i cestini usano spazio sul NAS prima di modificare la conservazione. Evita così di scambiare una stima basata sulle cartelle visibili per i blocchi trattenuti dagli snapshot o da un livello cestino.

Individua gli snapshot utilizzati come basi per la replica incrementale, dipendenze per la ripresa della ricezione, segnalibri, cloni o punti di rollback per la manutenzione in corso. Se l’eliminazione obbligherebbe a una nuova inizializzazione completa o interromperebbe un clone, modifica prima il piano di replica e conserva la base condivisa finché la nuova catena non sarà verificata.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

$799.00 - $2,499.00

Buy Now

Avvia il progetto pilota con la nuova regola e dimostra che il ripristino funziona ancora

Applica la nuova regola di conservazione a un dataset a basso rischio oppure visualizza l’elenco delle eliminazioni quando lo strumento supporta una simulazione. Salva i nomi e i timestamp che rimarrebbero, quindi conferma che i requisiti di ripristino più vecchi e più recenti siano ancora rappresentati prima di procedere.

Dopo l’eliminazione, verifica il comportamento dello spazio libero, lo snapshot pianificato successivo, la replica incrementale e il ripristino di un file recente e di uno più vecchio. Una policy che libera spazio ma interrompe la catena di invio o rimuove l’unico punto precedente all’aggiornamento non ha superato la verifica.

Adotta la regola solo dopo che due cicli di pianificazione hanno prodotto i livelli previsti e gli avvisi coprono gli snapshot mancanti. Interrompi la procedura e ripristina la policy precedente se la replica diventa di dimensione completa, gli snapshot scompaiono dall’interfaccia di ripristino o la cronologia rimanente non soddisfa più le domande di ripristino definite per iscritto.