Fai uno snapshot e rimettilo a posto

Cos'è uno snapshot qui

Una copia point-in-time del disco dell'istanza, catturata a livello di storage e scritta su uno storage diverso da quello su cui gira l'istanza. Gli slot sono venduti in pacchetti; uno slot contiene uno snapshot e viene riutilizzato quando lo sovrascrivi. Acquistarne uno non mette in pausa l'istanza, e il costo copy-on-write nei minuti successivi è abbastanza piccolo che raramente compare in un grafico di latenza.

Non è un backup. Uno snapshot vive nello stesso sito dell'istanza, il che ti protegge dai tuoi stessi rm e non dal sito. Il backup off-node è un componente aggiuntivo separato, crittografato lato tuo, scritto in una città diversa.

Acquisirne uno

curl -s -X POST https://paragonvps.com/api/v1/instances/<instance-id>/snapshots -H "Authorization: Bearer $Paragon_TOKEN" -H "Content-Type: application/json" -d '{"label":"pre-upgrade"}'

curl -s https://paragonvps.com/api/v1/instances/<instance-id>/snapshots -H "Authorization: Bearer $Paragon_TOKEN" | jq -r '.[] | .id + " " + .label + " " + .created'

Crash-consistent, e quando non basta

Uno snapshot di un'istanza in esecuzione è esattamente ciò che il disco sembrerebbe dopo un'interruzione di corrente. PostgreSQL, MariaDB e ogni filesystem con journaling nelle nostre immagini si riprendono da quello stato all'avvio, perché riprendersi è ciò per cui sono fatti. Il rischio non è davvero il database. È la tua stessa applicazione, a metà della scrittura di due file che devono essere coerenti tra loro.

Dove serve una linea pulita, flush e freeze del volume dati per il secondo che ci vuole:

sync
fsfreeze -f /srv/data
# take the snapshot here
fsfreeze -u /srv/data

Congela il volume dati. Non congelare mai /. Un filesystem root congelato impedisce al processo che dovrebbe scongelarlo di fare qualsiasi cosa, e l'unica via d'uscita è un reset forzato.

Per un database, l'opzione più pulita è fare lo snapshot e lasciare che il motore si riprenda, poi verificare che lo abbia fatto:

sudo -u postgres pg_isready
journalctl -u postgresql -n 50

Ripristino

Un ripristino ferma l'istanza, sostituisce il disco con lo snapshot e la riavvia. Secondi, non minuti. Gli indirizzi non cambiano, il reverse DNS che hai impostato resta impostato, e tutto ciò che è stato scritto dopo lo snapshot è perso.

Questo include qualunque cosa ti abbia spinto a ripristinare. Se c'è anche solo la possibilità che tu voglia leggere i log dallo stato rotto, fai uno snapshot di quello stato prima e poi ripristina sopra.

curl -s -X POST https://paragonvps.com/api/v1/snapshots/<snapshot-id>/restore -H "Authorization: Bearer $Paragon_TOKEN"

Pianificazione

Le pianificazioni per istanza sono arrivate con la revisione 5.4 della piattaforma. La scelta comune è giornaliera a un'ora fissa con una finestra mobile: il più vecchio viene eliminato una volta che gli slot sono pieni.

curl -s -X PUT https://paragonvps.com/api/v1/instances/<instance-id>/snapshot-schedule -H "Authorization: Bearer $Paragon_TOKEN" -H "Content-Type: application/json" -d '{"cron":"20 3 * * *","keep":7}'

Scegli un'ora tranquilla per il tuo carico di lavoro, non per noi. Il costo di storage di uno snapshot è proporzionale a ciò che cambia dopo, quindi una pianificazione che scatta durante il tuo batch notturno contiene molti più dati di una che scatta un'ora dopo.

L'annullamento di un'istanza elimina i suoi snapshot

Immediatamente, senza periodo di grazia, perché sono memorizzati sull'istanza. Qualunque cosa tu voglia conservare oltre l'annullamento appartiene al backup off-node o a qualcosa che non siamo noi.