restic check verifica la consistenza del repository, ma nella modalità ordinaria non legge tutti i dati salvati. Un controllo riuscito non dimostra neppure che il backup contenga il database aggiornato o che l’applicazione possa ripartire. Sono verifiche diverse, da organizzare esplicitamente.
È una distinzione che conta quando un report mostra tutto verde. La domanda successiva è: quale comando è terminato correttamente, su quale repository e con quali opzioni? Senza queste informazioni, “backup verificato” descrive troppo poco.
Struttura del repository e contenuto dei file
La documentazione restic sui controlli di integrità distingue il controllo ordinario dalla lettura dei dati. Per leggere e verificare tutti i pack si usa --read-data; per limitare la lettura esiste --read-data-subset.
# Repository e credenziali già configurati nell'ambiente
restic check
restic check --read-data
restic check --read-data-subset=5%Le tre righe sono alternative con copertura e costo diversi. Il controllo completo può richiedere tempo, letture remote e trasferimento di dati. La pianificazione deve tenere conto di questi costi e della capacità del sistema durante l’esecuzione.
Il campione percentuale è casuale: ripetere il 5% ogni giorno non dimostra che dopo venti giorni sia stato controllato il 100%. Per attribuire una copertura al controllo servono una strategia esplicita e risultati conservati, considerando anche che il repository cambia nel tempo.
Un file integro può essere il file sbagliato
Nei controlli interni sui backup ho incontrato una situazione diversa dalla corruzione: copie recenti dei file del sito, ma dump del database non aggiornati. Il repository poteva conservare correttamente un contenuto che non rappresentava più lo stato atteso dell’applicazione.
Per evitare questo equivoco controllo la produzione dei dati prima del loro invio. Il job che genera il dump deve avere un esito osservabile; il backup successivo deve acquisire il risultato corretto. La data dello snapshot non sostituisce la data e la validità del dump.
Anche i percorsi meritano una verifica. Un collegamento simbolico salvato come collegamento non dimostra che siano stati inclusi i file della destinazione. L’inventario del recupero deve indicare ciò che serve: database, allegati, configurazione e dipendenze esterne.
Provare il recupero a livello applicativo
Sceglierei uno snapshot preciso e lo ripristinerei in una destinazione isolata. Per un sito, proverei importazione del database, caricamento di pagine e media e un accesso di test. Prima dell’avvio disabiliterei email, webhook e processi con effetti esterni.
Annoterei quali credenziali o configurazioni sono state necessarie oltre ai file. Se il recupero dipende da un’informazione presente soltanto sul server perduto, il test ha individuato una lacuna concreta.
La prova dovrebbe includere anche uno snapshot storico rappresentativo. Recuperare soltanto l’ultimo non verifica che la retention conservi davvero le versioni richieste. Nei report terrei distinti esito del backup, esito del controllo e riuscita della rimozione delle copie scadute.
Se il controllo segnala un errore
Conserverei log, versione del client, comando e messaggio completo prima di tentare una riparazione. La guida di troubleshooting di restic invita a preservare il repository e sospendere le operazioni ordinarie, in particolare forget e prune, durante l’analisi.
Non attribuirei automaticamente il problema al provider: servono prove per distinguere dati mancanti, guasti locali e problemi del backend. Se occorre continuare a proteggere i dati di produzione, predisporrei una destinazione sana separata mentre indago sulla copia problematica.
Una riparazione può rendere nuovamente coerenti strutture e riferimenti; non ricrea per magia byte perduti. Per questo non inserirei un comando repair generico in un job automatico che reagisce a qualsiasi errore.
Nella migrazione di repository restic tra regioni B2 la stessa distinzione serve a decidere quando dismettere la sorgente: trasferimento terminato, integrità verificata e recupero provato sono tre risultati da registrare separatamente.