Adoption of M365 (Exchange Online, SharePoint, OneDrive, and Teams) has grown dramatically in the past year. Teams alone jumped from 115 million active Teams users to 145 million in the last quarter. With adoption so high it now has me asking these questions:
What are you doing to make sure that your data is protected? It is your enterprise data that you are putting in the cloud, so do you need to care about how you will get that data back if something happens?
In this article we will first take a look at why you should protect M365 data, then do some discovery around Backup as a Service (BaaS) and finally wrap up things with a couple ways to get started.
There is an underlying perception that once data is moved to the cloud it is protected by the cloud provider through the uptime SLAs provided. However, do note that the uptime SLAs are typically pertinent to infrastructure availability where your data lives, and not enterprise data recoverability. There are some scenarios by which you may get a best-effort option for recovery of your data which can help, but likely minimal guarantees. Data responsibility in the cloud follows a shared responsibility model. Customers are responsible for their data, and in the case of Microsoft M365, Microsoft is responsible for infrastructure availability and uptime only.
Not convinced your data could be at risk when it’s located in the cloud? Consider these stats and examples from the State of Cloud Security report. 70% of companies that host data or workloads in the cloud have experienced a breach of their public cloud environment in the past year. The most common attack types were malware (34%), followed by exposed data (29%), ransomware (28%), account compromises (25%), and cryptojacking (17%). Regardless of why your data went missing or became compromised—you are responsible for making sure you can recover it.
M365 has native ways to retain data, but they are not backups. They can best be described as policy based-retention options. Breaking it down to provide some examples of what this means, let’s look at SharePoint online, OneDrive, and Teams site data. By way of policy, document versions can be kept, and deleted items are retained for 93 days by default, but is this enough? Consider a security vulnerability such as ransomware where a point-in-time copy is needed. Only OneDrive natively has the option to do a point-in-time 30-day recovery specifically for ransomware if you configure it that way. This can be helpful, but consider the fact that more recent ransomware attacks will sit idle often times further back than 30 days to circumvent native retention. This means recovery of data without ransomware included isn’t guaranteed. These are just a couple examples of where it’s important to understand how far the native options will take you, and what your business will tolerate from a risk and recovery standpoint.
All things considered here, I still often get asked, “Why can’t I just use these options?” The answer is that you can use these options and I recommend it, but you need to take a hard look at your business recovery SLAs before assuming that what Microsoft is offering you is enough. What you will likely find is that the native options will complement your recoverability needs, but not meet your business-level SLAs. They will also leave you managing your data from multiple locations, and when it comes to doing an actual recovery in many scenarios it can take a very long time. There also are not any options for offsite long-term retention or immutability of data. If any of these items are required, a third-party solution must be used in addition to the Microsoft 365 Native options. Check out this podcast where these limitations are discussed in more detail.
With M365 data already in the cloud, it’s likely that you may also choose to protect M365 data with an as a Service solution. Let’s start by taking a closer look at why enterprises may choose an as a Service solution for any technology to get started.