Perché un controllo d’integrità del repository può essere superato mentre un singolo file non viene ancora ripristinato?

Un controllo del repository può avere esito positivo mentre il ripristino di un file fallisce, se il controllo convalida i metadati o un campione di dati invece dell’esatto percorso di recupero.

La verifica del backup non è un’operazione universale. Alcuni controlli confermano la struttura del repository, gli indici, i manifest e i chunk referenziati senza leggere ogni byte archiviato. Altri campionano i dati, ignorano i file che non sono mai stati acquisiti oppure non forniscono informazioni sui nomi, sui permessi, sulle ACL, sulle etichette, sullo spazio libero e sui blocchi applicativi del filesystem di destinazione. Considera il file che ha generato l’errore come un percorso che va dalla selezione dello snapshot, passando per gli oggetti archiviati, fino alla creazione nella destinazione.

Identifica esattamente cosa ha verificato il controllo riuscito

Salva il comando di controllo, le opzioni, la versione dello strumento di backup, il backend del repository, l’ID dello snapshot e il log finale. Determina se il controllo ha verificato la struttura del repository, i metadati dell’archivio, i chunk referenziati, i dati archiviati o un’estrazione effettiva.

Borg dichiara che il suo controllo standard dell’archivio legge i metadati, ma per impostazione predefinita non i dati dei file, a meno che non venga richiesta esplicitamente la verifica dei dati.

Un risultato positivo può quindi dimostrare che i riferimenti sono coerenti internamente, lasciando però alcuni chunk di dati utili non letti. Non considerare il repository completamente ripristinabile finché non avrai estratto file rappresentativi.

Determina se i dati archiviati del file sono stati effettivamente letti

Individua il file nello snapshot previsto e identifica i pack, i chunk o gli oggetti necessari per ricostruirlo. Confronta il ripristino non riuscito con l’ambito di lettura dei dati previsto dal controllo del repository.

Restic documenta i controlli read-data e read-data-subset, mostrando che un controllo strutturale di routine e una lettura completa del contenuto sono livelli di verifica differenti.

Se è stato letto solo un sottoinsieme, il file che ha generato l’errore potrebbe dipendere da un pack non verificato. Esegui un controllo dei dati mirato o completo, se supportato, prima di tentare una riparazione.

Conferma che il file fosse incluso nello snapshot

Elenca il percorso relativo esatto nello snapshot selezionato. Controlla filtri, esclusioni, avvisi relativi a sorgenti non leggibili, regole per i collegamenti simbolici, confini dei punti di montaggio e l’eventualità che l’interfaccia di ripristino abbia selezionato un’altra versione.

Kopia avverte che le policy di esclusione omettono i percorsi corrispondenti, quindi la coerenza del repository può risultare positiva anche quando il file desiderato non è mai stato acquisito.

Un percorso segnaposto o una voce relativa alla directory principale non dimostrano che il contenuto del file esista. Confronta l’inventario dello snapshot, le dimensioni, l’hash e il timestamp con il record previsto della sorgente.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

$799.00 - $2,499.00

Buy Now

Controlla i vincoli relativi al nome del file e al percorso di destinazione

Ripristina lo stesso file in un percorso locale breve e vuoto, utilizzando un nome semplice. Confronta caratteri non validi, nomi riservati, conflitti tra maiuscole e minuscole, spazi finali, lunghezza del percorso e normalizzazione Unicode.

Le indicazioni di Microsoft sui nomi dei file documentano le restrizioni sui nomi dei file e sui percorsi di Windows, che possono rifiutare un singolo percorso ripristinato mentre il repository rimane integro.

Se il file viene ripristinato in un percorso temporaneo breve, il contenuto archiviato è disponibile. Correggi la struttura della destinazione o la mappatura dei nomi invece di riparare il repository.

Verifica il ripristino di ACL, attributi estesi e proprietà

Ripeti il ripristino disabilitando la conservazione dei metadati, ma solo in una destinazione usa e getta, quindi confrontalo con il normale ripristino che conserva i metadati. Registra il primo attributo che ha generato l’errore.

GNU tar documenta separatamente il ripristino di ACL e attributi estesi, mostrando perché i dati del file possano essere leggibili mentre l’applicazione dei metadati fallisce.

Non considerare un ripristino senza metadati come soluzione definitiva quando le applicazioni dipendono da ACL, proprietà, intervalli sparsi o xattr. Usalo solo per individuare il livello che genera l’errore.

Controlla le etichette di sicurezza e la policy della destinazione

Controlla le etichette SELinux, l’antivirus o la protezione degli endpoint, i controlli anti-ransomware, i flag immutabili, i permessi della condivisione e i blocchi applicativi sulla destinazione del ripristino.

Red Hat documenta il ripristino dei contesti di sicurezza predefiniti quando i file arrivano con etichette mancanti o inappropriate.

Un file che viene estratto ma non può essere aperto potrebbe indicare un problema della policy di destinazione, non del repository. Esegui il test con lo stesso utente e la stessa applicazione che dovranno utilizzare il file ripristinato.

Esegui un ripristino isolato prima di qualsiasi riparazione

Ripristina il file che ha generato l’errore, i metadati della directory principale e diversi file vicini in un dataset vuoto o in una directory temporanea. Salva hash, log e stato del repository prima di eseguire comandi di riparazione.

La guida di ZimaSpace sulla verifica di checksum e metadati illustra la distinzione tra l’integrità del contenuto archiviato e il recupero utilizzabile da un’applicazione.

Il problema è risolto quando il file selezionato viene ripristinato dallo snapshot previsto, corrisponde al contenuto atteso, riceve i metadati necessari e si apre attraverso il percorso applicativo di produzione.

Domande frequenti

Un controllo del repository riuscito dimostra che ogni file può essere ripristinato?

No. Dipende dal fatto che il controllo abbia letto tutti i dati archiviati e che la destinazione sia in grado di ricreare ogni percorso e i relativi metadati.

Devo eseguire subito una riparazione dopo un singolo errore di ripristino?

No. Prima prova un’altra destinazione, conferma che il file esista nello snapshot ed esegui un controllo dei dati supportato. La riparazione può rimuovere metadati o oggetti danneggiati.

Un ripristino di prova riuscito è più significativo di un rapporto di verifica?

Sì, per il percorso di recupero testato. Dimostra la selezione, la decrittografia, la lettura del contenuto, la creazione nella destinazione e la gestione dei metadati per quello specifico campione.