Kopia zapasowa serwera firmowego nie powinna oznaczać wyłącznie skopiowania kilku folderów na dysk zewnętrzny. Dobra strategia backupu musi obejmować najważniejsze dane firmy, bazy SQL, systemy ERP, pliki użytkowników, konfigurację serwera, harmonogram kopii, retencję, kopię poza lokalizacją, zabezpieczenie przed ransomware oraz regularny test odtworzenia. Najważniejsze pytanie nie brzmi: „czy mamy backup?”, tylko: czy firma potrafi odzyskać dane i wrócić do pracy po awarii?
W małej firmie serwer często przechowuje pliki, dokumenty, bazę SQL, system ERP, Wapro, program magazynowy, księgowy, dane handlowe, dokumenty klientów, integracje, konfigurację usług i backupy innych systemów. Jeżeli taki serwer przestanie działać, firma może utracić dostęp do sprzedaży, faktur, magazynu, zamówień, korespondencji i danych potrzebnych do codziennej pracy.
Dlatego backup serwera firmowego powinien być traktowany jako element ciągłości działania firmy, a nie jako techniczny dodatek.
CISA w swoich zaleceniach dotyczących kopii zapasowych wskazuje zasadę 3-2-1: trzy kopie ważnych plików, dwa różne typy nośników oraz jedna kopia poza lokalizacją firmy. CISA podkreśla też, że backup powinien być wykonywany automatycznie i regularnie, a połączenie kopii lokalnych i zdalnych pomaga chronić firmę przed awariami, malware, ransomware i uszkodzeniami fizycznymi.
Dlaczego sama informacja „mamy backup” nie wystarczy?
W wielu firmach właściciel słyszy: „backup jest”. Problem w tym, że taka odpowiedź niczego jeszcze nie potwierdza.
Trzeba wiedzieć:
- co dokładnie jest backupowane,
- jak często wykonywana jest kopia,
- gdzie trafia backup,
- kto sprawdza, czy backup się wykonał,
- jak długo przechowywane są kopie,
- czy backup obejmuje bazy SQL,
- czy backup obejmuje system ERP lub Wapro,
- czy backup obejmuje konfigurację serwera,
- czy kopia jest poza lokalizacją firmy,
- czy backup jest chroniony przed ransomware,
- czy ktokolwiek wykonał test odtworzenia.
Backup, którego nikt nie testował, jest tylko założeniem. Może wyglądać poprawnie w panelu programu, ale dopiero odtworzenie danych pokazuje, czy firma rzeczywiście jest w stanie wrócić do pracy.
Najgorszy scenariusz to sytuacja, w której firma ma kopie zapasowe, ale po awarii okazuje się, że:
- backup nie obejmował właściwego katalogu,
- baza SQL nie była poprawnie kopiowana,
- kopia była uszkodzona,
- backup kończył się błędem od kilku tygodni,
- kopia była na tym samym serwerze, który uległ awarii,
- ransomware zaszyfrowało również backup,
- nikt nie zna hasła do systemu backupu,
- nikt nie wie, jak odtworzyć środowisko.
Dlatego backup trzeba projektować od strony odtworzenia, a nie tylko od strony wykonania kopii.
1. Nie wolno pominąć listy krytycznych danych
Pierwszy błąd to backupowanie „czegoś”, bez jasnej listy danych krytycznych. Firma powinna wiedzieć, które dane są niezbędne do działania i w jakiej kolejności trzeba je odtwarzać po awarii.
Na serwerze firmowym mogą znajdować się:
- pliki firmowe,
- dokumenty handlowe,
- umowy,
- faktury,
- dokumenty księgowe,
- dane kadrowe,
- baza SQL,
- baza Wapro lub innego ERP,
- program magazynowy,
- program księgowy,
- aplikacje firmowe,
- konfiguracje usług,
- skrypty i integracje,
- profile użytkowników,
- udziały sieciowe,
- dane platformy B2B,
- eksporty i importy danych,
- dokumentacja techniczna,
- certyfikaty,
- klucze licencyjne,
- konfiguracja drukarek i urządzeń.
Nie wszystko ma taką samą wartość. Dokument z pulpitu jednego użytkownika może być mniej ważny niż baza sprzedaży, ale czasami ten dokument może zawierać ważną umowę. Dlatego trzeba zacząć od mapy danych: gdzie są dane, kto ich używa i co stanie się, jeżeli zostaną utracone.
Dobra praktyka to podział danych na kategorie:
- krytyczne dla działania firmy,
- ważne, ale możliwe do odtworzenia z innych źródeł,
- archiwalne,
- tymczasowe,
- niepotrzebne.
Bez takiego podziału firma może backupować rzeczy mało ważne, a pominąć dane, które realnie zatrzymują pracę.
2. Nie wolno pominąć baz SQL i systemów ERP
Jeżeli na serwerze działa SQL Server, ERP, Wapro, program magazynowy lub księgowy, backup plików nie wystarczy. Baza danych wymaga poprawnego backupu. Nie można zakładać, że skopiowanie katalogu z plikami bazy w czasie pracy systemu daje bezpieczną i spójną kopię.
Microsoft w dokumentacji SQL Server podkreśla, że wykonywanie kopii zapasowych baz danych jest kluczowe dla ochrony danych. SQL Server obsługuje różne typy backupów, w tym pełne, różnicowe i logów transakcyjnych, a wybór właściwego modelu zależy od wymagań odtworzeniowych firmy.
W przypadku baz SQL trzeba sprawdzić:
- które bazy istnieją na serwerze,
- która baza jest produkcyjna,
- jak często wykonywany jest backup pełny,
- czy potrzebne są backupy różnicowe,
- czy potrzebne są backupy logów transakcyjnych,
- jaki jest model odzyskiwania bazy,
- gdzie trafiają pliki backupu,
- czy backup SQL jest później kopiowany poza serwer,
- czy backup można odtworzyć na innym środowisku,
- czy baza nie ma błędów,
- czy log transakcyjny nie rośnie bez kontroli.
Dla Wapro i innych systemów ERP baza danych jest często najważniejszym elementem. To tam znajdują się dokumenty, kontrahenci, towary, ceny, magazyny, faktury i historia operacji. Jeżeli backup nie obejmuje poprawnie bazy, firma może mieć kopię folderów, ale nie mieć możliwości odtworzenia systemu.
3. Nie wolno pominąć testu odtworzenia
Test odtworzenia to najważniejszy, a jednocześnie najczęściej pomijany element backupu. Firma może mieć codzienne kopie, ładny panel programu i zielone statusy, ale dopóki nikt nie wykonał testu przywrócenia danych, nie ma pewności, że backup działa.
CISA w przewodniku dotyczącym ransomware zaleca utrzymywanie offline’owych, szyfrowanych kopii krytycznych danych oraz regularne testowanie dostępności i integralności backupów w scenariuszu odzyskiwania po awarii. Podkreśla też, że wiele wariantów ransomware próbuje znaleźć, usunąć albo zaszyfrować dostępne kopie, aby uniemożliwić odtworzenie bez zapłaty okupu.
Test odtworzenia powinien odpowiedzieć na pytania:
- czy plik można odzyskać,
- czy folder można odzyskać,
- czy bazę SQL można odtworzyć,
- czy aplikacja po odtworzeniu działa,
- czy backup zawiera najnowsze dane,
- ile trwa odtworzenie,
- kto potrafi wykonać odtworzenie,
- czy hasła i klucze są dostępne,
- czy dokumentacja jest wystarczająca,
- czy odtworzenie można wykonać na innym sprzęcie lub serwerze.
Test nie musi od razu oznaczać pełnej symulacji katastrofy. Można zacząć od prostych działań: odtworzyć pojedynczy plik, folder, bazę testową, konfigurację lub wybraną aplikację. Najważniejsze, aby test był realny, udokumentowany i powtarzany.
Backup bez testu to nie strategia. To nadzieja.
4. Nie wolno pominąć kopii poza serwerem
Jednym z największych błędów jest trzymanie backupu wyłącznie na tym samym serwerze, który ma być chroniony. Jeżeli serwer ulegnie awarii, zostanie zaszyfrowany, skradziony, zalany albo uszkodzony, kopia może zniknąć razem z nim.
Backup powinien istnieć poza głównym serwerem.
Może to być:
- drugi serwer,
- NAS,
- dysk zewnętrzny rotowany i odłączany,
- chmura,
- repozytorium backupowe,
- kopia w innej lokalizacji,
- backup immutable,
- backup offline.
W praktyce dobrym punktem wyjścia jest zasada 3-2-1: trzy kopie danych, dwa różne typy nośników, jedna kopia poza lokalizacją. Dla firm narażonych na ransomware warto rozważyć także model rozszerzony: kopia odseparowana, niezmienialna lub offline.
NCSC w materiałach o backupach odpornych na ransomware zwraca uwagę, że system backupu również musi być chroniony przed nieautoryzowanym dostępem, bo przechowuje dane wrażliwe i krytyczne. To ważne, ponieważ backup nie powinien być najłatwiejszym celem po przejęciu konta administratora.
5. Nie wolno pominąć ochrony przed ransomware
Ransomware zmieniło podejście do backupu. Kiedyś wystarczyło myśleć głównie o awarii dysku, przypadkowym skasowaniu pliku albo uszkodzeniu serwera. Dzisiaj trzeba zakładać, że atakujący może próbować zniszczyć lub zaszyfrować również kopie zapasowe.
Dlatego backup powinien być zaprojektowany tak, aby nie był stale dostępny z tego samego konta i tego samego środowiska.
Warto uwzględnić:
- kopię offline,
- kopię odłączaną po wykonaniu backupu,
- kopię w innej lokalizacji,
- repozytorium immutable,
- oddzielne konto do backupu,
- MFA do panelu backupu,
- brak wspólnych haseł administracyjnych,
- ograniczenie dostępu do backupu,
- monitorowanie usuwania kopii,
- alerty przy nieudanych backupach,
- test odtworzenia po założeniu scenariusza ransomware.
NCSC w artykule o offline backupach wyjaśnia, że kopia niedostępna online w momencie infekcji może utrudnić ransomware dotarcie do niej. W przypadku chmury analogiczną rolę mogą pełnić mechanizmy ograniczające możliwość nadpisania lub usunięcia istniejących kopii.
Najważniejsze: backup musi być odporny nie tylko na awarię sprzętu, ale też na atak na konto administratora, skrypt kasujący dane, szyfrowanie udziałów sieciowych i błędną konfigurację.
6. Nie wolno pominąć retencji
Retencja określa, jak długo przechowywane są kopie. To bardzo ważne, bo nie każdy problem zostaje zauważony od razu. Jeżeli firma trzyma tylko jedną kopię z ostatniej nocy, może się okazać, że skopiowała już dane uszkodzone, zaszyfrowane albo błędnie zmienione.
Retencja powinna odpowiadać na pytania:
- ile dni wstecz można odzyskać dane,
- ile wersji plików jest dostępnych,
- czy są kopie dzienne,
- czy są kopie tygodniowe,
- czy są kopie miesięczne,
- jak długo przechowujemy archiwum,
- czy retencja spełnia potrzeby księgowe, prawne i biznesowe,
- czy retencja nie zapełnia nośnika backupu.
Przykład: jeżeli użytkownik przypadkowo usunął ważny folder tydzień temu, a firma ma tylko trzy dni retencji, backup nie pomoże. Jeżeli ransomware przez kilka dni stopniowo szyfrowało dane albo uszkodzenie bazy zostało zauważone późno, krótka retencja również może być problemem.
Retencja nie powinna być przypadkowa. Musi wynikać z tego, jak firma pracuje i jak szybko wykrywa błędy.
7. Nie wolno pominąć częstotliwości backupu
Nie każda firma potrzebuje backupu co kilka minut. Ale każda firma powinna wiedzieć, ile danych może stracić po awarii. To jest praktyczne pytanie biznesowe.
Jeżeli backup wykonuje się raz dziennie o 22:00, a serwer pada o 16:00, firma może stracić dane z całego dnia pracy. Dla jednej firmy to akceptowalne. Dla innej — nie.
Trzeba ustalić:
- jak często zmieniają się dane,
- ile dokumentów powstaje dziennie,
- ile zamówień wpływa do systemu,
- jak często aktualizuje się magazyn,
- ile pracy trzeba byłoby odtworzyć ręcznie,
- jaki jest akceptowalny poziom utraty danych,
- jaki jest akceptowalny czas przestoju.
Tu pojawiają się dwa ważne pojęcia:
RPO — ile danych firma może maksymalnie stracić.
RTO — jak szybko firma musi wrócić do pracy.
Nie trzeba używać tych skrótów w codziennej rozmowie, ale trzeba rozumieć ich sens. Inaczej backup może być technicznie poprawny, ale biznesowo niewystarczający.
8. Nie wolno pominąć konfiguracji serwera
Wiele firm myśli o backupie wyłącznie jako o kopii danych. Tymczasem po awarii trzeba odtworzyć nie tylko pliki, ale też środowisko pracy.
Warto zabezpieczyć informacje o:
- systemie operacyjnym,
- rolach serwera,
- użytkownikach i grupach,
- udziałach sieciowych,
- uprawnieniach,
- konfiguracji aplikacji,
- ścieżkach danych,
- zadaniach harmonogramu,
- usługach Windows,
- konfiguracji IIS, jeżeli występuje,
- certyfikatach,
- skryptach,
- integracjach,
- kontach technicznych,
- kluczach licencyjnych,
- ustawieniach SQL Server,
- konfiguracji backupu.
Jeżeli serwer ulegnie awarii, sama baza danych może nie wystarczyć. Trzeba wiedzieć, jak zainstalować aplikację, jak podłączyć bazę, jakie usługi uruchomić, jakie konta techniczne skonfigurować i jakie uprawnienia nadać.
Dobra kopia zapasowa powinna iść w parze z dokumentacją. Bez dokumentacji odtworzenie trwa dłużej i zależy od pamięci jednej osoby.
9. Nie wolno pominąć uprawnień do backupu
Backup zawiera często najbardziej wrażliwe dane firmy. Jeżeli ktoś ma dostęp do backupu, może mieć dostęp do plików, baz danych, dokumentów, danych klientów i historii firmy. Dlatego system backupu musi być zabezpieczony.
Trzeba sprawdzić:
- kto ma dostęp do panelu backupu,
- kto może usuwać kopie,
- kto może zmieniać harmonogram,
- kto może odtwarzać dane,
- czy dostęp jest chroniony MFA,
- czy konto backupu jest oddzielne,
- czy hasła są bezpiecznie przechowywane,
- czy konta byłych pracowników nie mają dostępu,
- czy backup nie jest dostępny jako zwykły udział sieciowy dla wszystkich.
Częsty błąd: backup zapisuje się na udział sieciowy, do którego dostęp ma konto administratora używane na co dzień. Jeżeli to konto zostanie przejęte, atakujący może usunąć albo zaszyfrować również kopię.
Dostęp do backupu powinien być ograniczony i kontrolowany.
10. Nie wolno pominąć monitoringu backupu
Backup musi być monitorowany. Nie wystarczy ustawić harmonogram i zapomnieć. Jeżeli backup przestanie działać, ktoś musi się o tym dowiedzieć.
Monitoring powinien informować o tym:
- czy backup wykonał się poprawnie,
- kiedy był ostatni poprawny backup,
- czy backup trwał nietypowo długo,
- czy backup nie zakończył się błędem,
- czy backup nie został przerwany,
- czy repozytorium ma wolne miejsce,
- czy nośnik backupu jest dostępny,
- czy kopia nie została usunięta,
- czy backup obejmuje właściwe dane.
Ważne są alerty. Jeżeli backup nie wykonał się od trzech dni, informacja musi trafić do osoby odpowiedzialnej. Jeżeli nikt nie czyta logów backupu, firma może przez miesiące żyć w przekonaniu, że dane są chronione.
11. Nie wolno pominąć backupu Microsoft 365 i poczty, jeśli są krytyczne
Wiele firm zakłada, że skoro poczta działa w Microsoft 365, to nie trzeba już myśleć o backupie. To uproszczenie. Microsoft zapewnia wysoką dostępność usługi i mechanizmy odzyskiwania w ramach platformy, ale firma nadal powinna ocenić, czy potrzebuje dodatkowego backupu danych z poczty, OneDrive, SharePoint i Teams.
Trzeba zadać pytania:
- czy firma musi odzyskiwać maile po dłuższym czasie,
- czy użytkownicy kasują pliki z OneDrive,
- czy SharePoint zawiera dokumenty krytyczne,
- czy Teams jest używany do wymiany ważnych plików,
- czy firma ma wymagania prawne lub archiwizacyjne,
- czy potrzebne jest niezależne odtworzenie danych po błędzie użytkownika,
- czy konto administratora mogłoby usunąć dane i retencję.
Nie każda mała firma potrzebuje rozbudowanego backupu Microsoft 365, ale każda powinna świadomie ocenić ten temat. Najgorsze jest założenie, że „chmura sama wszystko załatwia”.
12. Nie wolno pominąć procedury odtworzenia
Backup powinien mieć procedurę odtworzenia. Bez niej w czasie awarii zaczyna się improwizacja.
Procedura powinna określać:
- kto podejmuje decyzję o odtworzeniu,
- kto wykonuje odtworzenie,
- gdzie są kopie,
- jakie hasła są potrzebne,
- w jakiej kolejności odtwarzać systemy,
- co odtwarzamy najpierw,
- jak sprawdzić poprawność danych,
- kogo poinformować o przestoju,
- jak długo potrwa powrót do pracy,
- co zrobić, gdy główny serwer nie działa,
- co zrobić, gdy lokalizacja firmy jest niedostępna.
Dla firm korzystających z ERP kolejność ma znaczenie. Najpierw trzeba odtworzyć środowisko, potem bazę, potem aplikację, potem sprawdzić użytkowników, drukarki, integracje i dostęp do danych.
Procedura nie musi być długa. Musi być użyteczna.
13. Nie wolno pominąć scenariusza awarii całego serwera
Odtworzenie jednego pliku to jedno. Awaria całego serwera to zupełnie inny scenariusz. Firma musi wiedzieć, czy potrafi odtworzyć środowisko na nowym sprzęcie, maszynie wirtualnej albo w chmurze.
Trzeba odpowiedzieć:
- czy mamy obraz całego serwera,
- czy mamy backup bare-metal,
- czy wystarczy backup plików i baz,
- czy mamy instalatory aplikacji,
- czy znamy licencje,
- czy mamy hasła,
- czy mamy dokumentację,
- czy możemy odtworzyć serwer na innym sprzęcie,
- czy możemy uruchomić środowisko tymczasowe,
- ile potrwa pełne odtworzenie.
Jeżeli firma ma tylko kopię plików, a nie ma dokumentacji, instalatorów, licencji i backupu bazy, odtworzenie całego środowiska może być trudne. Dlatego strategia backupu musi obejmować nie tylko dane, ale też możliwość przywrócenia działania.
14. Nie wolno pominąć odpowiedzialności
Kto odpowiada za backup? To pytanie powinno mieć jasną odpowiedź. Jeżeli odpowiedź brzmi „chyba informatyk”, „chyba dostawca”, „chyba program sam robi”, to znaczy, że firma nie ma kontroli.
Trzeba ustalić:
- kto konfiguruje backup,
- kto monitoruje backup,
- kto dostaje alerty,
- kto testuje odtworzenie,
- kto podejmuje decyzję po awarii,
- kto zna procedurę,
- kto ma dostęp do kopii,
- kto odpowiada za dokumentację.
Backup bez właściciela procesu łatwo staje się fikcją. Dopóki wszystko działa, nikt się nim nie interesuje. Po awarii okazuje się, że każdy myślał, że ktoś inny to sprawdza.
Czego nie wolno robić przy backupie serwera?
Nie wolno:
- trzymać jedynej kopii na tym samym serwerze,
- zakładać, że RAID zastępuje backup,
- backupować tylko folderów, pomijając SQL,
- nie testować odtworzenia,
- ignorować błędów backupu,
- zostawiać backupu stale dostępnego dla ransomware,
- używać jednego wspólnego konta administratora do wszystkiego,
- nie dokumentować procedury,
- trzymać haseł tylko w głowie jednej osoby,
- nie sprawdzać retencji,
- nie mieć kopii poza lokalizacją,
- nie monitorować statusu kopii,
- zakładać, że chmura automatycznie rozwiązuje każdy problem.
Checklista: kopia zapasowa serwera firmowego
Praktyczne minimum:
- lista krytycznych danych,
- backup plików,
- backup baz SQL,
- backup ERP/Wapro,
- backup konfiguracji serwera,
- backup poza głównym serwerem,
- kopia poza lokalizacją,
- retencja dzienna, tygodniowa lub miesięczna,
- monitoring backupu,
- alerty błędów,
- zabezpieczenie dostępu do kopii,
- MFA do panelu backupu,
- kopia odporna na ransomware,
- test odtworzenia pliku,
- test odtworzenia bazy,
- procedura odtworzenia,
- dokumentacja haseł i licencji,
- osoba odpowiedzialna za backup.
Jeżeli firma nie ma większości tych elementów, to znaczy, że backup wymaga przeglądu.
Jak pomaga Rovens?
Rovens pomaga firmom sprawdzić, czy kopia zapasowa serwera rzeczywiście chroni najważniejsze dane, a nie tylko „coś zapisuje”. W ramach administracji serwerami dla firm można zweryfikować backup plików, baz SQL, ERP, Wapro, konfiguracji serwera, harmonogramów, retencji, logów, repozytoriów oraz procedury odtworzenia.
Podsumowanie
Kopia zapasowa serwera firmowego musi obejmować więcej niż przypadkowo wybrane foldery. Trzeba zabezpieczyć dane krytyczne, bazy SQL, ERP, Wapro, pliki, konfigurację serwera, dokumentację, hasła, licencje i procedurę odtworzenia. Backup powinien być regularny, monitorowany, odseparowany, chroniony przed ransomware i testowany.
Najważniejsze elementy to: lista danych krytycznych, poprawny backup SQL, kopia poza serwerem, retencja, test odtworzenia, monitoring, zabezpieczenie dostępu i jasna odpowiedzialność.
Firma nie powinna pytać tylko: „czy mamy backup?”. Powinna pytać:
- co dokładnie możemy odzyskać?
- z jakiego momentu?
- w jakim czasie?
- kto to zrobi?
- czy testowaliśmy odtworzenie?
- czy ransomware może usunąć kopię?
- czy backup obejmuje bazę ERP lub Wapro?
Dopiero odpowiedzi na te pytania pokazują, czy backup jest realnym zabezpieczeniem, czy tylko techniczną formalnością. Serwer firmowy może się zepsuć, dane mogą zostać usunięte, baza może się uszkodzić, ransomware może zaszyfrować pliki, a użytkownik może popełnić błąd. Dobra kopia zapasowa nie zapobiega każdemu problemowi, ale daje firmie możliwość powrotu do pracy.
