Many organizations have migrated to Microsoft Office 365 to reduce cost and complexity. Although using Office 365 might initially seem attractive, those who use it soon learn that Office 365 data protection
Office 365 is a cloud-based collection of Microsoft server applications such as Exchange Server, SharePoint, Lync and Yammer. This article focuses on backing up Office 365 Exchange Server and SharePoint Server since those applications are by far the most commonly used.
Myth: Moving to the cloud frees you from all application-level maintenance tasks -- including backups.
One popular myth is that moving to the cloud frees you from all application-level maintenance tasks -- including backups. While it is true that Microsoft does perform its own backups, it uses these backups primarily for internal purposes. Some people claim that Microsoft has recovered deleted mailboxes for them, but according to some message board posts, these types of recoveries can take Microsoft days or even weeks to complete.
Because Office 365 applications such as Exchange Server and SharePoint reside in the cloud, traditional backup applications cannot be used to perform Office 365 backups. There are some smaller vendors that offer Office 365 backup applications, but it is important to understand that backups created with such applications might not provide the granularity that you would expect.
Although the major backup vendors do not generally support Office 365 SharePoint backups, there is a vendor called MetaVis Technologies that offers a backup application that is designed to back up and restore Office 365-hosted SharePoint.
Unfortunately, Microsoft does not provide administrators with a viable method of performing their own Office 365 SharePoint backups. In fact, one TechNet article suggests using a method known as connect and export. The basic idea behind this method is to connect to individual SharePoint online elements such as calendars and document libraries using tools such as Outlook and Windows Explorer and then export the data locally. The problem with this method is that it is extremely labor-intensive. Not only must administrators protect each data type separately, they also must do so for each user.
If you need to protect Office 365 SharePoint, then your only real option is to use a backup application that supports it. Incidentally, MetaVis Technologies is not your only option. The next section describes some backup applications for Exchange Server, and many of these applications also support SharePoint backups.
Exchange Server backups
A variety of products can back up Office 365 Exchange Server. Some of them include CloudAlly, CloudFinder and AvePoint's DocAve. It is worth noting, however, that these backup products might not protect data in the same way that you would be able to in a local Exchange Server deployment. CloudAlly's website, for example, states that Exchange Online Mail Backup "is an Email only backup" (meaning that it can't protect other types of Exchange Server data) and that "the backup is activated using individual user credentials" and is "based on the IMAP interface."
So how can an organization protect hosted Exchange Server data? At first, the solution to this problem would seem to be to create a hybrid deployment and then stretch a Database Availability Group (DAG) between your on-premises Exchange Server deployment and Office 365. Unfortunately, although you can create a hybrid Exchange Server deployment that uses a combination of on-premises and cloud-based mailbox servers, there is no way to include Office 365 servers in your DAG.
Thus far, Microsoft tends to recommend two main solutions, neither of which is all that practical. One is to periodically export user mailbox contents to PST files. Obviously, this is not a practical approach because of the administrative effort involved.
For more on this topic
Get information on backup considerations for Office 365
Brien Posey takes a closer look at using Microsoft Office 365
Microsoft Exchange Conference offers Exchange Server, Office 365 insight
Microsoft's other recommended solution is to make use of the deleted item recovery feature. When a user deletes a message, the message is placed into the user's Deleted Items folder, where it remains for the next 30 days.
Similarly, deleted mailboxes are not permanently deleted for 30 days. Instead, they are simply disconnected from the user account. If administrators want to recover a deleted mailbox, they simply reconnect it to a user account by using the Office 365 Admin Center to recover the corresponding user account.
Since periodically dumping messages to PST files isn't really an option and item and mailbox recovery is limited by a 30-day retention period (which is customizable), administrators need to look for a better way to protect their Office 365 data.
When Microsoft created Exchange Server 2010, it introduced a legal hold feature. This feature was intended as a way of helping administrators comply with federal regulations mandating long-term message retention. In a pinch, such a feature could be used to protect mailbox data in the absence of a true backup.
The legal hold feature was renamed to In-Place Hold in Exchange Server 2013 and Office 365, but the feature still works in a manner similar to that of previous versions. Enabling an in-place hold retains all deleted items for either a seven-year period or until you release the hold (whichever comes first). An administrator can access and recover deleted items by performing a multi-mailbox search, which is built into the Office 365 Admin Center.
Be careful of one thing, though: storage space consumption. Although Office 365 allows you to place items on hold for an extended period of time, each user has a limited amount of Office 365 storage space. The actual amount of space available varies depending on the subscription type. In any case, administrators must take care to ensure that in-place holds do not cause the available storage to be exceeded.
Unfortunately, there isn't yet a good way to back up Office 365. While there are backup utilities for SharePoint, Exchange Server administrators will need to use more creative solutions to protect messaging data.
This was first published in June 2014