Veeam Backup for Microsoft 365 v6 Data Recovery Scenarios

Veeam Backup for Microsoft 365 is a solution that allows you to back up and restore Microsoft 365 data:

You can also protect data managed by this on-premises installations:

The purpose of this article is to illustrate how to restore access to your backup data in case of a disaster that impacted Veeam Backup for Microsoft 365 server.

For any further information about Veeam Backup for Microsoft 365 features and how to install and configure it, please refer to the official Veeam documentation.

I will start with a quick review of Veeam Backup for Microsoft 365 architecture describing its main components: backup server, proxy server and repositories, and then discuss and solve three “catastrophic” scenarios.

Architecture Brief

Before analyzing Veeam Backup for Microsoft 365 components, let’s look at how backup and restore flows work.

The diagram shows how, during a backup process, data flows from a Microsoft 365 tenant and local Exchange and SharePoint servers to Veeam Backup for Microsoft 365, then to a local backup repository:

As you can see, the backup data is written directly to the local repository.

When you have object storage as a backup target, the data will flow from the source environment to the Veeam Backup for Microsoft 365. Metadata is the written to a local repository, in an area called local cache, while actual data is written to the object storage container. A copy of the cache is also transferred to the object storage container — this will become very useful in the event of a disaster, as I’ll explain later.

Here is the data recovery flow:

When retrieving data from block storage, data flows between Veeam Backup for Microsoft 365 components and the repository itself.

On the other hand, when restoring data placed on object storage, all search and browse operations take place in the local cache repository. Once the items you want to restore have been identified and the restore process starts, only the related data is actually downloaded from the cloud, without generating unnecessary egress traffic and API requests that could raise the cloud costs.

Let’s go through the main components of Veeam Backup for Microsoft 365.

Backup server

This is the most important component as it allows you to add on-premises and Microsoft 365 organizations to Veeam Backup for Microsoft 365 infrastructure, define repositories, configure notifications, create reports on mailbox and users’ protection, license usage, and storage consumption, etc. and it is responsible for managing all backup and restore jobs.

Proxy server

This component is automatically installed together with the backup server and is responsible for executing backups and restores. It retrieves data from Microsoft 365 tenants and on-premises organizations and stores it in Veeam Backup for Microsoft 365 repositories.

During restore operations, the proxy server reads data from the Veeam Backup for Microsoft 365 repositories and writes it directly to the chosen destination.

For scalability, you can have multiple proxy servers managed by a single backup server. Refer to the Best Practice Guide for Veeam Backup for Microsoft 365 for more info.

Backup repository

A backup repository is a folder on a block storage, mounted to a backup proxy server. It can be on a local disk or remote (SAN) connected to the proxy server.

An object storage repository consists of two storage areas:

Starting from Veeam Backup for Microsoft 365 v6, you can extend your backup jobs pointing to object storage-based repositories with backup copy capabilities and have an instance of your backed-up data in Azure Blob Storage Archive, Amazon S3 Glacier or Amazon S3 Glacier Deep Archive storage classes. More info, here

Repositories used for backup copies also need an on-premises space to store their cache, just like the repositories used by regular backup jobs.

What’s the cache, anyway?

Veeam Backup for Microsoft 365 uses the local cache to retrieve the structure of the backed up objects and load it into the inventory pane of the Veeam Explorers, so that you can and browse through it and perform searches without downloading any data from object storage.

Cache is saved to the PersistentCache directory as a JET-based database and then is replicated to the object storage repository. The location of the PersistentCache directory is specified when you add a new repository that will offload data to some object storage container.

Disaster scenarios

Disaster scenario #1

In this first scenario block storage repositories  are used, but unfortunately the Veeam Backup for Microsoft 365 servers are no longer operational. For example, backups are hosted on a healthy data volume, and you can still safely access all backup files.

A first way to quickly perform an urgent restore is:

  1. Install a new Veeam Backup for Microsoft 365 server with all Veeam Explorers (it’s the default setup method, after all)

     2. Run the Explorer for the workload you want to restore (let’s say, Exchange Online)

    3. Browse the volume that contains the backup data previously managed by the old Veeam server

    4. Open one of the .adb files

     5. Browse through the content, choose the object you want to recover from the backup and start restoring

If, on the other hand, you want to perform a complete and permanent restore operation, you must add the same organization and repositories to the newly installed Veeam Backup for Microsoft 365 server:

  1. Add the same tenant(s) you managed with the faulty Veeam Backup for Microsoft 365 server
  2. Add a new backup repository pointing to the root folder of your old backup repository
  3. Repeat for all remaining backup repositories

Even if you don’t create any new backup job, you will be able to browse point-in-time states and restore your data.

You can even create a new backup job pointing at the recovered repository, any following backup will be added to the existing backup chain.

Disaster scenario # 2

Veeam Backup for Microsoft 365 servers are fine, all backups are still safe in the object storage repository, but the cache has been corrupted or deleted.

By looking at your repositories in the Veeam Backup for Microsoft 365 console, you will probably see that one or more of them show the message “Out of Sync”.

Remediation: just right click the “Out of Sync” repository and select Synchronize. That’s all!

This procedure can also be performed for Azure Blob Archive and AWS S3 Glacier/Glacier Deep Archive repositories, in case you want to restore access to your backup data copies.

Disaster scenario # 3

Veeam Backup for Microsoft 365 servers are out-of-service, but once again your backups are still safe in the object storage repository.

Again, for a complete recovery in production, install a new Veeam Backup for Microsoft 365 server with the Veeam Explorers.

Add the same tenant(s) managed by the faulty Veeam Backup for Microsoft 365 server.

Create a new object storage repository pointing to the same object storage container previously used by the now vanished Veeam Backup for Microsoft 365 server.

Create a new backup repository offloading the backup data to the newly created object storage repository.

And now, just two clicks on two message boxes:

Right click on the organization, select the Veeam Explorer of your choice and navigate between the available restore points. Even if you don’t create any new backup jobs, you will be able to browse point-in-time states and restore data.

Last step: you can create a new backup job pointing at the recovered repository. Any following backup will be added to the existing backup chain.

Dealing with archive storage

As mentioned above, you can use Azure Blob Archive or AWS S3 Glacier/Glacier Deep Archive storage classes as a target for backup copy jobs. If you need to access backup data placed in an archive object storage repository, you need to start a retrieval job. When this type of job is completed, the retrieved data will be accessible for a certain number of days during which it can be explored and restored using Veeam Explorers.

In case you lose the Veeam Backup for Microsoft 365 server you can follow this procedure to perform a data retrieve operation:

  1. Install a new Veeam Backup for Microsoft 365 server with the Veeam Explorers
  2. Add the same tenant(s) managed by the faulty Veeam Backup for Microsoft 365 server
  3. Create a new object storage repository pointing to the same Azure Blob Archive or AWS S3 Glacier/Glacier Deep Archive object storage container used by the old Veeam Backup for Microsoft 365 server

4. Create a new backup repository offloading the backup data to the newly created object storage repository

5. Click Yes twice.

6. Right click the newly created backup repository and select one of the available Retrieve commands:

7. Follow the Retrieve Backup Copy wizard to create a data retrieval job (for detailed info, click here)

8. When the retrieval job completed, you can open backups by right clicking the retrieval job and select Explore Retrieved…

9. Browse through the content, choose the object you want to recover from the backup and start restoring

Protecting Veeam Backup for Microsoft 365 servers

Can we protect the server components of Veeam Backup for Microsoft 365, perhaps with some proven Veeam technology? Yes, we can!

Veeam Backup for Microsoft 365 Backup and proxy servers include a specific Veeam VSS writer which allows you to perform their backups with application consistency, even while processing Microsoft 365 data backup and restore operations.

This way, you can leverage Veeam Backup & Replication to protect both virtual and physical Veeam Backup for Microsoft 365 installations, with at least four benefits:

Conclusions

In this article, we’ve seen how, in the event of a disaster hitting the Veeam Backup for Microsoft 365 servers, you can still perform restore operations from your backup data — whether it’s on local storage or stored in the cloud — with few simple steps.

In addition, I also described how to leverage Veeam Backup & Replication to protect Veeam Backup for Microsoft 365 servers and be able to quickly recover them, in both partial and total failure.

Exit mobile version