During my series of posts from the real world technical trenches, we have learned that it’s important to always be prepared for the unexpected. Last time we talked about on-premises servers, but today we are going to completely shift gears. Let’s think now about what happens when you move your workloads to the cloud? Does the responsibility of the data shift to the cloud provider? The answer is: No it doesn’t.
In today’s installment, I highlight backup lessons learned from an experience with Office 365 Exchange online.
Office 365 Exchange Online Planning
Office 365 has been a suitable option for organizations for some time now, and the usage growth rate is on the upswing. With that in mind, a good deployment will come with some planning. Most enterprises will choose a hybrid-migration approach in which mailboxes are migrated to the cloud, and the basics – such as relays – stay on-premises. Architecture decisions are made and implemented, and the migration process begins.
However, add in the topic of backups, and this cloud-migration conversation changes. There are several considerations to ensure a great backup outcome with your Office 365 Exchange Online environment.
First, let’s discuss your Exchange on-premises environment. Thinking about it, there is probably a solid backup plan in place. For example, your settings may be similar to this:
- Exchange Deleted Item Recovery is set to 60 days.
- Your organization holds mailboxes for 90 days after a person leaves, and for some the data is retained beyond that.
- Backups may be kept for a few months or longer.
While I realize this may not be your exact backup configuration, the point is that your enterprise has some options here. So, when you move to the cloud, why should an enterprise settle for anything less?
Let’s look at the Microsoft Office 365 Exchange Online SLAs next, and start thinking about whether these settings are reasonable for your enterprise. In this case, the SLA levels cannot be changed and are as follows:
- Deleted Item Recovery max cannot exceed 30 days.
- When a user leaves the organization, their account is deleted, and is recoverable for 30 days.
- Backups? What Backups?
So now let’s talk about the Real World
Let’s talk about an enterprise that thought they would be ok with the SLAs offered by Microsoft, but – thanks to the unexpected – it turns out they weren’t.
Enterprises with data in the cloud will expect their administrators to be accountable for their data. Like many, the decision to run Exchange Online without backups was made. Then, despite many awareness meetings about the Microsoft SLAs, backup conversations, and policy documentation, the worst of the worst happened.
In this case, multiple people left the organization at the same time, and it was the assumed their data was no longer needed. When the 30 days rolled by, per Microsoft’s Exchange Online SLA, their data was gone. There were accusations being made by the former employees that came to light after the data was removed from Exchange online. Unfortunately, this data was critical to the accusations, but the evidence was gone. Without going into many details, this did not turn out well for the organization.
Lessons Learned
- Accountability of Data – Know that when enterprise data is in the cloud, that the accountability doesn’t lie with the cloud provider. The accountability falls within the realm of the enterprise.
- Never Assume – That the unexpected cannot happen. Cloud or on-premises, the data retention policies should comply with your organization’s guidelines.
- Get the right teams involved – Your information technology team should not be making the final decisions around data retention.
The bottom line: Always prepare for the unexpected. Your data is a business asset, regardless of the location – cloud or on-premises. Ignoring this fact can lead to major outages, lost time, lost profits, and reduced employee productivity.
Stay tuned for next time when I use more real-life examples to help illustrate how to improve your enterprise backup strategy. You can find my many previous posts here.
