Want Microsoft 365 backup methods that fit your organization’s needs? Check out our free webinar “Practical Guide: Office 365 Backup Strategies That Scale” today!
It’s fair to say that people have come around to the idea that you need a backup solution for your Microsoft 365 business data beyond what’s provided natively. It’s also fair to say that there are a number of ways to do that, but Retention Policies (and Labels) are not one of them. To understand why, let’s start with breaking down what Retention Policies are.
What are Microsoft 365 Retention Policies?
Microsoft does a nice job of explaining what Retention Polices and Retention Labels are here. To summarize, you use them to:
- Keep business data for a specific period of time, even if someone deletes it
- Delete business data after a specific period of time
Simply put, Retention Policies are a Microsoft 365 compliance feature. They’re there so you can protect important business data stored in SharePoint, OneDrive, Exchange, and Microsoft Teams from being deleted prematurely or from being retained beyond a recognized lifespan (as defined by regulatory requirements for your industry, locale, etc.). At that, Retention Policies are very, very good.
But that brings up a question: if we can use Retention Policies to keep business data as long as we want, can’t that serve as our Backup and Restore solution? Set Retention Policies at the SharePoint Site and Exchange Mailbox levels to keep everything forever, and if someone deletes something, a copy of it is created. Instant “Backup” without needing to engage a third-party partner, run separate processes, manage a separate UI, storage, etc. Native and easy, right?
Native, Yes. Easy, No.
There are a number of reasons why Retention Policies are not a suitable replacement for a formal Backup solution. Ignoring that you might need to use them for their designed purpose (retention and disposal), let’s start with where deleted retained business data goes.
If a user deletes a SharePoint or OneDrive file and then needs it back later, it has to be pulled from the hidden Preservation Hold library. This is a potential restore issue because Preservation Hold is specific to that site, so whoever is doing the restore (Site Owner) needs to access it to pull out the copy of the document. Those libraries also count against your storage costs, so if you’re protecting every bit of business data in every site, that adds up over time.
For Exchange email and Teams channel messages and chats, the Recoverable Items folder is used (Teams content goes in a subfolder called Substrate Holds). There are plenty of nuances to if/when something goes into Recoverable Items and into which subfolder, but the real trick is if a business user can’t recover something from Recoverable Items themselves, admins have to with tools like eDiscovery search.
Disregarding the potential extra costs and complexity of configuring Retention Policies and Labels, if you’re thinking, “Okay, going and getting copies of deleted stuff sounds like a click-heavy pain but not a major tragedy,” I’d listen to that argument. But that’s not the only consideration, which brings us to the next issue with relying on Retention Policies as a backup solution: they’re content-focused
All Your Stuff, None of Your Structure or Settings
A Backup solution is an insurance policy. You have it in place, hoping to never have to “submit a claim” (perform a restore) because doing that means something bad happened. Following that logic, imagine if you suffered damage to your home and all your possessions. You want the insurance company to not only replace all your stuff, but also provide for your home being restored to its pre-damaged state. That’s when the money meets the road.
For a system like SharePoint, a Backup solution that captures configurations/settings/security for your Site Collections, Sites, lists, and libraries as well as your business data can put everything back as it was. Retention Policies cannot do that because they’re focused at the content level. You don’t get copies of any container or container-level configurations or settings in a way that you could use to restore a Site’s permissions but none of its objects or content. What if you simply want to restore the whole Site? You can’t, because Retention Policies are about item-level retention and disposal, not restore functionality.
Is this limiting as far as what’s backed-up and what you can restore? Very.
Speaking of restores, there’s one more thing to think about when trying to make Retention Policies/Labels work as a Backup solution: outages.
All Your Eggs in One Basket
I’m not an outage doomsayer. I’m really not. Large-scale outages are very infrequent. However, that doesn’t mean you shouldn’t plan for them.
When considering using Retention Policies as a Backup solution for Microsoft 365, remember that all your copies are in SharePoint/OneDrive libraries and Exchange mailbox folders. If an outage occurs, there’s no way to get to anything.
That Sales Manager who needs a copy of her deck to present to a customer, but SharePoint is down? She can’t get to her original or pull a copy out of the Preservation Hold library. If you had a separate Backup solution, in particular one that can restore out of place like AvePoint Cloud Backup and Restore, a few clicks and you can send her deck to her. Retention Policies have nothing like that because they’re not designed for that.
Outages are probably not your number one concern, but they’re certainly worth thinking about to ensure all of your bases are covered.
In conclusion, Retention Policies are great at what they’re designed for, but not suited for Backup and Restore purposes. Using them for Backups is like pounding a nail into a wall with the handle of a screwdriver instead of grabbing a hammer. You might think it’ll work fine, but bent nails, sore thumbs, and crooked holes are a real possibility. The right tool for the right job is always a better way to go.