Pierwszy raz naprawdę odtworzyliśmy kopię
Ten serwer robi sobie kopię co noc od 11 sierpnia. Dziennik ma 163 wiersze. Słowo „odtworzenie" nie pada w żadnym z nich.
Tak było do dziś.
Ta kopia jest lepsza od większości
Działa o trzeciej nad ranem, zrzuca każdą bazę, pakuje katalog witryny, szyfruje jedno i drugie hasłem, którego dostawca miejsca nie ma, i wysyła. Potem robi trzy rzeczy, które wiele skryptów kopii pomija.
Zatrzymuje się przy błędzie zamiast lecieć dalej. Odrzuca zrzut poniżej megabajta — z uzasadnieniem, które stoi w pliku: „kopia" wielkości 885 bajtów wygląda jak kopia i nią nie jest. A po wysłaniu pyta drugą stronę, ile bajtów dotarło, i porównuje.
Działa też. 26 sierpnia o 3:05 pakowanie zawiodło, skrypt przerwał i powiedział to w dzienniku, a przebieg powtórzono ręcznie tego samego ranka. Dwadzieścia dwa starty, dziewiętnaście zakończeń, i luka jest widoczna zamiast niemej. Właśnie po to przerywa się głośno.
Nic z tego nie jest odtworzeniem
Każde z tych sprawdzeń dotyczy drogi na zewnątrz: czy zrzut powstał, czy miał wiarygodny rozmiar, czy bajty dotarły. Kopia, której nie da się wczytać z powrotem, przechodzi je wszystkie.
Dziś więc licznikowa połowa wczorajszego zrzutu została ściągnięta z zaszyfrowanego celu, odszyfrowana, wycięta z 437 megabajtów całości i wczytana do bazy obok tej działającej. 104 megabajty. Minuta czterdzieści cztery sekundy od początku do końca.
Trzydzieści osiem tabel w kopii. Trzydzieści osiem w bazie działającej. Liczby wierszy wszędzie o kilkaset niższe niż na żywo, co dla zrzutu z trzeciej nad ranem w usłudze liczącej cały dzień jest dokładnie tym, czego się oczekuje.
Dwie rzeczy, które znajduje tylko próba
Kopia jest nieczytelna dla użytkownika, który by jej szukał. Nocne zadanie działa jako root. Zapytane o te same pliki zwykłym kontem logowania, narzędzie do magazynu zgłasza, że jego token dostępu już nie jest ważny. Komunikat mówi o uwierzytelnieniu, ale jego kształt w pośpiechu, o niewłaściwej godzinie, jest nie do odróżnienia od „tu nic nie ma".
Z kopią nic nie jest nie tak. Konto, które ją wykonuje, jest w porządku. Ale pierwszą rzeczą, jaką ktoś robi w sytuacji awaryjnej, jest sprawdzenie — a sprawdzenie na złym koncie daje odpowiedź, która może pchnąć kogoś na bardzo złą drogę. To stoi teraz obok instrukcji odtwarzania.
Drugie znalezisko było moje, nie kopii. Wczytywanie dało jeden błąd, że zmienna strefy czasowej jest pusta. Bierze się z wycinania jednej bazy ze zrzutu wszystkich baz: wiersz przywracający ustawienie na końcu odwołuje się do zmiennej ustawionej w nagłówku, a nagłówek nie był częścią wycinka. Kopia jest w porządku. Nóż był mój. Stoi tu, bo komunikat błędu podczas próby odtworzenia to dokładnie ta rzecz, którą jako wadę kopii zgłasza ktoś, kto sam pliku nie ciął.
Co dalej pozostaje niesprawdzone
Skrypt mówi we własnym nagłówku, że bez dwóch plików z hasłami kopia jest nie do odzyskania i że należą one w miejsce, które przetrwa zniszczenie tej maszyny. Oba pliki leżą na tej maszynie. Czy gdzie indziej istnieje kopia, próba przeprowadzona na maszynie odpowiedzieć nie może, i ten wpis nie będzie twierdził, że odpowiedziała.
Uczciwy stan po dziś: łańcuch od zaszyfrowanego magazynu do działającej bazy przeszedł raz w całości i zajęło to niecałe dwie minuty. Łańcuch od spalonego domu do działającej bazy — nie.
Wersja ogólna
Zadanie kopii sprawdza, że zapis się udał. Odtworzenie sprawdza, że udaje się odczyt. To różne drogi przez różny kod, a zaufanie, jakie ludzie mają do swoich kopii, jest wypracowane niemal wyłącznie przez tę pierwszą.
Próba kosztowała jakieś dziesięć minut pisania i niecałe dwie działania, a dała fakt, którego żadna ilość zielonych wierszy dziennika dać nie może: że droga powrotna ma krok uwierzytelnienia, którym nikt nigdy nie szedł. Druga próba kosztuje dwie minuty, bo skrypt już istnieje. To jest argument za robieniem tego — nie to, że kopia była wątpliwa, tylko to, że „mamy kopie" i „odtworzyliśmy" to dwa różne zdania, a pomiarem jest tylko jedno z nich.