Infrastruktura

Backup EZD RP — strategia, narzędzia, retencja

Strategia backup'u EZD RP: co backupować, jak często, gdzie przechowywać, kiedy testować odtwarzanie. Praktyczne wskazówki dla on-premise i SaaS.

Stan na 2026-05-13 • Bazujemy na oficjalnych źródłach NASK / gov.pl

Backup w EZD RP to nie tylko 'kopia bazy' — system ma kilka warstw danych, które trzeba backupować spójnie. Najgorszy scenariusz: backupy są, ale przy odtwarzaniu okazuje się, że nie pasują do siebie.

Co trzeba backupować

  • Baza danych (PostgreSQL/MS SQL) — wszystkie metadane: sprawy, dokumenty, użytkownicy, JRWA
  • Repozytorium plików (NFS / MinIO) — same pliki załączników
  • Konfiguracja klastra (etcd dla K8s) — definicje deploymentów, secrety
  • Certyfikaty — KSeF, SSL, kwalifikowane
  • Konfiguracja EZD RP — ustawienia, role, struktura organizacyjna

Strategia 3-2-1

Klasyczna reguła: 3 kopie danych, 2 różne nośniki, 1 kopia offsite (poza serwerownią).

WarstwaCzęstotliwośćRetencjaLokalizacja
WAL (PostgreSQL ciągły)Co minutę7 dniStorage lokalny + S3
Pełny backup bazyCodziennie 02:0030 dniS3 + offsite
Snapshot repozytorium plikówCodziennie 03:0030 dniS3 + offsite
Backup etcd (K8s)Co 6 godzin7 dniStorage lokalny
Konfiguracja EZD RP (export)Co tydzień12 miesięcyRepo Git + offsite
Pełny snapshot systemuCo miesiąc12 miesięcyOffsite
Test odtwarzania
Backup bez testu = brak backup'u. Minimum raz na kwartał trzeba przeprowadzić pełne odtwarzanie systemu na środowisku testowym. Inaczej w awarii odkryjesz, że backupy nie są kompletne.

SaaS — kto odpowiada za backup

W SaaS dostawca odpowiada za backup całej infrastruktury. Twoja jednostka odpowiada za:

  • Sprawdzenie SLA (jaka częstotliwość, jaka retencja)
  • Konfigurację — Twój eksport JRWA, struktury organizacyjnej (na wypadek opuszczenia dostawcy)
  • Politykę 'data sovereignty' — gdzie fizycznie są backupy
Polityka backup gotowa do produkcji
  • RPO i RTO udokumentowane (co możemy stracić, w jakim czasie odtworzymy)
  • Strategia 3-2-1 wdrożona
  • Testy odtwarzania przeprowadzone min. raz na kwartał
  • Procedura awaryjna spisana (kto co robi w razie awarii)
  • Lista osób z dostępem do backupów (i osób zastępczych)
  • Backup'y zaszyfrowane (zwłaszcza offsite)
  • Monitoring statusu backupu (alert, gdy backup się nie wykonał)
Źródła oficjalne
Audyt strategii backup

Sprawdzimy, czy Wasze backupy faktycznie chronią dane i czy odtwarzanie zadziała.

Umów audyt

Najczęstsze pytania

Czy backup bazy wystarczy?

Nie — bez backup'u repozytorium plików odtworzysz metadane, ale bez samych dokumentów. Trzeba backupować obie warstwy spójnie.

Jak długo przechowywać backupy?

Standardowo: 30 dni codziennie + 12 miesięcy miesięcznie. Część dokumentów EZD ma wieloletnią retencję — ale to inna sprawa (archiwum, nie backup).

Czy backup zastępuje archiwizację?

Nie. Backup chroni przed awarią. Archiwizacja (paczki ADE) realizuje wymóg prawny długiej retencji dokumentów.

Czytaj dalej

Infrastruktura
RTO i RPO dla EZD RP — definicje, cele, jak mierzyć
Co to są RTO (Recovery Time Objective) i RPO (Recovery Point Objective), jakie wartości są realne dla EZD RP w różnych modelach wdrożenia, jak je zmierzyć.
Infrastruktura
Wymagania sprzętowe EZD RP — Kubernetes, bazy, repozytoria
Komponenty wymagane do produkcyjnego uruchomienia EZD RP: klaster Kubernetes (RKE2), PostgreSQL/MS SQL, Redis, RabbitMQ, NFS/MinIO, backup. Minimalne, rekomendowane i konkretne konfiguracje dla 3 skal jednostek.
Model: on-premise
EZD RP on-premise — instalacja we własnej infrastrukturze
On-premise: pełna kontrola nad infrastrukturą i konfiguracją EZD RP — kosztem zespołu IT i serwerów. Dla kogo ma sens, architektura referencyjna, ścieżka wdrożenia, koszty i ryzyka.