„Mamy backup, hosting robi nam snapshot co noc." To zdanie słyszymy w co drugiej rozmowie o zabezpieczeniu ERP. I w co drugiej okazuje się, że tego backupu nie ma — jest tylko obraz maszyny, z którego bazy nie da się porządnie postawić.
Baza danych to nie jest zwykły plik. Kiedy Comarch Optima, enova365, Subiekt czy Microsoft Dynamics AX pracują, w środku bazy dzieją się rzeczy, których nie widać z poziomu systemu operacyjnego: otwarte transakcje, bufory pamięci, log transakcyjny, który zapisuje zmiany zanim trafią do plików danych. Gdy hipernadzorca robi snapshot maszyny w losowym momencie, łapie ten stan „w połowie zdania". Po odtworzeniu SQL Server podnosi się, uruchamia mechanizm recovery i — jeśli ma szczęście — dojdzie do spójnego stanu. Jeśli nie ma szczęścia, baza wchodzi w tryb SUSPECT i musisz dzwonić do producenta ERP.
To nie jest teoria. To scenariusz, który u naszych klientów zdarza się co roku, głównie po awarii zasilania albo po ransomware.
Co naprawdę robi „snapshot serwera"
Snapshot maszyny wirtualnej w Hyper-V, VMware czy Proxmoxie to zamrożenie stanu dysku (i opcjonalnie RAM-u) w konkretnej chwili. Z punktu widzenia hipernadzorcy — bardzo wygodne. Z punktu widzenia bazy danych — to jest tak, jakby ktoś nagle wyłączył prąd.
Dobrej klasy hipernadzorcy potrafią współpracować z aplikacjami przez VSS (Volume Shadow Copy Service) na Windowsie. Wtedy przed zrzutem system prosi SQL Server, żeby „wyprowadził się na chwilę" — zamknął otwarte transakcje, zrzucił bufory na dysk. To się nazywa application-consistent snapshot i to jest jedyny snapshot, o który warto walczyć.
Problem w tym, że w praktyce w małych firmach to często nie działa. Powody są proste:
- Kopia jest robiona z poziomu VPS-a u hostingodawcy, który VSS w ogóle nie wywołuje.
- VSS writer dla SQL Servera jest wyłączony po jakiejś aktualizacji i nikt tego nie zauważył.
- Baza żyje w bezpłatnej edycji SQL Server Express, gdzie niektóre mechanizmy są okrojone.
- Snapshot obejmuje dwa dyski i tylko jeden został zamrożony spójnie.
Efekt: masz plik VMDK, VHDX albo QCOW2, który wygląda jak backup, a po odtworzeniu może się okazać, że baza jest uszkodzona albo że brakuje ostatnich godzin operacji.
Co się dzieje, gdy trzeba naprawdę odtworzyć
U jednego z naszych klientów — 25-osobowej firmy dystrybucyjnej z branży elektrotechnicznej, korzystającej z Comarch Optima na SQL Server Express — padł kontroler RAID w środę wieczorem. Hosting miał codzienny snapshot z 3:00 rano. Odtworzenie maszyny zajęło godzinę. Uruchomienie Optimy zajęło kolejne 3 godziny, bo baza wpadła w recovery pending i wymagała ręcznej interwencji.
Gdy baza wreszcie wstała, okazało się, że brakuje 8 godzin transakcji — wszystkich faktur, przyjęć magazynowych i płatności z całego dnia roboczego. Firma spędziła następne dwa dni na ręcznym odtwarzaniu danych z papierowych WZ-tek i wyciągów bankowych. Straty czasu handlowców i księgowości oszacowano na około 30 000 zł. Snapshot był, formalnie działał — a i tak firma straciła cały dzień pracy.
Gdyby zamiast samego snapshota działała klasyczna strategia backupu bazy — pełna kopia co noc, kopia różnicowa co 6 godzin i backup logu transakcyjnego co 15 minut — punkt odtworzenia (RPO) wyniósłby maksymalnie 15 minut, a nie 8 godzin. Koszt takiego rozwiązania to jednorazowo kilka godzin konfiguracji i kilkanaście gigabajtów miejsca miesięcznie.
Jak wygląda backup bazy zrobiony poprawnie
Dla większości MŚP-owych instalacji Comarch Optima, enova365, Subiekt GT/Nexo czy Dynamics AX na Microsoft SQL Server sprawdza się prosty schemat:
- Pełna kopia (FULL) raz dziennie, w nocy, gdy nikt nie pracuje.
- Kopia różnicowa (DIFF) co 4–6 godzin w godzinach pracy — zajmuje kilka procent tego co FULL.
- Kopia logu transakcyjnego co 15 minut — pozwala odtworzyć bazę do konkretnego momentu z dokładnością do kilku minut.
- Backup w trybie FULL recovery model, nie SIMPLE — inaczej log nie da się do niczego użyć.
- Weryfikacja (RESTORE VERIFYONLY) po każdej kopii — sprawdza integralność pliku.
- Kopia trzymana w co najmniej dwóch lokalizacjach — jedna lokalnie, druga poza siedzibą firmy (chmura, drugi oddział, dysk offline).
To wszystko da się zautomatyzować w Ola Maintenance Plans, w SQL Server Agent (jeśli masz edycję Standard) albo w darmowym Ola Hallengren's SQL Server Maintenance Solution. Comarch Optima ma też własny mechanizm backupu z poziomu konsoli — dla małych baz w zupełności wystarcza, ale trzeba go włączyć.
Jedna uwaga: SQL Server Express nie ma SQL Server Agent. Automatyzację harmonogramu trzeba tam robić z poziomu Task Schedulera Windows albo skryptu PowerShell. To działa, tylko trzeba to zrobić — inaczej „mamy backup" oznacza „mamy nadzieję".
Backup poza serwerem — bo ransomware się nie patyczkuje
Nawet najlepsza kopia bazy jest bezużyteczna, jeśli leży na tym samym serwerze co produkcja. Współczesny ransomware szuka plików .bak, .trn, .mdf i szyfruje je razem z resztą. Widzieliśmy sytuację, w której firma miała 60 dni kopii — wszystkie na tym samym udziale sieciowym, wszystkie zaszyfrowane w ciągu 20 minut.
Zasada 3-2-1 (trzy kopie, na dwóch nośnikach, jedna poza siedzibą) obowiązuje też dla baz ERP. W praktyce dla MŚP oznacza to:
- kopia lokalna na serwerze,
- kopia na drugim fizycznym urządzeniu (NAS w innym pokoju, drugi serwer w drugiej lokalizacji),
- kopia poza firmą — Azure Blob Storage, AWS S3, backup u dostawcy hostingu, albo dysk USB, który wieczorem wraca do domu prezesa.
Kopia offsite powinna być immutable (niezmienialna) albo trzymana na koncie z osobnymi poświadczeniami, do których nie ma dostępu konto administratora domeny. Inaczej ransomware, który dostanie się na serwer, wykasuje też chmurę.
Test odtworzenia — jedyny prawdziwy dowód
Backup, który nigdy nie był odtworzony, to Schrödingerowski backup — jest i go nie ma jednocześnie. Regularne testowanie odtworzenia bazy do środowiska testowego to jedyny sposób, żeby wiedzieć, że kopia naprawdę działa.
Rekomendujemy: raz w miesiącu RESTORE ostatniej kopii FULL + wszystkich DIFF/LOG na osobny serwer testowy, uruchomienie Optima/enova/AX na tej kopii, otwarcie kilku faktur, wygenerowanie raportu. Zajmuje to około 2 godzin osobom przygotowanym, można to zrobić raz i spisać instrukcję krok po kroku (dokumentacja IT — patrz nasz oddzielny wpis).
Jeśli podczas testu okazuje się, że baza się nie odtwarza — masz problem znany, a nie problem odkryty w środku awarii. To jest cała różnica.
Podsumowanie
Snapshot maszyny to część planu, nie cały plan. Dla ERP potrzebujesz osobnej strategii backupu bazy, z krótkim RPO, kopią poza firmą i regularnym testem odtworzenia. Bez tego pierwszy poważny incydent kosztuje cię dzień pracy, dane sprzedażowe i nerwy — a często również zaufanie klientów, których faktury trzeba wystawiać drugi raz.
Jeśli nie wiesz, czy Twoja firma jest w tej lepszej połowie, umów pół godziny rozmowy. Powiemy, co dokładnie sprawdzić i od czego zacząć, jeśli backupu tak naprawdę nie ma.
Backup, którego nigdy nie odtworzyłeś, nie jest backupem — jest nadzieją. A nadzieja nie jest strategią IT.