Ta strona opisuje, jak dziś wygląda kopia zapasowa i plan odzyskiwania po awarii dla samej platformy ipIII (SaaS EU) — nie jest to playbook dla klienta na wypadek jego własnego incydentu (ten znajduje się osobno, patrz Playbook L). Podajemy cel odzyskiwania (RTO/RPO), nie obietnicę zerowej utraty danych. Doktryna claim ≤ proof: co jest dziś mechanizmem działającym, oznaczamy LIVE; czego jeszcze nie przetestowaliśmy jako udokumentowany dowód, oznaczamy ROADMAP.
ipIII działa dziś w jednym trybie — SaaS EU, wspólna instancja, jedna baza PostgreSQL w regionie Unii Europejskiej (patrz deployment-modes). Backup opiera się dziś na zarządzanych snapshotach wolumenu bazy (Fly Postgres) — mechanizm infrastruktury, nie autorski system K0NSULT. Elementy podnoszące dojrzałość DR (kopia niezmienna/offline, replika w innym regionie, udokumentowany, cykliczny test odtworzenia) są dziś ROADMAP — nie udajemy, że są gotowe.
Data weryfikacji: 2026-07-05. Kolumna Status: LIVE = mechanizm działa dziś (dowód: konfiguracja usługi zarządzanej) · ROADMAP = plan, brak dziś udokumentowanego dowodu.
| Warstwa | Mechanizm | Status | Uwaga |
|---|---|---|---|
| Baza danych (PostgreSQL, silnik ipIII) |
Zarządzane snapshoty wolumenu — cykliczne kopie po stronie operatora infrastruktury (Fly Postgres). | LIVE | Mechanizm infrastrukturalny usługi zarządzanej, nie autorska aplikacja backupowa K0NSULT. Harmonogram i retencja — po stronie dostawcy usługi bazy. |
| Kod i konfiguracja aplikacji | Repozytorium Git (historia commitów) + obraz kontenera budowany deterministycznie z commita. | LIVE | Odtworzenie warstwy aplikacyjnej = redeploy z commita. To nie jest backup danych — to backup kodu/konfiguracji. |
| Integralność pojedynczego dowodu (evidence-package) |
package_sha256 + wpis chain-of-custody w bazie przy eksporcie. |
LIVE | Potwierdza niezmienność treści pojedynczego pliku, nie zastępuje backupu całej bazy. |
| Kopia niezmienna / offline (immutable, WORM) | Egzemplarz odporny na nadpisanie/szyfrowanie, odizolowany od bieżącej sieci. | ROADMAP | Bez tej warstwy snapshot online teoretycznie mógłby zostać naruszony razem z produkcją w scenariuszu kompromitacji poświadczeń infrastruktury. Priorytet P1. |
| Replika w innym regionie | Kopia danych utrzymywana poza jednym regionem UE, na wypadek awarii całego regionu. | ROADMAP | Dziś jeden region — zgodnie z deployment-modes. Zależy od decyzji o kolejnym regionie UE. Priorytet P1. |
| Udokumentowany test odtworzenia (restore test) | Regularna, zapisana próba przywrócenia bazy z kopii, z pomiarem faktycznego czasu. | ROADMAP | Dziś nie mamy jeszcze udokumentowanego dowodu (data, wynik, zmierzony czas) dla środowiska ipIII. Priorytet P0 — jak trafnie ujmuje to Playbook L: backup nieprzetestowany odtworzeniem to hipoteza, nie zabezpieczenie. |
Poniższe wartości to wewnętrzne cele projektowe (target), nie umowne SLA i nie deklaracja zerowej utraty danych. Rzeczywisty czas odzyskiwania w konkretnym incydencie może odbiegać od celu — zależy od przyczyny, dostępności zespołu i stanu kopii. Docelowe wartości SLA dla konkretnego wdrożenia enterprise ustala umowa, nie ta strona.
| Scenariusz | RTO (cel) | RPO (cel) | Status dowodu |
|---|---|---|---|
| Utrata/awaria instancji aplikacji (compute) | ≤ 1 godzina | ≈ 0 (bez utraty danych — dane trzyma osobno baza) | ROADMAP — cel niepotwierdzony jeszcze zmierzonym testem |
| Uszkodzenie/utrata bazy danych, restore z ostatniego snapshotu | ≤ 4 godziny | ≤ 24 godziny (odstęp do ostatniego snapshotu) | ROADMAP — cel niepotwierdzony jeszcze zmierzonym testem |
| Awaria całego regionu hostingu (region UE) | ≤ 24–48 godzin | ≤ 24 godziny | ROADMAP — zależy od repliki cross-region (dziś brak) |
Niższe RPO (mniejsza utrata danych) wymaga częstszego zapisu stanu bazy (np. archiwizacji WAL) zamiast pojedynczego snapshotu dobowego — to element tej samej mapy ROADMAP powyżej.
Szkielet proceduralny. Kroki decyzyjne wymagają człowieka — narzędzie nie wykonuje failover ani przywrócenia bazy automatycznie, bez nadzoru osoby odpowiedzialnej za operacje/bezpieczeństwo.
GET /api/ip3/v1/_health + test logowania + odczyt przykładowego incydentu, zanim dostęp zostanie przywrócony użytkownikom.Dojrzałe podejście do ciągłości zakłada regularny, zaplanowany test przywrócenia — nie tylko istnienie kopii. Cel: potwierdzić, że procedura restore rzeczywiście działa, i zmierzyć faktyczny czas, zamiast zakładać go teoretycznie.
Zamiar: test odtworzenia w regularnym cyklu (np. kwartalnym) na środowisku nieprodukcyjnym, z zapisanym protokołem (data, scenariusz, zmierzony RTO/RPO, wynik).
Nie mamy jeszcze udokumentowanego, przeprowadzonego drillu dla środowiska ipIII. To jawny gap — nie ukrywamy go, tak jak w known-limitations.
Po pierwszym przeprowadzonym drillu wynik trafi do status-matrix i roadmap-dev — z datą, scenariuszem i zmierzonym czasem, nie jako gołosłowna deklaracja.
Testy odporności ICT (w tym scenariusze DR) mieszczą się w logice testów odporności opisanych w DORA/TIBER Pack — tam również jawnie oznaczonych jako wsparcie, nie jako formalny test regulacyjny.
Powiązane: tryby wdrożenia i gdzie leżą dane → /deployment-modes · pełny rejestr znanych ograniczeń → /known-limitations · playbook ciągłości dla incydentu klienta → /playbook-ciaglosc · żywy status komponentów → /status-matrix.