Un backup mai ripristinato non è un backup

Sul titolo sono tutti d’accordo. Quasi nessun cruscotto lo rispecchia.

Il motivo non è la pigrizia. È che tre elementi di prova sinceramente diversi arrivano dallo stesso tubo, finiscono in colonne adiacenti e vengono resi come un unico segno di spunta verde. Una volta che sono un solo segno di spunta, l’affermazione più forte del gruppo prende in prestito in silenzio la credibilità di quella più economica, e un cliente legge «protetto» dove ciò che è successo davvero è che un lavoro è terminato con esito zero.

Abbiamo passato una tornata a separare quelle tre cose nel nostro schema, e una seconda tornata a misurare un vero Proxmox Backup Server per scoprire quali di esse ci possa davvero dare. Ecco a che cosa siamo arrivati.

Tre prove, e non sono intercambiabili

La prima è la più economica ed è quella che ogni prodotto mostra. Vale esattamente ciò che dice: un processo è terminato. Le garanzie dietro a ciascuna modalità di vzdump riguardano ciò che quel processo poteva e non poteva promettere sullo stato del guest, e nessuna di quelle garanzie sopravvive al contatto successivo con un archivio di chunk corrotto.

La seconda è una prova reale ed è facile leggerci dentro troppo. Su questo torniamo più sotto.

La terza è l’unica che risponde alla domanda che un cliente sta davvero ponendo, ed è l’unica che le richiede di costruire qualcosa anziché di leggere qualcosa. Quell’asimmetria è il motivo per cui di solito manca.

Che cosa afferma davvero una verifica verde

Proxmox Backup Server può verificare uno snapshot: rilegge i chunk e li controlla rispetto al manifesto. Quando questo è avvenuto, l’elenco degli snapshot porta un oggetto verification con dentro uno stato.

È una cosa sinceramente utile da sapere, ed è più stretta di quanto sembri. Dice che i byte su quel datastore sono i byte che erano stati scritti. Non dice che la macchina si avvierà. Non dice che l’applicazione al suo interno partirà. Non dice che il database fosse in uno stato coerente nel momento dello snapshot. E se il backup è cifrato lato client, non dice che qualcuno abbia ancora la chiave: un controllo di integrità sul testo cifrato passa benissimo anche quando la chiave è sparita.

Quindi lo stato vive in una colonna propria nel nostro schema, ed è documentato nel codice come appartenente alla prova due, da non mescolare mai con «ripristino dimostrato». La prova tre avrà una tabella propria il giorno in cui qualcuno la realizzerà. Aggiungere un quarto valore a un enum esistente sarebbe stato mezza giornata di lavoro e una fonte permanente di confusione.

Un campo assente non è un fallimento

La nostra colonna ha tre valori: ok, fallito e sconosciuto. Quello di mezzo non è quello interessante.

Misurato contro un Proxmox Backup Server 4.2 dal vivo con snapshot reali sopra: uno snapshot che non è mai passato attraverso un’attività di verifica semplicemente non ha alcuna chiave verification. Il campo è assente. È una cosa diversa da una verifica che è girata ed è fallita, e farle collassare insieme le costa in entrambe le direzioni. Lo imposti su ok per impostazione predefinita e ogni snapshot mai controllato diventa controllato. Lo imposti su fallito e ogni snapshot storico nel suo database va improvvisamente a fuoco. Il terzo valore esiste per dire l’unica cosa vera: non si sa nulla.

Uno storage Proxmox semplice non riempie affatto quella colonna, perché il suo elenco dei contenuti non porta alcun concetto di verifica. Non è una lacuna della nostra integrazione. È la risposta.

Un altro dettaglio onesto, perché è del tipo che si tende ad arrotondare. L’oggetto verification che abbiamo misurato porta uno stato e un identificatore di attività, e nessuna marca temporale. Perciò il momento di «verificato il» che registriamo è il momento in cui noi abbiamo visto per la prima volta quello stato, che è una domanda diversa da «quando lo storage ha verificato questo». Risponde a «da quando lo sappiamo». Se una versione futura esporrà il tempo reale, la colonna dovrà cominciare a portarlo e il commento che spiega tutto questo va cancellato.

Vuoto deve significare vuoto

Ecco la regola più affilata di tutta la materia, e non ha nulla a che fare con la verifica.

Qualunque sistema che elenchi periodicamente i punti di ripristino finisce per dedurre qualcosa dall’assenza di uno snapshot: la settimana scorsa era qui, adesso non c’è, quindi è stato eliminato o sottoposto a prune. Quell’inferenza è portante, ed è valida soltanto se un elenco riuscito e vuoto è davvero vuoto.

Perciò abbiamo misurato che cosa risponde davvero un server di backup quando un elenco va storto, perché «un array vuoto» e «un errore che sembra un array vuoto» devono essere distinguibili. Quattro casi, tutti misurati contro la stessa istanza 4.2 dal vivo:

• un namespace vuoto risponde 200 con un array vuoto;
• un namespace che non esiste risponde 400 con un errore di non trovato, non con un elenco vuoto;
• un datastore che il token non può controllare risponde 403;
• un token errato risponde 401.

Tre di quei quattro devono diventare errori specifici anziché risultati. Se a uno qualsiasi di essi è permesso di raggiungere la sua logica di riconciliazione come «l’elenco è riuscito e lì non c’è niente», allora un solo errore di battitura nel nome di un namespace segna come sparita l’intera storia di backup di un cliente. La modalità di guasto non è un’interruzione del servizio. È una schermata che smette in silenzio di menzionare che esistono dei backup.

È la stessa classe di trappola di un hypervisor che risponde 200 prima che il lavoro sia cominciato: il codice di risposta va benissimo, e non è la risposta alla sua domanda.

La credenziale non deve poter rompere nulla

La decisione di sicurezza più utile in questa materia è anche la più noiosa.

Il token che un cliente crea per una destinazione di backup deve leggere gli snapshot e lo stato del datastore. Non deve eliminare, dimenticare, eseguire il prune né verificare. Sono operazioni separate che appartengono a chi possiede lo storage, secondo la propria pianificazione, con la propria identità.

Abbiamo costruito l’integrazione senza alcun comando di scrittura, il che rende l’affermazione strutturale anziché aspirazionale, e poi l’abbiamo controllata dall’altro lato: con un token che detiene i soli diritti di controllo, un’eliminazione su uno snapshot risponde 403. È quella la forma a cui puntare. Un’integrazione di sola lettura la cui credenziale è in grado di eseguire il prune è un’integrazione di sola lettura esattamente finché qualcuno non scrive un ciclo con dentro un errore di off-by-one.

C’è un corollario che i fornitori di hosting sbagliano nella direzione opposta. Se la sua piattaforma elimina un server, la questione della conservazione è una decisione che deve prendere il cliente, non un valore predefinito scelto dal suo codice. Rimuovere l’unica copia rimasta dei dati di qualcuno come effetto collaterale del riordino di una riga è una cosa che è successa ad aziende vere.

Che cosa deve essere un test di ripristino, se ne realizza uno

La prova tre è dove sta il lavoro, e vale la pena mettere per iscritto i vincoli prima di scrivere il codice, perché quasi tutti riguardano il non provocare un incidente con il proprio test.

Un test di ripristino ha bisogno di un posto isolato in cui ripristinare: una rete senza alcuna rotta verso la produzione, identificatori temporanei, indirizzi temporanei, indirizzi hardware temporanei. Mai l’indirizzo di produzione, e mai l’indirizzo hardware di produzione, perché un duplicato su una rete viva è un’interruzione del servizio che ha causato lei mentre controllava di potersi riprendere da un’interruzione del servizio. Ha bisogno di quote rigorose, perché il ripristino della macchina più grande di una flotta dentro un pool di prova è un evento di capacità. Ha bisogno di una scadenza e di una pulizia garantita, dato che a volte la macchina non riuscirà a salire e qualcosa deve comunque rimuoverla. E ha bisogno di non inviare notifiche, perché un allarme di monitoraggio da una copia di prova che finge di essere il sistema vero sveglierà qualcuno.

Ha bisogno anche di una politica esplicita di completamento, ed è qui che tutta la faccenda si guadagna il nome. Avviata è un livello. Raggiungibile è un altro. Guest agent che risponde è un altro. Filesystem montati è un altro. Un’applicazione che risponde a un controllo di salute definito dal cliente è il livello che corrisponde a ciò che un cliente intende con «ripristinabile». Ne scelga uno, registri quale ha scelto accanto al risultato, e non lasci mai che un livello più basso venga mostrato con l’etichetta di uno più alto.

Solo allora un server può mostrare «ripristino dimostrato», e deve portare con sé la data, il punto di ripristino esatto, l’ambiente in cui è girato, i controlli superati e per quanto tempo viene conservata la prova. Qualcosa di meno e la frase è decorazione.

Che cosa metteremmo per iscritto

1. 01Nomini le tre prove separatamente nel suo schema, prima di averle tutte e tre. Le nostre sono colonne separate e una tabella che non esiste ancora, il che si legge meglio di una colonna sola con un commento di scuse.
2. 02Conservi «sconosciuto» come valore vero. Qualunque valore predefinito che non sia «sconosciuto» è una menzogna su almeno una delle sue righe.
3. 03Faccia in modo che un elenco vuoto dimostri di essere vuoto, e trasformi ogni altra risposta in un errore distinto prima che raggiunga qualsiasi cosa faccia riconciliazione.
4. 04Dia all’integrazione una credenziale che non possa eliminare, e poi verifichi dall’esterno che non possa.
5. 05Metta per iscritto che cosa dovrebbe voler dire «ripristino» per lei, a quale livello di completamento, prima che qualcuno ci metta accanto un segno di spunta verde.

Il nostro stato, detto chiaramente: le prime due prove sono costruite e misurate, e non abbiamo alcun test di ripristino. La funzione di backup sta dietro a un interruttore e non è in vendita. È questa la differenza tra un piano e un’affermazione, ed è la stessa differenza di cui parla tutto questo articolo.

L’integrazione dietro a queste misurazioni è stata costruita per Provibr. La questione correlata dei tempi, che cosa succede quando un backup dura più della scadenza che gli ha dato, è in un timeout non è un pulsante di arresto; il lato container dei backup Proxmox è in VM o container su Proxmox.