4 things you should know about backup & recovery in Microsoft 365
Prior to Microsoft 365, enterprises were fully responsible for providing their own business continuity and data protection.
A multi-pronged, belt and braces approach for backup, that included the following elements, was typical:
- Multiple backup copies written to physical storage disks or tapes
- Use of secure offsite locations
- Full & incremental backups
- A regular cycle
- Recovery testing
Along with the requisite backup hardware, procedures and people, most enterprises invested in third-party backup and recovery solutions to meet their Microsoft Office-specific needs, with value-add functionality that included:
- Granularity down to individual message restores
- Fast, touch-of-a-button restores
With the shift to Microsoft 365, the expectation is that failover, backup and recovery is ‘baked in’.
According to Essential’s CTO, Dave Kellett, however, “Organisations used to the sophistication on offer with third-party backup and restore solutions will be somewhat disappointed by what’s on offer from Microsoft.”
So let’s dig a bit deeper into what protection you are actually getting for your subscription fee.
1. It’s more about prevention & resiliency – not backup per se
There’s a raft of security services and ‘fail-safes’ on offer in the Microsoft 365 ecosystem to protect your data from malicious corruption and malicious (or inadvertent) deletion in the first place.
There’s also infrastructure services to protect the integrity of your data.
But nowhere does it say in Microsoft’s service descriptions: “We provide a guaranteed backup and recovery service”.
In fact, with respect to Exchange Online, Microsoft specifically states, “Although lagged database copies are used in Exchange Online, it is important to understand that they are not a guaranteed point-in-time backup.”
So what should you know about Microsoft’s backup and recovery capability?
2. Restores by Microsoft are slow
As a base level of protection, Microsoft runs an automatic backup of your all your primary Office 365 apps (Exchange Online, SharePoint Online, OneDrive for Business, etc) every 12 hours, and keeps those backups for a period of 14 days.
In the event that all your in-place preventative measures fail, you can restore from backup by logging a call with the help desk, but this is a notoriously slow and inelegant process.
It could take up to 4 days for your system to be fully up and running again and this timescale may be unacceptable for your organisation.
Also, there’s a lack of granularity. For example, with a SharePoint restore you can only restore at site collection level (unlike specialist backup solutions that go down to document level restores). This means there is a chance any work done by users since the last backup will be over-written, and this could include work carried out in the last 11 hours and 59 minutes.
To put it simply, Microsoft’s current backup system is ‘there’, but it arguably lacks the sophistication and service levels that you may be used to if you’ve previously experienced 3rd-party specialist solutions for on-premises environments.
3. Restores can be labour-intensive for you
We often hear tales from IT teams of spending hours helping staff recover from inadvertent data loss. For example, constantly having to restore individual items to users OneDrive by using Microsoft’s eDiscovery tools to recover items from places like second-stage recycle bins and retention folders.
As well as proving to be a huge time sink, this also presents privacy issues as it requires giving the person doing the recovery access to the information those items contain.
Having a recovery capability that minimises intervention and indeed, enables a self-service approach to recovery where required, might prove valuable to your company.
4. There’s no guarantee
Another key aspect of the Microsoft backup service is that there are no guarantees around protection of your data.
It’s worth reviewing your Microsoft Services Agreement and reading ‘the small print’ – specifically 6b.
Although this paragraph relates to service continuity, the recommendation from Microsoft to ultimately ‘be responsible for your own data’ is clear…..