Odzyskiwanie do punktu w czasie a snapshoty: co tracisz
Odzyskiwanie do punktu w czasie a snapshoty sprowadza się do jednej liczby: ilości danych, którą możesz sobie pozwolić stracić. Poznaj RPO, dowiedz się, kiedy nocne snapshoty wystarczą, a kiedy po cichu okazują się niewystarczające.
Ktoś wykonuje DELETE bez klauzuli WHERE o 16:15. Najnowsza kopia zapasowa pochodzi z 03:00. Wszystko pomiędzy tymi godzinami przepada i żadne odtworzenie tego nie cofnie.
Ta luka ma nazwę — recovery point objective, czyli RPO — a decyzja odzyskiwanie do punktu w czasie a snapshoty dotyczy wyłącznie tego, jak duża może być ta luka.
Dwa modele
Snapshoty przechwytują stan danych w konkretnej chwili. Wykonuje się je zgodnie z harmonogramem, zwykle co noc. Odtworzenie snapshotu przywraca dokładnie stan z momentu jego utworzenia, a wszystko, co nastąpiło później, przepada.
Odzyskiwanie do punktu w czasie łączy pełną kopię zapasową z ciągłym strumieniem write-ahead logu bazy danych. Ponieważ każda zmiana jest rejestrowana w odpowiedniej kolejności, możesz odtworzyć stan z dowolnego momentu objętego przechowywanym logiem — w tym z 16:14, czyli minutę przed usunięciem danych.
Różnica nie jest stopniowa. To różnica między „straciliśmy dzień” a „straciliśmy minutę”.
Liczba, która przesądza o wyborze
Zadaj sobie szczerze jedno pytanie: co się stanie, jeśli stracisz wszystko zapisane w ciągu ostatnich dwunastu godzin?
W przypadku osobistego projektu, witryny z dokumentacją lub wewnętrznego narzędzia, którego dane można odtworzyć: niewiele. Nocne snapshoty są wtedy naprawdę właściwym rozwiązaniem, a płacenie za ciągłą archiwizację byłoby marnotrawstwem.
W przypadku wszystkiego, z czego korzystają klienci i do czego zapisują dane, odpowiedź zwykle brzmi mniej więcej: „musielibyśmy napisać do ludzi i to wyjaśnić”. Zamówienia, które już nie istnieją. Przesłane pliki, które zniknęły. Wiadomości, które zostały wysłane, ale teraz ich nie ma. Sam koszt obsługi zgłoszeń zazwyczaj przewyższa różnicę w wydatkach na infrastrukturę za cały rok.
Błędem nie jest wybór snapshotów. Błędem jest wybór snapshotów domyślnie, bez zastanowienia się, ile kosztowałaby dwunastogodzinna luka.
Do czego snapshoty naprawdę dobrze się nadają
Nie są gorszym produktem. Chronią przed awariami, których PITR nie obejmuje:
- Utratą całego dysku. Snapshot na oddzielnym storage przywraca wszystko, również pliki, których baza danych nie posiada.
- Szybkim, zgrubnym wycofaniem zmian. Cofnięcie nieudanej migracji w środowisku stagingowym jest szybsze ze snapshotu niż przez odtwarzanie logu.
- Kosztami. Przechowywanie jednej kopii dziennie jest tańsze niż przechowywanie każdej operacji zapisu.
- Prostotą. Mniejsza liczba elementów to realna zaleta operacyjna, szczególnie w małym zespole.
Pułapka polega na traktowaniu ich jako wystarczającego rozwiązania dla bazy danych, do której dane są zapisywane bez przerwy.
Ile kosztuje PITR
Nie jest darmowe, a koszty warto jasno nazwać:
- Storage. Przechowujesz pełną kopię bazową oraz każdy zapis z całego okresu retencji.
- Złożoność. Archiwizacja musi działać nieprzerwanie. Archiwizator, który po cichu nie działał przez tydzień, oznacza, że możliwe do odtworzenia dane kończą się tydzień temu — dlatego monitorowanie archiwum jest równie ważne jak jego konfiguracja.
- Czas odtwarzania. Odtwarzanie logu trwa dłużej niż przywrócenie snapshotu. RPO się poprawia, ale RTO zwykle się pogarsza.
Ta ostatnia zależność często zaskakuje. PITR oznacza mniejszą utratę danych, a nie szybszy powrót online.
Warstwowe rozwiązanie, którego faktycznie potrzebuje większość zespołów
W praktyce nie jest to wybór między dwiema rzeczami. Produkcyjne bazy danych zwykle potrzebują trzech warstw, ponieważ mogą ulec awarii na trzy różne sposoby:
Snapshoty, codziennie, przechowywane przez tydzień lub dwa. Tania ochrona na wypadek utraty maszyny. Obejmuje również pliki niedotyczące bazy danych, znajdujące się na tym samym wolumenie.
Logiczne zrzuty, codziennie, przechowywane poza hostem. pg_dump jest przenośny i z założenia spójny. Można go odtworzyć w innej głównej wersji, u innego dostawcy lub na laptopie — właśnie tego potrzebujesz, gdy problem dotyczy platformy, a nie danych.
Ciągła archiwizacja, gdy baza zawiera dane klientów. To warstwa, która zmienia „straciliśmy dzisiejsze dane” w „straciliśmy minutę”.
Każda z tych warstw obejmuje to, czego nie zapewniają pozostałe. Snapshot nie pomoże w przejściu do innego dostawcy. Logiczny zrzut nie pomoże odzyskać pliku, którego nie było w bazie danych. Żadne z nich nie pomoże cofnąć usunięcia sprzed czterech godzin.
Gdzie w tym wszystkim jest Dockup
Dockup zapewnia dwie warstwy chroniące przed najczęstszymi awariami i warto dokładnie wskazać, które to warstwy.
Snapshoty wolumenów, tworzone na żądanie lub zgodnie z harmonogramem i przechowywane według określonej liczby kopii:
dockup volume snapshot <volumeId> my-project/my-api
dockup volume schedule <volumeId> my-project/my-api --daily --retention 7
dockup volume restore <volumeId> <snapshotId> my-project/my-api
Logiczne kopie zapasowe baz danych, przesyłane bezpośrednio do object storage i szyfrowane podczas przesyłania:
dockup db backup my-project/main-db --json
dockup db backups my-project/main-db --json
W przypadku odtwarzania znaczenie mają dwie cechy tego drugiego rozwiązania. Kopia zapasowa nigdy nie trafia na hosta bazy danych — jest przesyłana do storage w miarę, jak pg_dump ją tworzy, więc nie dzieli losu dysku źródłowego. Ponadto zrzut, który kończy się kodem różnym od zera lub ma zerowy rozmiar, jest usuwany i oznaczany jako nieudany, zamiast pozostawać na liście i wyglądać jak prawidłowa kopia zapasowa.
Dockup nie uruchamia dziś za Ciebie ciągłej archiwizacji. Jeśli Twoje RPO rzeczywiście musi wynosić minuty, warto o tym wiedzieć przed podjęciem decyzji. Możesz też samodzielnie uruchomić taką archiwizację dla zarządzanej bazy danych, używając platformy do obsługi pozostałych elementów.
Ćwiczenie, które warto wykonać w tym tygodniu
Zapisz dwie wartości dotyczące produkcyjnej bazy danych:
- RPO — ile danych możesz stracić. Mierzone w czasie.
- RTO — jak długo możesz pozostawać offline. Również mierzone w czasie.
Następnie sprawdź, co faktycznie zapewnia Twoja obecna konfiguracja, odtwarzając coś z kopii. Jeśli zapisane wartości różnią się od tego, co zapewnia konfiguracja, właśnie znalazłeś decyzję, którą możesz podjąć, gdy nic jeszcze nie płonie — a to jedyny dobry moment, żeby ją podjąć.
Najczęściej zadawane pytania
Jaka jest różnica między RPO a RTO? RPO określa, ile danych tracisz — to luka między ostatnim możliwym do odtworzenia momentem a awarią. RTO określa, ile trwa odzyskiwanie. Snapshoty zapewniają duże RPO i krótkie RTO, a PITR odwraca tę zależność.
Czy mogę odzyskać wiersze usunięte godzinę temu z nocnego snapshotu? Nie. Snapshot przywraca stan z chwili, w której został utworzony. Wszystko, co zapisano później, nie znajduje się w pliku. Odzyskanie dowolnego momentu wymaga ciągłej archiwizacji.
Czy snapshot wolumenu to to samo co kopia zapasowa bazy danych? Nie. Snapshot przechwytuje dysk, w tym stan bazy danych w trakcie zapisu. Logiczny zrzut jest wewnętrznie spójny i przenośny między innymi wersjami oraz dostawcami. Większość środowisk produkcyjnych potrzebuje obu rozwiązań.
Jak długo należy przechowywać kopie zapasowe? Wystarczająco długo, aby zauważyć problem. Uszkodzenie danych lub nieudana migracja często wychodzą na jaw dopiero po kilku dniach, dlatego retencja obejmująca tylko jeden dzień często oznacza, że jedyne dostępne kopie zapasowe już zawierają uszkodzenia.