Continuity · Backup / DR

Backup and disaster recovery: RPO, RTO, and restore testing

Backup without defined RPO/RTO and restore tests is just disk cost. Disaster recovery without procedure and communication windows is a paper plan. In a managed model, both layers must be part of SLA — not an add-on "when there is time".

RPO and RTO — in plain terms

• RPO (Recovery Point Objective) — how much data you can lose (for example 15 minutes, 4 hours),
• RTO (Recovery Time Objective) — how fast the environment must return to operation.

Lower values mean more expensive architecture: more frequent snapshots, replication, warm/hot standby, separate location. Not every application needs near-zero RPO.

Common mistakes in practice

• backup on the same array / in the same AZ as production,
• no restore test (or a test "once every two years"),
• unclear who approves restore and who communicates with customers,
• retention too short for accounting or industry requirements.

What managed DR includes at BaseCloud

In Professional and Enterprise packages, backup and recovery procedures are part of operations: schedules, job monitoring, retention, and participation in DR tests. RPO/RTO scope is refined after assessment — we do not promise "zero downtime" without architecture that actually enables it.

Checklist before signing SLA

• list of critical systems and their business owners,
• RPO/RTO targets per system (not one number for the whole company),
• frequency and form of restore tests,
• escalation path and post-incident report.

View packages · DORA and business continuity · More articles