Cosa garantiscono davvero le modalità vzdump di Proxmox

Proxmox offre tre modalità di backup in un unico menu a tendina, il che le fa sembrare tre velocità della stessa cosa. Non lo sono. Differiscono in ciò che accade al guest in esecuzione e, di conseguenza, in ciò di cui l’archivio è realmente una copia.

La versione breve, e poi quella lunga:

La parola che fa tutto il lavoro in quella tabella è crash-consistent. Significa che l’archivio è ciò che il disco sarebbe stato se qualcuno avesse staccato il cavo di alimentazione in quell’istante. Un filesystem journaled se ne riprende. Un database con una transazione in corso può non farcela, e un’applicazione che mantiene il proprio stato su due file non saprà che uno dei due è più vecchio dell’altro.

snapshot non significa quiescenza

snapshot è l’impostazione predefinita ed è l’unica modalità che non interrompe nulla. Proxmox esegue uno snapshot a livello di storage e legge il backup da lì, quindi il guest continua a scrivere sul volume attivo per tutto il tempo.

C’è un modo per rendere migliore quell’archivio: il QEMU guest agent può congelare il filesystem all’interno del guest nel momento in cui lo snapshot viene preso, il che svuota le scritture in sospeso e restituisce un archivio che il guest stesso considera pulito. Se l’agente guest è installato, in esecuzione e risponde, è quello che accade.

La trappola sta in quel «se». Nulla nel risultato dell’API dice se il congelamento sia avvenuto. Il task vzdump restituisce un ID di task e, al termine, uno stato. Se qemu-guest-agent abbia risposto alla richiesta di congelamento è una riga nel log del task, non un campo che si possa rileggere.

Questo è un punto di decisione per chiunque costruisca automazione al di sopra di Proxmox, e vale la pena affrontarlo con intenzione. Quando abbiamo costruito il percorso di backup per la nostra integrazione Proxmox, abbiamo finito per registrare la coerenza come ciò che è accaduto, mai come ciò che è stato richiesto: un backup stop viene registrato come coerente, mentre snapshot e suspend vengono registrati come crash-consistent, punto. Nel nostro schema esiste un valore per «il guest è stato quiescito» e l’agente non lo emette mai, perché emetterlo significherebbe affermare di conoscere un congelamento che dall’API non possiamo verificare.

Un archivio descritto come leggermente peggiore di quello che è non costa nulla. Un archivio descritto come migliore di quello che è costa l’unico ripristino che conta.

suspend mette in pausa, non è una via di mezzo

suspend si legge meglio di come si comporta. Si dà per scontato che sia «snapshot, ma più sicuro», un compromesso tra nessun fermo e fermo completo. Quello che fa in realtà è mettere in pausa il guest mentre i dati vengono letti.

Offre la stessa garanzia di crash-consistency di snapshot, perché mettere in pausa una macchina non equivale a lasciarle svuotare i buffer e assestarsi. Si ottiene un’interruzione e nessuna promessa più forte. Il caso d’uso è ristretto: uno storage backend che non sa fare snapshot, dove la modalità snapshot non ha nulla da cui partire.

stop è l’unica garanzia onesta

stop spegne il guest, ne esegue il backup e lo riavvia. È l’interruzione più lunga e l’unica modalità in cui l’archivio è senza ambiguità la copia di un filesystem su cui nessuno stava scrivendo.

Per un server di database che qualcuno ripristinerà sotto pressione alle tre del mattino, non è un prezzo alto. Per una flotta di web server è un prezzo che nessuno pagherà ogni notte. Sono entrambe risposte corrette a domande diverse, ed è per questo che la modalità appartiene alla politica di backup e non a un’unica impostazione globale.

Qui conta un dettaglio di implementazione. Poiché sia stop sia suspend interrompono una macchina in esecuzione, un valore di modalità mancante o non riconosciuto non deve mai ricadere su una delle due. Nel nostro schema dei comandi la modalità viaggia come la parola letterale di Proxmox (snapshot, suspend, stop) anziché come un vocabolario nostro, e un valore non impostato si risolve in snapshot. Una tabella di traduzione tra le nostre parole e le loro metterebbe una traduzione sbagliata esattamente dove una traduzione sbagliata spegne la macchina di un cliente.

I parametri che decidono se il job parte

Prima della coerenza c’è una domanda più noiosa: vzdump partirà davvero? Quattro elementi della richiesta lo decidono, e tre di essi falliscono in modi difficili da leggere.

Lo storage di destinazione deve accettare i backup. Uno storage Proxmox ha un elenco content, e solo uno storage il cui elenco include backup può accogliere un vzdump. Non è un consiglio. Mandi il job a uno storage che contiene solo immagini disco e Proxmox lo rifiuta con un messaggio come storage 'x' does not support vzdump backups. Accurato, e privo di significato per il cliente che ha premuto il pulsante. Vale la pena controllare prima di inviare, così il rifiuto può dire «questo storage non accetta backup».

Un caso affine: uno storage che compare nell’elenco delle risorse del cluster con stato unknown è configurato ma non risponde. Una condivisione NFS spenta ha esattamente l’aspetto di una destinazione valida, fino al momento in cui il job fallisce.

La compressione ha un valore che non è la parola che ci si aspetta.

Proxmox scrive «nessuna compressione» come 0, non come none. Inviare none è il tipo di errore che produce un rifiuto silenzioso anziché uno chiaro, ed è il motivo per cui la nostra suite di test verifica la stringa esatta che lascia l’agente, invece di verificare soltanto che la chiamata sia riuscita.

La notifica per e-mail è rumorosa per impostazione predefinita, e va alla persona sbagliata. Senza un mailnotification=failure esplicito, Proxmox scrive a root@pam dopo ogni backup. Su una macchina gestita da una piattaforma, quella è posta al provider a proposito di qualcosa che ha fatto il cliente.

Due campi opzionali meritano di essere conosciuti. notes-template allega una nota all’archivio, e Proxmox vi espande i propri segnaposto, come {{guestname}}. protected=1 marca un archivio come protetto, e Proxmox si rifiuterà poi di rimuoverlo con il prune. È il meccanismo che serve per la copia che qualcuno prende prima di una modifica rischiosa, ed esattamente l’impostazione predefinita sbagliata per un job notturno.

La retention non è un parametro di vzdump

Sulla richiesta di backup non esiste alcuna impostazione di retention. Il prune si configura sullo storage, in Proxmox, ed è il proprietario dello storage a decidere quanto a lungo vivono le copie.

Questo ha una conseguenza progettuale per chi ci costruisce sopra: un pannello che offre un campo «conserva 7 copie» o mette mano alla configurazione dello storage, oppure cancella gli archivi da sé. Non abbiamo scelto né l’una né l’altra strada, e lo diciamo, invece di lasciar intendere il contrario con un campo che non fa nulla.

Andare in timeout non è la stessa cosa che fallire

Un vzdump di una macchina grande può sopravvivere a qualunque timeout di richiesta ragionevole. Quando accade, la cosa importante da capire è che nulla è stato annullato: il job continua a girare sull’hypervisor e finirà, o fallirà, secondo i propri tempi.

Un timeout è quindi un’affermazione sulla sua connessione, non sul backup. L’esecuzione resta aperta, l’ID del task è ancora valido, e la cosa onesta che una UI può fare è dire «ancora in corso» e riconciliare più tardi. L’alternativa, contrassegnarlo come fallito e lasciare che qualcuno ne avvii un secondo, mette due job vzdump sullo stesso storage per la stessa macchina.

Mentre gira, l’avanzamento reale è disponibile: vzdump scrive nel proprio log del task righe come 12% (1.2 GiB of 10.0 GiB). Una barra di avanzamento alimentata da quelle è onesta. Una barra alimentata da una stima è un’ipotesi con un segno di percentuale sopra.

Il ripristino è un’altra domanda, e conta unique

La questione della modalità finisce quando l’archivio esiste. Il ripristino ha una trappola tutta sua, ed è di rete.

Ripristini un archivio in una nuova VM senza chiedere nuovi identificatori e la nuova macchina eredita gli indirizzi MAC dell’originale. Se l’originale è ancora in esecuzione, ora ha due macchine con lo stesso MAC sullo stesso bridge, e il sintomo non è «il ripristino è fallito» ma «la rete della macchina di produzione fa cose strane». Il flag unique nella chiamata di ripristino è ciò che lo impedisce, e su una piattaforma che ripristina accanto a un originale in esecuzione non è un’opzione ma un prerequisito.

Altre due cose vale la pena saperle prima del primo ripristino:

• storage qui significa un’altra cosa. Nel backup è dove va l’archivio, e ha bisogno di backup nel proprio elenco dei contenuti. Nel ripristino è dove atterrano i dischi ripristinati, e ha bisogno di images. Stesso nome di campo, requisito diverso.
• Tornano solo i dischi. Una macchina ripristinata è una macchina con i dischi e l’hardware dell’archivio. Le assegnazioni di indirizzi, le regole del firewall e qualunque automazione fosse legata all’originale vivono nei suoi sistemi, non nel file vzdump, e con esso non viaggiano.

Che cosa non è misurato qui

Tutto quanto sopra sulla forma delle chiamate viene dallo schema dell’API di Proxmox e dal costruirci sopra; la semantica delle modalità è di Proxmox, descritta nella sua documentazione.

Ciò che deliberatamente non affermiamo è quanto costa ciascuna modalità in termini di tempo. Non abbiamo una durata di pausa misurata per suspend né un fermo misurato per stop: dipende dal guest, dallo storage e dalla quantità di memoria sporca, e un numero misurato su una macchina verrebbe poi citato come se fosse generale. Quei numeri devono venire dal suo hardware.

Altre due lacune meritano di essere nominate. Tutto ciò che c’è qui riguarda i guest QEMU; i backup dei container hanno regole proprie su mount point e bind mount, e non li abbiamo misurati. E in tutto questo non c’è alcun percorso incrementale: vzdump verso uno storage semplice scrive ogni volta un archivio completo. Il backup incrementale è ciò per cui esiste Proxmox Backup Server, ed è un software diverso con un diverso insieme di promesse.

Questo testo nasce dalla costruzione del percorso di backup Proxmox per Provibr, un pannello di gestione server per hosting provider, dove un backup descritto come migliore di quello che è sarebbe il peggior bug possibile. Le note di configurazione del lato hypervisor sono nella documentazione Proxmox, e la pagina integrazione Proxmox copre ciò che l’agente sa fare.