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.
Welcome back to the Pro Tech Show, and Happy New Year! 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. If you already use Office 365, comment below the video and let me know
if you back it up or not; and when you get to the end let me know if this video has
confirmed or changed your opinion.
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. Now 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. 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. Now 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. Now 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. Now we're going to
come back to that point later, but for now let's move on. By the way, if you're
interested in this sort of content then don't forget to subscribe for future
videos.
The third scenario is recovering from accidental loss of data. Typically
something that's been deleted or overwritten. Now 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. Now, 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. Now 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. Now
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. Now 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.
Our fourth scenario is malicious destruction of data. Now 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. The fifth and final scenario is recovery
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 then. 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.
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. This is what you've agreed to by using Office
365. I'm reading from the current version at the time of recording, which was
published in the 1st of July 2019 and became effective on the 30th of August
2019. There's a link in the description. 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. To see more content like this then
check out one of these videos over here. Don't forget to let me know if you're
backing up Office 365, and whether this video has changed or confirmed your opinion. If
you liked this video, there'll be another one up in a couple of weeks' time; so
don't forget to subscribe, and use the bell icon if you want to be notified.
Thanks for watching, guys. See you next time!