Backup zapisany w europejskim regionie nie musi oznaczać, że cała ścieżka przetwarzania danych pozostaje pod europejską kontrolą. W Kubernetes trzeba prześledzić nie tylko miejsce przechowywania plików, lecz także metadane, klucze, dostęp administracyjny, replikację i scenariusz odtwarzania po awarii.
Pytanie „czy backup jest w UE?” jest więc dobrym początkiem, ale zbyt wąskim kryterium wyboru architektury. W tym artykule pokazujemy, jak połączyć wymagania dotyczące suwerenności danych z możliwościami dobrze dobranej platformy backupu i Disaster Recovery (DR). Równie ważne są właściwy projekt, konfiguracja oraz regularne testy odtworzenia — dzięki nim technologia przekłada się na rzeczywistą odporność usługi.
W tym artykule
01. Suwerenność danych w Kubernetes
03. Mapa przepływów danych Kubernetes
04. Architektura backupu i DR w UE
05. Siedem decyzji dotyczących backupu i DR
06. CloudCasa — możliwości i dobór rozwiązania
07. Rola i usługi profesjonalne Sorigo
01. Suwerenność danych to więcej niż adres centrum danych
Na potrzeby projektowania infrastruktury warto rozróżnić trzy pojęcia. Rezydencja danych (data residency) opisuje miejsce ich przechowywania i przetwarzania. Suwerenność danych (data sovereignty) obejmuje dodatkowo kontrolę organizacyjną, jurysdykcję i zasady dostępu. Z kolei zgodność regulacyjna oznacza spełnienie konkretnych obowiązków, które zależą od rodzaju danych, branży, dostawców i modelu usług.
Jeżeli kopia bazy danych znajduje się w regionie chmurowym na terenie UE, ale katalog backupu jest utrzymywany gdzie indziej, klucze są zarządzane w innej jurysdykcji albo wsparcie dostawcy obejmuje dostęp z państwa trzeciego, konieczna jest analiza faktycznych odbiorców i przepływów. Zgodnie z wytycznymi EROD samo przebywanie administratora za granicą nie zawsze oznacza transfer w rozumieniu rozdziału V RODO; istotne jest między innymi, czy dane udostępniono odrębnemu podmiotowi w państwie trzecim. Żaden z tych elementów samodzielnie nie dowodzi naruszenia prawa, ale wymaga oceny podstaw i zabezpieczeń.
Warto w tym celu zacząć od przeglądu, jakim jest audyt platformy Kubernetes, obejmującego storage, RBAC, backup, DR i aspekty zgodności. Wyniki przeglądu pomagają dobrze dobrać oraz skonfigurować platformę ochrony danych.
02. RODO, NIS2, DORA: jakie pytania rzeczywiście trzeba zadać?
RODO nie ustanawia ogólnego nakazu przechowywania wszystkich danych osobowych wyłącznie w UE. Rozdział V określa warunki transferów danych osobowych poza Europejski Obszar Gospodarczy (EOG), a art. 32 wymaga zabezpieczeń adekwatnych do ryzyka, w tym możliwości terminowego przywrócenia dostępności danych i regularnego testowania skuteczności środków. Wymogi lokalizacji wyłącznie w UE mogą dodatkowo wynikać z kontraktów, przepisów sektorowych albo wewnętrznych polityk organizacji.
NIS2 w art. 21 wskazuje między innymi ciągłość działania, zarządzanie kopiami zapasowymi, odzyskiwanie po awarii i zarządzanie kryzysowe. Obowiązki danego podmiotu zależą od zakresu stosowania regulacji i przepisów krajowych. Z kolei DORA, istotna dla wskazanych kategorii podmiotów finansowych, w art. 12 wymaga udokumentowanych polityk backupu oraz procedur odtwarzania, ich okresowego testowania, a w określonych scenariuszach przywracania przy użyciu własnych systemów — logicznej i fizycznej separacji od systemu źródłowego.
Wniosek dla zespołu platformowego: nie należy utożsamiać „backup w UE” z „zgodnością z RODO/NIS2/DORA”. Trzeba umieć wykazać, co jest chronione, kto ma dostęp, gdzie przebiega przepływ danych i czy odtworzenie działa w praktyce.
03. Gdzie mogą trafić dane z klastra? Mapa, którą warto sporządzić przed wdrożeniem
Kubernetes rozdziela deklaratywną konfigurację, dane aplikacyjne, systemy storage i płaszczyznę zarządzania. Dlatego adres repozytorium obiektowego nie opisuje jeszcze wszystkich informacji niezbędnych do odtworzenia usługi. Osobno uwzględnij zasoby API, wolumeny, bazy danych, kopie etcd (w klastrach, za które odpowiada operator), metadane i katalog systemu backupowego, logi, klucze oraz komunikację agenta z usługą zarządzającą. W CloudCasa nawet tryb ochrony PV oparty wyłącznie na lokalnych snapshotach wiąże się z zapisem zasobów i metadanych klastra do zewnętrznego storage.
Snapshot wolumenu w Kubernetes jest użytecznym mechanizmem punktowego odtworzenia, ale nie zapewnia automatycznie niezależnej kopii poza domeną awarii. Podobnie eksport manifestów nie zastępuje ochrony danych aplikacyjnych. W przypadku baz danych trzeba także potwierdzić spójność — np. przez odpowiednie hooki, mechanizmy natywne dla silnika bazy lub świadomie zaprojektowany proces snapshotowania.
W środowiskach, w których za control plane odpowiada operator własnego klastra, osobnym elementem planu może być backup etcd. W usługach zarządzanych należy ustalić, które działania wykonuje dostawca, a które nadal leżą po stronie klienta. Nie ma jednego uniwersalnego zakresu backupu dla wszystkich dystrybucji Kubernetes.
04. Architektura referencyjna: trzy lokalizacje w UE i niezależne domeny awarii
Przy większej krytyczności rozwiązaniem referencyjnym mogą być trzy niezależne domeny awarii na terenie UE: produkcja w lokalizacji A, niezależne repozytorium kopii w lokalizacji B oraz odtwarzanie do klastra w lokalizacji C. W prostszych projektach dopuszczalna jest inna topologia, ale należy wtedy jawnie opisać wspólne zależności repozytorium i środowiska DR, w tym zasilanie, sieć, konta administracyjne, region chmurowy i dostawcę. Różne nazwy regionów na schemacie nie zastępują testu rzeczywistej separacji.
Najważniejszym ryzykiem nie jest wyłącznie utrata pojedynczego klastra. To również utrata konta administracyjnego, kluczy, repozytorium backupu albo usługi katalogowej. Dlatego warto rozdzielić role i uprawnienia, korzystać z retencji i niezmienialności kopii tam, gdzie wspiera je docelowy storage, a także zaplanować scenariusz przywracania bez dostępu do oryginalnego środowiska.
Przykład, jak projektuje się taką odporność od strony infrastruktury, opisuje realizacja Sorigo: platforma Kubernetes z redundancją geograficzną. Uwzględniono tam m.in. storage/CSI, HA/DR, backup, sieć, tożsamości i monitoring.
05. Siedem decyzji, które determinują skuteczność backupu i DR
1) Zdefiniuj granice dla danych i metadanych
Sporządź inwentaryzację kategorii danych, regionów, podprocesorów, katalogów backupu, logów i ścieżek wsparcia. Zweryfikuj także transfer do narzędzi obserwowalności i procedury serwisowe. Dopiero taki obraz pozwala świadomie określić, gdzie wymagana jest rezydencja UE, a gdzie konieczna jest dodatkowa analiza prawna.
2) Oddziel domeny awarii i uprawnienia
Przechowuj przynajmniej jedną przydatną do odtworzenia kopię poza pierwotnym obszarem awarii. Konto używane do zarządzania klastrem nie powinno automatycznie umożliwiać usunięcia całego repozytorium backupowego. Nie myl replikacji z backupem: replika może propagować uszkodzenie lub niepożądane zmiany.
3) Zaprojektuj kontrolę nad kluczami
Ustal, kto administruje KMS lub HSM, gdzie przetwarzane są klucze, jak wygląda ich rotacja i jak odzyskasz dostęp po utracie pierwotnej tożsamości. Szyfrowanie backupu nie wystarcza, jeżeli w scenariuszu awaryjnym klucz jest niedostępny lub zarządzany poza przyjętym modelem kontroli.
4) Połącz backup zasobów z danymi aplikacyjnymi
Odtworzenie Namespace, Deployment i PVC to dopiero krok techniczny. Usługa może nadal nie działać bez sekretów, certyfikatów, zależności sieciowych, DNS, polityk dostępu i spójnego stanu bazy. Zdefiniuj więc jednostką odtwarzania aplikację biznesową, a nie wyłącznie listę obiektów K8s.
5) Zdefiniuj RPO i RTO na poziomie usługi
RPO opisuje akceptowaną utratę danych w czasie, natomiast RTO — docelowy czas przywrócenia usługi. Parametry muszą odpowiadać realnemu profilowi biznesowemu. Sam harmonogram backupu nie dowodzi osiągnięcia RPO, a szybki restore pojedynczego PV nie potwierdza RTO pełnej aplikacji.
6) Przetestuj odtwarzanie do niezależnego środowiska w UE
Najbardziej wartościowy test obejmuje utratę źródłowego klastra, utworzenie lub przygotowanie klastra docelowego, odtworzenie storage i zasobów, rekonfigurację integracji oraz walidację aplikacji. Trzeba sprawdzić, czy tymczasowe dane testowe również pozostają w ustalonych granicach i są po teście usuwane.
7) Traktuj DR jako proces operacyjny, a nie projekt jednorazowy
Utrzymuj runbook, harmonogram testów, metryki, uprawnienia awaryjne i historię wyników. Zmiana wersji Kubernetes, klasy storage lub sposobu uwierzytelniania może naruszyć wcześniejsze założenia odtworzenia. Właściciel usługi powinien znać datę ostatniego udanego testu i zakres, który ten test rzeczywiście potwierdził.
06. CloudCasa w architekturze backupu i DR: możliwości oraz kryteria doboru
Dobrze dobrana platforma backupowa stanowi istotny element odporności Kubernetes. Przy wyborze należy przeanalizować obsługę sterowników CSI i rodzajów PV, zakres zasobów klastra, odtwarzanie do innego klastra, polityki retencji oraz niezmienialność kopii. Trzeba również rozróżnić snapshot pozostający w domenie źródłowej od kopii danych w niezależnym repozytorium: te mechanizmy rozwiązują odmienne problemy. Dla aplikacji stanowych warunkiem jest także weryfikacja spójności danych po restore.
Sorigo rekomenduje CloudCasa ze względu na konkretne możliwości ochrony Kubernetes: odtwarzanie zasobów i danych PVC z wybranego punktu do klastra źródłowego lub innego klastra, elastyczny dobór lokalizacji składowania oraz obsługę własnych repozytoriów S3/S3-compatible i Azure Blob. Producent dokumentuje także wariant self-hosted, w którym serwer, baza katalogowa MongoDB i agenci mogą działać w infrastrukturze klienta. Dane backupowe trafiają wtedy bezpośrednio z agenta do wybranego storage, bez przechodzenia przez serwer CloudCasa. To szczególnie interesujące w architekturach z rygorystycznymi wymaganiami rezydencji danych.
Wariant SaaS i wariant self-hosted trzeba jednak oceniać oddzielnie. W SaaS agent utrzymuje połączenie sterujące z usługą CloudCasa, a część operacji zarządzania repozytorium może korzystać z infrastruktury dostawcy; przed deklaracją rezydencji danych należy więc potwierdzić lokalizację katalogu, zakres metadanych, transfery i model dostępu. W self-hosted trzeba dodatkowo zabezpieczyć kopię katalogu MongoDB, logi oraz możliwość przywrócenia samej platformy zarządzającej. CloudCasa wspiera niezmienialne repozytoria przy wymaganej konfiguracji: w S3 Object Lock z domyślną retencją w trybie Compliance, a w Azure Blob z zablokowaną polityką version-level immutability. Dokumentacja wskazuje, że obsługa immutability wymaga płatnego planu. Właśnie połączenie tych funkcji z projektem, uprawnieniami i testami pozwala świadomie budować backup i DR w UE.
Jeśli celem jest spójność polityk w wielu klastrach i lepsza operacyjność, pomocne są też standardy zarządzania klastrami i automatyzacji — niezależnie od przyjętego produktu backupowego.
07. Gdzie w tym procesie realną wartość wnosi Sorigo?
W projektach Kubernetes backup łączy zagadnienia storage, sieci, DevOps, tożsamości, bezpieczeństwa i utrzymania. Rolą usług profesjonalnych Sorigo jest wykorzystanie możliwości wybranej platformy — w tym rekomendowanej CloudCasa — w konkretnej architekturze klienta: od analizy wymagań, przez wdrożenie i automatyzację, aż po pomiar skuteczności odtwarzania.
Etap I. Audyt i ocena ryzyka
Inwentaryzacja klastrów i obciążeń, mapa przepływów danych, analiza konfiguracji i uprawnień, zależności storage oraz istniejących kopii. Wynikiem jest lista luk i decyzji architektonicznych — nie tylko raport o błędnych ustawieniach.
Etap II. Architektura i wymagania operacyjne
Warsztaty z właścicielami aplikacji, bezpieczeństwem i compliance; uzgodnienie RPO/RTO, granic UE lub EOG zgodnie z polityką klienta, modelu kluczy, podwykonawców i scenariuszy testowych. Powstaje docelowy projekt architektury backupu i DR oraz lista wymagań dla wdrożenia CloudCasa.
Etap III. Wdrożenie i automatyzacja
Wdrażamy platformę ochrony danych dopasowaną do środowiska — w szczególności rekomendowaną CloudCasa, gdy spełnia wymagania projektu. Obejmuje to konfigurację backupu i odtwarzania, repozytoriów, polityk retencji, uprawnień, szyfrowania oraz monitoringu. Jeśli wybór pada na self-hosted, uwzględniamy również ochronę bazy katalogowej i platformy zarządzającej. Automatyzację i procesy GitOps/CI/CD integrujemy tam, gdzie wynikają z architektury; skuteczność potwierdzamy testem odzyskania usługi.
Etap IV. Testy odtworzenia i przekazanie wiedzy
Ćwiczenia odtwarzania do klastra docelowego, weryfikacja danych i funkcji biznesowych, pomiar czasu, dokumentacja odstępstw i przekazanie runbooków zespołowi utrzymania. Odbiór projektu opiera się na wynikach testu, a nie na komunikacie „backup zakończony sukcesem”.
Etap V. Rozwój i utrzymanie platformy
Przy zmianach środowiska równie ważne stają się przeglądy i obsługa eksploatacyjna. Usługi Kubernetes i mikroserwisowe Sorigo obejmują projektowanie HA/DR, dobór storage, DevOps i utrzymanie. W środowiskach hybrydowych uzupełnia je kompetencja wielochmurowego Kubernetes.
To nie jest abstrakcyjny model usługowy. W jednym z opublikowanych projektów Sorigo przeprowadziło audyt klastra Kubernetes w sektorze finansowym: oceniono ponad 20 węzłów w 9 obszarach, w tym backup, DR i business continuity, a następnie przygotowano roadmapę działań naprawczych.
Zobacz szczegóły realizacji: Audyt Klastra Kubernetes — case study Sorigo.
08. Checklista: siedem pytań przed deklaracją „nasze kopie są suwerenne”
Odpowiedź „nie wiemy” choćby na jedno pytanie krytyczne dla rezydencji lub odtwarzania oznacza lukę dowodową, a nie automatycznie naruszenie regulacji. Pierwszym krokiem powinno być sprawdzenie rzeczywistej konfiguracji backupu, katalogu, kluczy, dostępów oraz przebiegu testu. W zależności od wyniku wystarczy poprawić politykę lub konfigurację CloudCasa, albo trzeba zmienić separację domen awarii i procedurę DR.
FAQ: suwerenność danych i backup Kubernetes
Czy RODO wymaga trzymania backupu Kubernetes wyłącznie w UE?
Nie ma takiego ogólnego obowiązku. Transfer danych osobowych poza EOG podlega jednak zasadom rozdziału V RODO, a dodatkowe wymagania mogą wynikać z umów, regulacji sektorowych lub polityki organizacji.
Czy snapshot PVC jest pełnym backupem?
Niekoniecznie. Snapshot może służyć jako punkt przywrócenia wolumenu, lecz zakres ochrony i odporność zależą od dostawcy CSI, retencji, kopii poza domeną awarii i objęcia zasobów aplikacji. Sam snapshot nie dowodzi możliwości pełnego DR.
Czy DR można uruchomić w innym kraju UE?
Tak, technicznie jest to możliwe, ale architekturę trzeba odnieść do wymagań organizacji, rodzaju danych, zależności usługowych i kontraktów z dostawcami. „Inny kraj UE” nie gwarantuje jeszcze niezależności ryzyk, poprawności odtwarzania ani wymaganej wydajności.
Jak często należy testować odtwarzanie?
Częstotliwość wynika z krytyczności usługi, ryzyka, regulacji oraz tempa zmian infrastruktury. Co najmniej po istotnych zmianach warto ponowić testy wpływające na gotowość DR. Kluczowe jest dokumentowanie zakresu testu i uzyskanego wyniku.
Czy wdrożenie CloudCasa automatycznie zapewnia zgodność?
Nie. CloudCasa dostarcza funkcje pomocne w realizacji wymagań: własne repozytoria backupu, odtwarzanie między klastrami, ochronę niezmienialnych kopii (przy spełnieniu warunków planu i storage) oraz model self-hosted. Ocena zgodności zależy od konkretnego wdrożenia, danych osobowych, lokalizacji katalogu, dostępu dostawców, prawa właściwego i wyników testów. Tę samą zasadę należy stosować do każdej platformy backupu.
Jak połączyć właściwą technologię z gotowością do odtworzenia?
Warto zacząć od ustalenia, jaki system trzeba odtworzyć, w jakim czasie, z jakiego punktu odzyskiwania i pod czyją kontrolą. Na tej podstawie można wybrać i poprawnie wdrożyć platformę backupu oraz DR, a następnie sprawdzić jej działanie w realistycznym scenariuszu awarii.
Sorigo może wesprzeć zespół IT w audycie Kubernetesa, projektowaniu architektury backupu i DR w UE, doborze oraz wdrożeniu odpowiedniego rozwiązania — w tym rekomendowanej CloudCasa — i przetestowaniu scenariuszy awaryjnych. Skuteczna ochrona wymaga zarówno zaawansowanego narzędzia, jak i właściwego sposobu jego wykorzystania w codziennych procesach operacyjnych.
Jeśli chcesz przeanalizować własne środowisko, porozmawiaj z zespołem Sorigo o audycie gotowości backupu i Disaster Recovery w Kubernetes.
Źródła techniczne i regulacyjne
Podstawą sprawdzenia funkcji CloudCasa jest oficjalna dokumentacja docs.cloudcasa.io; pozostałe elementy techniczne i prawne porównano z dokumentacją Kubernetes, wytycznymi EROD i przepisami UE. Artykuł ma charakter edukacyjny i nie zastępuje indywidualnej oceny prawnej ani testu akceptacyjnego konkretnego wdrożenia.
RODO, rozporządzenie UE 2016/679 — art. 32 i rozdział V
Komisja Europejska — zasady transferu danych poza EOG
NIS2, dyrektywa UE 2022/2555 — art. 21
DORA, rozporządzenie UE 2022/2554 — art. 12
Kubernetes — Operating etcd clusters
CloudCasa — dokumentacja self-hosted: Overview
CloudCasa — dokumentacja magazynów backupu
CloudCasa — Kubernetes Restore Guide: odtwarzanie do klastra źródłowego lub alternatywnego
CloudCasa — instrukcja instalacji i wymogi self-hosted
CloudCasa — typy PV i metody backupu, ograniczenia CSI
CloudCasa — kopia zasobów i metadanych przy trybie snapshot-only
CloudCasa — komunikacja i usługi SaaS
CloudCasa — przepływ danych oraz izolacja self-hosted od SaaS