VBO Job and Repository Orchestration

[CKESSLER]

Dear All,
I was wondering what would be the best way to orchestrate my VBO Jobs / Infrastructure.

Already read these forum posts but did not came to a final conclusion:
- search.php?keywords=separate&fid%5B0%5D=47
- post419316.html?hilit=sharepoint%20and%20teams#p419316

Our Environment:
- Users: ~2.500 with 4TB Mailboxes and 1,5TB OneDrive Data
- SharePoint Online Classic Sites (no M365 Group) : ~ 100 sites with 4,5TB Data
- Teams Groups: ~ 1.000 with 0,5TB Data
- virtual VBO Server, backed up with VBR
- Two Backup Storages:
a) Dell ME4024 SAN Storage only for Backup used
b) Cloudian S3 Object Storage only for Backup used
(both are also used for VBR Backup as a SOBR / Cloudian for immutable Backups)

Our backup requirements:
- Backup: Backup Daily all data ; Snapshot-Based ; Retention 14 days
- Archiv: Backup Daily all data ; Item-Level-Based ; Retention 10 Years for Compliance Reasons
- Backups Protected Against Ransomware

I thougt about following design and would be interessted in your opinion.

Regarding Backup:
- VBO Server has 4 virtual volumes, one for each data type: Mailbox/Archiv, Sites,OneDrive,Teams
I separated it to several volumes because I would like to keep them not too large. Having more flexibility in the need of restoring whole VBO Server.
The volumes are hosted on the ME4024 while they are connected over ESX Host as a VMDK disk.

- on each Volume is the equivalent repository with snapshot-based and Retention 14 days
- The VBO is also backed up daily with VBR to the Cloudian for Immutable Backups.

- 4 Jobs created for Mailbox, Sites, OneDrives, Teams

Regarding Archiving
Backup directly to Cloudian S3
- Created 1x Bucket on the Cloudian with 4x Folders (again Mail,Sites,OneDrive,Teams) and added each as a own Object Storage Repository
- Created 4x Archiv-Repository with Offload to Object Storage Repository, Item-Level-Based and 10Y Retention.
- Created 4x Jobs for Archiving


I see the following drawbacks and questions :
- Backup: SharePoint Sites and Mailboxes of Teams are backed up twice since the jobs use different Repositories -> maybe solved by having one large repository for these jobs
- Archiving: No immutability possible since VBO currently does not support Immutable S3 Backup Management
- No Offsite Backups, both ME4024 and Cloudian are on same site. Maybe this can be achieved by creating additional Jobs for Backup to Azure S3 Storage.
- General: Veeam suggests maximum of 500 Mailboxes per Job and 50 Sites per Job ? Don't know what would be best to seperate it to multiple Mail/Site Jobs (I do not have valid user groups yet, which I can use)

Hope I explained everything understandable. Would like to add a picture of the setup, but don't know how it works in this forum...

Thanks for your input,

Chris

[Mike Resseler]

Hi Chris,

A lot of information, so we will probably have to take this step by step.

- Backup: Backup Daily all data ; Snapshot-Based ; Retention 14 days
- Archiv: Backup Daily all data ; Item-Level-Based ; Retention 10 Years for Compliance Reasons

I think we have to start with this. What I assume you want to do, is to take a backup of the data with a backup job with those requirements, and then create another backup job with the same objects but to object storage. This won't work because VBO lets you protect the data only once. Or did I misunderstood what you are trying to do?

[CKESSLER]

Hello Mike,

Thank you for your reply and that you take time for this.

Yes, that's basicly what I planned and already configured in a test:
- Job "O365_Backup_Mail" (To Repository 1 - Snapshot Based - 14 Days Retention)
- Job "O365_Archiv_Mail" (To Repository 2 - Item-Level - 10 Years Retention - with "Offload Backup Data to Object Storage" enabled)

As far as I can see, it works. My personal mailbox is included in both jobs and gets backed up with each of them.

You mentioned "VBO lets you protect the data only once". Are you refering to the fact, that if O365 data is already on the same repository, VBO will use this data?
(see post406812.html#p406812)
Then in my case, I have different repositories and therefore I guess it gets backed up again.

Regards,
Chris

[Mike Resseler]

Sorry,

Looks like I made a mistake. Yes, you are using a separate repository so it is indeed possible. So let me look into your other questions:

- Backup: SharePoint Sites and Mailboxes of Teams are backed up twice since the jobs use different Repositories -> maybe solved by having one large repository for these jobs

Correct, however:
- You can indeed work with one large repository but the downside are those warnings that we talked about
- You can also exclude the mailbox/ sharepoint sites from the general job and that would have my preference

- Archiving: No immutability possible since VBO currently does not support Immutable S3 Backup Management

Correct, but step by step you will see us move to this functionality. The question is if you can wait for that time.

- No Offsite Backups, both ME4024 and Cloudian are on same site. Maybe this can be achieved by creating additional Jobs for Backup to Azure S3 Storage.

In vNext you will also be able to do this with backup copy job from your object storage archive to AWS Glacier/ Deep Archive or Azure Archive. New functionality coming this year

- General: Veeam suggests maximum of 500 Mailboxes per Job and 50 Sites per Job ? Don't know what would be best to seperate it to multiple Mail/Site Jobs (I do not have valid user groups yet, which I can use)

I am not sure where that is stated (thats an old metric but it could be that we missed it somewhere). See here: https://bp.veeam.com/vbo/guide/design/sizing/
You will be able to take your 2.5K users in a single job. However, we do recommend to look into your job planning and don't let Exchange/ SP/ ... jobs all run at the same time

Thoughts?

[CKESSLER]

Hello Mike,

- Backup: SharePoint Sites and Mailboxes of Teams are backed up twice since the jobs use different Repositories -> maybe solved by having one large repository for these jobs
Correct, however:
- You can indeed work with one large repository but the downside are those warnings that we talked about
- You can also exclude the mailbox/ sharepoint sites from the general job and that would have my preference

Allright, I go with 1 Job / Repository / virtual Disk for Sites and Teams also using an own VBO Proxy Server

Then I still have the two other Jobs, ... One for Mail and one for OneDrives

- Archiving: No immutability possible since VBO currently does not support Immutable S3 Backup Management
Correct, but step by step you will see us move to this functionality. The question is if you can wait for that time.

Guess I will start without immutable storage

- No Offsite Backups, both ME4024 and Cloudian are on same site. Maybe this can be achieved by creating additional Jobs for Backup to Azure S3 Storage.
In vNext you will also be able to do this with backup copy job from your object storage archive to AWS Glacier/ Deep Archive or Azure Archive. New functionality coming this year

Great to hear and I'm looking forward to it.
May I asked what "vNext" means exactly?

- General: Veeam suggests maximum of 500 Mailboxes per Job and 50 Sites per Job ? Don't know what would be best to seperate it to multiple Mail/Site Jobs (I do not have valid user groups yet, which I can use)
I am not sure where that is stated (thats an old metric but it could be that we missed it somewhere). See here: https://bp.veeam.com/vbo/guide/design/sizing/
You will be able to take your 2.5K users in a single job. However, we do recommend to look into your job planning and don't let Exchange/ SP/ ... jobs all run at the same time

Well, I read the "500 Mailbox / 50 Site Best Practices" on the same site: https://bp.veeam.com/vbo/guide/operate/jobconfig.html
So maybe my link is outdated? or points out a Best PRactice while your Link is the technical limitation?


So far thank you for your answers, which helped me going further with my Job Orchestration

[nielsengelen]

vNext means the next release which is our upcoming v6 release later this year.

On the sizing link for job configuration, we are still updating it to match v5 data and therefor Mike suggested to go with 2500 in 1 job as we did huge improvements for scaling in v5.