Veeam O365 Best Storage Setup

[gingerdazza]

Hi. Starting to investigate Veeam O365 design, and interested to hear who is backing up to on-premises storage, who to public cloud storage like Azure, and who to third parties like iLand. Pros/cons, like/dislikes. Big no-nos. Etc. Would really appreciate any insights... thanks

[HannesK]

Hello,
to get better answers, I believe that it would help if you could tell the public what amount of data you are talking of. Maybe also how long you want to store it.

EDIT: For on-prem: block storage is better than SMB shares. The faster the better. For small environments (few hundred users with a few TBs not really relevant as long proper RAID controller is used).

For object storage in public cloud: I would go with vendors that do not charge for API calls.

Best regards,
Hannes

[Mike Resseler]

Hey Dazza,

I disagree with Hannes on the on-prem. Block storage is an option, but S3-compatible is also an option. There are indeed differences, but if you look at the market, then I think you can agree that object storage has a big future, and we are working more and more with these technologies. Block storage is still there, and also an option, depending on how you will architect your solution, this can be a very good solution. But it could also lead to performance issues if you make the wrong assumptions.

Going to the cloud basically has the advantages of going to the cloud . You can obviously use Azure, but also AWS, or use any other cloud where you can deploy it. iLand or others are options and (imho) have a better "relationship" model. You can phone them in case of issues, they have portals and manage a lot for you, where in Azure / AWS ... you still have to deploy and maintain the service yourself.

Very difficult to give you pros/ cons and so on, because what a pro is to me, might be a con to you...

[HannesK]

my on-prem was "block storage vs. SMB NAS file share" (I edited my post to avoid confusion)

because some people put the database on SMB storage...

I also assumed, that someone who considers public cloud blob storage (Azure), does not have a local S3 storage. But sure, also S3 compatible object storage on-prem is fine. Actually the feedback I got was, that moving from block storage to local object storage solved some performance issues (several thousand users)

[gingerdazza]

I s'pose, as always, "it depends"....
It seems like the biggest challenge with O365 is recovery.... recovering any size of data directly to O365 is likely to be painful due to the fact that the only 'front door' to O365 is the throttled API. So, no matter what bandwidth or storage we have, the restores to O365 are gonna be limited in desirable RTOs?? Yes?

We're not yet sure exactly how many people and how much data we're talking about... that's on its way but it's likely to start off around 50 users. Could eventually end up being 500.

So what advantages do you think customers will get from S3 storage over block?

What DR recovery strategies do you see being most successful in O365 given the limitations of recovery speed direct o the O365 cloud?

[Mike Resseler]

Hey Dazza,

Throttling is indeed the biggest issue with these type of services. What I believe the biggest advantage from object over block is the scalability to larger organizations and less infrastructure resources needed compared to block storage where the Jet databases need to run all the time. But if you are looking at eventually 500 users in 1 organization, then it won't make that much of a difference, besides (and might be important) that we can't encrypt the JET DB at the VBO level (bitlocker is a potential option) where we can encrypt object storage at rest

[gingerdazza]

Thanks. So, what strategies are being employed out there to provide reasonable SLAs on RTOs out there if large organisations are being massively limited with throttling?

[Steve-nIP]

Good question.

[ITP-Stan]

Was there not an option to use multiple user-accounts simultaneous for the restore?

[Mike Resseler]

@ITP-Stan That is for SharePoint / OneDrive for Business. But you are right, we do have mechanismes that work on avoiding the throttling as much as possible.