Zrób snapshot i przywróć go

Czym jest snapshot w tym miejscu

Kopia stanu dysku instancji w danym momencie, wykonana na poziomie warstwy pamięci masowej i zapisana na innym nośniku niż ten, na którym działa instancja. Miejsca są sprzedawane w pakietach; jedno miejsce mieści jeden snapshot i jest ponownie wykorzystywane, gdy go nadpiszesz. Wykonanie snapshotu nie wstrzymuje instancji, a koszt kopiowania przy zapisie w ciągu następnych minut jest na tyle mały, że rzadko pojawia się na wykresie opóźnień.

To nie jest kopia zapasowa. Snapshot znajduje się w tym samym miejscu co instancja, co chroni Cię przed Twoimi własnymi rm, a nie przed awarią miejsca. Kopia zapasowa poza węzłem to osobny dodatek, szyfrowany po Twojej stronie, zapisywany w innym mieście.

Wykonywanie snapshotu

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'

Spójny po awarii i kiedy to nie wystarcza

Snapshot działającej instancji jest dokładnie tym, jak wyglądałby dysk po odcięciu zasilania. PostgreSQL, MariaDB i każdy system plików z journalingiem w naszych obrazach odzyskują stan po takim zdarzeniu przy starcie, ponieważ to właśnie do tego służą. Ryzyko nie leży tak naprawdę w bazie danych. Chodzi o Twoją własną aplikację, która w połowie zapisuje dwa pliki, które muszą być ze sobą spójne.

Tam, gdzie potrzebna jest wyraźna granica, opróżnij i zatrzymaj wolumin danych na tę jedną sekundę, ile to trwa:

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

Zatrzymaj wolumin danych. Nigdy nie zamrażaj /. Zamrożony główny system plików uniemożliwia działanie procesu, który ma go odmrozić, a wyjściem z sytuacji jest twardy reset.

Dla bazy danych czystszym rozwiązaniem jest wykonanie snapshotu i pozwolenie silnikowi na odzyskanie, a następnie sprawdzenie, czy to się udało:

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

Przywracanie

Przywracanie zatrzymuje instancję, zamienia dysk na snapshot i uruchamia ją ponownie. Sekundy, nie minuty. Adresy się nie zmieniają, skonfigurowany przez Ciebie reverse DNS pozostaje, a wszystko zapisane od czasu snapshotu znika.

To obejmuje również to, co skłoniło Cię do przywrócenia. Jeśli istnieje jakakolwiek szansa, że zechcesz przeczytać logi ze stanu awaryjnego, najpierw wykonaj snapshot tego stanu, a potem przywróć na wierzch.

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

Harmonogramy

Harmonogramy per instancja pojawiły się w rewizji platformy 5.4. Codziennie o stałej godzinie z ruchomym oknem to typowy wybór: najstarszy jest usuwany, gdy miejsca się zapełnią.

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

Wybierz godzinę, która jest spokojna dla Twojego obciążenia, a nie dla nas. Koszt przechowywania snapshotu jest proporcjonalny do zmian, które nastąpią później, więc harmonogram uruchamiany podczas nocnego przetwarzania wsadowego przechowuje znacznie więcej danych niż ten uruchamiany godzinę później.

Anulowanie instancji usuwa jej snapshoty

Natychmiast, bez okresu karencji, ponieważ są przechowywane w odniesieniu do instancji. Wszystko, co chcesz zachować po anulowaniu, należy do kopii zapasowej poza węzłem lub gdzieś, gdzie nie jesteśmy my wcale.