Volume size

[matteu]

Hello,

I see on the best practice, 1 volume should be dedicated to Exchange data, 1 for onedrive, ...

I would like to know if it's an issue if the volume is "big" like 50To ?

If I want to split it, that means I have to do several job and each job save user from A to F first letter and then G to O and P to Z and have 3 volume right ?

[Mildur]

Hello Matteu

May I ask, Is this deployment for a service provider deployment or a single organization?

We strongly recommend using object storage instead of jet databases for service providers. Repositry optimizations for service providers in our next versions will be mainly focused on object storage based repositories.

And if you expect such a large amount of data (50TB), you should go with object storage based repositories. Much better compression (50% with object storage instead of 10% with jet database based repositories). Saving a lot money on disk and memory resources. Jet databases require a lot of Memory to keep them running.

To come back to your question, I wouldn't create a single 50 TB volume. How many repositories are you expecting? Probably you need them to distribute your repositories over multiple proxy server to achieve the expected performance.

Best,
Fabian

[matteu]

Hello,

Thanks for your answer !

It's for a single organization.

I understand object storage is recommended but sometimes customer doesn't have it unfortunately.

What is a "good maximum" size for you to manage backup on "normal" storage ?

I totally agree about don't create 50TB volume but I would like to know, how should I "manage it"'.
It will be 1 VM with probably several proxy yes.

My question is really about how to manage target repository. If I was service provider , I can use 1 repo = 1 customer.
Here, for the same customer, how can I split efficiently data over several repository.

[Mildur]

Hi Matteu

It will be 1 VM with probably several proxy yes.

Each proxy must be it's own machine.

For a single organization, first count the source objects and users which you need to protect. We have documented maximums per proxy server and jobs.
Then decide how many repositories and proxies you need for that.
Object based sizing: https://bp.veeam.com/vb365/guide/design ... sed-sizing
Max Config per proxy: https://bp.veeam.com/vb365/guide/design/maxconfig.html

When you know how many repositories and jet databases (one per year for each repository) will be created, you can define how many proxies you need to deploy.
To lower the chance of entire data loss if a volume has failed, create multiple volumes on the proxy servers. Better to use smaller volumes and put 1-2 repositories on each.
That will take away the risk with a 50TB volume failure.

About how many sites and users are we talking about?
I'm asking because if it has a reasonable size, you may be able to involve our system engineers or architects for the right design.

Best,
Fabian

[matteu]

Hello,

Sorry for my late answer.

Yes, the idea is 1 VBM365 VM + several proxies based on the max limit.

I agree to make several volume. My question is really about it. What is a "good" maximum size for 1 volume and how would you manage job between different repository. Do you use ID for it ?

It's not a "real" use case today but I have some customer with 2/3 sites and arround 2000 users and I would like to know how to be prepared

[Mike Resseler]

Hi Matteu,

Ideally, your repositories (if they are jet DB) will not be above 58 TB (in which we automatically make a new one). From a volume point of view, remember that there is a limit in VSS also.

With 2000 users, depending a bit on size, I would look into object storage repository though.

[matteu]

Just to understand better :

Veeam solution can handlet object or classic storage but for M365 Object will always be the prefered one because of 50% space improvment.
If my customer doesn't have any on premise object storage, that means he need to buy Azure / S3 / ... storage on storage provider to store these data.

[Mike Resseler]

Yes and no...

Because of the way application backup works, in this case object storage is the preference, especially when the organization grows or already has a decent size. That said, the classic jet DB repository is still an option depending a bit on the size. You spoke about 2000 users, did you check in the customers admin center (or asked them) what the current total size is of their SP/ OneDrive / Exchange environment? (Preferred separately). It might be perfect possible that Jet DB repositories are good enough depending on that size (and churn). But I have quite some customers around that amount of users that are very heavy M365 users, which lots of churn and massive amount of data where it might be more interesting to move to object storage.

And, if they don't have object storage on-premises, some of those have bought software that can leverage almost any storage and make it object storage. (I won't be naming names here to stay neutral but pretty sure you know the software solutions I am talking about )

[matteu]

Thanks for your answer.
Unfortunately no I don t know it s possible to use classic storage and use it as storage object.
Is it possible for you to give me some solutions name please ?

[Mike Resseler]

Ceph, openio, minio but I do not take preference at any of them (I honestly also don't know what the best solution for what scenario would be, there are other people in Veeam who are much more studied on that topic )

[matteu]

Thanks for your answer

[StanoSedliak]

When you know how many repositories and jet databases (one per year for each repository) will be created, you can define how many proxies you need to deploy.

Best,
Fabian

Hi, do does it mean, when we have several customer located on 1x o365 repository with jet DB for example:
10 customer and each of the customer has 10 folders/years inside, we are already using 10x10=100 Jet DBs and what I saw on bp maximum is 750 but recommended 250?

After we would reach 750 folders in the future it would be not possible to save another customer on this repository?
or if a new year will come and we would already had 745 folders and after 2024 it would be another 50 what would happened?

Thank you!

[Kiril2]

The 250 databases is not a hard limit but everything that is going over will cause problems in the long run. Just follow best practices

[matteu]

Just something I need to be sure to understand :
I will have a physical server and plan to use it as "all in one" and DAS storage attached (arround 50To).

Is it a problem to use 50To for a D: volume and use it with 3 repositories ? c:\Exchange + D:\OneDrive + D:\Sharepoint_Teams

If I divide it as D: + E: + F: the issue is I'm sure I will waste space.... because hard to be sure about what application will grow more than others (1 volume for exchange + 1 onedrive + 1 sharepoint/teams)