Rekomendowana strategia backupów i przywracania systemu EZD RP

Podczas dokonywania wyborów dotyczących architektury infrastruktury EZD RP istotne jest uwzględnienie polityki organizacji w zakresie backupów i ciągłości działania. Wybór odpowiedniej architektury powinien być zgodny z wymaganiami dotyczącymi ochrony danych oraz planem przywracania systemu w razie awarii. Jest to szczególnie istotne w przypadku usług przechowujących dane wyniesionych poza klaster Kubernetes, takich jak bazy danych, systemy kolejkowe czy repozytoria plików.

Prawidłowe zarządzanie kopiami zapasowymi oraz procesem przywracania systemu jest kluczowe dla zapewnienia ciągłości działania aplikacji EZD RP, szczególnie w kontekście wysokiej dostępności (HA). Wybór strategii backupu oraz mechanizmów przywracania należy zestawić z oczekiwanymi parametrami RPO (Recovery Point Objective) i RTO (Recovery Time Objective). Pozwoli to zminimalizować ryzyko utraty danych i skrócić czas ewentualnych przestojów w przypadku awarii.

Cel backupów w kontekście wysokiej dostępności (HA)

Celem backupów w kontekście wysokiej dostępności jest zapewnienie, że w przypadku nawet poważnej awarii organizacja jest w stanie szybko przywrócić działanie systemu z minimalną utratą danych. RPO określa maksymalną ilość danych, którą można utracić, podczas gdy RTO definiuje maksymalny dopuszczalny czas potrzebny na przywrócenie systemu do pełnej operacyjności.

Osiągnięcie tych celów wymaga:

• implementacji klastrów w trybie active-active lub active-passive – zapewniają one, że w przypadku awarii jednego z węzłów inny węzeł automatycznie przejmuje jego rolę i minimalizuje wpływ incydentu na ciągłość działania systemu;
• zastosowania replikacji danych – wybór między replikacją synchroniczną a asynchroniczną wpływa na czas przywracania danych oraz poziom ich utraty. Replikacja synchroniczna gwarantuje pełną zgodność danych między węzłami, ale może wpłynąć na wydajność. Replikacja asynchroniczna jest szybsza, ale jej zastosowanie może przełożyć się na większą stratę danych w przypadku awarii.

Zalecenia dotyczące backupów

W kontekście systemu EZD RP zaleca się wykonywanie kopii zapasowych jedynie danych persystentnych, które są kluczowe dla działania systemu. Należą do nich:

• Relacyjna baza danych – regularne backupy baz danych PostgreSQL/MS SQL są kluczowe dla ochrony danych biznesowych.
• Systemy kolejkowe i mechanizmy zarządzania danymi – Redis i Rabbit pełnią kluczową rolę nie tylko jako systemy cache i kolejkowe, ale również zapewniają ciągłość identyfikatorów oraz innych krytycznych mechanizmów systemu. Regularny backup ich zawartości jest niezbędny dla zachowania integralności i ciągłości operacji systemu po awarii.
• Repozytorium plików – kopie bezpieczeństwa danych przechowywanych w udziałach NFS lub repozytoriach obiektowych zapobiegają utracie dokumentów i plików.

Proces przywracania systemu

W przypadku awarii proces przywracania systemu EZD RP musi być przebiegać zgodnie z przyjętą w organizacji polityką w tym zakresie. Wykonywane w określonej kolejności kroki zależą od rodzaju uszkodzeń i elementów, które wymagają przywrócenia. Przedstawiamy ogólne zasady odtwarzania danych i przywracania pozostałych elementów środowiska EZD RP.

Odtwarzanie danych z backupów:

• Pierwszym krokiem jest odtworzenie wszystkich danych persystentnych z backupów. Dotyczy to relacyjnych baz danych (PostgreSQL/MS SQL), zawartości systemów kolejkowych i mechanizmów zarządzania danymi (Redis, Rabbit), a także repozytoriów plików (NFS lub repozytorium obiektowe). Te dane są kluczowe dla przywrócenia pełnej funkcjonalności systemu.

Przywracanie pozostałych elementów systemu:

• maszyny wirtualne – mogą być przywrócone z backupów lub, w zależności od scenariusza, ponownie zainstalowane przy użyciu narzędzi automatyzujących, takich jak szablony maszyn wirtualnych.
• środowisko Kubernetes – w przypadku awarii szybkie ponowne zainstalowanie Kubernetes i podłączenie do odtworzonych usług jest kluczowe. Do odtwarzania środowiska warto wykorzystać narzędzia, które zapewnią automatyzację konfiguracji i wdrożenia aplikacji w środowisku Kubernetes.
• HA Proxy i inne elementy sieciowe – komponenty mogą być ponownie zainstalowane lub skonfigurowane zgodnie z wcześniejszymi opisami, np. za pomocą narzędzi takich, jak Ansible lub Terraform.
• kontenery aplikacji EZD RP – mogą być odtworzone poprzez ponowne uruchomienie z wcześniej przygotowanych kontenerów zdefiniowanych w HelmChart. Decyzja dotycząca ponownego uruchomienia lub reinstallacji zależy od specyfiki awarii i tego, czy kontenery zostały uszkodzone.