Job Design
- General
- User-based Services (Exchange, OneDrive)
- Microsoft SharePoint Online
- Microsoft Teams
- Catch-All Job
General
Veeam Backup for Microsoft 365 provides various options for creating backup jobs to protect the environment.
Backup jobs can be configured based on Users, Groups, Sites, Teams and Organizations.
While configuring a single backup job might be appealing, maintaining such a job presents challenges due to risks like a single point of failure, management complexity, backup duration, and restore issues.
As a best practice, it is recommended to split backup objects into several jobs, considering both the number of objects and the infrastructure capacity (e.g., proxies).
Although you can backup multiple services within a single job, it is advisable to create jobs per service. For instance, having separate backup jobs for Exchange, OneDrive, and SharePoint + Teams is recommended. The number of backup objects should dictate the creation of 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 allow for job expansion when required while still staying within the limits. Reassigning objects from one job to another may involve running these jobs on another proxy and, consequently, to another repository, necessitating a complete new full backup. Ideally, the association of a single object to one job should remain constant over time to avoid this scenario.
If you encounter issues with failed job retries due to an increase in environment size, consider extending the retry fail time in the job configuration to at least to 20 minutes or more.
Additionally, it is recommended to schedule backup jobs outside of work hours to minimize the impact on Microsoft 365 throttling when other clients (OneDrive, ActiveSync, etc.) are in operation.
User-based Services (Exchange, OneDrive)
For easier maintenance, all user-based services in Exchange, including Exchange Archive, OneDrive, and Personal SharePoint sites, should be based on User-Group objects.
Dynamic Azure Active Directory Groups
Using Azure AD dynamic groups for user-based jobs is a best practice as these groups are automatically and dynamically updated within the Azure AD, 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.
With Azure AD Dynamic User Membership in Azure Active Directory, you can easily split your user base into even groups. 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 being 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-9a-f].*")
To increase the granularity you can just easily add a “lower level” of number/letter to your regex, For example, 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-9a-f].*")
Group3: (user.objectId -match "^1[0-7].*")
Group4: (user.objectId -match "^1[8-9a-f].*")
A community driven PowerShell script available on VeeamHub to help you automatically generate 64 groups in Azure AD and create the corresponding jobs in Veeam Backup for Microsoft 365. These groups contain a Dynamic Group membership rule to filter on the first two characters of the user’s identifier. If more or fewer groups are needed, the corresponding array can be modified in the script.
You can add additional parameters to the Dynamic Group membership rules to filter users even further, for example, by categorizing 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. An example can be found in the VeeamHub which will add SharePoint sites and Teams to jobs by respecting a defined maximum of objects.
SharePoint Online also offers Personal Sites for users. These sites can be seen as a profile display and collaboration entry point for employees. In most cases, these sites do not contain important company data, which is why we advise checking if they need to be protected or not. There are thousands of personal user sites that could be excluded from backup jobs, which can drastically reduce the time and performance impact during backups.
There are some points to consider 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. On average we have observed 1-2TB of data being protected from a customer’s tenant per day. However, this can increase with a higher number of users 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.
Consider protecting the corresponding Teams and SharePoint data within one job to avoid warning messages indicating that the data is already protected by a different job. This can occur when separate Teams and SharePoint jobs run in parallel and try to protect the same data stored by Teams in its SharePoint site.
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.
Alternatively, you can select individual teams or create PowerShell scripts to protect Teams based on names.
Catch-All Job
You can create a catch-all job that will back up all items 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, it is only recommended for smaller organizations with a limited number of objects.
You can add excludes to the job to avoid backing up items that you do not want to include (blacklisting).