Scale-out, splitting and 2 stage VeeamO365 Repo's

[ortec-RW]

Hi

I've been thrown into our companies Veeam Office 365 setup. Been using the regular Veeam B&R up until now. Just getting to grips with the O365 product.

My problem is sizing. Out current repository is almost 20TB, fully NAS based. And it's running out of space. I cannot extend the NAS space. I could replace it with a new NAS of let's say 40TB so my problem is moved forward about 3 years. But I don't like moving problems. I like to fix them. But how on earth do you size and scale VeeamOffice365 ?

Time to split up the data right ? We already have a split in Mail and Sharepoint, so I could divide them over two NAS repositories. One big (mail) and one smaller (Sharepoint). But that's still not really solving it, just moving around more smaller bits.

The folder structure in each repository is based on Years. So it looks like there is built-in split possibility.
What would happen if I move the 'oldest' years someplace else ? And only leave the recent years inside the active repository ?

- Would I break my repository as a whole ?
- I would only be able to do restores on data that changed/was born within the years I leave inside the repositories ?
- Can I 'attach' those older years to another passive (read-only) Veeam O365 server if I want to do older restores ?
- Or do I need to throw this idea outside the window and do something completely different ?

I want my active repositories to be smaller. But still be able to go back further, but that older data doesn't have to be online all the time, and be a burden on my recent backup data. I could even live with a smaller Retention, and only 'freeze' each year as archive. If my recent repo's are small, I can do a 2nd stage backup on them using Veeam B&R towards Immutable S3 storage. Which is not possible natively with VeeamO365.

Any tips are welcome.

[Mike Resseler]

Hi Richard,

First: do you consider object storage? (doesn't matter if it is AWS/ MSFT/ Wasabi/ IBM cloud or on-prem S3 compatible). With 20 TB, I think this would be the way forward. Jet DB repository works great till a certain size, but after that you should consider the object storage route, especially as data in M365 will only grow in the future.

[ortec-RW]

Yes I have. And we have S3 on-prem. It scales much better, but scaling S3 is currently not an option for our company. And it still doesn't offer me immutability, since that's not natively supported in VeeamO365 with S3.

I don't have to have 5 years of immutable O365 backup data in S3. If I could store the last 3 months in S3 with immutability, I'd be happy to store the remaining 4,5 years in regular S3 without Immutability. The problem is where do I make the cut ? Or how do I split this huge pile of data ?

[BaptisteT]

Hi Richard,

To start with a correct assumption, you can use https://calculator.veeam.com/vbo/ that could help you design the future of your repository.
You will see that storage require on object storage is around 50% less than on block storage, so on a budget perspective it can become really interesting.

Beside sizing, there is no way to split or cut or move folder data on block storage, it's JetBlue DB with lots of relation.

So your options are to split jobs based on services (which is best practice on a performance stand point) on multiple repository to fits your needs (multiple buckets would be a must)

Regards,

[ortec-RW]

Good points. With that calculator and the 50% gain, I just might be able to get additional S3 budget.

But I'm still stuck with my immutability issue. No native support. The only way I can get immutable O365 backups is to backup to a repository, and then backup that repository a 2nd time as block-storage in Veeam B&R to another S3 bucket via an SOBR. Just like my VMs, only much much bigger.

I'm even re-considering going with on-prem S3 now. Or immutability at all.
But I have an entire night to loose sleep over that. And Xmas too

[Mike Resseler]

@ortec-RW

Immutability is something which is on my roadmap, including for S3-compatible (if those vendors support it obviously). Also on the roadmap is backup copy from any object storage to any object storage. In that case you might get your entire strategy.

[Eric_Cartman]

@Mike Resseler:
Any idea when these "features" are implemented in Veeam Backup for O365?
We have the same problems in our company.

Backup is limited to one Raidcluster insteadto the whole ScaleOut and Backup Copy Jobs are non existent which in case of Randsomware etc is a big security issue...

[Mike Resseler]

@Eric_Cartman

I do have an idea . In all seriousness, immutability and backup copy from object storage to any object storage (backup copy from object storage to a low-cost object storage such as Azure archive / AWS glacier and deep archive) is coming out any day now. Enhancing that functionality is next on the list but it won't be there in 2 months. I do hope to have all of this in the next version. (v7)

[Eric_Cartman]

Thank you for that information - looking forward to the "new" features

[Eric_Cartman]

And count a +1 for the feature request of encrypting the backup

[Mike Resseler]

@Eric_Cartman I might be understanding it wrong but you can already encrypt an object storage repository?

[Eric_Cartman]

@Mike Resseler: Yeah but not on prem!
Like in B&R where you can encrypt the backup and backup copy jobs which are transported to a on prem Repository and in my case to a hardened Repository

[clo101]

So how does Backup Copy solve the problem of very large backup sets? I have 50TB backups of exchange, 20TB in Sharepoint, close to 50TB on One Drive.

We have a corporate policy to keep backups for a minimum of 7 years. We have been an early adopter of VBO since version 3.

We use VBR 11 for regular and the SOBR works well with GFS and scale out to the many cheaper storage tiers. For 0365 we are reaching our storage capacity and need some guidance how the current job can be moved to object and further Tiered into Hot, Cool and Archive.

Anyone has any suggestions as from my experience with backup copy it just creates another copy of what i have in archive.

[Mike Resseler]

@Eric_Cartman There is no encryption on a Jet DB repository. The only way to do this would be to encrypt all data and store it encrypted into that database but that leads to a whole lot of other issues I'm afraid. Only encryption such as bitlocker is possible at this point in time and honestly I do not see us going in another direction for Jet DB repositories

@clo101 Are you using the Jet DB repository?

[clo101]

yes we are using the JET DB repository for the on prem repository.

[bperez]

the new Version of VBO is 6.0 and it supports object storage (immutability depends on the vendor). I just upgraded to 6.0 and will be trying to do this soon.

[Polina]

Hi Brent,

Object storage repositories are introduced in VB365 for a few versions already, but immutability is not yet supported.