Defend · Service 08
Backup & continuity
A backup is a claim. A restore is evidence. We test yours on a schedule and send you the result, so recovery is a practised routine well before the day it really counts.
The assumption
Your Microsoft 365 data is yours to back up
This is stated plainly in Microsoft's own shared responsibility model, and it still surprises people in the room. Microsoft guarantees the availability of the service. Protecting the data inside it falls to you.
Retention policies and the recycle bin serve a different purpose. They expire, they can be changed by an administrator, including a compromised one, and they leave you exposed when a mailbox has been maliciously purged, a SharePoint site deleted, or a ransomware payload synchronised through OneDrive to every device that had it open.
The second assumption we test is the one about your servers: that the job reported success. Success means data was written. Proving it can be read back into a working system, inside the time your business can survive without it, takes a restore.
Coverage
What we protect, and how far back
Retention is set from your actual obligations: record-keeping requirements, contracts and insurance.
Microsoft 365
Exchange Online, SharePoint, OneDrive and Teams — including chat, channel content and the files behind both. Point-in-time restore to the item level, so you can recover one mailbox folder on its own.
Servers & virtual machines
Image-level backup for on-premises, co-located and Azure workloads, with local copies for speed and offsite copies for survivability. Bare-metal and instant recovery where the platform supports it.
Endpoints
Laptop and desktop protection for the data that never made it to OneDrive. Frequently the difference between an inconvenient reimage and a lost fortnight of work.
Immutability & isolation
Backup copies that cannot be altered or deleted within their retention window, held in a separate security domain with separate credentials — because modern ransomware looks for your backups first and encrypts them second.
Documented RTO & RPO
Recovery time and recovery point objectives agreed per system, in writing, and proven achievable by testing. Until it is measured, a target is an aspiration.
Disaster recovery runbook
The written sequence for a total loss event: who declares it, in what order systems come back, what depends on what, who is called, and how staff are told — kept somewhere that stays reachable when your network is down.
The proof
Restores run on a schedule, and you see the results
The Essential Eight requires restore testing to reach maturity. We would do it anyway, because it is the only backup metric that means anything.
What is tested | How often | What you receive |
|---|---|---|
File & mailbox item restore | Monthly | Restore log with elapsed time, in the monthly report |
Full server restore to isolated network | Quarterly | Test report with measured RTO against target |
Microsoft 365 tenant-level restore | Quarterly | Sample restore across Exchange, SharePoint and Teams |
Disaster recovery walkthrough | Annually | Tabletop exercise with your leadership, and a revised runbook |
When a test fails, and occasionally one does, it appears in your report with the cause and the remediation. The occasional failure is how you know the testing is real.
Questions
What people ask
How long should we retain backups?
Long enough to cover your record-keeping obligations and long enough to outlast a slow-burn compromise. Seven years is common for financial records; twelve months of daily points with monthly archives is a reasonable operational default. We set it from your obligations.
Where is the data stored?
Australian data centres by default, with the specific region named in your service schedule. If you have a contractual or regulatory requirement for a particular location or sovereignty arrangement, tell us during the assessment and we will design to it.
What is a realistic RTO?
For a single virtual machine with instant recovery: under an hour. For a full site rebuild from offsite copies: measured in days and dependent on your bandwidth. A four-hour full-site RTO quoted before anyone has tested it in your environment is a brochure figure.
Do we still need this if we are fully in the cloud?
More than ever. Cloud removes hardware failure as a cause. Accidental deletion, malicious insiders, compromised administrator accounts, ransomware synchronised through OneDrive and a SaaS vendor's own outage all remain. The failure modes changed; the need is the same.
When was your last successful restore
If the answer is “the backup reports say it is fine”, that is the answer we hear most often — and it is the one worth checking.