Jednym z najczęstszych problemów przy odzyskiwaniu systemów ERP po awarii jest odtworzenie bazy danych SQL. Sama kopia może istnieć, ale po przywróceniu okazuje się, że baza jest niespójna, transakcje są urwane w połowie, a program księgowy zgłasza błędy i odmawia uruchomienia. Backup bazy danych SQL w chmurze, który nie uwzględnia specyfiki silnika bazodanowego, w momencie awarii może okazać się bezużyteczny.
W biurach rachunkowych i firmach pracujących na programach typu Insert, Comarch Optima, Enova czy Symfonia baza SQL to serce całego systemu. Faktury, rozliczenia, deklaracje, historia operacji – wszystko siedzi w bazie. A większość firm nie wie, ile kopii tak naprawdę ma, jak często się wykonują i czy ktokolwiek sprawdził, czy da się z nich odtworzyć działające środowisko.
Kopia plików to nie to samo co backup bazy SQL
To najczęstszy błąd. Ktoś konfiguruje backup, wskazuje folder z danymi programu i zakłada, że to wystarczy. Problem polega na tym, że baza SQL Server to nie jest zwykły plik, który można skopiować jak dokument Word.
Baza SQL działa cały czas. Procesy zapisują dane, transakcje są otwarte, pliki bazy są zablokowane przez silnik SQL Server. Zwykła kopia pliku w takim momencie może być niespójna, uszkodzona albo po prostu niemożliwa do odtworzenia. Program zgłosi błąd, baza się nie zamontuje, a dane przepadną.
Dlatego backup bazy danych SQL w chmurze musi działać inaczej niż kopia folderów.
PRAKTYCZNA WSKAZÓWKA:
W wielu firmach wygląda to tak: program ERP robi własną kopię bazy danych w swoim formacie, pliki i system lądują osobno na NAS-ie, a jeszcze gdzieś jest stary dysk zewnętrzny z kopiami sprzed kilku miesięcy. Trzy różne miejsca, trzy różne harmonogramy, różne okresy przechowywania kopii. Jedno narzędzie backupowe, które obejmuje bazę SQL, pliki i cały system w jednym miejscu, znacząco upraszcza zarówno codzienną kontrolę, jak i sam proces odtwarzania.
Czym jest backup application-aware i dlaczego ma znaczenie?
Profesjonalne rozwiązania backupowe potrafią rozpoznać, że na serwerze działa SQL Server, i zamiast kopiować surowe pliki, wykonują backup w sposób, który uwzględnia stan bazy danych. Nazywa się to backup application-aware.
W praktyce wygląda to tak: przed wykonaniem kopii system backupowy komunikuje się z SQL Server przez mechanizm VSS (Volume Shadow Copy Service). SQL Server kończy otwarte transakcje, zapisuje logi i zgłasza gotowość. Dopiero wtedy wykonywana jest kopia. Efekt? Spójna, kompletna kopia bazy, którą można odtworzyć bez problemów.
To samo dotyczy Microsoft Exchange, jeśli firma korzysta z własnego serwera pocztowego. Backup application-aware rozumie strukturę bazy Exchange i potrafi ją zabezpieczyć w sposób, który pozwala na odtworzenie pojedynczych skrzynek, wiadomości, a nawet konkretnych załączników.
Co powinien obejmować backup w środowisku księgowym?
W firmie pracującej na systemie ERP z bazą SQL rzadko wystarczy zabezpieczenie samej bazy. Środowisko składa się z kilku elementów i każdy z nich wymaga ochrony.
1. Baza danych SQL Server
To absolutna podstawa. Backup bazy danych SQL w chmurze musi być application-aware, wykonywany regularnie i przechowywany w co najmniej dwóch lokalizacjach. Warto sprawdzić, czy rozwiązanie backupowe pozwala na odtworzenie bazy do konkretnego punktu w czasie, a nie tylko do ostatniej pełnej kopii.
2. Cały serwer – obraz systemu
Backup bazy danych SQL to jedno, ale co jeśli padnie cały serwer? Reinstalacja systemu, konfiguracja Windows Server, instalacja SQL Server, przywrócenie bazy – to mogą być godziny albo nawet dni pracy. Backup obrazu całego serwera pozwala odtworzyć kompletne środowisko w ciągu minut. System, konfiguracja, aplikacje, baza – wszystko wraca dokładnie w takim stanie, w jakim było w momencie wykonania kopii.
3. Pojedyncze pliki i foldery
Nie wszystko siedzi w bazie SQL. Skany dokumentów, umowy, pliki Excel, szablony wydruków, konfiguracje programów. Te dane też trzeba zabezpieczyć, bo ich utrata potrafi sparaliżować pracę równie skutecznie jak utrata bazy.
4. Serwer Exchange i poczta
Jeśli firma korzysta z własnego serwera Exchange, backup musi obejmować bazy skrzynek pocztowych. Utrata poczty to utrata korespondencji z klientami, urzędami, kontrahentami. W kontekście biura rachunkowego to mogą być maile z dokumentami źródłowymi, na podstawie których robione były księgowania.
5. Hosty i maszyny wirtualne
W środowiskach, gdzie działa kilka maszyn wirtualnych, backup powinien obejmować je wszystkie. Najlepiej na poziomie hosta, żeby w razie awarii można było odtworzyć całe środowisko, a nie każdą maszynę z osobna.
UWAGA:
Wiele firm backupuje tylko jedno z powyższych. Sama baza SQL bez obrazu serwera, albo sam serwer bez Exchange. Warto zrobić przegląd i sprawdzić, które elementy środowiska są faktycznie chronione, a które nie.
Jak często robić backup bazy danych SQL?
To zależy od tego, ile danych firma jest w stanie stracić. Termin techniczny to RPO (Recovery Point Objective) i w praktyce oznacza on: jeśli backup bazy danych SQL w chmurze wykonywany jest co 6 godzin, to w najgorszym przypadku firma traci dane z ostatnich 6 godzin pracy.
Dla biura rachunkowego w okresie rozliczeniowym, kiedy dziennie wystawiane są dziesiątki faktur i księgowane setki dokumentów, RPO 24 godziny to za dużo. RPO 6 godzin to rozsądne minimum. Niektóre środowiska wymagają jeszcze częstszych kopii.
Warto też zwrócić uwagę na retencję, czyli jak długo przechowywane są starsze kopie. Retencja 7 dni to za mało, bo atak ransomware może pozostawać niewykryty przez tygodnie. Retencja 365 dni daje możliwość cofnięcia się do czystej kopii sprzed miesięcy, co przy zaszyfrowaniu danych może uratować firmę. Właśnie dlatego backup bazy danych SQL w chmurze z elastyczną retencją to nie luksus, ale podstawa bezpiecznej pracy na systemach księgowych.
Backup lokalny, w chmurze czy hybrydowo?
Backup na NAS stojącym obok serwera to lepsze niż nic, ale nie chroni przed pożarem, zalaniem ani kradzieżą. Backup bazy danych SQL w chmurze eliminuje ten problem, bo dane trafiają do zewnętrznego centrum danych, niezależnego od siedziby firmy.
Najlepsze rozwiązanie to model hybrydowy: kopia lokalna dla szybkiego odtwarzania plus kopia w chmurze dla ochrony przed poważnymi awariami. Jeśli dostawca oferuje georeplikację do drugiego centrum danych, to jeszcze lepiej, bo nawet awaria jednego DC nie oznacza utraty kopii.
Warto sprawdzić, czy dostawca przechowuje dane w centrach danych na terenie Unii Europejskiej i czy posiada certyfikat ISO 27001. Dla firm przetwarzających dane finansowe klientów to nie jest opcja, to wymóg wynikający z RODO.
Czego nie widać w cenniku – pytania, które warto zadać
Przy wyborze rozwiązania backupowego różnica między dostawcami często nie leży w cenie miesięcznej, ale w tym, co jest, a czego nie ma w pakiecie.
- Czy backup obejmuje bazy SQL, Exchange i obrazy całych serwerów, czy tylko pliki?
- Ile maszyn lub stacji roboczych można podpiąć w ramach pakietu?
- Czy aplikacja agenta backupowego jest w cenie, czy płaci się osobno za każde urządzenie?
- Jak często wykonywane są kopie i ile punktów przywracania jest dostępnych?
- Czy kopie trafiają do dwóch niezależnych lokalizacji?
- Czy dostawca przeprowadza testy odtwarzania i jak często?
- Czy kopie są chronione przed zmianą i usunięciem (WORM)?
- Jak szybko można odtworzyć dane w razie awarii?
PRAKTYCZNA WSKAZÓWKA:
Odpowiedzi na te pytania pokażą, czy to jest profesjonalna usługa backupowa, czy tylko przestrzeń dyskowa z etykietą „backup”.
Backup jako część środowiska, nie osobny zakup
W firmach, które korzystają z serwera w chmurze, backup powinien być częścią tego samego środowiska. Serwer, baza SQL, firewall, Microsoft 365 i backup od jednego dostawcy, na jednej fakturze, z jednym supportem. Nie trzeba wtedy koordynować trzech firm i zastanawiać się, czyja to odpowiedzialność, gdy coś nie działa.
Jeśli firma potrzebuje dodatkowej warstwy ochrony, np. niezmienialne repozytorium na dane archiwalne, warto sprawdzić też możliwość podpięcia S3 Storage jako dodatkowego celu backupu.
Podsumowanie
Backup bazy danych SQL w chmurze to nie jest kopia folderu na dysk USB. To backup bazy danych SQL w chmurze z funkcją application-aware, który rozumie jak działa SQL Server i robi spójną kopię bez przerywania pracy. To ochrona nie tylko bazy, ale całego serwera, plików, poczty i maszyn wirtualnych. To retencja liczona w miesiącach, nie dniach. I to regularne testy, które potwierdzają, że w razie awarii dane da się faktycznie odtworzyć.
Dla firm pracujących na systemach księgowych i sprzedażowych nie powinien to być koszt, ale warunek spokojnej pracy.