Kopia na zielono. Czy dane wrócą?

Kopia co noc kończyła się na zielono, ale próba odtworzenia z 25 lipca 2026 roku ujawniła cztery błędy. Od dawna nie robiłem takiej próby i wpadłem w znajomą pułapkę: ufałem zielonemu wynikowi. Dziś sprawdzam kopie na trzech poziomach, od czytelności pliku po odpowiedź uruchomionego programu. Każdy łapie inny błąd, przez który dane mogłyby nie wrócić.

Jak powstaje kopia

Baza zmienia dane podczas pracy programu. Zwykłe kopiowanie jej plików może zebrać fragmenty z różnych chwil, które później nie będą do siebie pasować. Dlatego zapis przygotowuje sama baza: tworzy spójny zrzut, który można do niej wczytać. Dopiero taki plik wkładam do kopii. Przy odtwarzaniu trzeba go jeszcze wczytać do bazy; samo rozpakowanie na dysku nie udostępni danych programowi.

Oprócz zrzutów zapisuję pliki aplikacji, konfigurację i hasła używane przez programy. Ustawienia mówią aplikacji, gdzie szukać danych. Hasło pozwala się zalogować, ale tylko wtedy, gdy baza rozpoznaje także konto programu. Żeby odzyskać dostęp, potrzebuję zarówno danych, jak i tych pozornych dodatków.

Całość szyfruję. Jedna kopia zostaje w domu, druga trafia poza dom, do innej lokalizacji. Gdy przypadkiem usunę plik w domu, nie chcę, żeby następne kopiowanie powtórzyło pomyłkę. Dlatego kopia poza domem nie kasuje plików tylko dlatego, że zniknęły u źródła. To chroni przed powieleniem usunięcia, choć nie czyni samej kopii nieusuwalną.

Skąd wiem, że kopia przestała się robić

Zadanie, które w ogóle nie ruszyło, nie wyśle własnego raportu o błędzie. Dlatego pilnuję wieku ostatniej udanej kopii. Gdy robi się za stara, alarm wynika z upływu czasu. Nie muszę czekać na zgłoszenie od zadania, które milczy. Cisza przestaje uchodzić za sukces. Osobny alarm zwraca uwagę na podejrzany rozmiar pliku: kopia mogła powstać, lecz zawierać mniej danych, niż powinna. Dzięki temu wiem, kiedy zajrzeć do zadania lub jego wyniku. To, czy odzyskam dane, sprawdzam już przez odtwarzanie.

Trzy poziomy sprawdzania

Najpierw sprawdzam plik z kopią. W pełnej próbie przywracam dane i uruchamiam aplikację. Pomiędzy pełnymi próbami automat regularnie odtwarza fragment z bieżącej kopii. Te kontrole uzupełniają się: każda zagląda tam, gdzie pozostałe mogłyby przeoczyć błąd.

Kontrola spójności archiwum

Sprawdzam, czy plik z kopią da się poprawnie odczytać. Kontrola spójności pozwala wykryć uszkodzone archiwum, zanim będę go potrzebował po awarii. Samo istnienie pliku niewiele mi daje, jeśli nie da się wydobyć jego zawartości.

Archiwum może jednak bezbłędnie przechować niepełną kopię. Jeśli pominąłem plik z hasłem, kontrola nie znajdzie w nim uszkodzenia, bo w ogóle go nie dostała. Bada to, co zapisałem. Żeby zauważyć brak rzeczy potrzebnych programowi, muszę spróbować go uruchomić z odtworzonych danych.

Pełna próba odtworzenia

Pełną próbą nazywam tu odtworzenie danych i uruchomienie aplikacji na przygotowanym komputerze. Pobieram kopię, przywracam jej zawartość i sprawdzam, czy program odpowiada. Wspomniana próba z 25 lipca 2026 roku pokazała cztery sposoby, na jakie ten plan może się rozminąć z rzeczywistością:

• Brak kont bazy. Dane wracały, ale aplikacja nie mogła się zalogować, bo kopia nie zawierała jej kont. Raport potwierdzał zapis danych; nie sprawdzał, czy wróci także dostęp dla programu.
• Skrypt pomijał bazy. Narzędzie do odtwarzania rozpakowywało pliki, lecz nie wczytywało zrzutów do baz. Raport z kopiowania potwierdzał zapis plików, więc nie widział brakującego kroku w narzędziu do ich odtwarzania.
• Reguła wykluczeń pomijała hasła. Pasowała do zbyt wielu plików i odrzucała część tych, których aplikacje potrzebowały do logowania. Zadanie wykonywało regułę zgodnie z poleceniem, więc nie zgłaszało błędu.
• Dane wracały pod złą nazwą. Program uruchomiłby pusty magazyn obok odtworzonego, jakby właśnie wprowadził się na pusty dysk. Pliki były na miejscu, tylko aplikacja szukała ich pod inną nazwą. Raport z kopiowania nie sprawdzał tej zgodności.

Usunąłem błędy, a po przebudowie skryptu kopii powtórzyłem ćwiczenie 22 sierpnia 2026 roku. Chciałem sprawdzić, czy poprawki przetrwały zmianę sposobu przygotowania kopii. Przetrwały wszystkie cztery. Rozszerzyłem też próbę: zamiast wcześniejszych 3 baz odtworzyłem 7 i uruchomiłem aplikację.

Próby nie kończę na komunikacie „baza odtworzona”. Czekam na poprawną odpowiedź aplikacji. Dopiero przy jej uruchomieniu dane, konta, hasła i ustawienia muszą zadziałać razem. Gdybym zatrzymał się przy przywróceniu bazy, mógłbym przeoczyć choćby brak dostępu dla programu. Tabela pokazuje czas aż do tej odpowiedzi, bez sprawdzania wszystkich funkcji aplikacji.

Etap próby z 22 sierpnia 2026 roku	Czas
Pobranie kopii — 1,26 GB	117 s
Rozpakowanie i odszyfrowanie	około 21 s
Uruchomienie bazy, przywrócenie kont i 4 baz	około 27 s
Odtworzenie 3 pozostałych aplikacji z bazami	około 44 s
Uruchomienie aplikacji do pierwszej poprawnej odpowiedzi	około 12 s
Łącznie	około 220 s, czyli około 3,7 min

Ponad połowę czasu zajęło samo pobranie kopii. Dlatego zegar włączam już przy pobieraniu. Start przy rozpakowaniu dałby ładniejszy wynik, ale pominąłby najdłuższe czekanie. W awarii musiałbym przecież najpierw zdobyć kopię, zanim zacznę z niej odzyskiwać dane. Ten pomiar dotyczy przygotowanego komputera; nie obejmuje instalacji systemu.

Podczas sierpniowej próby znalazłem też błąd w samym narzędziu ratunkowym. Skrypt uruchomiony omyłkowo na działającym komputerze nadpisałby bieżącą konfigurację starszą wersją z kopii. Miał pomagać po awarii, a potrafiłby dołożyć własną. Poprawiłem go: dziś sam sprawdza, gdzie działa, zanim nadpisze konfigurację. Pamięć o tym, na którym komputerze pracuję, przestaje być jedynym zabezpieczeniem. Podczas awarii mam już wystarczająco dużo rzeczy do zapamiętania.

Automat co tydzień

Pomiędzy pełnymi próbami automat co tydzień odtwarza kolejną z pięciu baz z najnowszej kopii, osobno od tej używanej na co dzień. Każda wraca do sprawdzenia co pięć tygodni. Wybrałem stałą kolejność: losowanie mogłoby omijać którąś bazę tygodniami, a ja nie wiedziałbym z góry, kiedy przyjdzie na nią pora. Przy sprawdzaniu po kolei żadna nie zostaje zapomniana.

Automat korzysta ze skryptu wyjętego z samej kopii. To istotny szczegół: poprawiona wersja na dysku mogłaby zadziałać, choć ta zapisana w kopii nadal miałaby błąd. Chcę sprawdzać zestaw, którego rzeczywiście użyłbym w awarii.

Dlatego nie podmieniam skryptu na nowszy przed próbą. Kopia musi oddać dane przy użyciu dołączonego narzędzia. Wynik mówi wtedy coś także o tym narzędziu, a nie tylko o mojej umiejętności ręcznego wyciągnięcia danych z plików.

Jednorazową bazę do próby automat uruchamia z tego samego obrazu co baza używana na co dzień, czyli z tej samej wersji oprogramowania i dodatków. Jedna z baz bez swojego rozszerzenia w ogóle by się nie odtworzyła. Dzięki temu brak dodatku w próbie nie udaje błędu samej kopii.

Sam fakt, że baza wystartowała, niewiele mówi: pusta też potrafi działać. Dla każdej ustaliłem więc minimalną liczbę tabel i osobną kontrolę treści, dobraną do tego, co w niej ważne. W jednej automat liczy dokumenty, w innej zapisane procesy automatyzacji, w kolejnej wpisy o zdjęciach i filmach. Sprawdza w ten sposób, czy wróciła także zawartość, z której korzysta program.

19 września 2026 roku, po wdrożeniu rotacji, przepuściłem przez automat wszystkie pięć baz na kopii z tej nocy. Wszystkie pięć wróciło, a próby trwały od 14 do 47 sekund na bazę. Sprawdziłem też, czy kontrola potrafi zgłosić porażkę: przy celowo zawyżonym progu ćwiczenie nie przeszło. Automat nadal nie uruchamia aplikacji, więc jego czasu nie porównuję z czasem pełnego ćwiczenia.

Po każdej próbie automat niszczy odszyfrowane hasła, żeby nie zostały na dysku. Ręczne testy tego dnia wywołały alarm o masowym kasowaniu danych: moje zabezpieczenie wykrywające podejrzane zachowania wzięło mnie za intruza, choć automatu się nie czepia.

Zyskuję za to regularną odpowiedź na pytanie, czy z bieżącej kopii nadal wracają dane. Pełną próbę powtarzam po każdej zmianie skryptu kopii, po dodaniu bazy i nie rzadziej niż co pół roku. Poprzedni wynik nie mógł sprawdzić nowej bazy ani zmian, które zrobiłem później. Automat podtrzymuje kontrolę pomiędzy ćwiczeniami, a pełna próba sprawdza także to, czego on nie obejmuje.

Pełne odtworzenie od zera, na nowym sprzęcie i z instalacją systemu, zaplanowałem wraz z rozbudową o nowe maszyny; po tej próbie uzupełnię tekst o wynik.