Backup, którego nikt nie otworzył, nie jest backupem

W sierpniu napisałem współpracowniczce, że kopia zapasowa serwera ze stronami klientów jest „prawdopodobnie martwa". Kilka godzin później wysyłałem sprostowanie: kopia działała, punktów przywracania było 269, najnowszy z ostatniej nocy. Pomyliłem się w dobrą stronę, ale się pomyliłem - i to w dniu, w którym na jednej ze stron siedział włamywacz, a od odpowiedzi na pytanie „czy mamy z czego odtworzyć" zależał cały plan działania.

Najgorsze zauważyłem dopiero po chwili. Oba zdania, to błędne i to poprawione, napisałem, zanim wyciągnąłem z tej kopii choćby jeden plik. Prowadzę agencję AI i automatyzacji dla MŚP, utrzymuję serwery, na których stoją strony i poczta klientów, i wiem, że w małej firmie backup to najczęściej kwestia wiary: ktoś go kiedyś ustawił, coś się świeci na zielono, więc jest. Opowiem, jak wygląda sprawdzenie kopii odczytem, ile to kosztuje i co znalazłem, kiedy wreszcie zrobiłem to u siebie. Nie wszystko mi się spodobało.

Spis treści

• Skąd wiedziałem, że kopia nie działa? Znikąd
• Co to właściwie znaczy „otworzyć" backup?
• Dlaczego wyciągnięcie jednego pliku zajęło mi pół wieczoru?
• Czy 269 sprawnych punktów oznacza, że śpię spokojnie?
• A co z kopią, która naprawdę nie działała?
• Jak sprawdzam kopię już w chwili, gdy ją robię
• Co ma z tym wspólnego AI?
• Jak zrobić taki test u siebie w jedno popołudnie?
• Kiedy taki test to przesada?
• Słownik pojęć

Skąd wiedziałem, że kopia nie działa? Znikąd

Dziesiątego sierpnia rano przyszło zgłoszenie: jedna ze stron klienta na naszym serwerze pokazuje co innego ludziom, a co innego wyszukiwarce. Przeglądarka dostawała niewinną stronę firmową, robot Google ponad sto kilobajtów spamu. Włamanie na WordPressa, tyle że starannie zamaskowane. Jak ustalałem, kiedy sprawca naprawdę wszedł, opisałem osobno w tekście o tym, dlaczego daty plików kłamią. Tutaj interesuje mnie jedno pytanie, które padło w pierwszej godzinie: czy mamy czystą kopię sprzed włamania?

Odpowiedziałem z pamięci. Jakiś czas wcześniej, przy przeglądzie innej maszyny, widziałem zadanie kopii celujące w magazyn, który nie odpowiadał na połączenia. Zadanie skonfigurowane, harmonogram ustawiony, a kopie nie powstawały. Głowa zrobiła resztę: podobna konfiguracja, ten sam magazyn, więc pewnie to samo. Napisałem „prawdopodobnie martwa, jak tamta" i wróciłem do odcinania zainfekowanej strony od świata.

To jest dokładnie ten mechanizm, za który na co dzień krytykuję modele językowe. Model czegoś nie wie, więc dopowiada najbardziej prawdopodobny ciąg dalszy i podaje go pewnym tonem. Zrobiłem to samo: dopasowałem wzorzec z innego serwera i podałem go dalej jako diagnozę. Modelowi wybaczam to łatwiej niż sobie.

Wieczorem usiadłem do sprawy porządnie. Zalogowałem się do magazynu kopii, wylistowałem zawartość i zobaczyłem 269 punktów przywracania. Jeden na dobę, zawsze w nocy, każde zadanie zakończone statusem OK, ostatni punkt sprzed kilkunastu godzin. Napisałem sprostowanie. Głupio mi było, nie będę udawał, że nie.

I tu mógłbym odetchnąć. Tylko że lista z 269 pozycjami mówi o kopii dokładnie tyle, ile moje poranne „prawdopodobnie martwa", czyli nic sprawdzonego. Zamieniłbym jedno założenie na drugie, po prostu przyjemniejsze.

Co to właściwie znaczy „otworzyć" backup?

Znaczy: wyciągnąć z niego konkretną rzecz i porównać z tym, czego się spodziewasz. Nie popatrzeć na listę, nie przeczytać zielonego statusu, nie sprawdzić rozmiaru. Wyjąć plik i go obejrzeć.

Lista to nie dowód

Status „OK" przy zadaniu kopii oznacza, że program skończył pracę bez błędu, który sam umie rozpoznać. Nie oznacza, że w środku jest to, co myślisz. Kopia może być kompletna i zaszyfrowana kluczem, którego nikt już nie ma. Może obejmować dysk systemowy, a pomijać ten z danymi, bo ktoś go dołożył rok po ustawieniu zadania. Może zawierać bazę danych złapaną w połowie zapisu. Z zewnątrz wszystkie te przypadki wyglądają identycznie: data, rozmiar, zielona kropka.

Porównuję to do gaśnicy w biurze. Wisi, ma plombę i naklejkę z przeglądu. Czy zadziała, dowiesz się, kiedy wyciągniesz zawleczkę. Z gaśnicą próba jest kłopotliwa, bo ją zużywa. Przy kopii zapasowej tej wymówki nie ma - odczyt niczego nie psuje i można go powtarzać do woli.

Jeden plik, trzy odpowiedzi

Wybrałem punkt z drugiego lipca, czyli sprzed pierwszych śladów włamania, i wyciągnąłem z niego jeden mały plik konfiguracyjny zainfekowanej strony. Ten sam, który atakujący podmienił na własny, żeby zablokować właścicielowi wejście do panelu i przepuszczać tylko swoje skrypty.

Wersja leżąca na serwerze miała 533 bajty. Ta z kopii - 884 bajty i zwyczajną treść, jaką WordPress generuje sam. Zajrzałem jeszcze do katalogu, w którym po włamaniu leżało czterdzieści plików. W kopii był jeden. Folderu z tylnym wejściem nie było wcale.

Ten jeden odczyt odpowiedział na trzy pytania naraz. Kopia daje się otworzyć, więc hasła i klucze, które mam, są właściwe. Zawiera dysk ze stronami, a nie sam system. I jest czysta, czyli do włamania doszło po drugim lipca, co przy okazji zawęziło okres, w którym trzeba było szukać drogi wejścia. Z samej listy 269 punktów nie wyczytałbym żadnej z tych rzeczy.

Dopiero wtedy mogłem napisać zdanie, pod którym da się podpisać: mamy czysty stan sprzed infekcji i wiem, że się otwiera, bo trzymam w ręku plik z niego.

Dlaczego wyciągnięcie jednego pliku zajęło mi pół wieczoru?

Bo nigdy wcześniej nie robiłem tego na tym serwerze. To ta mniej wygodna część historii.

Kopie robiły się od miesięcy. Procedury odtwarzania nie miałem spisanej, no bo przecież to standardowe narzędzie i w razie czego się doczyta. Kiedy przyszło do użycia, potknąłem się cztery razy z rzędu. Najpierw o konto: magazyn kopii miał osobnego użytkownika, innego niż administrator serwera, i trzeba go było odszukać w konfiguracji. Potem o hasło, które narzędzie do odczytu pojedynczych plików chciało dostać inaczej niż narzędzie do robienia kopii. Potem o klucz szyfrujący, bo kopie są zaszyfrowane i plik z kluczem trzeba było wskazać ręcznie. Na końcu o ścieżkę: dysk w kopii ma budowę warstwową i katalog strony siedzi kilka poziomów głębiej, niż podpowiada intuicja.

Każda z tych przeszkód to pięć - dziesięć minut, kiedy jest spokojny wieczór, a ja szukam jednego pliku. Teraz wyobraź sobie to samo o trzeciej w nocy, kiedy serwer nie wstaje, klienci dzwonią, a ty pierwszy raz w życiu czytasz dokumentację polecenia do odtwarzania. Wtedy każda taka przeszkoda trwa trzy razy dłużej, bo ręce się trzęsą.

Przy kluczu szyfrującym zatrzymam się na dłużej. Plik z kluczem leży na serwerze, co jest normalne, bo serwer musi nim szyfrować każdą nocną kopię. Ale jeśli to jedyny egzemplarz, a maszyna spłonie albo ktoś ją wyczyści, to razem z nią znika możliwość otwarcia czegokolwiek. Zaszyfrowana kopia bez klucza jest warta dokładnie tyle, co brak kopii, tylko zajmuje więcej miejsca. Drugi egzemplarz klucza ma leżeć w menedżerze haseł, poza maszyną, której dotyczy. Sprawdź to u siebie przed wszystkim innym, bo tego błędu nie widać, dopóki nie jest za późno.

Po tamtym wieczorze spisałem działającą sekwencję poleceń razem z pułapkami. Wyszło pół strony. Następnym razem odczyt pliku zajmie kilka minut, obojętnie, kto z zespołu będzie go robił.

Czy 269 sprawnych punktów oznacza, że śpię spokojnie?

Nie. Otwarcie kopii pokazało też rzeczy, których wolałbym nie zobaczyć, i uczciwie będzie je wymienić.

Osiem dni dziury

Przeglądając listę punktów, zauważyłem przerwę. Na początku sierpnia przez osiem dni z rzędu nie powstał ani jeden. Potem kopie ruszyły znowu, jakby nigdy nic. Przyczyny nie udało mi się ustalić. Gdyby awaria wypadła akurat wtedy, cofnęlibyśmy się o ponad tydzień zamiast o dobę, a ja dowiedziałbym się o tym w najgorszym możliwym momencie.

Alarm, który dzwoni u kogoś innego

Dlaczego nikt nie zauważył tej przerwy? Bo powiadomienie o nieudanej kopii było ustawione na adres administratora po stronie hostingu. Rozsądne ustawienie z dnia instalacji i pewnie nikt do niego potem nie zaglądał. Tyle że to ja odpowiadam przed klientami za ich strony, a o nieudanej kopii nie dostałbym nawet maila.

Sam mail o błędzie to zresztą słabe zabezpieczenie. Przychodzi, kiedy zadanie się uruchomi i wywróci. Kiedy nie uruchomi się wcale, panuje cisza, a cisza wygląda jak sukces. Lepiej mierzyć coś innego: wiek ostatniej udanej kopii. Jeśli przekracza półtorej doby, ma dzwonić u mnie. Taki pomiar łapie wszystkie rodzaje porażki naraz, także te, których program nie umie zgłosić.

Dane to jeszcze nie dostępność

Każdy z tych punktów to pełny obraz maszyny, kilkaset gigabajtów. Wyjęcie jednego pliku trwa chwilę. Odtworzenie całego serwera oznacza ściągnięcie tego wszystkiego przez sieć, czyli godziny, w trakcie których kilkadziesiąt stron klientów nie działa. Kopia raz na dobę oznacza z kolei, że w najgorszym razie tracimy do dwudziestu czterech godzin zmian. Dla strony wizytówki to żaden problem. Dla sklepu z zamówieniami już tak.

I rzecz, do której przyznaję się najmniej chętnie: pełnego, próbnego odtworzenia tej maszyny na serwer testowy do dziś nie zrobiłem. Otworzyłem jeden plik z jednego punktu. To wystarcza, żeby przestać mówić „chyba". Nie wystarcza, żeby obiecać klientowi, że po awarii wstaniemy w trzy godziny, bo tego czasu nikt nie zmierzył. Próba stoi na liście zadań i dopóki jej nie przeprowadzę, nie podaję nikomu żadnej liczby godzin.

A co z kopią, która naprawdę nie działała?

Żeby nie wyszło, że ta historia ma same szczęśliwe zakończenia. W tym samym miesiącu znalazłem u siebie backup, który faktycznie był martwy, i to od dawna.

Chodzi o firmowy dysk sieciowy: nieduże urządzenie z dwoma dyskami w lustrze, na którym leżą archiwa projektów z wielu lat. Kopia do chmury producenta została ustawiona w 2021 roku i od tamtej pory figurowała w mojej głowie jako „załatwione". Przy porządkach w połowie sierpnia okazało się, że nie działa od miesięcy, i to z dwóch niezależnych powodów. Urządzenie pytało o adresy internetowe router, którego dawno nie ma w sieci, więc nie potrafiło nawet znaleźć chmury. A samo repozytorium z 2021 roku było uszkodzone i odrzucało każdą próbę połączenia.

Powiadomienia o błędach? Szły na skrzynkę, która nie istnieje. Odbijały się miesiącami, a ja co roku opłacałem abonament za chmurę, do której nic nie trafiało. Szczerze? Byłem wściekły, głównie na siebie.

Założyłem nowe zadanie, tym razem szyfrowane. I tu wyszła druga warstwa problemu: to urządzenie ma 256 MB pamięci, wlutowanej, bez możliwości rozbudowy. Po trzydziestu godzinach pracy wysłało 2,8 GB z mniej więcej 540, czyli pół procenta. Po drodze oprogramowanie raz samo wyrzuciło cały dotychczasowy postęp i zaczęło od zera. W takim tempie pierwsza pełna kopia trwałaby większą część roku. Dwudziestego trzeciego sierpnia przerwałem to, bo udawanie, że kopia „się robi", jest gorsze niż świadomość, że jej nie ma.

Dziś przenoszę te dane na dysk chmurowy, a po przenosinach całość przejdzie porównanie sum kontrolnych, żeby mieć dowód, że dotarło to samo, co wyszło. Przy inwentaryzacji wyszło, że ponad 109 tysięcy plików, razem około 185 GB, istniało wyłącznie na tym jednym urządzeniu.

Dwa dyski w lustrze dawały mi przez te lata poczucie bezpieczeństwa, na które nie zasługiwały. Lustro chroni przed awarią jednego dysku. Nie chroni przed skasowaniem pliku, zaszyfrowaniem przez złośliwy program ani zalaniem biura, bo każdą z tych rzeczy wiernie i natychmiast powtarza na drugim dysku. O tym, jak łatwo uzależnić firmę od jednego punktu, pisałem już w tekście o tym, jak w jedną noc straciłem dostęp do całej firmy. Wtedy poszło o fakturę. Tu mogło pójść o archiwum wielu lat pracy.

Jak sprawdzam kopię już w chwili, gdy ją robię

Jest jeszcze jeden rodzaj kopii, o którym łatwo zapomnieć: ta robiona ręcznie tuż przed ryzykowną operacją. Przed aktualizacją, przed migracją, przed usunięciem czegokolwiek. Tu sprawdzenie odczytem jest najtańsze, bo oryginał jeszcze istnieje i jest z czym porównać.

Tamtego sierpniowego dnia, zanim dotknąłem zainfekowanej strony, zrobiłem archiwum jej plików, 1,4 GB, i osobno zrzut bazy danych, 1,6 MB. Jedno i drugie od razu otworzyłem. Archiwum dało się wylistować do końca, czyli nie urwało się w połowie. Zrzut bazy dał się otworzyć i były w nim tabele, których się spodziewałem. Zajęło to parę minut.

Kilka dni wcześniej wygaszałem stary, nieużywany serwis. Przed skasowaniem bazy rozpakowałem jej świeżo zrobioną kopię i policzyłem tabele. Wyszło 51, tyle samo co w żywej bazie. Dopiero wtedy skasowałem oryginał. Brzmi to jak pedanteria, dopóki nie zobaczysz na własne oczy zrzutu bazy o rozmiarze zero bajtów, który powstał bez żadnego komunikatu, bo skrypt dostał złe hasło. Albo archiwum uciętego w dwóch trzecich, bo skończyło się miejsce na dysku. Obie rzeczy na liście plików wyglądają jak zrobiona kopia.

U mnie zasada brzmi tak: kopia przed operacją nieodwracalną, której nikt nie odczytał, nie liczy się jako zrobiona. Ta minuta bywa jedyną rzeczą, która dzieli pomyłkę od katastrofy.

Co ma z tym wspólnego AI?

Więcej, niż się wydaje. Agent AI, który wykonuje za mnie zadania, raportuje „gotowe" dokładnie tak, jak zadanie kopii raportuje „OK". W obu przypadkach to informacja, że proces się zakończył, a nie że wynik jest dobry.

Dlatego dzień po sierpniowej wpadce dopisałem do rejestru, w którym osiada doświadczenie mojego agenta, regułę mniej więcej tej treści: kiedy masz powiedzieć, że kopia istnieje albo da się z niej coś odtworzyć, sprawdź to odczytem, a nie obecnością na liście. Wyciągnij konkretny plik i porównaj z oczekiwaną treścią. Reguła powstała po moim błędzie, nie po błędzie maszyny, i to chyba najuczciwszy sposób jej uzasadnienia.

Szybko się okazało, że pasuje do wszystkiego. „Zapisano dokument" nie znaczy, że dokument wygląda poprawnie. „Wysłano" nie znaczy, że doszło. „Certyfikat odnowiony" nie znaczy, że serwer podaje nowy. Za każdym razem jest ta sama luka między komunikatem a skutkiem i za każdym razem zamyka ją to samo: odczytać wynik tam, gdzie miał wylądować.

Z modelami językowymi mam dzięki temu trochę zdrowszą relację. Przestałem się dziwić, że potrafią z przekonaniem podać coś niesprawdzonego, odkąd złapałem na tym samego siebie. Wymagam od nich tego samego, czego od siebie: zanim powiesz „działa", pokaż, co odczytałeś.

Jak zrobić taki test u siebie w jedno popołudnie?

Nie potrzebujesz do tego administratora na etacie. Jeśli serwerami zajmuje się u ciebie firma zewnętrzna, tym lepiej, bo cały test sprowadza się do jednej prośby: pokażcie mi przy mnie plik z zeszłego wtorku. Reakcja na tę prośbę powie ci o stanie twoich kopii więcej niż jakikolwiek raport.

A jeśli robisz to sam albo chcesz wiedzieć, czego wymagać:

• Wybierz plik, który znasz. Ofertę, którą zmieniałeś w konkretnym dniu, arkusz z cennikiem, cokolwiek, o czym wiesz, jak wyglądało tydzień temu. Chodzi o to, żebyś umiał ocenić, czy dostałeś właściwą wersję.
• Odtwórz go obok, nigdy na miejsce oryginału. Do osobnego folderu, na inny komputer. Test odtwarzania nie może nadpisać tego, co działa.
• Otwórz i porównaj. Sam fakt, że plik się pojawił, jeszcze niczego nie dowodzi. Ma się otworzyć i zawierać to, co powinien. Przy plikach technicznych porównaj rozmiar albo sumę kontrolną.
• Bazę danych wgraj do pustej, testowej bazy i policz tabele albo rekordy. Zrzut, który „jest", a nie daje się wgrać, to najczęstsza niespodzianka.
• Zmierz czas i spisz kroki. Ile trwało, jakie hasło było potrzebne, gdzie się potknąłeś. Ta kartka jest warta więcej niż sama kopia, bo w dniu awarii nie będziesz miał głowy do zgadywania.
• Sprawdź, gdzie leży klucz albo hasło do kopii. Jeśli tylko na maszynie, którą ta kopia ma ratować, popraw to dzisiaj.
• Sprawdź, do kogo idzie alarm. Na czyją skrzynkę, czy ta skrzynka istnieje i czy ktoś ją czyta. Jeśli się da, ustaw powiadomienie o tym, że ostatnia udana kopia jest starsza niż doba z kawałkiem.
• Wpisz powtórkę do kalendarza. Jeden plik raz na kwartał, całość raz w roku. Kopie psują się po cichu, więc jednorazowy test starzeje się razem z nimi.

Pierwszy raz zajmie ci to popołudnie, głównie przez szukanie haseł. Każdy kolejny to kwadrans. O tym, że takie utrzymanie jest stałym kosztem, a nie jednorazowym wydatkiem, pisałem przy okazji ukrytych kosztów wdrożeń i podtrzymuję: to najtańsza pozycja na tamtej liście.

Kiedy taki test to przesada?

Rzadko, ale bywa. Jeśli twoja firma liczy kilka osób i wszystko trzyma w usługach chmurowych, czyli poczta u dużego dostawcy, dokumenty na dysku online, księgowość w programie przez przeglądarkę, to nie masz własnej kopii do testowania i nie ma sensu budować całej procedury z kwartalnym odtwarzaniem.

Masz za to inne pytanie, równie konkretne. Co się stanie, kiedy ktoś skasuje folder i zorientujecie się po dwóch miesiącach? Kosz w większości takich usług trzyma pliki przez ograniczony czas, a historia wersji też ma swoje granice. Zrób więc ten sam test w wersji kieszonkowej: skasuj plik próbny, odczekaj, przywróć. Wyeksportuj dane z programu księgowego i sprawdź, czy ten eksport da się w ogóle otworzyć. To dziesięć minut, a odpowiada na to samo pytanie.

Przesadą jest też codzienny rytuał. Ręczne sprawdzanie kopii co rano kończy się zwykle po kilku tygodniach, bo zawsze jest dobrze i ręka sama przestaje klikać. Raz na kwartał, z wpisem w kalendarzu i z automatem pilnującym wieku ostatniej kopii pomiędzy testami, wytrzymuje dłużej niż najlepsze postanowienia.

Moje 269 punktów okazało się sprawne. Miałem szczęście, a dokładniej: miałem je na jednym serwerze i nie miałem na dysku sieciowym, i do sierpnia nie potrafiłbym powiedzieć, gdzie jest które. Tyle właśnie wiesz o kopii, do której nikt nie zajrzał.

Słownik pojęć

• Punkt przywracania - zapisany stan serwera albo dysku z konkretnej chwili, do którego można wrócić. 269 punktów to 269 takich „zdjęć", po jednym na noc.
• Weryfikacja odczytem - sprawdzenie kopii przez wyciągnięcie z niej konkretnego pliku i porównanie z oczekiwaną treścią, zamiast polegania na statusie zadania.
• Lustro dysków (RAID 1) - dwa dyski, na które dane zapisują się jednocześnie. Chroni przed awarią jednego z nich, ale każde skasowanie i każde uszkodzenie pliku powtarza natychmiast na obu, więc kopią zapasową nie jest.
• Suma kontrolna - krótki „odcisk palca" wyliczony z zawartości pliku. Jeśli odcisk oryginału i kopii jest identyczny, pliki są takie same co do bajta.
• Klucz szyfrujący - plik albo hasło, bez którego zaszyfrowanej kopii nie da się odczytać. Musi mieć drugi egzemplarz poza maszyną, którą kopia zabezpiecza.

Jeden plik z zeszłego wtorku

Jeśli po tym tekście nie masz pewności, co odpowiedziałaby twoja firma na prośbę „pokażcie mi plik z zeszłego wtorku", napisz do mnie na [email protected]. Opisz w kilku zdaniach, gdzie leżą dane i kto robi kopie. Odpiszę, od którego pliku sam bym zaczął sprawdzanie i na co patrzeć przy odczycie.

Więcej o tym, jak wygląda współpraca ze mną, od pierwszej rozmowy po wdrożenie.