Do You Need to Back up Office 365?
If you're looking for the backup option in Office 365 then good luck, because it doesn't exist. So do you need to bring your own backup then? Well, ask a roomful of supposed experts and some will say "yes" and some will say "no". So what's going on there? Are the pro-backup team living in the past? Are they trying to flog you a service that you don't actually need? Or have the anti-backup team been drinking so much Microsoft Kool-Aid that they've lost the ability to reason? Let's find out.
To decide if you need to back up Office 365 you need to consider what you'd use those backups for. I'm going to talk through five scenarios where traditionally you'd rely on a backup, and I'll tell you what Office 365 can and can't do about it. Then I'll tell you what I think the answer is; and finally I'll tell you what Microsoft's say the answer is. With all of that you should have all the information you need to make a good decision.
1. Recover from a Physical Failure
Thinking about times you might rely on a backup, one of the first things to spring to mind is recovering from a physical failure or disaster. The good news is you've outsourced this problem to Microsoft. Worrying about infrastructure and facilities? That's their problem. They have service level agreements, and it's up to them to make sure they meet them. This isn't really something you need to worry too much about.
2. Revert to a Previous Point in Time
Another common reason people use backups is to revert the data back to a previous point in time. That could be to undo a mistake or just to see what a document looked like before some changes happened. Looking at Office 365's options for SharePoint, you have version history. This is a lot more convenient - it's end-user accessible. With that enabled, every time you save a change to a document it records it as a separate version; and end-users can go in and browse through those versions and revert if they need to.
There are some limitations. It only works for SharePoint, it only works if it's enabled for a document library, it can only hold so many versions, and it doesn't help at all if the file's been deleted. Remember it's end-user accessible, which means end-users can just go and delete the files or the versions. It's a useful feature that lets people roll back documents to previous versions or to see what changes have occurred; but it doesn't prevent data loss, and it's not a compliance solution. We're going to come back to that point later, but for now let's move on.
3. Recover from Accidental Data Loss
Typically something that's been deleted or overwritten. There are a couple of really useful in-built features that can help with this. Exchange's deleted item retention, and SharePoint's recycle bin are both good examples. They allow end- users to go in and undo deletions from the past. I say the past... there is a limit. So they have to realise quickly enough. The limit varies between services, but as a guide you can undo a deletion from a couple of weeks ago, but not back several months. And that of course assumes no one's gone in and clicked the purge button.
In addition to those user- facing undo features, as an admin you can go in and enable retention policies. These effectively prevent anyone from permanently deleting or overwriting data. Every time a change is made it stores it as a new version. So this fills in some of the gaps we mentioned with the version history in SharePoint.
From an end-user's point of view it might look like they've deleted something, but really it's still there. A compliance admin can go in and retrieve it.
This is fairly effective at preventing data loss due to simple end-user mistakes, but it isn't perfect. It's major weakness is that it's not storing a separate copy of the data somewhere else - as you would with a backup. The retention copy is stored right in alongside the live data.
Take a mailbox, for example. If you enable retention on a mailbox and the user tries to delete an email, all that really happens is that email gets put into a hidden folder. It's still in the mailbox. So if anything happens to that mailbox you lose the live data, and you lose the retention data too.
The classic example, and one I've seen several times; is an administrator deleting and recreating a mailbox to try and fix an issue. Now as a side note, that's almost never the right thing to do, but unfortunately it's something a lot of admins jump to. You can enable retention for the mailboxes themselves, well that just adds an extra step for the admin to purge it. You can argue that's bad administration, and I would agree with you; but let's face facts. People make mistakes. If your data recovery plan relies on people having not made mistakes, then that is a bad plan.
One option that sometimes gets touted as a potential solution to this problem is preservation lock. With that enabled, even your admins can't override or change your retention policies. That is a potentially dangerous option. Once it's enabled you can't turn it off until the defined period of time has elapsed. Even if you want to. I'm not a lawyer so don't take this as legal advice, but there are a number of data privacy laws which might take issue with that. The European GDPR being one, potentially. It might not take kindly to being unable to delete certain types of data. So please use that option with caution. Certainly, I wouldn't advocate enabling it across the board.
I've been focusing on the actions of your admins, but this problem extends beyond your admins, and beyond the admins at any of your support partners. I've seen Microsoft's own support team cause data loss. They accidentally wiped out two weeks worth of data at one of my customers. To be fair to them they put their hands up, they apologized, and they provided compensation; but, they couldn't bring the data back. So retention policies: they're really useful if you want to preserve and locate data in your live system, but it's in your live system, and if you try to view it as a recovery solution, that is a major weakness.
4. Recover from Malicious Action
I don't think I need to spend a lot of time in this one. I've already explained a number of scenarios where you could lose data accidentally, so if someone wants to destroy the data on purpose they have options. The really scary scenario here is if one of your admin accounts was compromised, or if an admin went rogue for that matter. If that happens there's not a lot you can do. You can enable retention policies, but then they can just turn them off and purge the data anyway. About the only thing that might help is preservation lock; but I've already told you why that one could be a bad idea.
5. Recover from Data Corruption
Data corruption can and does happen - even in Office 365. Whether that happens on Microsoft's end, your end, or somewhere in-between... it doesn't really matter - the effect is the same. The fact is that your data can be damaged or destroyed through no fault of your own. Microsoft do have protections in place is to prevent catastrophic corruption from causing large-scale data loss. Your data exists in multiple replicas, and they replicate using transactions (that's planned changes) rather than the underlying storage. So if the storage itself becomes corrupt they can just flip over to a different replica.
This doesn't prevent small-scale data corruption from damaging or destroying individual files, though. Retention policies won't help either. They are triggered in response to planned changes. Data corruption isn't a planned change, so there'll be no copy made. Microsoft do actually take backups of SharePoint Online, but it's more for their purposes than yours. But, if you notice a problem and you get ticket in quickly enough they can restore back within the last 14 days. They can only restore an entire site collection. They can't restore individual files; but if you're really in a pinch that, might be useful to know.
My thoughts
Do you need to back up Office 365? Well, I can't tell you how much value to place on your data - that's up to you. What I will say, is that if you value the data you're putting in Office 365, then "yes" you should back it up. If you don't then you're accepting some level of risk that you might lose that data. Less so than with an on-premises environment, granted, but there is still risk. Office 365 provides some pretty decent data retention services. These are not the same as data recovery services. All of that data is stored in the live environment. Replicas don't count either. By definition they replicate changes - good or bad. You need a separate, offline, point-in-time copy that you can recover from.
That same argument works in reverse, by the way. A retention system is not a backup, and a backup is not a retention system. If I receive an email and delete it straight away, that's not going to show in a backup. If I change a file five times between backup windows, you're not going to see that version history in the backup. If you need to record all of the changes that happen, you need to use the retention options. It's about using the right tool for the job.
What Microsoft Say
As it stands there are several scenarios where your data could be unrecoverable without a backup, and that's why I think you should have one. If you're not convinced yet, let me try one last thing to persuade you. Let's look at the Microsoft Services Agreement. Scroll to paragraph 6B if you want to read along.
We strive to keep the Services up and running; however, all online services suffer occasional disruptions and outages, and Microsoft is not liable for any disruption or loss you may suffer as a result. In the event of an outage, you may not be able to retrieve Your Content or Data that you've stored. We recommend that you regularly backup Your Content and Data that you store on the Services or Store using Third-Party Apps and Services.
There you have it. Microsoft themselves say that if you use Office 365 you should use a third-party backup service. If you don't, they've made it very clear that the risk lies with you, not with them. If you're comfortable with that risk, that's your decision. As for me? I've got a backup.
