Backup placement is the part of a residency decision that a production-only review leaves unanswered. A production-only review approves one dataset in one place. Unless it explicitly includes the repository, copy-job target, replica and archive tier, it does not establish that those destinations meet the same residency boundary. Each of those destinations holds a placed copy of the same data, placed by whoever configured it, at the time they configured it.
This post makes a narrow argument. It does not claim that a regulation requires backups to sit beside production, and it does not claim that any vendor fails to control where copies go. It argues that backup placement is its own architecture decision, and that it needs its own inventory, a named owner and a verification routine, evaluated apart from the production dataset.
The residency review covered one dataset. Its copies sit outside the boundary, unexamined.
Backup Placement Is Not Production Placement
Production placement is a design-time decision. Someone chooses a region or a site, a review confirms it against the residency requirement, and the decision is recorded. Copy placement is a configuration-time decision. It is made when a backup job gets a target, when a replication policy gets a destination, when a tiering rule gets a bucket. The two decisions typically have different owners, different change paths and different review gates, so approving one says nothing about the other. That makes this a data protection architecture question before it is a compliance one.
Isolation is a different property again. A repository can be isolated by account and identity and still sit in a location nobody assessed. Your Backup System Is Part of the Blast Radius covers the isolation side of backup design; as that post puts it, isolation is measured by what the system depends on, not where it resides. The broader platform-level jurisdiction problem is covered in Sovereign Cloud vs. Public Cloud: Navigating Compliance in a Non-Deterministic Landscape. This post applies the question to the copies.
The Copy Paths a Residency Review Misses
A residency review that starts and ends with the production dataset covers one row of the inventory below. Backup placement is spread across every other row: each is a placed copy or a recovery destination, with its own point at which its location is decided.
| Item | Typically created by | Where its placement is decided |
|---|---|---|
| Production baseline (not a copy) | Application and platform owners | Architecture and residency review |
| Primary backup repository | Backup administration | Repository or storage target configuration |
| Secondary copy-job target | Backup administration | Copy job or policy settings |
| Replica or DR target | Backup or DR administration | Replication policy or DR design |
| Archive or cloud-tier copy | Backup administration or storage teams | Tiering, archive or cloud-target policy |
| Restore target (a destination, not necessarily a stored copy) | Recovery operators, at restore time | The recovery runbook or the restore operation itself |
The production baseline is the reference row. Every row below it has a placement decision of its own. A production review covers those decisions only when it explicitly includes them. A replica or DR target deserves its own line because it is built to be used during an outage, so the location that matters is the one the data is recovered from, not only the one it is stored in.
A restore target is not necessarily a retained backup copy. It is a destination into which data is restored, and the access paths around it matter while recovery is running. It belongs in the inventory with that label.
Backup catalogs and metadata belong on the inventory as well. This post makes no claim about how any product places them. It notes only that a register listing the data copies and omitting the records that describe them is incomplete, and that the architect should ask the question.
What Two Vendors Show, and What They Don't
Two vendor documents illustrate the pattern: the Veeam ONE 13 user guide and Rubrik's API reference. They are examples of how backup placement can be handled. This is not a comparison, and nothing here describes what other vendors offer or what either product can do beyond what these pages state.
| Source | What it shows | What it does not establish |
|---|---|---|
| Veeam ONE 13 | Location-based reporting and mismatch detection across protected objects, backups, backup copies and replicas. Locations are configured assignments on infrastructure objects. | Independent verification of physical residency or legal jurisdiction. The Veeam ONE and Veeam Backup & Replication topology views must match; otherwise report data can be invalid. |
| Rubrik API | A replication specification accepts a cloud provider and target region, alongside retention settings. | Whether the target is validated against a residency policy or continuously enforced. |
Veeam ONE's Data Sovereignty report presents protected objects, backups and replicas "grouped by location," and a companion Data Sovereignty Violations report lists protected objects with backups or replicas “residing in a different location.”. Because locations are configured assignments, the report tells you where Veeam has been told things are, and where those configured locations disagree. That is useful detection. It is not proof of where the bytes physically sit, and it is not a finding of legal noncompliance. Veeam also notes that the topology views in Veeam ONE and Veeam Backup & Replication must match, or the report data can be invalid, so the report is only as reliable as the configuration behind it.
Rubrik's developer documentation describes a ReplicationToCloudRegionSpecInput type with four fields: cloudProvider ("Replication cloud provider"), replicationTargetRegion ("Replication target region"), retention ("Retention period on replication region") and retentionUnit ("Unit of retention period"). The target region is a string input to the replication specification. The reference documents the field. It does not say whether the value is validated against a residency policy or enforced after the fact.
Read together, the two pages show one pattern: placement is declared in one place and observed in another. Rubrik's field records where a replica is meant to go. Veeam's report compares configured locations after the fact. Neither document establishes preventive enforcement, and that is a statement about these two pages, not about what these products can do or what any other vendor provides. For the architect the consequence is the same either way. A declared location is a claim. A report is evidence that the configuration is consistent with itself. Neither is a verified fact about where the data sits.
What GDPR Chapter V Does and Does Not Say
Placement discussions pick up a legal reflex quickly, so the boundary needs stating precisely. Article 44 of the GDPR sets the general principle: "Any transfer of personal data which are undergoing processing or are intended for processing after transfer to a third country or to an international organisation shall take place only if, subject to the other provisions of this Regulation, the conditions laid down in this Chapter are complied with by the controller and processor, including for onward transfers of personal data from the third country or an international organisation to another third country or to another international organisation." The text governs transfers. Chapter V regulates qualifying transfers; it does not itself impose a general geographic residency requirement.
The EDPB's Guidelines 05/2021 (Version 2.0, February 2023) explain what counts as a transfer. Paragraph 9 sets out "three cumulative criteria": the exporter is subject to the GDPR for the processing; the exporter discloses or otherwise makes the personal data available to another controller or processor; and the recipient is in a third country or is an international organization. All three must hold.
Paragraph 16 is the one that matters for placement. Remote access from a third country, including access for support or administration, and cloud storage outside the EEA offered by a service provider, can be transfers when those criteria are met. Not every access event qualifies, but the point for the architect is that exposure is a function of who can reach the data, from where, and under what relationship. Storage location is only part of it.
Paragraph 17 draws the limit. Processing by the same controller or processor outside the EU, without making the data available to another controller or processor, is not a Chapter V transfer. That does not exempt the processing from the GDPR. Section 4 of the Guidelines addresses processing outside the EEA where no transfer takes place: the controller remains accountable, must still assess the legal framework and risks of that processing, including conflicting laws and disproportionate public-authority access, and must apply appropriate safeguards. Articles 5, 24 and 32 remain relevant.
Put plainly: Chapter V regulates qualifying transfers. It is not a residency mandate, and it does not require backups to sit in the same country as production. It also does not make location irrelevant. Contractual, sectoral and national requirements can impose different restrictions, and the accountability duties apply whether or not a transfer occurs. The legal question and the architectural question overlap, but they are not the same question. The backup placement test below is the architectural one, and confirming the legal position for a specific data set is a job for counsel.
A declared location without a verification entry is a claim, not evidence.
The Placement Test
Apply the backup placement test to each row of the inventory, one row at a time. It asks four questions.
- Where does it reside? Record the declared location of the copy and the basis for it: the policy field, the repository setting, the site.
- Who can reach it, and by what path? Storage location is only part of the answer. Providers, support relationships and administrative access from other locations are part of the access path.
- Who owns the placement decision? A named role, not a team that happens to configure the job.
- How is it verified, and how often? Name the evidence source, what it establishes, and the cadence. A declared location is a claim; a check against a platform report shows consistency, not physical residency.
The output is a backup placement register: one row per copy path, kept with the DR documentation. It is a table, not a framework.
| Field | What the row records | Why it exists |
|---|---|---|
| Copy path | Which inventory row this is: repository, copy target, replica, archive tier or restore target | Keeps the register aligned to the inventory |
| Declared location | Where the copy is configured to reside, and the setting that says so | Gives verification something to compare against |
| Access path | The providers, support relationships and administrative routes that can reach the copy | Makes exposure a function of access, not only storage |
| Owner | A named role with authority over both the boundary and the policy | Prevents the decision from defaulting to whoever built the job |
| Verification and cadence | The evidence source, what it establishes, the check frequency and the last validation date; configuration consistency is distinguished from independent residency evidence | Separates a declaration from evidence of where the data sits |
A register that records only the declared location has the weakness of a location tag: it is accurate until someone changes the policy. That is why the last column carries the weight. Scheduled checks should compare declared placement against independent evidence of actual placement wherever that evidence is available. A comparison between policy settings and a platform report can identify configuration drift or inconsistent location assignments, but it does not independently prove where the data resides. The architect should record what each check establishes, and what it does not. This verification routine is an architectural recommendation, not a capability established by either vendor document discussed above.
Who Owns the Decision
The failure mode to test for here is an ownership gap, not a technical one. Backup administration typically sets copy policy. Data governance typically sets the residency boundary. The join between the two, the question of whether a given copy sits inside the boundary, can fall to nobody. Whether it does in a particular organization is a question the architect has to answer, not assume either way.
The backup placement decision needs to sit with a role that can see both sides: able to read the boundary that governance set, and able to change the policy that backup administration runs. In practice that means writing the owner column of the register before the first verification run, not after the first finding.
Architect's Verdict
Backup placement is a decision that is often made by default. A production review can approve one dataset in one place while subsequent copies are placed through configuration decisions that were not part of that review. Treating those two decisions as one is how a residency boundary can end up covering the dataset and nothing else.
The problem is not that vendors hide where copies go. The two documents examined here show a declared field and a configured-location report. The problem is that declaration and detection are not verification, and the difference between them often has no named owner. A backup placement register with an owner and a verification cadence narrows that gap without requiring any claim about what a product enforces.
A residency boundary drawn around the production dataset protects the dataset. It says nothing about the copies, and those copies may become the source of recovery when something fails.
Additional Resources
- Data Protection Architecture — the pillar guide for backup, recovery and resilience architecture, including where copy design sits in the wider recovery model.
- Your Backup System Is Part of the Blast Radius — the isolation side of backup design: shared accounts, identity and API authority, as distinct from where copies sit.
- Sovereign Cloud vs. Public Cloud: Navigating Compliance in a Non-Deterministic Landscape — the broader platform-level jurisdiction problem this post applies to backup copies.
- EDPB Guidelines 05/2021 on the interplay between Article 3 and Chapter V — the official guidance on what counts as a transfer, including the three cumulative criteria and the accountability section.
- Veeam ONE 13 User Guide: Data Sovereignty Overview — the report that groups protected objects, backups and replicas by configured location.
- Veeam ONE 13 User Guide: Data Sovereignty Violations — the companion report that lists protected objects whose backups or replicas reside in a different location.
- Rubrik Developer Center: ReplicationToCloudRegionSpecInput — the API type documenting the replication cloud provider, target region and retention fields.
- GDPR Article 44 (EUR-Lex, Regulation (EU) 2016/679) — the general principle for transfers quoted in this post.
Originally published at rack2cloud.com
Top comments (0)