Plan Disaster Recovery (DR) dla środowiska Humansoft HermesSQL określa procedury przywracania systemu po katastrofalnej awarii – pożarze serwerowni, zalaniu, rozległym ataku ransomware lub długotrwałej awarii zasilania. Firma bez planu DR działa na zasadzie "zobaczymy co się stanie" – często z dramatycznymi konsekwencjami dla ciągłości biznesu.
Nasz serwis opracowuje i wdraża plany Disaster Recovery dla środowisk HermesSQL, definiując cele RTO i RPO oraz techniczne mechanizmy szybkiego przywrócenia działania po katastrofie.
Kluczowe parametry planu DR
Plan DR definiuje dwa kluczowe parametry, z których firma musi sobie zdawać sprawę:
- RTO (Recovery Time Objective): maksymalny akceptowalny czas przywrócenia systemu – np. "HermesSQL musi być dostępny w ciągu 4 godzin od zgłoszenia awarii"
- RPO (Recovery Point Objective): maksymalna akceptowalna utrata danych – np. "Możemy stracić najwyżej 1 godzinę danych"
Te dwa parametry definiują wymaganą architekturę DR: niskie RPO wymaga częstych backupów lub replikacji, niskie RTO wymaga gotowego środowiska zastępczego.
Techniczne elementy DR dla HermesSQL
Wdrażamy elementy DR dostosowane do możliwości finansowych i wymagań klienta: backup w chmurze (replikacja plików backupu do Azure/S3), zapasowy serwer w gotowości ciepłej (warm standby) lub zimnej (cold standby), dokumentacja procedur przywrócenia z każdego scenariusza awarii.
Testy planu DR
Plan DR, który nie był testowany, to plan, który najprawdopodobniej nie zadziała w kryzysie. Przeprowadzamy coroczne testy DR: symulujemy utratę serwera i mierzymy rzeczywisty czas przywrócenia. Wyniki testów trafiają do raportu i mogą skutkować korektą procedur lub rozbudową infrastruktury DR.
