Maak een snapshot en zet het terug

Wat een snapshot hier is

Een punt-in-tijd-kopie van de instance-schijf, genomen op de storagelaag en weggeschreven naar andere opslag dan waar de instance op draait. Slots worden in pakketten verkocht; één slot bevat één snapshot en wordt hergebruikt wanneer je het overschrijft. Het nemen ervan pauzeert de instance niet, en de copy-on-write-kosten in de minuten erna zijn klein genoeg dat het zelden in een latentiegrafiek verschijnt.

Het is geen backup. Een snapshot leeft op dezelfde locatie als de instance, wat je beschermt tegen je eigen rm en niet tegen de locatie. Off-node backup is een aparte add-on, versleuteld aan jouw kant, weggeschreven naar een andere stad.

Er een nemen

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, en wanneer dat niet genoeg is

Een snapshot van een draaiende instance is precies hoe de schijf eruit zou zien na een stroomstoring. PostgreSQL, MariaDB en elk journaling-bestandssysteem in onze images herstellen vanuit die staat bij het opstarten, omdat herstellen waarvoor ze bedoeld zijn. Het risico zit niet echt in de database. Het zit in je eigen applicatie, halverwege het schrijven van twee bestanden die het met elkaar eens moeten zijn.

Waar je een schone lijn nodig hebt, spoel en bevries je de datavolume voor de seconde die het kost:

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

Bevries de datavolume. Bevries nooit /. Een bevroren root-bestandssysteem stopt het proces dat het moet ontdooien met helemaal niets doen, en de uitweg is een harde reset.

Voor een database is de nettere optie om een snapshot te nemen en de engine te laten herstellen, en dan te controleren dat dat gebeurd is:

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

Herstellen

Een restore stopt de instance, wisselt de schijf voor de snapshot om en start hem weer. Seconden, geen minuten. Adressen veranderen niet, de reverse-DNS die je hebt ingesteld blijft ingesteld, en alles wat sinds de snapshot is geschreven is weg.

Dat omvat wat je ook deed besluiten om te herstellen. Als er enige kans is dat je de logs uit de kapotte staat wilt lezen, neem er dan eerst een snapshot van en herstel er dan overheen.

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

Planning

Per-instance-schema's kwamen met platformrevisie 5.4. Dagelijks op een vast uur met een schuivend venster is de gebruikelijke keuze: de oudste wordt verwijderd zodra de slots vol zijn.

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}'

Kies een uur dat rustig is voor je workload in plaats van rustig voor ons. De opslagkosten van een snapshot zijn evenredig aan wat daarna verandert, dus een schema dat aflaat tijdens je nachtelijke batchjob bevat veel meer data dan een schema dat een uur later aflaat.

Het annuleren van een instance verwijdert diens snapshots

Onmiddellijk, zonder respijtperiode, omdat ze tegen de instance worden opgeslagen. Alles wat je na annulering wilt bewaren hoort in off-node backup of ergens dat helemaal niet bij ons is.