Kopia zapasowa była. Odtworzenie się nie udało

10 października 2026 w kontrolowanym teście powstały trzy archiwa ZIP. Jedno zawierało komplet czterech plików, drugie pomijało konfigurację, trzecie zostało celowo uszkodzone. Niepełne archiwum rozpakowało się bez błędu. Brak wyszedł dopiero przy porównaniu wyniku z listą plików źródłowych.

To prosty eksperyment wykonany na potrzeby tego tekstu, na syntetycznych danych. Nie opisuję awarii własnego dysku ani skuteczności konkretnego komercyjnego programu do backupu. Chodzi o różnicę między posiadaniem archiwum a odtworzeniem tego, co miało się w nim znaleźć.

Co dokładnie zostało sprawdzone

Skrypt uruchomiono w Windows, z mechanizmem ZIP biblioteki .NET. Zestaw zawierał notatkę tekstową, plik CSV, ustawienia JSON i drugi plik tekstowy reprezentujący projekt. Wszystkie powstały na potrzeby próby. Nie użyto danych klientów, prawdziwych haseł ani prywatnych dokumentów.

Każde archiwum odtwarzano do osobnego katalogu. Po rozpakowaniu skrypt sprawdzał obecność oczekiwanych plików i porównywał ich sumy SHA-256 z oryginałami. Kopia niepełna powstała z celowo pominiętym plikiem ustawień. Uszkodzoną przygotowano przez ucięcie około połowy bajtów prawidłowego archiwum.

Próba	Rozpakowanie	Pliki zgodne z oryginałami
Pełne archiwum	Powodzenie	4 z 4
Pominięty plik ustawień	Powodzenie	3 z 4
Ucięte archiwum	Błąd	0 z 4

W trzeciej próbie nie odzyskano plików tą metodą. Nie znaczy to, że każdy uszkodzony ZIP daje ten sam wynik albo że specjalistyczne odzyskiwanie byłoby niemożliwe. Sprawdzony został konkretny uszkodzony plik i konkretna metoda odtwarzania.

Brak błędu był prawdziwy, kompletność już nie

Najciekawszy wynik dała druga próba. Rozpakowanie zakończyło się poprawnie, bo archiwum było technicznie poprawne. Zawierało dokładnie te trzy pliki, które do niego trafiły. Narzędzie nie miało podstaw wiedzieć, że oczekiwałem również czwartego.

Ten drobiazg zmienia sposób czytania raportu z backupu. Zielony status może oznaczać, że zadanie wykonało skonfigurowane czynności. Jeżeli wybór katalogów był niepełny, powodzenie operacji tego nie naprawi. Test przywracania potrzebuje oczekiwanego wyniku, a nie tylko przycisku „rozpakuj”.

Nie twierdzę, że każde oprogramowanie do backupu ogranicza się do takiej kontroli. W tym eksperymencie sprawdzam sam mechanizm błędu: pominięcie danych przed utworzeniem kopii może pozostać niewidoczne przy późniejszym, poprawnym odczycie archiwum.

Suma kontrolna też ma granicę

Zgodność SHA-256 potwierdziła w teście zgodność bajtów odtworzonych plików z przygotowanymi oryginałami. Nie sprawdzaliśmy jednak, czy prawdziwa aplikacja potrafi uruchomić się z odzyskaną bazą, czy ma wymagane zależności albo dostęp do klucza szyfrującego.

Nie mierzono również czasu przywrócenia dużego zbioru. Cztery małe pliki nie opisują odtwarzania terabajtów ani pracy pod presją przerwy w firmie. Przy realnym systemie do listy oczekiwań dopisałbym jego uruchomienie i wykonanie konkretnej czynności na odzyskanych danych. Sam komplet plików byłby dopiero etapem pośrednim.

Co zmienić w następnym sprawdzeniu kopii

CISA zaleca testowanie dostępności i integralności backupów oraz trzymanie chronionych kopii poza zasięgiem atakowanego środowiska. Wskazuje też znaczenie kopii offline i szyfrowania. To osobny problem od poprawności ZIP-a: kopia może być czytelna, lecz niedostępna po utracie konta lub zniszczona razem z danymi roboczymi. Przy historiach takich jak LockBit pytanie o zasięg przejętych uprawnień dotyczy również miejsca przechowywania backupu.

Przy własnym teście zacząłbym od wypisania, co ma wrócić. Potem odtworzyłbym dane do innego miejsca, bez nadpisywania oryginałów, i sprawdził rezultat. Jeśli kopia jest zaszyfrowana, próba musi uwzględniać dostęp do klucza także wtedy, gdy podstawowy komputer przestaje działać.

W tym małym teście wystarczyła lista czterech nazw, żeby wykryć problem niewidoczny przy rozpakowaniu. Przy następnym sprawdzaniu backupu warto mieć własną taką listę. I faktycznie spróbować odzyskać zapisane na niej rzeczy.

Źródła i metodyka

• Skrypt przeprowadzonego testu i zapis wyników z 10 października 2026. Skrypt tworzy wyłącznie nowe katalogi testowe w katalogu tymczasowym; nie usuwa ich automatycznie.
• CISA: #StopRansomware Guide, zalecenia dotyczące kopii zapasowych

Zdjęcie ilustracyjne: Vincent Botta / Unsplash. Pokazany dysk nie uczestniczył w teście.