365 Job design to grow into

[dhayes16]

Hello. Sorry, I think this has been asked many times. We have a site with about 70 users. At present, they are only using Exchange Online for email and teams. We want to design this site as well as others we do with the best practices in mind. I know Veeam has published several articles on best practices. But for this particular site, I see them migrating a LOT of data from on-prem servers to O365 so we want to build a solid backup strategy now to grow into. We could just do one backup job for the entire organization now but I suspect that will get ugly later as they grow and we want to provide a solid foundation to start. So we were thinking of (4) Backup jobs where the "Backup the following Objects" are all set to "Organization". However, for each backup job, we would edit the Organization and select the "Processing Options" we want to include. For instance, we were thinking of the following:

Backup Job 1: Processing Options Mail and Archive
Backup Job 2: Processing Options OneDrive
Backup Job 3: Processing Options Sites
Backup Job 4: Processing Options Teams

We were thinking that this would also be "dynamic" for each processing option so we do not need to manually "include" new users, new sites, etc. They would just be picked up by the Processing options above. Then as they grow we can get a little more creative if needed to include/exclude specific objects. The backup Repo would be Wasabi with one bucket but individual folders corresponding to the Backup Jobs above (4 separate folders).

Would this work? Any downsides? Am I overthinking it?

Thanks

[Mildur]

Hello Dave

One main goal of using different repositories is to leverage different retention periods for each type of source data. And different repositories may be required if you protect huge M365 tenants (Recommended maximums per proxy). With just 70 users, I assume you won't reach the recommended maximum.

For your design: I recommend to point the Sites and Teams job to the same repository. Teams Files are protected by SharePoint and Teams backup jobs. Pointing them to the same repository will only backup such data once. Using dedicated repositories for Teams and SharePoint will download and store the data twice in VB365.

Best,
Fabian

[dhayes16]

Thank you Fabian. That makes complete sense. So assuming we are well under maximums would it be logical to build baseline backup jobs in VB365 as follows?

Backup Job 1: Processing Options Mail and Archive
Backup Job 2: Processing Options OneDrive
Backup Job 3: Processing Options Sites and Teams

Is using the method described where were would create backup jobs based on the initial selection of "Organization" and then make the granular selection of "Processing Options" make sense? Would the 3 jobs above pick up all data in the organization in separate backup jobs? We don't want any data missed.

Although this is likely overkill for this particular customer we want to come up with a baseline backup job configuration for all customers that may help avoid a situation where a sudden change in business or increased use of 365 resources pushes those maximums thus requiring us to re-architech those cloud repos in the future. I guess avoiding one large backup job dumping all 365 data into one large repo.

I hope I am making sense. Once again Fabian thank you for your responses.

[Mildur]

Hi Dave

You're welcome.

Is using the method described where were would create backup jobs based on the initial selection of "Organization" and then make the granular selection of "Processing Options" make sense? Would the 3 jobs above pick up all data in the organization in separate backup jobs? We don't want any data missed.

Yes, with this setting, the jobs will pick up new objects after they were created in your M365 organization. no data will be "forgotten".

Although this is likely overkill for this particular customer we want to come up with a baseline backup job configuration for all customers that may help avoid a situation where a sudden change in business or increased use of 365 resources pushes those maximums thus requiring us to re-architech those cloud repos in the future. I guess avoiding one large backup job dumping all 365 data into one large repo.

The current recommendation for scaling purposes (using multiple repositories/proxies) are based on Veeam Backup for Microsoft 365 V7.
For service provider one of the main bottlenecks (after Microsoft's throttling policies) are proxy server. Especially for enterprise customer and service provider who protect huge M365 organizations. Multiple proxy server have to be deployed with dedicated repositories. Each proxy server requires each own backup job. We plan to solve this in our upcoming version 8.

Best,
Fabian

[dhayes16]

Thanks again...Ahh...So I did not realize the dedicated proxy server per repository. For small to mid-sized customers that will be an issue since there is typically only one proxy server. I suspect we will need to wait until V8 to change things around.

Thank you Fabian!

[Mildur]

Hi Dave

Maybe I wasn't clear. I apologize.
--> One proxy server can have multiple repositories.

You can create the 3 repository on a single proxy server. A second proxy server is strongly recommended if you start protecting more than 5000 users or 20000 objects.

Best,
Fabian

[dhayes16]

Thank you...You are the best as usual!