-
- Service Provider
- Posts: 271
- Liked: 61 times
- Joined: Nov 17, 2014 1:48 pm
- Full Name: Florin
- Location: Switzerland
- Contact:
Object Storage vs Jet
I heard today, that veeam recommends to use object storage over conventional repositories if you backup more then 1000 users.
Never heard of that recommendation before and also couldn't find anything official in the documentation.
The reason for it should be, that if you use object storage, you workaround the limitations of the Jet-DB.
Is this true?
If yes, whats the limit? 1000 users per repository or in general?
We currently backup several thousand users to several different (convential) repositories and don't really have issues with it. But as we're growing every day, it would be useful to know the recommendations.
Never heard of that recommendation before and also couldn't find anything official in the documentation.
The reason for it should be, that if you use object storage, you workaround the limitations of the Jet-DB.
Is this true?
If yes, whats the limit? 1000 users per repository or in general?
We currently backup several thousand users to several different (convential) repositories and don't really have issues with it. But as we're growing every day, it would be useful to know the recommendations.
-
- Product Manager
- Posts: 8184
- Liked: 1317 times
- Joined: Feb 08, 2013 3:08 pm
- Full Name: Mike Resseler
- Location: Belgium
- Contact:
Re: Object Storage vs Jet
Hey Florin,
The 1000 users limitation comes more from the SMB versus larger customers number then it is a true, technical recommendation. You can have more users on a Jet DB repository depending on the size (and more importantly, depending on the # of SharePoint sites and Teams). As a service provider, I would recommend to go to Object Storage as many of our future improvements around scalability (and lower TCO for the service provider) will come only on Object Storage repositories because that is the only way we can build out a true scale-out solution.
Hope it helps
The 1000 users limitation comes more from the SMB versus larger customers number then it is a true, technical recommendation. You can have more users on a Jet DB repository depending on the size (and more importantly, depending on the # of SharePoint sites and Teams). As a service provider, I would recommend to go to Object Storage as many of our future improvements around scalability (and lower TCO for the service provider) will come only on Object Storage repositories because that is the only way we can build out a true scale-out solution.
Hope it helps
-
- Service Provider
- Posts: 271
- Liked: 61 times
- Joined: Nov 17, 2014 1:48 pm
- Full Name: Florin
- Location: Switzerland
- Contact:
Re: Object Storage vs Jet
Thanks for the clear statement. That helps for planning.
-
- Enthusiast
- Posts: 78
- Liked: 46 times
- Joined: Dec 10, 2019 3:59 pm
- Full Name: Ryan Walker
- Contact:
Re: Object Storage vs Jet
I'd also like to append something on why to use Object Storage: Retention and the failure that was Jet.
VBO - I'd have to verify on the Onedrive/Sharepoint side but at least on the Exchange side - utilizes an exchange DB per year - and thus grows without shrinking even if you purge those previous years data via retention.
Case in point: I purged a LOT of old mailboxes... but even if it takes the data out of the last 2-3 years DBs, that space is only freed up inside that specific DB to be reused. So if it's sitting on non-dedupe storage (aka cheap and deep) then you're faced with a ton of white space that 'could' be reused but cannot be without shrinking the EDBs - which while in theory you COULD do using Eseutil, it is not from what I've seen officially supported nor would I generally recommend it, especially when we're talking tens of TB of data.
Object Storage doesn't care. Object Storage just issues Delete commands on data. Object Storage now has free space to take in all your new goodness.
Object Storage is The Way
VBO - I'd have to verify on the Onedrive/Sharepoint side but at least on the Exchange side - utilizes an exchange DB per year - and thus grows without shrinking even if you purge those previous years data via retention.
Case in point: I purged a LOT of old mailboxes... but even if it takes the data out of the last 2-3 years DBs, that space is only freed up inside that specific DB to be reused. So if it's sitting on non-dedupe storage (aka cheap and deep) then you're faced with a ton of white space that 'could' be reused but cannot be without shrinking the EDBs - which while in theory you COULD do using Eseutil, it is not from what I've seen officially supported nor would I generally recommend it, especially when we're talking tens of TB of data.
Object Storage doesn't care. Object Storage just issues Delete commands on data. Object Storage now has free space to take in all your new goodness.
Object Storage is The Way
-
- Veeam Software
- Posts: 3170
- Liked: 770 times
- Joined: Oct 21, 2011 11:22 am
- Full Name: Polina Vasileva
- Contact:
Re: Object Storage vs Jet
Hi Ryan,
Thanks for sharing your findings and the pros of using object storage repositories - all valid and fair.
Btw, the principles of storing the data in Jet-based repositories are the same for all types of data - databases are created per year of backed-up data.
Thanks for sharing your findings and the pros of using object storage repositories - all valid and fair.
Btw, the principles of storing the data in Jet-based repositories are the same for all types of data - databases are created per year of backed-up data.
Who is online
Users browsing this forum: Bing [Bot] and 15 guests