Machen Sie einen Snapshot und setzen Sie ihn zurück

Was ein Snapshot hier ist

Eine Momentaufnahme des Instanz-Datenträgers, die auf der Storage-Ebene erstellt und auf einem anderen Speicher abgelegt wird als dem, auf dem die Instanz läuft. Slots werden in Paketen verkauft; ein Slot fasst einen Snapshot und wird wiederverwendet, wenn Sie ihn überschreiben. Das Erstellen pausiert die Instanz nicht, und die Copy-on-Write-Kosten in den Minuten danach sind so gering, dass sie selten in einem Latenz-Diagramm auftauchen.

Es ist kein Backup. Ein Snapshot liegt am selben Standort wie die Instanz, was Sie vor Ihren eigenen rm schützt, nicht vor dem Standort. Off-Node-Backup ist ein separates Add-on, das auf Ihrer Seite verschlüsselt und in einer anderen Stadt gespeichert wird.

Einen Snapshot erstellen

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-konsistent – und wann das nicht reicht

Ein Snapshot einer laufenden Instanz ist genau das, was der Datenträger nach einem Stromausfall zeigen würde. PostgreSQL, MariaDB und jedes journaling-Dateisystem in unseren Images stellen sich beim Start aus diesem Zustand wieder her, denn genau dafür sind sie da. Das Risiko ist nicht wirklich die Datenbank, sondern Ihre eigene Anwendung, die gerade dabei ist, zwei Dateien zu schreiben, die zusammenpassen müssen.

Wo Sie eine saubere Linie brauchen, leeren und frieren Sie das Datenvolumen für die Sekunde ein, die es dauert:

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

Frieren Sie das Datenvolumen ein. Frieren Sie niemals / ein. Ein eingefrorenes Root-Dateisystem hindert den Prozess, der es wieder auftauen soll, daran, irgendetwas zu tun, und der Ausweg ist ein harter Reset.

Für eine Datenbank ist die sauberere Option, einen Snapshot zu machen und die Engine wiederherstellen zu lassen, und dann zu prüfen, dass das funktioniert hat:

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

Wiederherstellen

Eine Wiederherstellung stoppt die Instanz, tauscht den Datenträger gegen den Snapshot und startet sie wieder. Sekunden, nicht Minuten. Adressen ändern sich nicht, das gesetzte Reverse-DNS bleibt gesetzt, und alles, was seit dem Snapshot geschrieben wurde, ist weg.

Das beinhaltet auch das, was Sie zur Wiederherstellung veranlasst hat. Falls es eine Chance gibt, dass Sie die Logs aus dem kaputten Zustand lesen möchten, machen Sie zuerst einen Snapshot davon und stellen dann darüber wieder her.

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

Zeitplanung

Zeitpläne pro Instanz kamen mit Plattform-Revision 5.4. Täglich zu einer festen Stunde mit rollendem Fenster ist die übliche Wahl: Der älteste wird verworfen, sobald die Slots voll sind.

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

Wählen Sie eine Stunde, die für Ihre Workload ruhig ist, nicht für uns. Die Speicherkosten eines Snapshots sind proportional zu dem, was danach geändert wird, also hält ein Zeitplan, der während Ihres nächtlichen Batch-Jobs feuert, viel mehr Daten als einer, der eine Stunde später feuert.

Die Kündigung einer Instanz löscht ihre Snapshots

Sofort, ohne Gnadenfrist, denn sie sind gegen die Instanz gespeichert. Was Sie über die Kündigung hinweg behalten wollen, gehört in das Off-Node-Backup oder irgendwohin, das gar nicht bei uns ist.