Recovery od podstaw: rollback, PITR i powrót po awarii

Najprostszy plan recovery zaczyna się od jednego pytania:

text

do którego punktu mamy wrócić?

Nie od narzędzia.

Nie od dostawcy chmury.

Nie od diagramu disaster recovery, który dobrze wygląda w dokumentacji i którego nikt nie ćwiczył.

Najpierw trzeba umieć nazwać stratę.

text

ile danych możemy stracić
jak długo system może być niedostępny
czy cofamy kod, dane, ruch, czy wszystko naraz

Bez tego recovery robi się chaotyczne.

Ktoś mówi "rollback", ktoś inny ma na myśli przywrócenie backupu, ktoś trzeci chce przepiąć ruch, a baza danych już zdążyła przyjąć nowe rekordy w formacie, którego stara wersja aplikacji nie rozumie.

Ta seria jest o prostym, praktycznym recovery.

Nie o pełnej strategii dla banku, regionów aktywnych w dwóch chmurach i automatycznym failoverze wszystkiego.

Chodzi o podstawowy zestaw ruchów, które trzeba rozumieć, zanim słowo "odtwarzanie" zacznie cokolwiek znaczyć.

Co będzie w tej serii

Zaczniemy od pojęć.

PITR mówi o odtworzeniu danych do konkretnego punktu w czasie.

RPO mówi, ile danych możemy stracić.

RTO mówi, jak długo możemy wracać do działania. Jeśli gdzieś pojawia się TRO, zwykle chodzi właśnie o RTO.

SLO opisuje obietnicę techniczną, którą system ma spełniać.

SLA opisuje zobowiązanie wobec klienta albo organizacji.

Potem zejdziemy do bardziej konkretnych przypadków.

Najpierw cofanie wydania:

text

kod
migracje
kompatybilność danych
feature flags
kolejki i eventy

Bo rollback aplikacji często jest prosty tylko wtedy, kiedy baza nie poszła za daleko.

Następnie PITR całego serwera.

Nie jako magiczny przycisk "restore", tylko jako sekwencja decyzji:

text

odtworzyć
sprawdzić
zamrozić zapisy
przepiąć ruch
potwierdzić stan

Potem PITR pojedynczej bazy na tym samym serwerze, czyli przypadek mniejszy, ale często bardziej zdradliwy, bo inne bazy, aplikacje i integracje mogą dalej żyć swoim rytmem.

Na końcu będzie krótko o tym, co zrobić po wszystkim.

Recovery nie kończy się w momencie, w którym wykresy wróciły do zielonego.

Trzeba jeszcze odtworzyć przebieg zdarzeń, sprawdzić dziury w runbooku, poprawić monitoring, dopisać test odtworzeniowy i zdecydować, czy zaakceptowane RPO i RTO były naprawdę świadomą decyzją.

Minimalny model

W tej serii będę trzymał się prostego modelu:

text

aplikacja
baza danych
backup pełny
WAL albo binlog
routing do aktywnego endpointu
runbook

To wystarczy, żeby pokazać najważniejsze mechanizmy bez zasłaniania ich platformą.

Kubernetes, managed database, VM albo bare metal zmieniają implementację.

Nie zmieniają podstawowych pytań:

text

co dokładnie straciliśmy
do czego wracamy
czego nie wolno już nadpisać
kto przełącza ruch
jak wiemy, że odtworzony stan jest poprawny

Jeżeli te pytania są jasne, recovery jest nadal stresujące, ale przestaje być improwizacją.

I o to chodzi w tej serii.