Guide
Backup, Disaster Recovery and Continuity
These three terms get used interchangeably and mean different things. Confusing them is how organisations end up with backups they cannot recover from within a timeframe that matters.
At a glance
- Backup is copies. Recovery is restoring them.
- Continuity is operating while recovery happens.
- RPO is data loss; RTO is downtime.
- Untested recovery is an assumption
Three distinct things
Backup is the creation and retention of recoverable copies. Disaster recovery is the capability to restore systems and data to a working state within a defined timeframe. Business continuity is how the organisation keeps operating during that period — where people work, how they communicate, which processes have manual fallbacks.
Having all three is what people mean when they say they are prepared. Having backup alone means you will eventually recover, at an unknown speed, having improvised everything in between.
- Backup: copies with defined retention
- Disaster recovery: restoration to a working state
- Continuity: operating during the outage
Setting RPO and RTO honestly
Recovery point objective is how much data you can afford to lose, expressed as time — nightly backups imply up to a day. Recovery time objective is how long restoration may take before the impact becomes unacceptable.
Both are business decisions with cost attached, and both should be set per workload. Applying one figure across everything either overspends on systems that do not need it or underprotects the ones that do. The useful conversation is about what an hour, a day or a week of loss actually costs.
- Set RPO and RTO per workload, in writing
- Price the difference between tiers before choosing
- Include SaaS and cloud data, not just servers
- Revisit objectives when the business changes
Designing against ransomware
Modern ransomware targets backups deliberately, using the same administrative credentials that manage production. The defences are immutability, air-gapping or otherwise placing at least one copy beyond the reach of a compromised domain administrator, plus separate credentials for backup infrastructure and alerting on backup configuration change.
The classic guidance — multiple copies, more than one medium, at least one off-site, at least one immutable, and zero errors on the last verified restore — remains the practical standard.
Testing is the whole point
A backup job reporting success proves a job ran. It does not prove the data is complete, usable, or restorable within your RTO. Testing means restoring on a schedule, checking the result opens and functions, timing it against the objective and recording what happened.
Full-system recovery rehearsal for critical workloads at least annually, sample restores more frequently, and a written record of each. If a test misses the objective, the design changes — that is the mechanism by which recovery capability actually improves.
Keep exploring
Related Oakville services
Most engagements combine several of these. Follow the thread that matches the problem you are trying to solve.
Questions
Frequently asked questions
- Is cloud data automatically backed up?
- Generally no. Cloud platforms protect their own infrastructure and offer limited retention against deletion. Point-in-time recovery of your data usually requires separate backup with its own retention.
- How long should we keep backups?
- Long enough to cover both operational needs and any regulatory or contractual retention period, and long enough to recover from a compromise discovered weeks after it began.
- What does a good restore test record look like?
- Date, what was restored, who performed it, how long it took, whether the data was usable, and any deviation from the objective with the resulting action.
Find out what you could recover today
A coverage review and test restore replace assumption with a factual answer.