Your in-jurisdiction document store replicates its nightly backup copy to a distant region — which goal does that serve, and which duty does it break?
answer
- distance is the point and the problem
- the backup is the copy people forget
- region loss versus zone loss
- retention decides how long it sits there
- replica copies a delete, backup rewinds it
basics
~20 sCopying the backup far away serves recovery from the loss of the whole originating region, which no copy inside that region can. It breaks residency, because a readable copy of regulated records now sits outside the jurisdiction the contract names.
solid answer
~50 sThe distant copy exists for one reason: a failure that takes the whole originating region with it. A copy in another zone of the same region survives a zone loss but not that. So the setting is doing a real job — and it is doing it across a border, which is exactly what the residency clause forbids. In a review the finding is simple: a readable copy of regulated records is held outside the named jurisdiction, and retention means it stays there for as long as the policy keeps it. The resolutions are a second region **inside** the jurisdiction if one exists, a second zone if it does not, or accepting a narrower recovery posture and writing that down. Keep the distinction straight while you argue it: a **standby replica** reproduces a deletion faithfully, while a **retained backup** can be rewound to a moment before the mistake.
go deeper
Remember that a backup is a full readable copy of the records, so wherever it lands counts for a residency rule exactly as the primary store does.
Explain why the distant copy exists at all: a copy inside the same region cannot survive losing that region, so the duty and the recovery goal genuinely conflict.
Show the resolution path and its cost: a second region in-jurisdiction if one exists, otherwise a zone, otherwise a narrower recovery posture that someone signs off on.
Own the trade explicitly. Decide which data classes accept a reduced recovery posture for a strict reading, and make that ruling once rather than per team.
## Two requirements pointing in opposite directions A regulated store usually carries two instructions at once. The first says *survive the loss of the place you are in*, and the natural way to satisfy it is to keep a copy somewhere far enough away that the same event cannot destroy both. The second says *do not let the records leave this jurisdiction*. Distance is the whole point of the first and the whole problem of the second, and no configuration reconciles them by itself. This is why the residency question that actually catches teams is not "which region is the store in". It is "where does the backup land", and it is usually asked for the first time by someone outside the team. ## What each copy is actually for Before arguing about placement, be precise about which mechanism the scenario has, because the two are constantly conflated and they protect against different things. | | Standby replica | Retained backup | |---|---|---| | **Follows changes** | continuously, or with a small lag | on a schedule | | **Protects against** | the loss of a failure domain | a mistake, a bad migration, a malicious delete | | **A deletion is** | reproduced faithfully on the other side | still present in an older generation until retention expires | | **Rewinds to a moment** | no | yes, within the retention window | So a cross-region **replica** buys you a warm copy after a regional loss; a cross-region **backup** buys you that plus the ability to go back to yesterday. Both put readable records on the far side of a border, and the backup usually keeps them there longer, because retention is measured in weeks or months rather than seconds. ## What the review records The finding is not "data was transferred". It is "a readable copy of regulated records is held outside the jurisdiction, for the duration of the retention policy, and can be restored there". Three details make it worse or better: - **How long it stays.** A copy governed by a long retention is a standing exposure, not a momentary one. - **Whether it is readable there.** If the destination can restore it without anything held inside the jurisdiction, the copy is fully useful — to you and to anyone who can compel the operator. - **Whether anyone can tell.** A team that cannot say where its backup generations are has a second finding on top of the first. ## Resolving it, in the order worth trying 1. **A second region inside the same jurisdiction.** The cleanest answer where the jurisdiction has more than one. The copy is far enough to survive a regional loss and never crosses the border. 2. **Another availability zone of the same region.** Available almost everywhere, and it genuinely protects against a zone-level failure — a separate power and network domain — but it does not protect against losing the region. State that narrowing out loud rather than letting it pass as equivalent. 3. **Keeping the far copy but making it unusable outside.** Encrypting so that a restore requires something held inside the jurisdiction is a real design, and whether it satisfies a given contract is a legal reading rather than an engineering fact. Readings differ; do not assert one. 4. **Accepting the narrower posture and writing it down.** If the strict reading wins, the amount of data you can lose in a regional failure is now bounded by what the in-jurisdiction copy gives you. That is a decision someone must own, not a detail to leave implied. ## The traps around this one - **"It is only a backup."** A backup is a full, readable copy of the records. If anything, it is the most complete copy you own. - **"We delete it quickly."** A copy that existed abroad is a copy that existed abroad, and proving a clean deletion is harder than proving it never left. - **"Replication is our backup."** It is not. Replication faithfully reproduces the delete you are trying to recover from. If the scenario needs a rewind, it needs retention. - **"Transfer is encrypted, so it is fine."** Encryption in transit protects the bytes on the wire; the residency question is about the copy at the far end. - **"More copies in more places is safer, so it must help compliance."** More places is more exposure under a residency clause. The two goals really do pull apart here. ## Where providers differ Defaults are not uniform and you should not assume one. On some platforms a managed store's backups stay inside the originating region unless you explicitly enable an outward copy; on others an outward copy is part of the default durability story and must be turned off deliberately. The charge behaves differently too: traffic leaving a region for another one is normally billed on a different schedule than traffic between zones inside it, and both are normally billed by volume moved out. The engineering answer is the same everywhere — go and read what the default actually does for this store, then put the result in the inventory.
- The jurisdiction has only one region. What is actually left?Another zone of that region, which protects against a zone failure but not a regional one; or a far copy made unusable outside, which is a legal reading rather than an engineering fact; or accepting that a regional loss costs you more data than you would otherwise lose. Whichever you pick, name it in the recovery documentation.
- Does deleting the foreign copy quickly make the transfer acceptable?Rarely, and it is the weakest argument in the room. The copy existed and was readable there, evidence of a complete deletion is harder to produce than evidence nothing left, and a store that keeps older generations may not have removed it when you think it did.
saying these in an interview costs you the question
- Calling a cross-region replica a backup
- Assuming a backup is exempt because it is not live data
- Believing encryption in transit resolves where the copy lands
- Treating a second zone as equivalent to a second region
- Thinking a short-lived foreign copy leaves nothing to find