Perché uno snapshot di un NAS domestico può preservare dati già corrotti?

Uno snapshot di un NAS domestico può preservare dati corrotti perché il suo compito è conservare uno stato del filesystem, non decidere se ogni file in quello stato sia integro. Se un database, documento, foto o file multimediale è già danneggiato quando lo snapshot viene creato, il ripristino di quello snapshot può riprodurre la stessa versione danneggiata.

Il momento della corruzione è importante. Uno snapshot può proteggere una versione precedente da una sovrascrittura successiva, ma non può creare una versione pulita che non è mai stata catturata. La condivisione di blocchi copy-on-write crea anche un secondo caso: un danno fisico a un blocco può influenzare più di una vista del filesystem che ancora fa riferimento a quel blocco.

Uno snapshot preserva uno stato del filesystem, non una copia nota come buona

Uno snapshot del filesystem registra uno stato di archiviazione in un momento specifico. In OpenZFS, per esempio, uno snapshot è una versione di sola lettura di un filesystem o volume, e inizialmente condivide i dati con il dataset attivo invece di duplicare ogni file. La documentazione degli snapshot OpenZFS descrive come lo snapshot conserva i dati che altrimenti rimarrebbero condivisi fino a quando il dataset attivo cambia.

Quell'operazione non stabilisce se il contenuto memorizzato sia semanticamente corretto. Un filesystem può preservare un file strutturalmente leggibile anche quando un'applicazione ha scritto record non validi, uno strumento di sincronizzazione ha copiato la versione sbagliata o un ransomware ha sostituito i byte originali con contenuti crittografati. Il successo dello snapshot significa quindi che uno stato è stato conservato; non certifica che lo stato fosse buono.

La corruzione presente al momento dello snapshot diventa parte del punto di recupero

Considera uno snapshot programmato creato a mezzanotte. Se un'applicazione corrompe un database alle 22:00, lo snapshot di mezzanotte registra lo stato del filesystem post-corruzione. Tornare a quello snapshot riporta il database a mezzanotte, ma mezzanotte è già troppo tardi per fornire una copia sana.

La stessa sequenza può verificarsi dopo una sincronizzazione difettosa, un'importazione incompleta, un salvataggio accidentale o una crittografia non autorizzata. Lo snapshot non "incorpora" la corruzione come proprietà speciale; semplicemente conserva la versione esistente al momento della cattura. Uno snapshot più vecchio può ancora contenere una versione utilizzabile, ma ogni snapshot creato dopo il danno può contenere lo stesso errore logico.

Il momento della corruzione determina se uno snapshot può essere utile

Uno snapshot è più utile quando la modifica logica indesiderata avviene dopo il punto di recupero. Se lo snapshot di lunedì contiene un file integro e il file attivo viene sovrascritto martedì, la visualizzazione di lunedì può ancora mostrare i dati precedenti. Se il file era già danneggiato lunedì, quel punto di recupero non può risolvere il problema.

Il danneggiamento dello storage sottostante crea un percorso diverso. Uno snapshot potrebbe essere stato integro al momento della creazione, ma diventare illeggibile in seguito se un blocco fisico a cui fa ancora riferimento si danneggia e il filesystem non può ricostruire una copia verificata. Per questo motivo, il momento della corruzione deve essere considerato insieme alla condivisione dei blocchi e alla ridondanza dello storage.

La condivisione di blocchi copy-on-write può esporre un blocco danneggiato attraverso gli snapshot

Gli snapshot copy-on-write sono efficienti in termini di spazio perché i dati non modificati sono condivisi. La documentazione del modello di archiviazione Btrfs spiega che uno snapshot e il suo sottovolume sorgente condividono i dati comuni non modificati. Uno snapshot è quindi una vista storica del filesystem, non automaticamente una seconda copia fisica su supporti separati.

Quando il file attivo viene modificato normalmente, il copy-on-write assegna un nuovo spazio per la modifica mentre lo snapshot continua a fare riferimento ai blocchi precedenti. Questa separazione è ciò che rende possibile il rollback. Tuttavia, se un blocco non modificato è ancora condiviso e quel blocco memorizzato diventa in seguito illeggibile o restituisce dati errati, tutte le visualizzazioni che dipendono da esso possono incontrare lo stesso guasto.

I checksum e l'archiviazione ridondante possono cambiare il risultato rilevando la discrepanza e fornendo un'altra copia, ma lo snapshot stesso non crea questa protezione. Il copy-on-write fornisce la separazione delle versioni; non crea un dominio di guasto hardware indipendente.

I checksum e gli scrub testano l'integrità; gli snapshot no

Snapshot, checksum e scrub appartengono a parti diverse dello stack di protezione. Uno snapshot conserva la cronologia, un checksum aiuta a determinare se i byte memorizzati sono cambiati inaspettatamente, e uno scrub legge proattivamente i dati memorizzati per cercare errori. Trattare queste funzionalità come intercambiabili porta a una falsa sicurezza su ciò che un punto di recupero può dimostrare.

I checksum possono rilevare modifiche inaspettate ai blocchi

La documentazione Btrfs sul calcolo dei checksum afferma che i checksum vengono calcolati prima delle scritture e verificati dopo che i blocchi sono stati letti dall'archiviazione. Una discrepanza può rivelare che il blocco recuperato non è lo stesso che il filesystem si aspettava di memorizzare.

Un checksum corrispondente non dimostra che un documento, un database o un file multimediale sia logicamente corretto. Se un'applicazione scrive dati errati attraverso il normale percorso di scrittura, il filesystem può calcolare un checksum valido per quei byte errati. Il blocco è intatto dal punto di vista del filesystem anche se il contenuto a livello applicativo è inutilizzabile.

La ridondanza determina se uno scrub può riparare il danno

Uno scrub può rilevare errori di checksum, errori di lettura e alcuni problemi di metadati, ma il rilevamento non è la stessa cosa della riparazione. La documentazione Btrfs sullo scrub spiega che la riparazione automatica su archiviazione replicata utilizza dati verificati e corretti da un'altra replica. Senza una copia alternativa valida, il filesystem può identificare il blocco danneggiato senza poterlo ricostruire.

Uno studio USENIX sull'integrità dei dati in ZFS separa similmente il rilevamento basato su checksum dal recupero tramite ridondanza. La lezione pratica è più ristretta di “gli scrub correggono la corruzione”: uno scrub può riparare solo i guasti per i quali il sistema di archiviazione può individuare o ricostruire dati sostitutivi affidabili.

La conservazione delle istantanee aiuta solo se esiste ancora uno stato sano

La corruzione non viene sempre notata immediatamente. Una foto, un archivio o un file di progetto raramente aperto può rimanere danneggiato per settimane prima che qualcuno tenti di usarlo. Se la rotazione delle istantanee ha già rimosso ogni versione precedente al danno, una raccolta profonda di istantanee recenti potrebbe comunque non contenere alcun punto di recupero sano.

La conservazione dovrebbe quindi riflettere la finestra di rilevamento probabile, non solo la frequenza con cui vengono create le istantanee. Le istantanee orarie forniscono una cronologia recente dettagliata, mentre i punti giornalieri, settimanali o mensili di durata più lunga estendono il periodo in cui un errore non rilevato può essere evitato. Non esiste un programma universale: l'intervallo utile dipende dalla frequenza delle modifiche, dalla capacità disponibile e dalla rapidità con cui i file importanti vengono normalmente controllati.

Verifica uno snapshot prima di sostituire i dati NAS attivi

Scegliere uno snapshot per data è solo il primo passo. Prima di ripristinare un intero dataset o sostituire il file attivo, ripristina una versione candidata in una posizione separata quando la piattaforma home NAS lo consente. Questo evita che un tentativo di recupero non verificato sovrascriva dati più recenti che potrebbero ancora essere utili.

1. Stima quando è apparsa per la prima volta la corruzione.
2. Seleziona uno snapshot precedente a quel momento.
3. Ripristina il candidato in una cartella o clone alternativo.
4. Apri, valida o confronta il contenuto recuperato prima di sostituire i dati attivi.

La validazione dovrebbe corrispondere al tipo di dati. Un checksum noto può verificare un archivio non modificato, mentre un database può richiedere un controllo di coerenza proprio e una foto o un video potrebbe dover essere decodificato. Per la relazione più ampia tra punti di recupero, copie indipendenti e protezione fuori dispositivo, vedere questa strategia di backup per NAS domestici.

FAQ

Uno snapshot preso prima della corruzione può comunque diventare illeggibile?

Sì. Uno snapshot protegge uno stato logico precedente da modifiche successive ai file, ma può comunque condividere lo stesso pool di archiviazione e blocchi fisici. Se uno di questi blocchi è danneggiato e non è disponibile una copia ridondante verificata, lo snapshot precedente può diventare illeggibile anche se è antecedente alla corruzione logica in esame.

Uno snapshot riuscito significa che ogni file al suo interno è sano?

No. Uno snapshot riuscito indica che il filesystem ha creato il punto di recupero. Non significa che ogni file sia stato aperto, decodificato, controllato rispetto a una versione affidabile o validato dall'applicazione che lo ha creato.

Può uno scrub dei dati riparare una corruzione scritta da un'applicazione?

Di solito no, quando l'applicazione ha scritto normalmente il contenuto errato. In tal caso, il filesystem può memorizzare i byte errati con un checksum valido, senza lasciare discrepanze a livello di blocco che lo scrub possa rilevare. Il recupero richiede una versione sana precedente, un processo di riparazione consapevole dell'applicazione o una copia indipendente.

Sostituire un file attivo corrotto ripara gli snapshot più vecchi?

No. La sostituzione dei file attivi scrive o fa riferimento a dati sani per il dataset attivo, ma gli snapshot più vecchi continuano a rappresentare i loro stati storici. Uno snapshot che ha mantenuto la versione corrotta normalmente rimane corrotta fino alla sua scadenza o cancellazione.