Kopia 1 TB i restore, który trwał kilka dni

Klient przyszedł z kopią, która formalnie istniała. Objętość: 1 TB. Job szedł, retencja była ustawiona, panel pokazywał sukces. W dniu awarii okazało się, że jedyna droga odtworzenia to cały dysk. Kilka plików, bez których aplikacja nie wstaje, leżało w tym samym zbiorze co media, logi i archiwum.

Z czym przyszedł klient

Serwis produkcyjny miał jedną politykę backupu: kopia maszyny albo wolumenu, w całości. Przy utracie danych albo przy uszkodzeniu hosta procedura brzmiała tak samo. Uruchamiamy restore pełnego obrazu. Czekamy, aż 1 TB przejdzie przez sieć i weryfikację. Potem startujemy system i sprawdzamy, czy aplikacja wstaje.

Czego naprawdę potrzebował serwis

Do pierwszego requestu nie był potrzebny cały terabajt. Wystarczała konfiguracja, dump bazy albo katalog danych silnika, klucze i ten katalog aplikacji, bez którego proces nie startuje. Reszta mogła wrócić później: historia, media, logi, archiwa.

Zespół wiedział to z praktyki. Nie miał jednak listy, runbooka ani osobnego jobu. Restore pojedynczego pliku nie był w procedurze. Ćwiczenie, jeśli w ogóle było, polegało na odtworzeniu całości na innym hoście.

Ile to trwało

Transfer, weryfikacja chunków i start maszyny zajmowały kilka dni. RTO w umowie liczyło czas do momentu, gdy system wstaje. W praktyce zegar szedł od startu pełnego restore. Serwis stał, bo procedura nie umiała wyciągnąć kilku megabajtów z terabajta.

Dlaczego pełny dysk blokuje RTO

Kopia 1 TB ma sens. Jest historią, jest pełnym rebuildem, jest materiałem do audytu. Nie jest ścieżką startową. Sieć, kolejka I/O i weryfikacja skalują się z objętością. Czas restore idzie za terabajtem, nawet gdy do ruchu wystarczą megabajty.

Jedna kopia, jedna droga

Gdy jest jeden job i jeden tor, każda awaria wygląda tak samo. Odtwarzamy wszystko, potem sprawdzamy serwis. Dump logiczny bazy, jeśli w ogóle jest, leży w tym samym obrazie i czeka razem z resztą zbioru.

Bez zestawu startowego nikt nie ma prawa powiedzieć, które pliki są warunkiem ruchu. Wtedy jedyna bezpieczna decyzja brzmi: przywróć całość. To jest poprawne z punktu widzenia kompletności. Jest kosztowne z punktu widzenia RTO.

Jak to ułożyliśmy

Zaczęliśmy od spisu, nie od nowego storage. Razem z klientem zapisaliśmy zestaw startowy: pliki i zbiory, bez których serwis nie przyjmuje ruchu. Krótka lista, z właścicielem i z miejscem w kopii. Pełny obraz 1 TB zostaje. Przestaje być jedyną drogą.

Dwa joby, dwa czasy

Dump logiczny bazy i kopia zestawu startowego poszły osobnym jobem, z częstszym RPO. Restore pojedynczego pliku jest w procedurze. Montujemy kopię albo wyciągamy plik z serwera kopii, na przykład z Proxmox Backup Server, bez odtwarzania całej maszyny.

Pełny dysk ma własny runbook. Służy do rebuildu i do audytu, nie do pierwszego startu. Gdy serwis już przyjmuje ruch, reszta zbioru może wracać w tle.

Ćwiczenie, które mierzy właściwą liczbę

W kalendarzu ćwiczymy zestaw startowy, nie 1 TB. Mierzymy czas do momentu, gdy serwis przyjmuje ruch. Osobno zapisujemy czas do momentu, gdy cały zbiór jest na miejscu. To dwie liczby. Mieszanie ich w jednym RTO było źródłem kilku dni oczekiwania.

Skutek

Serwis wstaje z kilku plików. Pełna kopia 1 TB wraca potem, gdy start już jest. RTO startowe liczy się w godzinach, nie w dniach czekania na cały dysk. Ten sam układ, restore pliku i pełnej maszyny w kalendarzu, opisujemy w usłudze bezpieczeństwa danych.

Podsumowanie

Duża kopia nie jest błędem. Błędem jest jedna droga restore, gdy serwisowi do pracy wystarcza krótka lista plików. Spis zestawu startowego, osobny job i ćwiczenie tej ścieżki zmieniają RTO bez wyrzucania terabajta historii.