Backup, Recovery, and Data Retention

Backup, recovery, and data retention are among the most misunderstood areas of shared responsibility. Customers often hear that the provider stores the data, supports snapshots, or offers recovery features and assume their recovery problem is therefore solved. It is not. The provider may operate the storage platform and recovery mechanisms, but the customer still owns what data needs to be recoverable, how much loss is acceptable, how fast recovery must happen, and how long data must be retained.

This is the key distinction: provider capability is not the same thing as customer recovery objective.

The control path usually looks like this:

    flowchart TD
	    A["Provider offers backup or recovery feature"] --> B["Customer defines RPO, RTO, and retention"]
	    B --> C["Customer configures and validates recovery model"]
	    C --> D["Customer proves restore and retention behavior with evidence"]

What to notice:

• the provider may offer the mechanism
• the customer still defines success criteria
• restore testing and evidence remain customer-governed

What the Customer Still Owns

Customer responsibilities in this area often include:

• defining recovery point and recovery time objectives
• deciding which systems need backup and which do not
• selecting retention periods
• validating restores and recovery workflows
• aligning retention with legal or business rules
• documenting evidence that recovery expectations were tested

Without those decisions, provider backup features are just unused capability.

A Practical Recovery Policy

 1data_service: customer-orders-db
 2
 3recovery_requirements:
 4  rpo_minutes: 15
 5  rto_minutes: 60
 6  retention_days: 90
 7  restore_test_frequency: quarterly
 8
 9provider_capabilities_used:
10  - snapshots
11  - point-in-time-recovery
12
13customer_evidence:
14  - restore-test-report
15  - retention-policy-review

What this demonstrates:

• the provider feature set is only one part of the control
• the customer still chooses the target and validates the outcome
• backup governance is incomplete without restore evidence

Backup Coverage Is Not Recovery Coverage

Many teams document that a backup exists and then stop there. That is not enough. Recovery depends on scope, restore order, and operational readiness. A protected database is not sufficient if the application secrets, object storage, queue definitions, or configuration needed to make the system usable again are missing or out of sync.

A stronger recovery review asks:

• which components must be restored together to make the service usable
• which systems are rebuildable and therefore do not need the same backup treatment
• which recovery steps are manual, time-consuming, or dependent on a specific person
• which retention settings apply to production data, logs, snapshots, exports, and legal hold copies

This is why the customer side of the model includes system understanding, not just feature enablement. The provider can expose recovery capabilities, but only the customer can define what a usable recovery actually looks like.

Why Retention Is Part of the Same Problem

Retention is often separated from backup design, but the two are closely linked. A system that retains data longer than necessary increases privacy and governance risk. A system that retains data for too little time may fail legal, investigative, or business requirements. Customers must decide both what to preserve and when to dispose of it.

Restore Testing Needs Tiers, Not Just a Calendar

Quarterly or annual restore tests are useful, but the stronger pattern is to test according to the importance of the system and the difficulty of the recovery path. A simple restore of one low-risk dataset does not prove that the most important workload can be recovered under pressure.

In practice, customers usually need at least three tiers of validation:

• configuration validation that confirms backup and retention settings still match the policy
• controlled restore tests that prove important datasets can actually be recovered
• scenario-based recovery exercises that prove the team can restore the service within the expected business window

Without that layered approach, backup governance looks complete on paper while the real recovery path remains unproven.

Common Mistakes

• assuming provider snapshots automatically satisfy recovery objectives
• never testing restore paths because a managed service advertises backup support
• separating retention policy from business and legal requirements
• focusing on backup existence rather than on recovery outcome

Design Review Question

A team uses a managed database with point-in-time recovery and claims backup responsibility is mostly provider-owned. The team has never defined an RPO or RTO, never tested a restore, and does not know how long the backed-up data is retained. Is the conclusion strong?

No. The stronger answer is that the provider offers the recovery mechanism, but the customer still owns the recovery objective, validation process, and retention policy. Without those, backup capability has not become a working control.

Check Your Understanding