Capability
Backup, Disaster Recovery and Continuity
Backup is the control that decides how bad a bad day becomes. It is also the control most often assumed to be working on the evidence of a green dashboard.
At a glance
- Coverage checked against a real system inventory
- Immutable or air-gapped copies off the domain
- Recovery objectives agreed per workload
- Restores tested on a schedule and recorded
Coverage and design
The first exercise is comparing what is backed up against everything that would need to be recovered. Gaps typically appear in the same places: Microsoft 365 data, SaaS platforms, endpoint-stored files, virtual machine configuration, and line-of-business systems with database requirements the standard job does not meet.
Design then follows the objectives. Multiple copies, at least one off-site, at least one immutable or otherwise beyond reach of a compromised administrator account. Ransomware operators target backup infrastructure deliberately, so backup credentials are separated from production identity as a matter of course.
- Full system and data inventory mapped to jobs
- Microsoft 365 and SaaS protection
- Immutable or air-gapped retention
- Backup credentials separated from production identity
- Retention set against operational and regulatory needs
Recovery objectives and testing
Recovery point objective sets how much data loss is tolerable; recovery time objective sets how long restoration may take. Both are business decisions with cost attached, and both should be set per workload rather than as a single figure applied to everything.
Testing is what converts a configuration into a capability. We restore on a schedule, verify the restored data is usable rather than merely present, time the exercise against the stated objective, and record the result. When a test misses the objective, the design changes.
- RPO and RTO per workload, agreed in writing
- Scheduled restore testing with recorded outcomes
- Full-system recovery rehearsal for critical workloads
- Documented runbooks usable under pressure
Continuity planning
Continuity extends past data. It covers where people work when a site is unavailable, how they communicate when email is down, which processes have manual fallbacks, and who decides to invoke the plan.
Plans are kept short and available offline. A continuity document that only exists on the file server it is meant to protect has failed before it is opened.
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 Microsoft 365 already backed up?
- No. Microsoft protects the service; recovering your data after deletion, sync corruption or ransomware is your responsibility and needs separate backup with its own retention.
- How often should restores be tested?
- Sample restores monthly, and a full-system recovery rehearsal for critical workloads at least annually. Cadence rises where compliance or client contracts require it.
- Can you take over backups that already exist?
- Yes, starting with a coverage review and a test restore. We would rather find the gap during onboarding than during an incident.
Prove the restore works
A coverage review and test restore give you a factual answer about what you could actually recover today.