pSQL Size?

[DaStivi]

How big is the database/cache sizes on your pSQL Servers ?

After Migration from V7 to V8 my PostgreSQL is growing and growing... All repo upgrade and indexing jobs are finished ! But database is still growing and making constant write IOs!

I'm up to 500GB now after just 4 days now after Migration on the disk where I put the PostgreSQL on!

Also getting errors about psql issues in jobs (points to low iops of disks.. but having ssds and obviously the DB is constantly writing huge amounts of small IOs!)

# 07670173

[Polina]

Hi Stephan,

Tehnically, constant writes and db growth are expected, and we recommed disks with 7500 IOPS for the database. v8 saves more metadata, including the details on newly created restore points.
Any chance you estimated the total size of your v7 config and repository cache databases? How big was it compared to the current 500GB?

[DaStivi]

"configDB" where around 180GB, but probably there where whitespace in it, as i just before the upgrade i lowered the "keep session" from all to only 53weeks, as this also blew up my veeamONE and VSPC Databases!
overall the S3 Metadata JetDBs where somewhere around 150GB

so everything would sum up to around 300 to 350GB max?!

after the upgrade i also started some move-vboentitiy jobs... it looks like these jobs also caused some of the write IOs, because i stopped these jobs and aborted them now. and write at this time the write IOs got down...
so right now, the move jet2s3 options is even more an issue then with v7 ... the moves were also a lot slower than before!

the overall Job Durations are around double the times now then compared to v7 job durations!

[Polina]

350 GB plus the space for indexing of all restore points, which you can estimate as follows:
Size = (Number of objects in each RP) x (Number of RPs) x 400 bytes
Example: 10,000 users (mailbox + OneDrive). Each RP gives 10,000 records in the corresponding tables = 30,000 records per RP. Each record is about 400 bytes. In total, a RP consumes 11.4 MiB.

Are you running job on individual proxies or on proxy pools?
Are you on the latest v8.1 patch?

[DaStivi]

how to find out the number of objects and restore points?

migrated alls S3 repos to proxy pools
v8.1.1.159, yes..

[DaStivi]

ok i'll see following information in VeeamONE that might be a start:

Users: 24400
Groups: 4800
Sites: 27000
teams 7800
Sum: 64000 (objects?)

[Polina]

Users consist of mailboxes, archive mailboxes, OneDrives and personal sites - each of those counts as an object.
With groups it depends on what exactly you're protecting within them. It could be 4.8K group mailboxes, or 4.8K groups mailboxes + 4.8K group sites; or there can be a number of individual users you protect with those groupping.
I'd say, you have 64K object protected as a minimum, potentially more.
If each of those has a daily backup, this will give you an idea for your calculations...

[DaStivi]

I'll try to get a report from Veeam One, but i am unable to-do so... I'll see a restore points counts in Veeam one client, on per repository view, per object...
so information is somewhere inside Veeam one

I'm not able to gather a report from the one web client that lists me just all restore points

i can't export anything from one client where i just could sum up everything in excel...

running jobs every 2hours, for the bigger customers every 4hours!

in one customers, i see per user 6700 restore points max but not for alles users and there are 7800 in this repo...

if I'll count about 2.5 objects per user (mailbox+onedrive and for some personal site) I'll end on about 100k objects.
if i reverse math the psql database size of currently 530GB, divided by 400bytes, I'll end up on 1.4billions divided by the assumed 100k users, i end on an average of 14000 restore points

another math:
normally retention period is 3years, doing like a backup every 2 to 4 hours, would end up in about 8 restore points per day, equals to around 8700 restore points in 3 years

so Maybe the size is what it is apparently..

[DaStivi]

350 GB plus the space for indexing of all restore points

indexing is additionally to the amount the s3 cache dbs had?
and even after indexing jobs in vb365 console are finsihed the database still has writes on it?

any (size) difference on incremental or full-sync for these "index/more-metadata information" operations ?

[Polina]

At least, you now have the idea how and why the database is growing, and hopefully it helps to plan for the future, right?

[DaStivi]

btw: this is how the growth curve looks like:

[Polina]

>> indexing is additionally to the amount the s3 cache dbs had?
Correct. During the upgrade we need to transfer existing caches to the PGSQL, and additionally we do indexing to collect to the database the information on all existing restore points and objects withing them.

>> and even after indexing jobs in vb365 console are finsihed the database still has writes on it?
Not sure what you mean by this. All the new metadata produced by backup tasks after the upgrade is written to the database. Proxies are constantly working with it.

>> any (size) difference on incremental or full-sync for these "index/more-metadata information" operations ?
Job type does not matter. Each time a new restore point is created, we save its information to the database.

[DaStivi]

>> and even after indexing jobs in vb365 console are finished the database still has writes on it?
Not sure what you mean by this. All the new metadata produced by backup tasks after the upgrade is written to the database. Proxies are constantly working with it.

i meant that even after all the indexing jobs where finished in the vb console, the DB grow a lot!

if you check my screenshot the jobs where finished between 13th and 14th ... but after that it started to grow again! and even more...
considering there where a lot of full-sync running after the upgrade it still strange that there is almost double the amount of DB size needed, because indexing had like all the restore points of the last 3 years... and then only a few days of backup runs caused a lot more db growth?

as said i also see some "connection" to growth while running the move-vboentitiy cmdlet.. i understand that when moving restorepoints&objects from Jet to s3 it causes index data... but it was just a relatively "small customer" with just a few hundred users, that also doesn't stand in relationship to the growth?