Jak monitorować backupy,
aby wykryć problem przed awarią?

Wykonywanie kopii zapasowych to dopiero początek. Równie ważne jest sprawdzanie, czy backup rzeczywiście działa, obejmuje właściwe dane i pozwoli przywrócić system w wymaganym czasie.

W wielu firmach zadania backupowe zostały skonfigurowane kilka lat temu i od tamtej pory działają bez większego nadzoru. Administrator otrzymuje wiadomość tylko wtedy, gdy aplikacja sama zgłosi błąd. Jeżeli zadanie w ogóle się nie uruchomi, powiadomienie nie zostanie wysłane albo repozytorium przestanie być dostępne, problem może pozostać niezauważony przez wiele dni.

Najgorszy moment na sprawdzanie jakości backupu to dzień awarii serwera, ataku ransomware albo przypadkowego usunięcia danych.

Dlatego monitoring kopii zapasowych powinien być integralną częścią całej strategii backupowej.

Dlaczego zielony status backupu nie wystarcza?

Status „success" oznacza zazwyczaj tylko tyle, że zadanie zakończyło się bez błędu rozpoznanego przez oprogramowanie. Nie musi potwierdzać, że:

• -skopiowano wszystkie wymagane dane,
• -baza danych jest spójna,
• -backup trafił do właściwego repozytorium,
• -kopia off-site została wykonana,
• -pliki można odczytać,
• -znane są klucze szyfrujące,
• -odtworzenie zmieści się w wymaganym RTO,
• -aplikacja będzie działała po przywróceniu.

Przykładowo zadanie może zakończyć się poprawnie, ale skopiować pusty katalog po zmianie ścieżki. Backup maszyny wirtualnej może się wykonać, mimo że natywna kopia bazy SQL nie działa od kilku dni. Synchronizacja do drugiej lokalizacji może nie obejmować najnowszych punktów przywracania.

Dlatego trzeba monitorować nie tylko wynik zadania, lecz cały łańcuch ochrony danych. Więcej o tym, dlaczego kopie zawodzą, w artykule Dlaczego backup nie gwarantuje odzyskania danych?

Jakie elementy powinien obejmować monitoring backupów?

Uruchomienie zadania

System powinien wykryć zarówno nieudany backup, backup zakończony ostrzeżeniem, zadanie, które w ogóle się nie uruchomiło, jak i zadanie, które nadal działa mimo przekroczenia typowego czasu.

Brak komunikatu nie oznacza sukcesu.

Jeżeli backup ma wykonywać się codziennie o godzinie 22:00, monitoring powinien oczekiwać potwierdzenia jego zakończenia w ustalonym przedziale. Po przekroczeniu tego czasu powinien powstać alert.

Czas ostatniego udanego backupu

To jedna z najważniejszych metryk. Nie powinna być jednak porównywana z uniwersalną granicą 24 godzin. Limit musi wynikać z RPO. Przykładowo:

• -system pomocniczy może mieć RPO 24 godziny,
• -serwer plików może wymagać kopii co 4 godziny,
• -baza ERP może wymagać backupu logu co 15 minut,
• -krytyczny system transakcyjny może korzystać z jeszcze krótszego RPO.

Alert powinien pojawić się przed przekroczeniem założonego RPO, a nie dopiero długo po nim.

Czas trwania zadania

Nagła zmiana czasu wykonywania kopii może oznaczać problem. Niepokojące są zarówno backup trwający znacznie dłużej niż zwykle, jak i zadanie kończące się podejrzanie szybko.

Wydłużenie może wskazywać na problemy ze storage, wolną sieć, zwiększony przyrost danych, przeciążenie źródła lub równoległe zadania. Wyjątkowo krótki czas może oznaczać, że część danych została pominięta albo źródło nie było dostępne.

Najlepiej porównywać wynik z typowym czasem dla danego systemu, a nie z jedną wartością ustaloną dla całego środowiska.

Ilość przesłanych i chronionych danych

Warto obserwować wielkość źródła i backupu, ilość zmienionych danych, liczbę chronionych maszyn i baz, współczynnik deduplikacji oraz liczbę punktów przywracania.

Nagły spadek ilości danych może oznaczać pominięcie katalogu, wyłączenie maszyny z zadania albo błąd integracji. Nagły wzrost może wskazywać na masowe zmiany plików, szyfrowanie danych, wyłączenie mechanizmu przyrostowego lub utworzenie dużej ilości nowych danych.

Nie każda zmiana jest awarią, dlatego warto analizować trendy i porównywać je z historią.

Dostępność repozytorium

Monitoring powinien sprawdzać, czy repozytorium odpowiada, jest zamontowane, można na nim zapisywać, certyfikat połączenia jest ważny i czy urządzenie nie zgłasza błędów sprzętowych.

Sam ping do serwera backupowego nie wystarczy. Host może odpowiadać, mimo że datastore jest niedostępny lub system plików został zamontowany w trybie read-only.

Wolne miejsce i tempo jego zużycia

Alert na poziomie 95% wolumenu często pojawia się za późno. Lepiej monitorować bieżące wykorzystanie, średni przyrost dzienny, przewidywaną datę zapełnienia, skuteczność pruning i Garbage Collection oraz ilość danych oczekujących na synchronizację. Dzięki prognozowaniu można zaplanować rozbudowę repozytorium przed wystąpieniem problemu.

Retencja

Monitoring powinien potwierdzać, że firma posiada wymaganą liczbę punktów przywracania: kopie godzinowe z ostatniej doby, dzienne z ostatnich 14 dni, tygodniowe, miesięczne i punkty archiwalne.

Zadanie może wykonywać się poprawnie, ale błędnie skonfigurowany pruning może usuwać kopie zbyt szybko. Warto również sprawdzać najstarszy dostępny punkt przywracania, szczególnie gdy firma chce chronić się przed późno wykrytym ransomware lub uszkodzeniem danych.

Kopia off-site

Lokalny backup nie jest pełną strategią ochrony. Monitoring powinien niezależnie kontrolować wykonanie kopii lokalnej, synchronizację off-site, opóźnienie pomiędzy lokalizacjami, stan docelowego repozytorium i wynik weryfikacji po stronie zdalnej.

Sukces lokalnego backupu nie oznacza sukcesu synchronizacji do drugiej lokalizacji.

Weryfikacja integralności

Narzędzia backupowe mogą sprawdzać sumy kontrolne, spójność bloków, manifesty i stan łańcucha backupów. Takie testy pomagają wcześniej wykryć uszkodzenia repozytorium. Nie zastępują jednak pełnego restore - potwierdzają integralność danych, ale nie gwarantują, że system operacyjny, baza i aplikacja uruchomią się poprawnie.

Testy przywracania

Najważniejszym potwierdzeniem jakości backupu jest odtworzenie danych. Test może mieć kilka poziomów:

Nie każdy rodzaj testu trzeba wykonywać co tydzień. Przykładowo: automatyczna weryfikacja repozytorium regularnie, test pojedynczego pliku co miesiąc, test krytycznej bazy co miesiąc lub kwartał, pełny test ERP raz na kwartał, scenariusz DR raz lub dwa razy w roku.

Monitoring całego łańcucha backupu

Dobra strategia nie kończy się na jednym zadaniu. Przykładowy łańcuch może wyglądać następująco:

1. 1 aplikacja wykonuje natywny backup bazy,
2. 2 plik trafia na wydzielony wolumen,
3. 3 maszyna jest kopiowana do lokalnego repozytorium,
4. 4 backup jest synchronizowany off-site,
5. 5 repozytorium wykonuje weryfikację,
6. 6 okresowo uruchamiany jest test restore.

Każdy etap powinien posiadać osobny status. Jeżeli monitorowany jest wyłącznie ostatni punkt, może się okazać, że do repozytorium poprawnie kopiowany jest plik .bak, który nie był aktualizowany od tygodnia.

Trzy poziomy monitorowania backupu

Jak monitorować Proxmox Backup Server?

W środowisku Proxmox warto kontrolować kilka warstw. O samym PBS pisaliśmy szerzej w artykule Czy naprawdę warto wdrożyć PBS?

Zadania backupowe Proxmox VE: status backupu każdej maszyny, maszyny wyłączone z harmonogramu, czas ostatniej udanej kopii, długość zadania, ilość przesłanych danych oraz ostrzeżenia QEMU Guest Agent.

Proxmox Backup Server:

PBS posiada system powiadomień i notification matchers, który pozwala kierować komunikaty do określonych odbiorców zależnie od typu i ważności zdarzenia. Warto jednak dodatkowo zbierać dane w niezależnym systemie, takim jak Zabbix, Prometheus lub inna platforma monitoringu. Dzięki temu awaria samego PBS nie blokuje wszystkich alarmów.

Natywne backupy aplikacji: osobno trzeba monitorować backup SQL Server, PostgreSQL, kopie systemu ERP, dumpy aplikacji i eksporty konfiguracji. Zielona kopia VM nie oznacza, że backup logu SQL działa poprawnie.

Jak monitorować Veeam?

W środowisku Veeam warto kontrolować Backup Jobs, Backup Copy Jobs, repozytoria, proxy, hardened repository, retencję, health checks, SureBackup, błędy sesji i licencje.

Veeam ONE może zapewnić dodatkowe raportowanie, alarmy, analizę trendów oraz kontrolę środowiska backupowego. SureBackup pozwala automatycznie uruchamiać maszyny w odizolowanym środowisku i wykonywać testy, ale zakres weryfikacji powinien być dostosowany do aplikacji - sam start systemu nie musi potwierdzać działania ERP albo bazy.

Jak monitorować BorgBackup, Restic i skrypty?

W prostszych środowiskach dobrze sprawdza się model heartbeat. Można wykorzystać Healthchecks.io, własny endpoint monitoringu, Zabbix Sender, Prometheus Pushgateway lub integrację z systemem ticketowym.

Skrypt powinien wysyłać osobny status dla rozpoczęcia zadania, sukcesu, błędu, czasu wykonania, ilości danych oraz wyniku prune i check. Wysyłanie sygnału wyłącznie po sukcesie pozwala wykryć brak wykonania, ale nie pokazuje przyczyny problemu - najlepiej łączyć heartbeat z logiem i kodem zakończenia.

Najważniejsze metryki

Czy wskaźnik sukcesu powinien wynosić 99%?

Sam procent udanych zadań może być mylący. Przy tysiącu backupów rocznie skuteczność 99% oznacza dziesięć nieudanych kopii. Nie wiadomo również, czy błędy dotyczyły testowych maszyn, czy krytycznego systemu ERP.

Lepsze wskaźniki to liczba systemów bez aktualnej kopii, czas przekroczenia RPO, liczba nieobsłużonych alertów, liczba nieudanych testów restore, czas naprawy problemu, zgodność retencji i dostępność kopii off-site.

Celem nie jest uzyskanie ładnego procentu, lecz pewność, że krytyczne dane pozostają możliwe do odtworzenia.

Jak ustawić alerty, aby nie powodowały chaosu?

Zbyt duża liczba komunikatów prowadzi do ignorowania alarmów. Każdy alert powinien zawierać nazwę systemu i zadania, czas ostatniego sukcesu, oczekiwane RPO, komunikat błędu, repozytorium, priorytet, właściciela zgłoszenia oraz link do dokumentacji lub panelu.

Nie każde nieudane zadanie wymaga telefonu w środku nocy. Priorytet musi wynikać z krytyczności systemu i czasu pozostałego do przekroczenia RPO.

Eskalacja alertów

Samo wysłanie wiadomości nie rozwiązuje problemu. Proces powinien uwzględniać:

1. 1 utworzenie zgłoszenia,
2. 2 przypisanie właściciela,
3. 3 potwierdzenie przyjęcia,
4. 4 eskalację po określonym czasie,
5. 5 rozwiązanie przyczyny,
6. 6 wykonanie kolejnej poprawnej kopii,
7. 7 zamknięcie zgłoszenia.

Alert nie powinien zostać uznany za rozwiązany tylko dlatego, że administrator kliknął „acknowledge". Potwierdzeniem naprawy jest poprawny backup, prawidłowa synchronizacja albo udany test odtworzenia.

Dashboard backupów i raport dla zarządu

Dobry dashboard powinien w pierwszej kolejności pokazywać wyjątki: systemy bez aktualnej kopii, przekroczone RPO, nieudane zadania, błędy weryfikacji, nieaktualne kopie off-site, repozytoria zagrożone zapełnieniem i systemy bez aktualnego testu restore. Dopiero niżej trendy pojemności, czasy zadań i statystyki transferu. Administrator powinien po otwarciu dashboardu od razu zobaczyć, które systemy wymagają działania.

Zarząd nie potrzebuje listy wszystkich kodów błędów. Raport powinien odpowiedzieć na pytania: czy wszystkie systemy krytyczne są chronione, czy spełniamy wymagane RPO, kiedy ostatnio testowaliśmy restore, czy kopia znajduje się poza główną lokalizacją, jakie ryzyka pozostają otwarte i jakie działania są potrzebne. Można wykorzystać prosty podział: zielony (wymagania spełnione), żółty (ryzyko lub zbliżający się problem), czerwony (brak aktualnej albo sprawdzonej kopii).

Najczęstsze błędy w monitorowaniu backupów

Alarm wysyłany wyłącznie po błędzie nie wykryje zadania, które nie zostało uruchomione. Powiadomienia wysyłane przez chroniony serwer mogą nie dotrzeć po jego awarii. A gdy jeden e-mail trafia do kilku osób, każdy zakłada, że problem rozwiąże ktoś inny.

Jak wdrożyć monitoring backupów krok po kroku?

1. 1 Przygotuj inwentaryzację: serwery, maszyny wirtualne, bazy, aplikacje, Microsoft 365, urządzenia, repozytoria. Nie da się kontrolować kompletności backupu bez listy systemów, które powinny być chronione.
2. 2 Ustal krytyczność: dla każdego systemu określ właściciela biznesowego, RPO, RTO, retencję i wymagany poziom testów.
3. 3 Zmapuj cały łańcuch: źródło, zadanie, repozytorium lokalne, kopia off-site, retencja, weryfikacja, restore.
4. 4 Zintegruj narzędzia: API, logi, webhooki, e-mail parser, heartbeat, eksportery, natywne integracje.
5. 5 Ustaw alerty według RPO: próg powinien być indywidualny dla każdego systemu.
6. 6 Dodaj testy restore: rozpocznij od prostych testów, a następnie przejdź do odtwarzania całych aplikacji.
7. 7 Wdróż eskalację: każdy alert musi mieć właściciela i czas reakcji.
8. 8 Raportuj trendy: analizuj pojemność, liczbę błędów, czasy restore i zgodność z RPO.

Podsumowanie

Skuteczne monitorowanie backupów nie polega na odbieraniu wiadomości „backup zakończony sukcesem". Trzeba kontrolować, czy zadanie się uruchomiło, kiedy zakończył się ostatni poprawny backup, czy spełnione jest RPO, czy repozytorium jest dostępne, czy retencja działa zgodnie z planem, czy kopia off-site jest aktualna, czy dane przeszły weryfikację i czy można je rzeczywiście przywrócić.

Najważniejszym wskaźnikiem nie jest liczba zielonych zadań. Jest nim zdolność firmy do odzyskania właściwych danych w wymaganym czasie.

W PRO-Admin monitoring backupów traktujemy jako część całego systemu ciągłości działania. Łączymy dane z Proxmox Backup Server, Veeam, natywnych backupów baz i repozytoriów off-site. Alerty porównujemy z wymaganym RPO, automatycznie tworzymy zgłoszenia i regularnie testujemy odtwarzanie. Dzięki temu problem z kopią jest wykrywany podczas zwykłego dnia pracy, a nie dopiero podczas poważnej awarii.