EntraID backup sizing

[Henrik.Grevelund]

Hi,

I can't seem to find anything stating how to size the postgresql database and the Cache repository.

Anyone having some numbers ?

[Mildur]

Hi Henrik

We don't have a calculator yet for this workload.

Cache repository sizing is similar as for NAS backup. The size of your audit and sign-in log matters.
For EntraID objects, I have a number from our testing last year:
- 8000 User organization, 21 restore points = 4GB database (7 year estimation = 400GB)

May I ask if you have specific numbers? Are you planing to provide EntraID as a backup service to your customer?

Best,
Fabian

[Henrik.Grevelund]

Hi Fabian,

Thanks for the numbers. I was a bit suprised that the entraID job is a full every time.
Right now i am only backing up a very small domain, 17 users, 900 objects in total. So that wasn't really big enough to calculate size from.

We are looking into providing it as a service, but there are a few things preventing it.
First of, the licensing, one of our customers has around 2000 VM's and 16.000 users. If we where to backup their EntraID with Veeam, it would more than double their bill. I do know that R&D isn't setting prices, but this fact will prevent installations.
Productwise there are also a couple of things that i would like to change.
It requires a postgresql to work, and if its placed on the VBR server, there are no good way backup this database. It contains backup data, and we need to have 2 copies. So the database has to placed in a Linux machine to be able to do application aware backup.
It requires a general purpose proxy, and it has to be in the VBR server, i don't like to have this load running on the VBR server, it should be possible to select another.
We can't setup a shared environment for all our customers since they will be saved in the same database.

The documentation states that the VBR server has to be able to access port 443 on:
Microsoft Entra ID Services (service tag: AzureActiveDirectory)
Azure Resource Manager (service tag: AzureResourceManager)

If the firewall doesn't understand this, then just download a 3,7 MB file with ip's
That makes it pretty difficult to use in a setup not placed in Azure, or if you don't have a any rule towards the internet.
So the proxy fetching the data from MS should be placed in a DMZ zone.

Sorry but have to find the Cant's to build a good sulotion.

Got this : You must include Veeam support case ID, or your post will be removed (learn more).
So adding the closed case about problems creating the tenant : 07584482

[Mildur]

Hi Henrik

First of, the licensing, one of our customers has around 2000 VM's and 16.000 users. If we where to backup their EntraID with Veeam, it would more than double their bill. I do know that R&D isn't setting prices, but this fact will prevent installations.

Licensing consumption is 10 Rental points = 10 EntraID Users. The cost should be similar as for customers with VUL. If you think its too expensive, I would suggest to talk to your regional sales representative from Veeam.

It requires a postgresql to work, and if its placed on the VBR server, there are no good way backup this database. It contains backup data, and we need to have 2 copies. So the database has to placed in a Linux machine to be able to do application aware backup.

pg_dump is a supported way for PostgreSQL on Windows. Application Aware processing for PostgreSQL on Windows is on our Roadmap (no ETA).

It requires a general purpose proxy, and it has to be in the VBR server, i don't like to have this load running on the VBR server, it should be possible to select another.

V1 of EntraID backup only supports one proxy. We may lift this limitation with upcoming versions.

We can't setup a shared environment for all our customers since they will be saved in the same database.

That's not true. Yes, we use the same PostgreSQL instance, but each Tenant has a different database. You can verify that with PGAdmin. With SQL queries you could list the size of each database for billing your customers.




Best,
Fabian

[Henrik.Grevelund]

Hi Fabian,

>pg_dump is a supported way for PostgreSQL on Windows. Application Aware processing for PostgreSQL on Windows is on our Roadmap (no ETA).
This would require the usage of an external scheduler, and montoring of this. Also when it becomes supported for windows, would you configure application aware backup of the VBR server ?

>That's not true. Yes, we use the same PostgreSQL instance, but each Tenant has a different database. You can verify that with PGAdmin. With SQL queries you could list the size of each database for billing your customers.
That was me not saying it the right way.
I would like that each tenant was writing their backup data to a seperate postgresql instance placed on seperate linux machines. That makes sure that backup data from different customers doesn't mix and can have different retentions.

[Mildur]

Hi Henrik

Yes, If available I would consider to use application aware processing.

I would like that each tenant was writing their backup data to a seperate postgresql instance placed on seperate linux machines. That makes sure that backup data from different customers doesn't mix and can have different retentions.

But the data is already separated today, right? Each Entra ID tenant has its own database and database files. Do you see any mix-up of backup data in your lab? If one of your clients cancels their contract, you can simply remove the backups from the configuration and delete the corresponding database from the PostgreSQL instance.

Additionally, retention is configured at the backup job level, not at the PostgreSQL instance level, which allows for different retention settings for each Entra ID tenant.

Best,
Fabian

[Henrik.Grevelund]

Hi Fabian,

>retention is configured at the backup job level, not at the PostgreSQL instance level, which allows for different retention settings for each Entra ID tenant.
Not complety true. Since Veeam backup for EntraID only is able to backup to 1 target, we have to use backup of that postgresql to get the second copy (32110 rule)
So the backup of the postgresql is for all databases, so the secondary copy of all customers will have the same retention.