Storing a backup in a European region does not necessarily mean that the entire data processing chain remains under European control. In Kubernetes, you need to track not only where files are stored, but also metadata, encryption keys, administrative access, replication and disaster recovery procedures.
The question “Is the backup stored in the EU?” is therefore a good starting point, but too narrow a criterion for choosing an architecture. In this article, we explain how to combine data sovereignty requirements with the capabilities of a well-selected backup and Disaster Recovery (DR) platform. Proper design, configuration and regular recovery testing are equally important — they are what turn technology into genuine service resilience.
In this article
01. Data sovereignty in Kubernetes
03. Mapping Kubernetes data flows
04. Backup and DR architecture within the EU
05. Seven key backup and DR decisions
06. CloudCasa — capabilities and solution selection
07. Sorigo’s role and professional services
08. Data sovereignty checklist
01. Data sovereignty is about more than the location of a data centre
When designing infrastructure, it is worth distinguishing between three concepts. Data residency describes where data is stored and processed. Data sovereignty goes further, covering organisational control, jurisdiction and access policies. Regulatory compliance, in turn, means meeting specific obligations that depend on the type of data, industry, providers and service model.
If a database backup is stored in an EU cloud region, but the backup catalogue is maintained elsewhere, encryption keys are managed under a different jurisdiction, or the provider’s support arrangements allow access from a third country, the actual recipients and data flows need to be assessed. According to EDPB guidelines, an administrator being located abroad does not automatically constitute a transfer under Chapter V of the GDPR. Among other factors, it matters whether the data is made available to a separate entity in a third country. None of these elements alone proves a legal violation, but each requires an assessment of the applicable legal basis and safeguards.
A good starting point is a Kubernetes platform audit, covering storage, RBAC, backup, DR and compliance aspects. The findings help identify the right data protection platform and configure it appropriately.
02. GDPR, NIS2 and DORA: what questions actually need to be asked?
The GDPR does not impose a general requirement to store all personal data exclusively within the EU. Chapter V sets out the conditions for transferring personal data outside the European Economic Area (EEA), while Article 32 requires security measures appropriate to the level of risk. These include the ability to restore data availability in a timely manner and regularly test the effectiveness of security measures. Requirements to keep data exclusively within the EU may also arise from contracts, sector-specific regulations or an organisation’s internal policies.
Article 21 of NIS2 addresses, among other things, business continuity, backup management, disaster recovery and crisis management. The obligations applicable to a given entity depend on the directive’s scope and national implementing legislation. DORA, which applies to specific categories of financial entities, requires documented backup policies and recovery procedures under Article 12. It also requires periodic testing and, in certain scenarios involving recovery through an entity’s own systems, logical and physical separation from the source system.
The takeaway for platform teams: “backup in the EU” should not be treated as equivalent to “GDPR/NIS2/DORA compliance”. Organisations must be able to demonstrate what is protected, who has access, where data flows and whether recovery actually works in practice.
03. Where can data from a cluster end up? A map worth creating before implementation
Kubernetes separates declarative configuration, application data, storage systems and the management plane. This means that the address of an object storage repository does not tell you where all the information required to restore a service is located. You should separately account for API resources, volumes, databases, etcd backups (in clusters managed by the operator), metadata and the backup system catalogue, logs, encryption keys and communication between the agent and the management service. With CloudCasa, even PV protection based exclusively on local snapshots involves writing cluster resources and metadata to external storage.
A Kubernetes volume snapshot is a useful point-in-time recovery mechanism, but it does not automatically provide an independent copy outside the original failure domain. Similarly, exporting manifests does not replace application data protection. For databases, consistency must also be verified — for example, through appropriate hooks, database-native mechanisms or a deliberately designed snapshot process.
In environments where the operator is responsible for the control plane of a self-managed cluster, etcd backup may be a separate component of the recovery plan. With managed services, it is important to establish which operations are handled by the provider and which remain the customer’s responsibility. There is no single universal backup scope that applies to every Kubernetes distribution.
04. Reference architecture: three EU locations and independent failure domains
For more critical workloads, a reference architecture may consist of three independent failure domains within the EU: production in location A, an independent backup repository in location B, and recovery to a cluster in location C. Simpler projects may use a different topology, but any shared dependencies between the repository and DR environment must then be explicitly documented. These include power supply, networking, administrative accounts, cloud regions and providers. Different region names on an architecture diagram are no substitute for testing actual isolation.
The biggest risk is not limited to losing a single cluster. It also includes losing an administrative account, encryption keys, the backup repository or the identity management service. That is why it is worth separating roles and permissions, using retention policies and backup immutability wherever supported by the target storage, and planning a recovery scenario that does not depend on access to the original environment.
An example of how this type of infrastructure resilience can be designed is presented in a Sorigo project: Geographically Redundant Kubernetes Platform. The project covered storage/CSI, HA/DR, backup, networking, identity management and monitoring.
05. Seven decisions that determine backup and DR effectiveness
1) Define boundaries for data and metadata
Create an inventory of data categories, regions, subprocessors, backup catalogues, logs and support access paths. Also verify transfers to observability tools and service procedures. Only with this overview can you consciously determine where EU data residency is required and where additional legal analysis is necessary.
2) Separate failure domains and access permissions
Keep at least one recovery-capable copy outside the original failure domain. An account used to manage a cluster should not automatically be able to delete the entire backup repository. Do not confuse replication with backup: replication can propagate corruption or unwanted changes.
3) Design encryption key management
Determine who administers the KMS or HSM, where keys are processed, how rotation works and how access can be recovered after losing the original identity. Encrypting backups is not enough if the key is unavailable during a disaster or managed outside the agreed control model.
4) Combine resource backups with application data protection
Restoring a Namespace, Deployment and PVC is only a technical step. The service may still fail without secrets, certificates, network dependencies, DNS, access policies and a consistent database state. Define the business application, rather than just a list of Kubernetes objects, as the recovery unit.
5) Define RPO and RTO at the service level
RPO describes the acceptable amount of data loss measured in time, while RTO defines the target time for restoring a service. These parameters must reflect actual business requirements. A backup schedule alone does not prove that the RPO can be achieved, and a fast restore of a single PV does not confirm the RTO of an entire application.
6) Test recovery to an independent environment within the EU
The most valuable test covers the loss of the source cluster, creation or preparation of a target cluster, restoration of storage and resources, reconfiguration of integrations and application validation. You should also verify that temporary test data remains within the agreed boundaries and is removed after the test.
7) Treat DR as an operational process, not a one-off project
Maintain runbooks, testing schedules, metrics, emergency access permissions and a history of test results. Changes to the Kubernetes version, storage class or authentication method may invalidate previous recovery assumptions. The service owner should know when the last successful test took place and exactly what that test confirmed.
06. CloudCasa in backup and DR architecture: capabilities and selection criteria
A well-selected backup platform is an important component of Kubernetes resilience. When choosing one, analyse its support for CSI drivers and PV types, the scope of cluster resources it protects, recovery to another cluster, retention policies and backup immutability. You should also distinguish between a snapshot that remains within the source failure domain and a data copy stored in an independent repository: these mechanisms solve different problems. For stateful applications, verifying data consistency after restoration is also essential.
Sorigo recommends CloudCasa because of its specific Kubernetes protection capabilities: restoring resources and PVC data from a selected recovery point to either the source cluster or another cluster, flexible selection of storage locations, and support for custom S3/S3-compatible repositories and Azure Blob. The vendor also documents a self-hosted deployment option in which the server, MongoDB catalogue database and agents can run within the customer’s infrastructure. In this model, backup data flows directly from the agent to the selected storage without passing through the CloudCasa server. This is particularly interesting for architectures with strict data residency requirements.
However, SaaS and self-hosted deployments need to be assessed separately. In SaaS, the agent maintains a control connection to the CloudCasa service, and some repository management operations may use the provider’s infrastructure. Before making any claims about data residency, you should therefore verify the catalogue location, metadata scope, data transfers and access model. With self-hosted deployments, you must also protect the MongoDB catalogue backup, logs and the ability to restore the management platform itself. CloudCasa supports immutable repositories when configured appropriately: for S3, Object Lock with default retention in Compliance mode; for Azure Blob, a locked version-level immutability policy. The documentation states that immutability support requires a paid plan. Combining these capabilities with proper architecture, permissions and testing is what makes it possible to build a well-controlled backup and DR strategy within the EU.
If the goal is to maintain consistent policies across multiple clusters and improve operational management, cluster management and automation standards can also help, regardless of the backup product selected.
07. Where does Sorigo bring real value to this process?
In Kubernetes projects, backup involves storage, networking, DevOps, identity management, security and operations. Sorigo’s professional services focus on applying the capabilities of the selected platform — including the recommended CloudCasa solution — to the customer’s specific architecture. This covers everything from requirements analysis and implementation to automation and measuring recovery effectiveness.
Stage I. Audit and risk assessment
Inventory of clusters and workloads, data flow mapping, configuration and permissions analysis, storage dependencies and existing backup solutions. The outcome is a list of gaps and architectural decisions — not just a report highlighting incorrect settings.
Stage II. Architecture and operational requirements
Workshops with application owners, security and compliance teams; agreement on RPO/RTO, EU or EEA boundaries in line with the customer’s policies, encryption key management, subcontractors and testing scenarios. The result is a target backup and DR architecture design and a list of requirements for CloudCasa implementation.
Stage III. Implementation and automation
We implement a data protection platform tailored to the environment — in particular, our recommended CloudCasa solution where it meets the project’s requirements. This includes configuring backup and recovery, repositories, retention policies, permissions, encryption and monitoring. If a self-hosted deployment is selected, we also account for protecting the catalogue database and management platform. We integrate automation and GitOps/CI/CD processes wherever required by the architecture, and verify their effectiveness through a service recovery test.
Stage IV. Recovery testing and knowledge transfer
Recovery exercises to the target cluster, verification of data and business functionality, time measurements, documentation of deviations and handover of runbooks to the operations team. Project acceptance is based on test results, not simply a “backup completed successfully” notification.
Stage V. Platform development and maintenance
As the environment evolves, regular reviews and operational support become equally important. Sorigo’s Kubernetes and Microservices services cover HA/DR architecture, storage selection, DevOps and maintenance. In hybrid environments, these services are complemented by our multi-cloud Kubernetes expertise.
This is not just an abstract service model. In one of its published projects, Sorigo conducted a Kubernetes cluster audit for an organisation in the financial sector. More than 20 nodes were assessed across 9 areas, including backup, DR and business continuity. The project also resulted in a roadmap of corrective actions.
Explore the project: Kubernetes Cluster Audit — Sorigo Case Study.
08. Checklist: seven questions to answer before claiming “our backups are sovereign”
An “unknown” answer to even one question critical to data residency or recovery indicates an evidence gap, not automatically a regulatory violation. The first step should be to verify the actual configuration of backups, the catalogue, encryption keys, access permissions and the recovery testing process. Depending on the findings, it may be sufficient to adjust a policy or CloudCasa configuration, or it may be necessary to change the separation of failure domains and the DR procedure.
FAQ: Data sovereignty and Kubernetes backup
Does the GDPR require Kubernetes backups to be stored exclusively within the EU?
There is no such general requirement. However, transfers of personal data outside the EEA are subject to the rules set out in Chapter V of the GDPR. Additional requirements may also arise from contracts, sector-specific regulations or an organisation’s internal policies.
Is a PVC snapshot a complete backup?
Not necessarily. A snapshot can serve as a volume recovery point, but the scope of protection and resilience depend on the CSI provider, retention policies, copies outside the failure domain and whether application resources are also protected. A snapshot alone does not prove that full DR is possible.
Can DR be set up in another EU country?
Yes, this is technically possible, but the architecture must be assessed against the organisation’s requirements, data types, service dependencies and provider contracts. Being located in “another EU country” does not automatically guarantee independent risk domains, successful recovery or the required performance.
How often should recovery be tested?
The frequency depends on service criticality, risk, regulatory requirements and the pace of infrastructure changes. At a minimum, testing should be repeated after significant changes that affect DR readiness. Documenting the scope and results of each test is essential.
Does implementing CloudCasa automatically ensure compliance?
No. CloudCasa provides capabilities that help meet relevant requirements: custom backup repositories, cross-cluster recovery, immutable backup protection (subject to plan and storage requirements) and a self-hosted deployment model. Compliance depends on the actual implementation, personal data involved, catalogue location, provider access, applicable jurisdiction and test results. The same principle applies to every backup platform.
How do you combine the right technology with actual recovery readiness?
The best starting point is to determine which system needs to be restored, how quickly, from which recovery point and under whose control. This provides the foundation for selecting and correctly implementing a backup and DR platform, followed by validating its operation in a realistic disaster scenario.
Sorigo can support your IT team with Kubernetes audits, EU-based backup and DR architecture design, selection and implementation of the right solution — including our recommended CloudCasa platform — and testing of disaster recovery scenarios. Effective protection requires both an advanced tool and the right approach to using it in everyday operational processes.
If you would like to assess your own environment, get in touch with the Sorigo team to discuss a Kubernetes backup and Disaster Recovery readiness audit.
Technical and regulatory references
The official docs.cloudcasa.io documentation is the primary source for verifying CloudCasa capabilities. Other technical and legal aspects have been cross-checked against Kubernetes documentation, EDPB guidelines and EU legislation. This article is intended for educational purposes and does not replace an individual legal assessment or an acceptance test of a specific implementation.
GDPR, Regulation (EU) 2016/679 — Article 32 and Chapter V
European Commission — Rules on international data transfers outside the EEA
NIS2, Directive (EU) 2022/2555 — Article 21
DORA, Regulation (EU) 2022/2554 — Article 12
Kubernetes — Operating etcd clusters
CloudCasa — Self-hosted documentation: Overview
CloudCasa — Backup storage documentation
CloudCasa — Kubernetes Restore Guide: Restoring to the source or an alternative cluster
CloudCasa — Self-hosted installation guide and requirements
CloudCasa — PV types, backup methods and CSI limitations
CloudCasa — Resource and metadata backup in snapshot-only mode
CloudCasa — Communication and SaaS services
CloudCasa — Data flow and self-hosted isolation from SaaS
CloudCasa — MongoDB catalogue backup and recovery
EDPB — Guidelines 05/2021 on the interplay between Article 3 and Chapter V of the GDPR