Jak AI pilnuje kopii zapasowych w Veeam i mówi, czy firma ma z czego się odtworzyć?

Tak, AI może każdego rana sprawdzić, czy kopie zapasowe w Veeam Backup & Replication, Proxmox Backup Server i Synology Active Backup przebiegły poprawnie, i powiedzieć właścicielowi oraz informatykowi jednym zdaniem, co się udało, a co nie. Żeby to działało, nie potrzeba osobnej platformy monitoringowej ani dodatkowych licencji: wystarczy połączenie z API systemu kopii, prosty automat uruchamiany co rano i kilka reguł, które zamieniają surowe wyniki zadań na zrozumiałą informację. Firma dowiaduje się, że ma z czego się odtworzyć, albo dowiaduje się o problemie zanim problem stanie się katastrofą.

Firma miała kopie zapasowe. Tylko nikt nie czytał maili od Veeam

Typowa historia wygląda tak. Informatyk skonfigurował Veeam Backup & Replication kilka lat temu, zadania backup działają w nocy, Veeam wysyła codzienny raport mailowy. Problem polega na tym, że tych maili nikt nie czyta. Trafiają do folderu "Powiadomienia" albo do wspólnej skrzynki helpdesk, gdzie toną w zgłoszeniach użytkowników.

Przez kilka miesięcy jedno zadanie kończy się z ostrzeżeniem "Warning: unable to truncate transaction logs on SQL Server". Nikt nie reaguje, bo to tylko ostrzeżenie, kopia technicznie się powiodła. Potem zadanie zaczyna kończyć się błędem. Kiedy pada dysk i firma potrzebuje odtworzyć serwer plików, okazuje się, że ostatnia dobra kopia ma trzy miesiące. Dane są, ale dane sprzed kwartału. Taki scenariusz zdarza się realnie, nie tylko w szkoleniach z bezpieczeństwa.

AI nie zastępuje dobrego administratora. Robi coś innego: czyta to, co administrator powinien czytać, ale nie czyta, bo codzienne przeglądanie raportów z Veeam jest nudne i schodzi na dalszy plan. AI się nie nudzi.

Jak AI sięga do danych: REST API w Veeam, tokeny Proxmox, baza Synology

Zanim AI cokolwiek powie, musi mieć skąd brać dane. Każdy z tych systemów udostępnia je inaczej.

Veeam Backup & Replication od wersji 10 ma REST API działające na porcie 9419. Jest udokumentowane przez Veeam i daje dostęp do:

• listy zadań przez endpoint /api/v1/jobs wraz z typem (Backup Job, Replication Job, Backup Copy Job) i ustawionym harmonogramem,
• wyników sesji przez /api/v1/backupSessions, gdzie dla każdej sesji jest pole result z wartością Success, Warning lub Failed oraz pole endTime,
• listy chronionych obiektów i dat ostatnich kopii dla każdej maszyny,
• stanu repozytoriów przez /api/v1/backupInfrastructure/repositories: pola capacityGB, freeSpaceGB i usedSpaceGB.

Żeby połączyć się z API, potrzebne jest konto serwisowe z rolą Veeam Backup Viewer (dostęp tylko do odczytu) i włączone REST API w konsoli Veeam. Token dostępowy generuje się przez POST na endpoint /api/v1/token z loginem i hasłem konta serwisowego.

Veeam ONE, moduł raportowania sprzedawany osobno, ma własne Reporting REST API. Daje dostęp do gotowych raportów: Protected VMs, Unprotected VMs, Repository Capacity Forecast. Można je wywołać programowo i dostać dane w JSON lub CSV. Jeśli firma ma Veeam ONE, część danych wyciągamy stamtąd gotowych, bez budowania własnych zapytań od zera.

Proxmox Backup Server ma REST API na porcie 8007. Autoryzację realizuje przez tokeny API tworzone w sekcji Datacenter > API Tokens, z uprawnieniami DataStore.Audit i Sys.Audit. Z API pobieramy listę datastores z zajętością, historię zadań przez endpoint /api2/json/nodes/{node}/tasks oraz status ochrony klientów. Proxmox Backup Server nie ma tak rozbudowanej warstwy raportowej jak Veeam, więc AI musi więcej przetworzyć z surowych danych zwracanych przez API.

Synology Active Backup for Business to inny przypadek. Synology nie udostępnia oficjalnego publicznego API dla Active Backup. Dane wyciągamy dwoma sposobami: przez bazę MariaDB lokalnie na NAS-ie, do której sięgamy przez SSH kontem z uprawnieniami do schematu activebackup, albo przez cykliczny eksport raportów CSV z konsoli DSM. Przy podejściu z bazą trzeba sprawdzić po każdej aktualizacji DSM, czy struktura tabel się nie zmieniła, bo Synology nie dokumentuje tego schematu oficjalnie.

Czego producenci nie udostępniają przez API: Veeam nie pokazuje pełnych logów wewnętrznych zadań przez REST (pełne logi są w plikach .log na serwerze Veeam). Synology Active Backup nie ma otwartego, wersjonowanego API do warstwy zadań kopii. To ograniczenia, z którymi trzeba się liczyć przy projektowaniu monitoringu.

Co AI wyciąga z systemu i na co patrzy

Z powyższych źródeł budujemy aktualny obraz stanu ochrony danych firmy. Konkretnie wyciągamy:

• nazwę zadania, typ, datę i godzinę ostatniego uruchomienia, wynik sesji (Success, Warning, Failed),
• listę maszyn wirtualnych i serwerów fizycznych objętych każdym zadaniem oraz datę ostatniej udanej kopii dla każdej z nich osobno,
• zajętość repozytoriów: ile GB zajęte, ile wolne, jaka retencja jest ustawiona i ile punktów odtworzenia jest aktualnie dostępnych,
• zadania Backup Copy Job, czyli kopie poza siedzibą: kiedy ostatnia sesja, z jakim wynikiem,
• datę i wynik ostatniego testu Sure Backup, jeśli jest konfigurowany,
• powtarzające się ostrzeżenia przy konkretnych maszynach lub zadaniach.

AI patrzy na rzeczy, które dla człowieka są nudne i przez to człowiek przestaje na nie patrzeć. Trzy dni bez udanej kopii konkretnego serwera. Repozytorium zapełnione powyżej progu alarmowego. Zadanie Backup Copy Job niepowodzenie drugi raz z rzędu. Ostrzeżenie powtarzające się przy tym samym SQL Serverze od tygodnia. Te rzeczy nie są awariami. Właśnie dlatego maile z ostrzeżeniami trafiają do folderu i nikt ich nie otwiera.

Co rano dostaje właściciel, a co informatyk

Tutaj jest ważny podział. Właściciel firmy i informatyk potrzebują innych informacji z tych samych danych.

Właściciel dostaje jedno zdanie, a pod nim ewentualne alerty. Na przykład: "Wczoraj w nocy skopiowały się wszystkie maszyny. Kopia poza siedzibą do repozytorium zdalnego: bez błędów. Jedno ostrzeżenie: serwer SQL-PROD wymaga uwagi informatyka." Albo, w złym scenariuszu: "Uwaga: serwer FILES-01 nie ma udanej kopii od czterech dni. Wymaga działania przed końcem dnia."

Informatyk dostaje konkret. Nazwy zadań zakończonych błędem lub ostrzeżeniem. Treść komunikatu błędu z sesji Veeam. Aktualną zajętość repozytoriów z szacunkiem, kiedy przy obecnym tempie przyrostu zabraknie miejsca. Listę maszyn z brakującymi kopiami i datami ostatnich udanych sesji.

Do tego AI raz w tygodniu przypomina o teście odtworzenia Sure Backup, jeżeli minęło więcej niż 30 dni od ostatniego. W Veeam Sure Backup to osobne zadanie, które uruchamia VM z kopii w izolowanej sieci wirtualnej i weryfikuje, czy system się uruchamia i przechodzi testy dostępności. Bez regularnego Sure Backup kopia może być technicznie kompletna, ale nie dać się odtworzyć przez uszkodzony indeks repozytorium lub problem z dyskiem. Nikt o tym nie myśli, dopóki nie potrzebuje odtwarzać.

Veeam rzuca ostrzeżenia. AI zamienia je na decyzje

"Warning: unable to truncate transaction logs on SQL Server 'ERP-SQL'. Guest processing failed." To nie jest błąd kopii. Kopia się powiodła. Ale baza danych SQL Server rośnie, bo logi transakcyjne nie są czyszczone po sesji backup. Informatyk musi sprawdzić model odzyskiwania bazy i uprawnienia konta Veeam na SQL Serverze: konto musi mieć rolę sysadmin albo uprawnienia do wywołania procedur backupu logów. Bez tego za kilka tygodni dysk bazy może przekroczyć dostępną pojemność.

AI nie zgaduje i nie tłumaczy technikaliów. Mówi wprost: "Zadanie BACKUP-ERP kończy się z ostrzeżeniem dotyczącym logów transakcyjnych na serwerze ERP-SQL. To ostrzeżenie pojawia się czwarty raz z rzędu. Wymaga działania informatyka w tym tygodniu, zanim dysk bazy urośnie ponad dostępną pojemność."

Albo, przy zapełnionym repozytorium: "Repozytorium REPO-MAIN przekroczyło 90 procent pojemności. Przy obecnym tempie przyrostu nowe sesje backup zaczną kończyć się błędem za kilka dni. Potrzebna decyzja: rozszerzenie repozytorium, zmiana polityki retencji albo przeniesienie starszych punktów odtworzenia do archiwum."

Te zdania nie są trudne do napisania. Problem polega na tym, że bez automatyzacji nikt ich nie pisze. Informatyk widzi maila z ostrzeżeniem, myśli "zajmę się tym w wolnej chwili" i odkłada. AI nie odkłada, bo nie ma wolnych chwil.

Raport do audytu i do ubezpieczyciela z danych z Veeam

Coraz więcej firm dostaje pytania od ubezpieczycieli przy polisach cyber: jakie mają polityki backupów, jak często testują odtworzenie, gdzie trzymają kopie poza siedzibą, jak długo przechowują dane. Wymagania audytu wewnętrznego i NIS2 pytają o to samo.

Bez automatyzacji zbieranie tych informacji to kilka godzin pracy: logujemy się do Veeam, klikamy po raportach, kopiujemy do arkusza kalkulacyjnego, formatujemy. Dane mogą być nieaktualne, bo Sure Backup nie był uruchamiany od dwóch miesięcy i nikt nie sprawdzał.

Z AI: pytamy "Przygotuj raport stanu kopii zapasowych na dzisiaj do audytu" i dostajemy dokument z danymi pobranymi w tej chwili z systemu. Pole "Data ostatniego testu Sure Backup" pochodzi z bazy Veeam, nie z pamięci informatyka. Raport pokazuje też białe plamy: maszyny, które nie są objęte żadnym zadaniem backup. Veeam ONE ma gotowy raport Unprotected VMs, ale do tej pory nikt go nie uruchamiał, bo nie było kiedy.

Taki raport można wygenerować w dowolnym momencie, nie tylko przed audytem. I można go porównać z raportem sprzed miesiąca, żeby zobaczyć, czy stan ochrony danych poprawił się czy pogorszył.

Od czego zaczynamy

Żeby AI mogło czytać dane z Veeam, potrzebujemy kilku rzeczy:

• Veeam Backup & Replication z włączonym REST API (w konsoli: Configuration > REST API, domyślnie port 9419) i kontem serwisowym z rolą Veeam Backup Viewer,
• dostęp sieciowy z serwera automatu do portu 9419 na serwerze Veeam,
• jeśli firma ma Veeam ONE: osobne dane dostępowe do jego Reporting REST API,
• listę repozytoriów i zadań, które mają być monitorowane (kopie środowisk testowych i dev często pomijamy w raporcie do właściciela).

Przy Proxmox Backup Server: token API z uprawnieniami DataStore.Audit, dostęp sieciowy do portu 8007.

Przy Synology Active Backup: dostęp SSH do NAS-a z kontem uprawnionym do schematu bazy aktywnego backupu albo skonfigurowany cykliczny eksport raportów CSV z konsoli DSM.

Typowo to jedno spotkanie techniczne z informatykiem firmy. Ustalamy, jakie maszyny i repozytoria mają być pilnowane, kto dostaje poranne powiadomienie i w jakiej formie (mail, wiadomość na Teams lub Slack, SMS przy poważnym alercie), jakie progi mają wyzwalać reakcję. Potem automat działa codziennie sam, bez angażowania nikogo.

Jeśli chcecie zobaczyć, jak taki monitoring wygląda w praktyce i co konkretnie AI wyciąga z Waszego środowiska backupów, zapraszamy na 15 minut rozmowy. Możecie też zajrzeć na realne wdrożenia u firm, które już sprawdzają stan swoich kopii zapasowych przez AI zamiast przez ignorowane maile od Veeam.