Infrastruktura

Backup EZD RP — strategia 3-2-1

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

Bazujemy na oficjalnych źródłach NASK / gov.pl. Linki źródłowe: na dole strony.
Ilustracja: Infrastruktura — Backup EZD RP — strategia 3-2-1

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
Sprawdzone: 30 maja 2026
Audyt strategii backup

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

Umów audyt
Wsparcie wdrożeniowe
Potrzebujesz wsparcia we wdrożeniu lub konfiguracji? Skontaktuj się z zespołem Lynx360 — bezpłatna pierwsza konsultacja.
Audyt środowiska technicznego →

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 — wartości i pomiar
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, PostgreSQL, MinIO
Sprawdź wymagania infrastrukturalne EZD RP dla małej, średniej i dużej jednostki: klastry, bazy danych, storage, backup, monitoring i HA.
Model: on-premise
EZD RP on-premise: infrastruktura, Kubernetes, koszty
Jak wdrożyć EZD RP we własnej infrastrukturze: Kubernetes, baza danych, Redis, RabbitMQ, repozytorium plików, backup, RTO/RPO i kompetencje IT.