Job Design
- General
- User-based Services (Exchange, OneDrive)
- Microsoft SharePoint Online
- Microsoft Teams
- Catch-All Job
General
Veeam Backup for Microsoft 365 offers multiple options to create the backup job to protect the environment.
Backup jobs can be created based on Users, Groups, Sites, Teams and Organizations.
Configuring a single backup job is appealing, but the maintenance of a single backup job is challenging because of risks like single point of failure, management, backup duration and restore.
As a best practice the backup objects should be split to several jobs, depending on the amount of objects but also on the amount of infrastructure (e.g. proxies). While you can backup multiple services within a single job it is recommended to create jobs per service, e.g. separate Exchange backup, OneDrive backup and SharePoint backup jobs. Depending on the number of backed up objects there should be multiple jobs for each service.
Please refer to the recommended configuration maximums for details on how many objects/users can be in one job. The best practice is to stay well below (50-75%) the recommended maximum to be able to grow jobs when required and still stay within the limits. Reassigned objects from one job to another might include running these jobs on another proxy and thus to another repository which would involve a complete new full backup. The association of a single object to one job should preferrably stay the same all the time to avoid this scenario.
When experiencing issues with failed job retries because of environment size increase the retry fail in the job configuration at least to 20 minutes or more.
Also you should run the backup jobs outside the work hours to reduce the impact on Microsoft 365 throttling when other clients (OneDrive, ActiveSync etc..) are operating.
User-based Services (Exchange, OneDrive)
All user-based services in Exchange should be based on User-Group objects for easier maintenace. User-based services are Exchange, Exchange Archive, OneDrive and Personal SharePoint sites.
Dynamic Azure Active Directory Groups
The use of Azure AD dynamic groups for user-based jobs is a best practice as these groups are automatically and dynamically updated within the Azure AD, thus always representing the current state of your user base.
Please be aware that Azure AD Premium P1 licenses are required for every user that is part of a dynamic group.
You can split your user base easily into even groups with Azure AD Dynamic User Membership in Azure Active Directory. Create dynamic groups and leverage the dynamic rules based on the objectID property. This property is a unique GUID for each user and thus a randomized number with statistically equal distribution of starting numbers/letters (HEX) over your user base.
That said you can easily create regular expression match rules on the objectID property to create groups in any granularity. For example to split your user base in 50% you could use two groups with the following rules
Group 1 (50%): (user.objectId -match "^[0-7].*")
Group 2 (50%): (user.objectId -match "^[8-f].*")
To increase the granularity you can just easily add a “lower level” of number/letter to your regex, e.g. to group into 32 groups your first four groups could look like this:
Group1: (user.objectId -match "^0[0-7].*")
Group2: (user.objectId -match "^0[8-f].*")
Group3: (user.objectId -match "^1[0-7].*")
Group4: (user.objectId -match "^1[8-f].*")
There is a PowerShell script available on VeeamHub which can help you to automatically generate these groups in Azure AD.
You can add additional parameters to the query to restrict users even further, e.g. by filtering for users who have a specific plan assigned.
Microsoft SharePoint Online
Designing jobs for SharePoint can become a bit challenging for larger environments. In theory you can add as many sites into a single job as described in the configuration maximums. We strongly recommend keeping the amount of SharePoint pages to process within a single job much lower.
A way to split SharePoint sites into different jobs can be done dynamically by using PowerShell scripting. You can find an example in the VeeamHub which will add the SharePoint sites based on the first letter of the name.
Additional knowledge: There are some points you need to think of when it comes to SharePoint, such as how many SharePoint sites need to be protected or how many libraries are in the sites. A site with multiple libraries can be protected faster than a site with the same files within one library. In average we could see 1-2TB of data being protected from a customer tenant per day. But this can increase with a higher amount a ser’s in a tenant as Microsoft describes in their Application Throttling document.
Microsoft Teams
As most Teams data lies in SharePoint, the Teams job should point to the same repository as the SharePoint job for the corresponding Team sites. This way data objects are only stored once in the repository, even when linked from two services within Microsoft 365.
To protect all current and future Teams sites in an organization, you can choose to back up the organization object and then select only to process “Teams”. Be aware that this is only recommended if you have a small number of Teams in your organization and you will not exceed the configuration maximums. Each Team will count as 3 objects (Exchange, SharePoint and Teams itself) for the sizing.
Otherwise you can select single teams or create PowerShell scripts to protect Teams based on names.
Catch-All Job
You can create a catch-all job which will backup all items which are not yet processed by any other job. With this you can catch newly created users, Teams, SharePoint sites, etc. until you assign them to the appropriate job.
As this job needs to enumerate all your Microsoft 365 objects, this is only recommended for smaller organizations with a limited amount of objects.
You can add excludes to the job to avoid backup up items that you do not want to backup (blacklisting).