Jak przygotować Disaster Recovery
dla małej firmy?

Awaria serwera, ransomware, pożar w biurze albo utrata dostępu do usług chmurowych mogą zatrzymać firmę w ciągu kilku minut.

Problemem nie jest wyłącznie utrata danych. Nawet firma posiadająca poprawne kopie zapasowe może przez wiele dni nie być w stanie wznowić działalności, jeżeli nie wiadomo:

• -które systemy należy odtworzyć jako pierwsze,
• -gdzie znajdują się kopie,
• -kto posiada potrzebne hasła,
• -na jakim sprzęcie uruchomić aplikacje,
• -jak skontaktować się z pracownikami i klientami,
• -ile czasu potrwa odzyskanie środowiska.

Disaster Recovery nie jest więc inną nazwą backupu. To przygotowany i przetestowany sposób przywrócenia działania firmy po poważnej awarii.

Mała organizacja nie potrzebuje drugiego Data Center ani infrastruktury projektowanej jak dla banku. Potrzebuje realistycznego planu dostosowanego do wartości danych, kosztu przestoju i posiadanego budżetu.

Czym jest Disaster Recovery?

Disaster Recovery, w skrócie DR, to zestaw procedur, technologii i odpowiedzialności umożliwiających odzyskanie systemów informatycznych po poważnym incydencie. Plan może obejmować odzyskanie danych, odbudowę serwerów, uruchomienie aplikacji biznesowych, przywrócenie dostępu użytkowników oraz komunikację z pracownikami, klientami i dostawcami.

Disaster Recovery a Business Continuity

Przykładowo plan DR może opisywać przywrócenie ERP, a plan ciągłości działania może określać, w jaki sposób przez kilka godzin przyjmować zamówienia bez tego systemu.

Backup a Disaster Recovery

Backup jest jednym z fundamentów DR, ale sam w sobie nie jest planem odzyskiwania. Kopia zapasowa odpowiada na pytanie: czy posiadamy dane potrzebne do odtworzenia? Disaster Recovery odpowiada na kolejne pytania: gdzie uruchomimy system, kto wykona odtworzenie, jak długo to potrwa, w jakiej kolejności uruchomimy usługi i jak użytkownicy uzyskają dostęp.

Firma może posiadać bardzo dobry backup, ale nadal nie mieć skutecznego DR.

Wysoka dostępność a Disaster Recovery

Wysoka dostępność, czyli HA (klaster Proxmox, dwa kontrolery domeny, redundancja zasilania), ogranicza przestoje po awarii pojedynczego komponentu. Nie chroni jednak automatycznie przed ransomware, błędem administratora, uszkodzeniem danych, pożarem całej serwerowni ani przejęciem kont administracyjnych. Więcej o różnicach między HA a DR opisaliśmy w artykule HA dla ERP.

Disaster Recovery zakłada, że podstawowe środowisko może zostać całkowicie utracone albo uznane za niezaufane.

Jakie zdarzenia powinien obejmować plan DR?

Plan powinien odpowiadać na scenariusze realne dla konkretnej firmy. Najczęściej warto uwzględnić:

Nie każdy scenariusz wymaga osobnej, rozbudowanej instrukcji. Przykładowo przy awarii sprzętu można od razu rozpocząć restore. Po ransomware najpierw trzeba ustalić zakres kompromitacji i upewnić się, że nie przywracamy systemu do nadal zainfekowanego środowiska.

Krok 1. Zrób inwentaryzację środowiska

Nie można przygotować odzyskiwania systemów, o których istnieniu nikt nie pamięta. Inwentaryzacja powinna obejmować infrastrukturę (serwery, hosty wirtualizacji, macierze, routery, łącza, UPS, usługi chmurowe), systemy i aplikacje (Active Directory, ERP, CRM, bazy danych, pocztę, VPN, backup) oraz dane (gdzie się znajdują, kto jest właścicielem, jak często się zmieniają).

Trzeba też zinwentaryzować dostępy: konta administratorów, domeny, konta chmurowe, klucze szyfrujące, licencje i certyfikaty. Hasła nie powinny znajdować się bezpośrednio w arkuszu inwentaryzacyjnym. Należy przechowywać je w firmowym menedżerze haseł z zapewnionym dostępem awaryjnym - piszemy o tym w artykule Menedżer haseł w firmie.

Krok 2. Określ, co jest naprawdę krytyczne

Nie wszystkie systemy trzeba odtworzyć jednocześnie. Dla każdego systemu warto ustalić wpływ niedostępności na firmę, zależności, kolejność odzyskiwania i dopuszczalny czas przestoju.

Taki podział pozwala uniknąć sytuacji, w której zespół podczas awarii najpierw odtwarza łatwy, ale mało ważny serwer, zamiast systemu generującego przychody.

Krok 3. Ustal RTO i RPO

RTO i RPO trzeba ustalać z właścicielami procesów biznesowych, a nie wyłącznie z administratorem.

Krok 4. Zidentyfikuj zależności

Aplikacja rzadko działa samodzielnie. ERP może zależeć od Active Directory, DNS, SQL Server, udziału sieciowego, serwera licencji, integracji z bankiem i komunikacji z WMS. Jeżeli podczas awarii zostanie odtworzony tylko serwer aplikacyjny, system nadal może nie działać.

Dlatego plan powinien zawierać mapę zależności i kolejność uruchamiania:

1. 1 sieć i firewall,
2. 2 storage,
3. 3 Active Directory i DNS,
4. 4 baza danych,
5. 5 serwer aplikacyjny,
6. 6 usługi integracyjne,
7. 7 dostęp użytkowników,
8. 8 monitoring i backup.

Krok 5. Zbuduj strategię backupową

Podstawowym punktem wyjścia jest zasada 3-2-1-1-0:

Nie oznacza to, że każda mała firma musi korzystać z taśm, dwóch chmur i trzech różnych produktów. Praktyczna konfiguracja może obejmować dane produkcyjne, lokalny backup na oddzielnym serwerze, kopię off-site, warstwę immutable lub offline oraz regularny test restore.

Backup lokalny zapewnia szybkie odtwarzanie plików, baz i maszyn wirtualnych - powinien znajdować się na oddzielnym urządzeniu i korzystać z innych kont niż produkcja. Backup off-site chroni przed utratą całego budynku. Kopia immutable albo offline ogranicza możliwość usunięcia backupu przez ransomware lub przejęte konto administratora - więcej o tym w artykule Immutable Backup.

Sama synchronizacja danych do drugiej lokalizacji nie zawsze jest backupem. Usunięcie lub zaszyfrowanie może zostać natychmiast przeniesione na system docelowy.

W przypadku baz danych i systemów ERP nie należy opierać się wyłącznie na kopii całej maszyny wirtualnej - warto posiadać również natywne kopie SQL Server, PostgreSQL, konfiguracji aplikacji i certyfikatów. Kompletną strategię backupu ERP opisaliśmy w artykule Backup ERP.

Krok 6. Wybierz sposób odzyskiwania

Cold, warm i hot DR

Mała firma najczęściej wybierze cold albo ograniczone warm DR. Nie należy jednak zakładać, że warm DR zawsze będzie tanie lub możliwe do uruchomienia w kilka minut - zależy to od wielkości danych, aplikacji i przygotowania środowiska.

Krok 7. Przygotuj scenariusze awaryjne

Ransomware

Procedura nie powinna rozpoczynać się od natychmiastowego przywrócenia wszystkich systemów. Najpierw trzeba:

1. 1 odizolować zagrożenie,
2. 2 zabezpieczyć dostępne dowody i logi,
3. 3 ustalić zakres kompromitacji,
4. 4 zabezpieczyć backupy,
5. 5 zmienić przejęte poświadczenia,
6. 6 przygotować czyste środowisko,
7. 7 wybrać punkt przywracania,
8. 8 uruchamiać systemy etapami,
9. 9 monitorować je po odtworzeniu.

Przywrócenie kopii do nadal przejętej sieci może doprowadzić do ponownego zaszyfrowania.

Utrata lokalizacji i dostępu do chmury

Plan powinien określać możliwość pracy zdalnej, alternatywną lokalizację, zapasowe łącze i komunikację z pracownikami. Dla Microsoft 365 i innych usług SaaS trzeba przygotować co najmniej dwa niezależne konta administracyjne, MFA, zabezpieczone konta awaryjne i backup krytycznych danych.

Chmura ogranicza ryzyko awarii lokalnego sprzętu, ale nie eliminuje błędów użytkownika, przejęcia konta ani problemów z dostępem administracyjnym - piszemy o tym w artykule Microsoft 365 to nie backup.

Krok 8. Udokumentuj procedury

Plan DR powinien być zrozumiały dla osoby, która nie projektowała infrastruktury. Dokumentacja powinna zawierać listę systemów, priorytety, RTO i RPO, zależności, kolejność odzyskiwania, lokalizację backupów, kontakty awaryjne i kryteria zakończenia awarii.

Dokument nie powinien znajdować się wyłącznie na serwerze, który planujemy odzyskiwać. Kopia powinna być dostępna w bezpiecznej usłudze chmurowej, offline i dla kilku uprawnionych osób. Nie należy przechowywać otwartego dokumentu zawierającego wszystkie hasła - plan powinien wskazywać, gdzie znaleźć poświadczenia w menedżerze haseł.

Krok 9. Określ role podczas awarii

Nawet w małej firmie powinno być wiadomo, kto podejmuje decyzję o uruchomieniu DR, kto odpowiada za infrastrukturę, kto kontaktuje się z dostawcami i kto informuje pracowników. Jedna osoba może pełnić kilka ról, ale odpowiedzialność musi być wcześniej określona.

Warto również przygotować zastępstwa. Plan zależny od jednego administratora przestaje działać, gdy ta osoba jest niedostępna.

Krok 10. Przygotuj komunikację kryzysową

W czasie awarii pracownicy chcą wiedzieć, czy mogą pracować i gdzie zgłaszać problemy, a klienci pytają o realizację zamówień i przewidywany czas naprawy. Plan powinien zawierać kanały awaryjne, listę odbiorców, osoby zatwierdzające komunikaty i gotowe szablony informacji.

Nie należy deklarować terminu przywrócenia, dopóki zespół nie posiada wystarczających danych.

Krok 11. Testuj Disaster Recovery

Plan nieprzetestowany jest tylko hipotezą.

Podczas testu należy zapisać czas wykrycia awarii, czas uruchomienia systemu, rzeczywiste RTO i RPO oraz wykryte braki. Jeżeli plan zakłada odtworzenie ERP w cztery godziny, a test trwa dwanaście, firma posiada RTO zapisane w dokumencie, ale nie w rzeczywistości.

Krok 12. Utrzymuj plan w aktualności

Plan DR szybko się dezaktualizuje - zmieniają się serwery, adresy IP, hasła, pracownicy i wersje aplikacji. Dokumentację należy aktualizować po każdej większej zmianie, po migracji, po incydencie i po teście.

Jak wirtualizacja pomaga w Disaster Recovery?

Wirtualizacja ułatwia odtwarzanie, ponieważ system nie jest tak mocno związany z konkretnym sprzętem - maszynę wirtualną można zwykle przywrócić na innym hoście lub w drugim klastrze. Nie oznacza to jednak, że sama wirtualizacja zapewnia DR.

Snapshoty nie są pełnym backupem. Klaster w jednej lokalizacji nie chroni przed utratą budynku. Replikacja może przenieść uszkodzone lub zaszyfrowane dane. Wirtualizacja jest narzędziem ułatwiającym odzyskiwanie, a nie gotowym planem.

Monitoring planu DR

Nie wystarczy otrzymywać informację, że zadanie backupowe zakończyło się powodzeniem. Monitoring powinien sprawdzać czas ostatniego backupu, zgodność z RPO, stan kopii off-site, weryfikację danych i wynik ostatniego testu restore. Brak nowej kopii przez kilka dni powinien generować alarm, nawet jeżeli sam serwer produkcyjny działa poprawnie. Szczegółowo opisaliśmy to w artykule Jak monitorować backupy?

Najczęstsze błędy w planach Disaster Recovery

Kopia istnieje, ale nikt nie wie, gdzie ją odtworzyć i ile to potrwa. Systemy są uruchamiane przypadkowo, bez uwzględnienia zależności. A maszyna się uruchamia, ale ERP, integracje lub baza nie działają poprawnie.

Minimalny plan DR dla małej firmy

1. 1 listę systemów i danych,
2. 2 priorytety odzyskiwania,
3. 3 RTO i RPO,
4. 4 mapę zależności,
5. 5 lokalny backup,
6. 6 kopię off-site,
7. 7 warstwę immutable lub offline,
8. 8 listę kontaktów,
9. 9 procedury odzyskiwania,
10. 10 dostęp awaryjny do haseł,
11. 11 sposób pracy zastępczej,
12. 12 harmonogram testów.

To wystarczy, aby znacząco poprawić odporność firmy.

Plan wdrożenia na 30 dni

Po miesiącu firma nie będzie miała idealnego DR, ale będzie posiadała działający fundament zamiast niezweryfikowanych założeń.

Jak ocenić gotowość firmy?

Warto odpowiedzieć na pytania:

1. 1 Czy wiemy, które systemy są krytyczne?
2. 2 Czy znamy ich RTO i RPO?
3. 3 Czy kopia znajduje się poza główną lokalizacją?
4. 4 Czy ransomware może usunąć wszystkie backupy?
5. 5 Czy testowaliśmy przywracanie?
6. 6 Czy znamy kolejność uruchamiania systemów?
7. 7 Czy druga osoba posiada potrzebne dostępy?
8. 8 Czy plan jest dostępny poza podstawowym serwerem?
9. 9 Czy wiemy, jak pracować bez ERP lub serwera plików?
10. 10 Czy znamy rzeczywisty, a nie deklarowany czas restore?

Jeżeli na kilka pytań odpowiedź brzmi „nie wiem", firma powinna potraktować przygotowanie DR jako jedno z najważniejszych zadań infrastrukturalnych.

Podsumowanie

Disaster Recovery nie jest produktem, który można kupić i uznać temat za zakończony. To połączenie backupu, infrastruktury, dokumentacji, odpowiedzialności, komunikacji i testów.

Mała firma nie potrzebuje najbardziej zaawansowanego rozwiązania. Potrzebuje rozwiązania, które odpowiada na jej rzeczywiste ryzyko i które da się utrzymać.

Najważniejsze pytanie nie brzmi: „Czy mamy backup?" Powinno brzmieć: „Czy potrafimy przywrócić kluczowe systemy w czasie akceptowalnym dla firmy, nawet jeżeli stracimy podstawowy serwer, lokalizację albo konta administracyjne?"

W PRO-Admin przygotowujemy plany Disaster Recovery dla środowisk Windows, Linux, Proxmox, VMware, systemów ERP, baz danych i usług chmurowych. Rozpoczynamy od inwentaryzacji, RTO i RPO, a następnie projektujemy backup, kopię off-site, procedury odzyskiwania i testy. Celem nie jest stworzenie dokumentu, który trafi do szuflady. Celem jest potwierdzenie, że po awarii firma rzeczywiście potrafi wznowić działalność.