Opublikowano 30 września 2026 · 3 min czytania
Pusty log znaczył dwie rzeczy naraz. Jedną dobrą, jedną fatalną
Skrypt pilnujący mojej kopii zapasowej trzymanej poza domem ma dwie ścieżki. Pierwsza: „kopia jest stara, robię nową" — zostawia wpis w logu. Druga: „kopia jest aktualna, nie robię nic" — kończyła się bez śladu.
Przez kilka miesięcy nie widziałem w tym problemu. Zobaczyłem 16 sierpnia 2026, kiedy przy przeglądzie całego zestawu kopii zajrzałem do tego logu i zrozumiałem, na co właściwie patrzę.
Dwie sytuacje, jeden ekran
Pusty log znaczył jednocześnie dwie rzeczy:
- Nie było potrzeby robić kopii, bo poprzednia jest świeża.
- Automat w ogóle nie wystartował.
Pierwsza jest w porządku. Druga oznacza, że od nieznanego dnia nie mam kopii poza domem — czyli tej jednej, która przeżywa pożar i kradzież. Dzieli je wszystko. Na ekranie nie dzieli ich nic.
To jest sedno rzeczy, którą nazwałem sobie fałszywym zerem: zdrowy wynik i nieudany pomiar dają tę samą liczbę. Zero błędów. Zero wpisów. Zero alertów.
Fałszywe zero jest groźniejsze od zwykłego błędu, bo zero błędów to dokładnie ten wynik, którego się chce. Nikt nie drąży dobrej wiadomości. Awaria pomiaru przebiera się za sukces mierzonej rzeczy i może tak stać miesiącami — dokładnie tyle, ile stała u mnie.
Naprawa nie polega na dokładniejszym mierzeniu
Polega na dorzuceniu trzeciego stanu. Nie „w porządku / awaria", tylko „w porządku / awaria / nie wiem".
Od 16 sierpnia skrypt zapisuje każde uruchomienie, także te, które nic nie robią. Jedna linijka na przebieg, również gdy przebieg polega na stwierdzeniu, że nie ma nic do roboty. Pusty log ma dziś jedno znaczenie: automat nie ruszył.
Ten sam wzorzec wrócił tego samego dnia w drugim miejscu. Kontrola stanu dysków w serwerze domowym wymaga narzędzia, które czyta je tylko z uprawnieniami administratora — a zadanie w tle nie ma jak podać hasła. Do czasu, aż to skonfigurowałem, skrypt nie udawał, że dyski są zdrowe. Pisał ?? SMART niedostępny i nie podnosił przy tym alarmu. Trzeci stan, ta sama zasada: brak odczytu to nie jest dobry odczyt.
Czego nie zrobiłem
Nie dałem zadaniu w tle pełnych uprawnień administratora, choć to była najkrótsza droga i kusiła najbardziej — jedna linijka i problem znika. Zamiast tego pozwolenie obejmuje wyłącznie narzędzie do odczytu stanu dysków, które nic nie zapisuje. Odczyt idzie w trybie, który nigdy nie pyta o hasło, więc brak konfiguracji nie zawiesza zadania w tle na wieki, tylko daje ten uczciwy znak zapytania.
Nie zrobiłem też alarmu z samego „nie wiem". Powiadomienie przy każdej niedostępności pomiaru nauczyłoby mnie ignorować powiadomienia — a wtedy przestałbym czytać także te prawdziwe.
To działa też w drugą stronę
Zepsuty pomiar potrafi wyprodukować fałszywy alarm, i tego samego dnia dostałem taki prezent. Przy pierwszym podejściu do testu odtworzenia kopii wyszły 22 rzekomo brakujące pliki jednego z pakietów biurowych. Nie brakowało ani jednego. Zamontowana była starsza migawka z godziny 12:06 zamiast najnowszej, a ja porównywałem stan sprzed kilku godzin ze stanem obecnym.
Liczba 22 była prawdziwa. Odpowiadała tylko na inne pytanie niż to, które zadałem.
Właściwy test, zrobiony na najnowszej kopii, wypadł tak: 54 pliki, 52 zgodne co do bajta, 0 brakujących. Dwa rozbieżne to pliki robocze bazy zdjęć, które zmieniają się w trakcie pracy — rozbieżność jest tam normalna. Porównanie całej kopii systemowej wykazało 26 różnic, wszystkie w katalogach budowania, świadomie wykluczonych. Zero różnic w danych, które są moje.
Trzy rzeczy, które z tego biorę
Zero to nie jest wynik, tylko dwa różne wyniki o tym samym wyglądzie. Zanim uwierzę w zero, muszę wiedzieć, czy pomiar się odbył.
Każdy automat potrzebuje trzeciego stanu. „Nie wiem" wypowiedziane wprost jest warte więcej niż fałszywe „w porządku" i tańsze niż fałszywy alarm.
Sprawdzaj, na co właściwie patrzysz. Moje 22 brakujące pliki nie istniały. Zanim wyciągniesz wniosek z liczby, upewnij się, że pochodzi z tego źródła, o którym myślisz — bo liczba pomyli się rzadko, a pytanie bardzo często.
Wszystkie liczby pochodzą z przeglądu i testu odtworzenia kopii przeprowadzonych 16 sierpnia 2026 na moim własnym sprzęcie. Nie ma tu ani jednej liczby przykładowej.

Patryk Piecyk
Warszawa · na etacie od 10.2026 · rozwój w stronę ERP/SAP i AI
Przez 7,5 roku pracowałem w niemieckiej firmie, pięć lat prowadząc jej biuro: zamówienia, faktury, reklamacje, ERP. Od czerwca 2026 buduję własne narzędzia do tej samej roboty — nie jestem programistą z wykształcenia, kod powstaje w parze z asystentem AI, a projekt, decyzje i testy są moje. Te notatki opisują, co się w tych systemach zepsuło i co z tego wyszło.
Masz pytanie do tego tekstu?
Napisz do mnie →