When an organization migrates its Exchange, SharePoint or Lync deployments to Microsoft Office 365, Microsoft's cloud app service, one of the first questions often asked is how backups and restorations work in the Office 365 environment. The sad truth is that you might not have as many options for restoring your data as you might think. As such, it is critically important to understand your options for disaster recovery in an Office...
Before I begin
The options for protecting and recovering Office 365 data vary from one Office 365 application to the next. This article will focus on Exchange Server, because it is the most widely used of the Office 365 applications. SharePoint and Lync will be discussed in future articles.
The first line of defense
When it comes to recovering Exchange Server data, your first line of defense is the same as it would be in an on-premises deployment. If an item is deleted by mistake, you can retrieve that item as long as the item's retention period has not expired.
Individual deleted messages are retained for 30 days. There's a way to change the deleted item retention period, but it isn't a user-level operation. When a user deletes a message, a copy of the deleted message is placed into the user's Deleted Items folder and the user is able to retrieve the message directly from the Deleted Items folder without involving the administrator.
There is also a 30-day retention period for deleted mailboxes. If a mailbox is deleted, then the administrator can get it back (with some exceptions) by using the Office 365 Web interface.
When administrators sign into Office 365, they are taken to the Admin Overview page, shown in Figure A. To recover a deleted mailbox, the administrator must click the Manage link found beneath Exchange. Upon doing so, the administrator will be taken to the Exchange Mailboxes page, which contains a Deleted Mailboxes icon. Clicking this icon causes the Deleted Mailboxes page to appear, as shown in Figure B. If a deleted mailbox is listed, you can select it and then recover the mailbox.
Click on the Manage link shown within the Exchange section.
You might have noticed in Figure B that no deleted mailboxes are listed. That's because I haven't deleted any mailboxes recently. However, there are other reasons why the list might be empty or might not display a deleted mailbox.
Mailboxes will not be listed if they were deleted more than 30 days ago. The Deleted Mailboxes list only displays user mailboxes. Resource mailboxes are not recoverable. Finally, mailboxes will not appear on the list if they belong to a federated domain or if the mailbox has never been used.
What about traditional backup and recovery?
Microsoft's primary mechanisms for protecting Office 365-based Exchange Servers are geographically distributed Database Availability Groups. Microsoft says they also perform traditional backups of Office 365 servers. However, those backups are used for internal purposes only if they experienced a catastrophic event that wiped out large volumes of customer data. Although Microsoft may occasionally restore data for a customer, the company seems to discourage the practice.
This can be a bit disheartening, because item-level recovery alone is often inadequate. Item-level recovery protects an organization against deleting items such as messages or mailboxes, but it does not allow for the recovery of a corrupt mailbox. Neither is there a provision for reverting a mailbox server to an earlier point in time (such as might be necessary if a virus corrupted all the mailboxes on a server). The Office 365 service-level agreement addresses availability, not recoverability.
Unfortunately, Microsoft does not allow Office 365 customers to be involved in the backup process. Customers cannot access the backups that Microsoft makes and there is no centralized mechanism for administrators to back up their own Exchange mailboxes. In a series of posts on an Office 365 message board, Microsoft makes suggestions such as asking users to export their contacts to a CSV file, or dumping mailbox contents to PST files for safekeeping. But these approaches are completely impractical for use in anything but the smallest organizations.
One last option
If a mailbox becomes corrupted and you can't get Microsoft to restore the mailbox, then you might be able to use the Outlook cache to get the mailbox data back. Outlook maintains an OST file containing the full mailbox contents (including messages, contacts, calendar items, etc.) The OSTs exist on individual PCs (or on a centralized server if roaming profiles are being used).
OSTs are different from PSTs because they are created automatically, fully encrypted, and unlike a PST, they are a complete mailbox copy that can be used to regenerate a mailbox's contents in the event of data loss. In an emergency, it is possible to disconnect a PC from the Internet and then open Outlook to access the cached data. This data can then be copied to a PST file. At that point you can delete and then recreate the corrupt mailbox. After doing so, the contents of the PST file can be merged into the newly created mailbox. This would occur in a cloud-based mailbox.
When it comes to disaster recovery for Office 365 Exchange, Microsoft uses redundancy to keep the service running and creates internal backups for use in the event of a large-scale disaster. The company has also taken steps to prevent mailbox corruption, such as using Forefront Protection for Exchange to guard against viruses.
For the time being, this seems to be the extent of your options for protecting Office 365 Exchange. However, some backup providers have begun to introduce products for backing up Office 365 SharePoint. It is possible that these vendors might eventually develop a similar solution for protecting Office 365 Exchange. Symantec currently has a cloud-based archiving solution for Office 365 Exchange called Live Office but does not yet offer true backup capabilities for Office 365 Exchange.
About the Author:
Brien M. Posey, MCSE, has received Microsoft’s MVP award for Exchange Server, Windows Server and Internet Information Server (IIS). Brien has served as CIO for a nationwide chain of hospitals and has been responsible for the Department of Information Management at Fort Knox. You can visit Brien's personal website at www.brienposey.com.