Il backup è finito. Nessun errore, tutti i file copiati, la spunta verde. Poi aprite il documento che vi serviva e ci trovate la versione sbagliata, perché quella buona era di ieri. Il backup era fatto bene: siamo noi che lo abbiamo usato male.

In questo articolo prendiamo Restic, un programma di backup libero, e rispondiamo a tre domande concrete: come si sceglie la versione giusta da recuperare, come sapete che quello che avete salvato si legge ancora, e quando potete dire di essere davvero tornati al lavoro. Alla fine trovate la prova da fare con un documento qualsiasi.

Se preferite, vi racconto tutto anche nel video qui sopra.

Indice

La domanda giusta

Di solito ci chiediamo: ho un backup? Ma la domanda giusta, secondo me, è un'altra: da quale momento ripartirei, e ho mai provato a farlo?

Sembrano due domande simili, e invece misurano due cose completamente diverse. La prima vi dice che una copia esiste, la seconda vi dice se quella copia vi rimette in piedi.

Il backup protegge anche l'errore

Restic conserva tutto in un repository, cioè l'archivio da cui recuperate quello che vi serve. E ogni volta che fate un backup crea uno snapshot, cioè una fotografia di tutti i file inclusi, scattata in un momento preciso.

Ricordatevi questa parola, perché è la chiave di tutto: il documento di ieri e quello di oggi possono avere lo stesso identico nome ed essere due versioni diverse, in due snapshot diversi.

Prendiamo il programma di un corso, dove c'è scritto che la lezione comincia alle 18:00, e facciamo un primo backup. Poi qualcuno modifica il documento e scrive 08:00, e un secondo backup salva anche quella modifica. Restic non ha modo di sapere che l'orario è sbagliato: dal suo punto di vista sta proteggendo l'ultima versione del documento, e lo fa benissimo.

Se adesso chiediamo la versione più recente, ci ritroviamo le 08:00. Restic ci ha dato esattamente quello che gli abbiamo chiesto: il momento sbagliato, di fatto, l'abbiamo scelto noi.

Primo controllo: la versione, in una cartella nuova

Prima di recuperare guardate l'elenco degli snapshot e cercate quello precedente alla modifica, aiutandovi con la data, con le cartelle incluse e con quello che vi aspettate di trovarci dentro. Dire «il backup di ieri» non basta: se ieri avete salvato due volte, una prima e una dopo l'errore, quella frase può voler dire due cose diverse.

Poi c'è un dettaglio che vale oro: dove recuperate. La documentazione sul ripristino avverte che il ripristino può sovrascrivere i file che ci sono già. Per questo io recupererei sempre in una cartella nuova: così confrontate le due versioni senza perdere quella su cui state lavorando.

Da terminale, i passaggi sono questi (al posto di ID_SNAPSHOT va il codice che leggete nell'elenco):

restic -r /percorso/del/repository snapshots
restic -r /percorso/del/repository restore ID_SNAPSHOT --target /percorso/cartella-nuova

Nella prova del video, nella cartella nuova il corso comincia alle 18:00, mentre il documento di partenza dice ancora le 08:00. Avete ritrovato la versione che cercavate, e quella attuale è rimasta intatta. Lo snapshot più recente, recuperato in un'altra cartella con latest al posto del codice, restituisce invece le 08:00.

Poi c'è un controllo in più, da veri smanettoni: l'hash, cioè l'impronta che si ricava dai byte del file e che permette di confrontare il contenuto senza fidarsi del nome. Su Linux la calcolate con sha256sum seguito dal nome del file. Nella prova l'impronta SHA-256 del file recuperato coincide con quella dell'originale di quel momento, e coincidono anche i byte.

Attenzione, però: la verifica tecnica da sola non basta. Lì dentro c'è davvero l'orario che vi serviva? Questo lo sa solo chi conosce il proprio lavoro.

Secondo controllo: l'archivio si legge ancora?

Restic offre due controlli, e vi chiedo di non confonderli. Li descrive la pagina sul lavoro con i repository:

restic -r /percorso/del/repository check
restic -r /percorso/del/repository check --read-data

Il primo controlla la struttura dell'archivio, cioè come sono collegati tra loro i pezzi, ma da solo non rilegge il contenuto dei backup. Il secondo, con l'opzione --read-data, rilegge e verifica tutti i dati conservati. Per questo nella prova li usiamo entrambi.

C'è un prezzo, ed è giusto dirlo. Con un archivio grande, rileggere tutto richiede tempo e genera traffico verso il servizio che lo conserva, quindi va messo in conto quando organizzate le verifiche. Però una copia che non avete mai provato a leggere, secondo me, è un enorme punto interrogativo proprio su ciò che dovrebbe salvarvi il giorno del guasto.

Terzo controllo: il lavoro riparte?

Un file integro non è per forza quello che vi serve. Immaginiamo un progetto con tutti i documenti perfettamente leggibili, che però ha perso un'immagine collegata. Oppure un'applicazione che ritrova tutte le fotografie, ma non il database che le tiene in ordine.

Controllare l'archivio e far ripartire il lavoro sono due cose diverse, e per tornare operativi servono entrambe. Quindi partite da un'attività concreta: recuperate il documento, apritelo con il programma che usate tutti i giorni e cercate la frase, il numero o l'immagine che vi aspettate di trovare.

Se state proteggendo un progetto, provate a riaprirlo con tutto quello che gli serve. Una cartella piena, da sola, non vi dice che quel lavoro riparte.

La password del backup

Restic cifra i backup, cioè li rende illeggibili a chi non ha la chiave, e la password protegge proprio l'accesso alle chiavi che servono per leggerli. Lo spiega la pagina sulla preparazione del repository. Nella prova, con una password sbagliata, l'accesso viene negato, come ci aspettavamo.

Per la riservatezza è un'ottima notizia. Per il recupero, invece, significa una cosa precisa: insieme ai dati dovete custodire anche il modo per aprirli.

Ve lo dico da persona che ha studiato cybersecurity: questo è un disastro che non ha nemmeno bisogno di un attaccante. Se l'unica copia della password stava nel computer che avete perso, il repository conservato altrove resta lì, perfetto e illeggibile. E lo stesso vale per l'accesso al servizio che lo ospita.

Il recupero, quindi, va pensato prima: dove tenete le credenziali, chi le può usare, e se il piano funziona anche quando il vostro computer di sempre non c'è più.

Sincronizzazione e posizione dell'archivio

Qualcuno di voi mi dirà: ma io ho una cartella sincronizzata nel cloud, non basta? La sincronizzazione fa un altro mestiere. Il suo compito è tenere uguali le copie, e quindi copia con la stessa diligenza anche la modifica sbagliata. Il backup a versioni, invece, conserva i momenti precedenti, ed è proprio quello che ci ha restituito l'orario delle 18:00.

Conta anche dove tenete il repository. Nella prova usiamo un archivio locale temporaneo, perché così il meccanismo si vede bene. Ma una copia che sta sullo stesso disco dei dati originali ne condivide il destino: se quel disco si rompe, spariscono tutti e due.

Un errore in un documento, la perdita del computer e un account violato sono tre incidenti diversi, e copie, accessi e versioni devono tenerne conto. La domanda giusta, quindi, non è quante copie avete, ma da quale incidente volete potervi rialzare.

La prova da fare

La prossima volta che leggete «backup completato», fate così:

  1. prendete un documento di prova;
  2. recuperatene una versione precisa in una cartella nuova, scegliendo lo snapshot con la data e il contenuto che vi aspettate;
  3. apritelo con il programma di tutti i giorni e controllate che sia la versione giusta.

Avrete risposto a una domanda molto più utile di «ha finito?».

La prova del video usa Restic 0.19.1 su Linux, presa dalla pagina ufficiale della versione, con un archivio locale temporaneo e un file di prova: non simula guasti del disco né archivi su servizi remoti.

La regola da portarvi via

Insomma, la regola è questa: un backup vale quanto il ripristino che avete provato. Un backup è una promessa, e il ripristino è il momento in cui la verificate.

È per questo che il tema mi sta così a cuore: avere i file è solo l'inizio, mentre sapere come recuperarli vi rende molto meno dipendenti dal singolo computer o dal singolo servizio. Gli strumenti open source ci danno possibilità concrete, ma diventano davvero nostri quando capiamo come funzionano.

E vi lascio con una curiosità che mi intriga tantissimo: se doveste ricostruire un intero archivio fotografico, cosa vi servirebbe oltre alle immagini? Pensate a come è organizzata la libreria, a cosa conserva l'applicazione e a dove lo conserva.

Per approfondire

Se volete ripartire dalle basi, cioè che cos'è una copia di sicurezza e perché spostare i file su un altro disco non basta, leggete «Hai fatto un backup?».

E se la password del backup la tenete in un password manager, controllate anche dove vive quell'archivio: ne parlo in «Password manager: dove vive il vostro archivio e come ne uscite».

E voi, quale lavoro vorreste poter recuperare per primo: un documento, un progetto, le fotografie? Scrivetelo nei commenti del video.

Fonti

Comandi e opzioni cambiano tra una versione e l'altra: ricontrollateli sulla documentazione della versione che usate.