Restoring Data with Microsoft 365 Backup (Preview)

The Evolution of Microsoft 365 Backup to its Current Preview Status

Paul Robichaux, a longstanding MVP and someone who knows much more than I do about backup technologies, wrote an interesting review of the public preview of Microsoft 365 Backup for Practical365.com. I don’t need to dive into the details of what Paul covered about the mechanisms used by Microsoft 365 Backup to protect SharePoint Online, OneDrive for Business, and Exchange Online data. Instead, I decided to focus on how restore operations work. I did this on the basis that it’s straightforward for a backup product to stream data from a repository to create a copy of one form or another. The trick is to be able to restore copied data to the right place at the right time in the right way.

For background, I’ve been tracking the progress of Microsoft 365 Backup for several years, including discussions with the Microsoft engineers who built the product. When Microsoft began to discuss the product in public, I concluded that it was something I needed to test and potentially use over the longer term to protect my tenant’s data.

Until now, I have largely eschewed backups for Microsoft 365 and relied on native data protection (for Exchange Online) and retention policies. I consider many of the arguments advanced by companies selling backup solutions to be firmly rooted in FUD, especially when it comes to Teams. Unsurprisingly, because Teams is the most difficult Microsoft 365 workload to backup (and even harder to restore), Microsoft hasn’t included it in its set of target workloads.

When Microsoft launched the preview of Microsoft 365 Backup, I configured backup policies for all workloads and opted to protect the most active (and probably) valuable sites, accounts, and mailboxes in the tenant, including the site holding the source files for the Office 365 for IT Pros eBook. Backups have progressed since early January. Apart from adding extra mailboxes and accounts to the backup policies, I haven’t had to do anything since the original configuration.

Restoring Microsoft 365 Data

The big selling point for Microsoft 365 Backup is that it makes it fast and easy to restore data. The data for backups is stored in the Microsoft Cloud and is almost instantly accessible, or so the story goes. Backup professionals don’t like all their eggs stored in one cloud basket and don’t consider Microsoft 365 Backup to be a true backup. However, having everything in the Microsoft cloud makes backup and restore operations much faster than if the data must transit the internet to storage in a backup vendor’s datacenter.

There’s no doubt that Microsoft created a simple and easy to use UI for backup. The downside is that there’s no log to help you understand what happened during a restore or more importantly, where problems might have been met. Before beginning, it’s wise to read the latest set of limitations documented by Microsoft. Apart from anything else, you might discover that you must do something before a restore is possible, such as removing in-place holds from Exchange mailboxes. The number of documented limitations is likely to decrease as Microsoft develops the product from its current preview statis to a point where Microsoft 365 Backup is generally available.

You can learn the details of restore operations from Microsoft’s documentation. Creating a restoration task follows much the same path for all workloads:

• Select the workload.
• Select the protected locations (site, account, or mailbox) to restore.
• Select the restore point (Figure 1).
• Confirm everything and launch the restoration task.
• Wait for the restoration task to complete.

My experience is that Exchange Online restores are quicker than SharePoint Online or OneDrive for Business. That’s likely due to the way Exchange uses an existing copy-on-write mechanism to tag items. In all tests, Exchange restored data within a few minutes. As a quick and simple test to ensure that the data was restored, I used PowerShell to note the contents of important folders before and after a restore.

For example, here are the folder statistics at the time that I wanted to restore to:

Get-EXOMailboxFolderStatistics -Identity "James.Ryan@office365itpros.com" | where-object {$_.ItemsInFolder -gt 0 -and $_.Name -in $Folders} | Format-Table Name, ItemsInFolder, FolderSize

Name          ItemsInFolder FolderSize
----          ------------- ----------
Deleted Items             0 0 B (0 bytes)
Inbox                  1038 248.5 MB (260,572,313 bytes)
Sent Items               19 794.1 KB (813,182 bytes)
Deletions                 6 3.689 MB (3,868,185 bytes)
Purges                    1 1.904 KB (1,950 bytes)

I then removed some items from the Inbox and emptied the Deleted Items folder. The increased number of items in the Deletions folder matches the number of items removed from the Inbox and those emptied from Deleted Items (5).

Name          ItemsInFolder FolderSize
----          ------------- ----------
Deleted Items             0 0 B (0 bytes)
Inbox                  1033 247 MB (258,973,507 bytes)
Sent Items               19 794.1 KB (813,182 bytes)
Deletions                11 5.214 MB (5,467,162 bytes)
Purges                    1 1.904 KB (1,950 bytes)

I then created a restore task using the restore point closest to the time when I first noted the folder contents. When the restore finishes, I checked the data reported by Exchange. We can see that it roughly matches what was there at the start. One item from Sent Items was deleted, so it’s in Deleted Items. This emphasizes that Exchange Online uses a roll forward mechanism for restore, meaning that items that aren’t affected (a refile to another folder doesn’t affect the item status, a deletion does) are left intact.

Name          ItemsInFolder FolderSize
----          ------------- ----------
Deleted Items             1 19.28 KB (19,745 bytes)
Inbox                  1038 248.5 MB (260,572,377 bytes)
Sent Items               18 774.9 KB (793,459 bytes)
Deletions                 6 3.689 MB (3,868,185 bytes)
Purges                    1 1.904 KB (1,950 bytes)

Naturally, this is an imperfect way to validate restore operations. A visual check of mailbox contents confirmed that everything that I expected to be there was in place. Exchange Online logs audit records for the New-MailboxEnhancedRestoreBatch and New-MigrationBatch operations when it starts a restoration task. The details of the audit event only tell you that a restore began for a user called “NT AUTHORITY\\SYSTEM (w3wp).” Some of the data logged in the events might be useful to a Microsoft support representative, but the information isn’t detailed enough to help a tenant administrator understand what happened.

Happy that I could restore mailboxes, I went ahead to try to restore data for a SharePoint site.

Restoring SharePoint Online

Both SharePoint Online and OneDrive for Business use a roll back process for restores. In other words, you decide what restore point to use, and Microsoft 365 Backup rolls back the site or account to have the content stored at that time. Restores can be to the same site or to a new site. If you restore to the same site, the possibility currently exists that people working in the site might have their work overwritten. Microsoft plans to lock sites against changes to avoid this issue in the future. Exchange uses a roll-forward process, meaning that unchanged items since the chosen restore point are unaffected and only changed or deleted items are brought back. In any case, my experience with SharePoint restores didn’t go so well.

I added a bunch of files to a site and then tried to roll back to a point beforehand. The idea was to replicate infection by malware when you need to restore a site to the last good backup before the malware arrived. SharePoint accepted the restore task and about fifty minutes later politely failed. Nothing happened to the restore destination and the detail available about what happened to cause the restoration task to fail was non-existent (Figure 2).

Many attempts to restore the site failed and the last restoration task failed after nearly three hours (the second task listed in Figure 3). SharePoint Online does not log any audit records for administrators to check nor is any other log available to consult to discover why the task failed. Despite rereading the documentation several times and checking all the settings, I could make no progress. Perhaps it’s just me, but I failed in my initial attempts to successfully restore SharePoint Online sites or OneDrive for Business accounts.

Without Microsoft 365 Backup generating a log file or revealing more details about failure symptoms it’s hard to diagnose what’s happening. I put the problem to Microsoft and learned that the problem is due to the holds applied by retention policies. This limitation is documented for OneDrive and mailboxes but not for sites. For now, the solution is to restore files to a new site. This works and restoring files to a different site allows them to be copied to the original site as necessary. However, it’s not quite the smooth recovery operation that I anticipated, even in a preview product.

My biggest concern is that the holds imposed by retention policies block restoration tasks. When things go wrong, administrators want to restore sites or accounts back to good health as quickly as possible. Speed, after all, is the promise extended by Microsoft 365 Backup. Altering settings for Microsoft 365 retention policies to remove holds on sites, including the potential need to adjust adaptive scopes, is not speedy. It can take days before changes are fully respected by SharePoint Online. How then are fast restores possible?

Remember It’s a Preview

Microsoft 365 Backup is a preview solution, but it’s a paid-for preview and I expected what appears to be a straightforward restore request to happen without trauma. After talking to Microsoft, I think they understand that problems exist that must be sorted out before the product reaches general availability. As noted above, these issues include speed of restore, faster detection of problems in restoration tasks, better error handling and logging, and much more elegant handling of sites under control of retention policies.