Teams backup job design.

[dotdk]

Hello all,

Im searching for input on how you guys are handling larger M365 tenants, especially in regards to backing up teams.

We are a service provider, and one of our customers which consists of roughly 17500 users, have as of today 39633 Teams which are being handled in a job which only have teams selected. The 39633 teams resolves to 113.802 objects.

One of the problems we have is the time it takes just to count the objects - the "found xxx objects", that for this customer takes 109 hours before all teams are resolved, so that alone leaves us unable to do a daily backup.

We know about the 20.000 objects pr. proxy as a best practice, but if we were to split the job in to multiple jobs and on different proxy as repositories, how would that even be manageble since there is no autotmatic method to ensure all teams are being covered.

On another customer who has 3206 teams (9960 objects) the backup jobs runs for 4 hours 29 minutes and 50 second, where of the object enumeration takes 4 hours 29 minutes and 3 seconds. So the times it takes to "discover" the objects seems to be high, so how can we handle this as more and more customer are increasing the number of teams.

As info the teams job is being run on its own proxy as the only job, the proxy is specced with 16 cores and 128 GB memory. Threads on the proxy is set to 64.

[Polina]

Hi Thomas,

Resolving Teams objects takes more time compared to, for example, users, because from the backup perspective each team consists of 3 objects - team mailbox, team site, and teams metadata. I expect some enumeration improvements for Teams coming in the next version, but still, it won't be lightning fast.

Further increase of proxy CPU and RAM, unfortunately, won't make much difference to backup performance, according to our tests. However, you can try to play with the number of threads a bit. There's still a challenge of balancing between the faster processing and throttling applied at the same time, but given the big number of objects in the job, this can help to speed up.

For managing teams, some PowerShell creativity might come in handy. For example, there's an example of the script that allows to dynamically distribute SharePoint sites across multiple jobs, and, I believe, potentially something similar can be created for Teams.