postgres user password (migrating SQL to postgres)

[BostjanUNIJA]

Hi.
VBR environment popped up a message that database size is reaching the limit (configuration backup for VBR is stored in local/builtin SQL instance).

Now we would like to migrate current configuration backup from SQL to PostgreSQL.
If we check with Veeam.Backup.DBConfig we see that Microsoft Entra ID backup repository is already using local postgres instance (port 542 & username: postgres).

Questions:

1. What's the default password for postgres user for Microsoft Entra ID?
2. Can we migrate VBR configuration to this same local postgresql instance that is already used for Microsoft Entra ID? But how do we define credentials for postgres username in the phase of migrating configuration backup from SQL to Postgersql?
3. We see that PostGreSQL version installed is 15.10-1; that was probably installed durring upgrade from 12.1 to 12.3. Should we upgrade Postgresql to 15.13-1 before doing the migration from SQL to postgresql?


Thank you.
With best regards

[david.domask]

Hi BostjanUNIJA,

Entra ID repositories are postgreSQL databases, and it's normal for them to cohabitate the same postgres instance as the Veeam Configuration database.

Should work to just do a Migration as outlined in the User Guide; when configuring the instance, Veeam will ensure the account used for installation and NT Authority/SYSTEM can access the instance, but if required you can add an additional user for the migration.

Upgrading is fine, before or after.

[BostjanUNIJA]

Thank you for reply.
Another question.
Did Veeam wizard (before version 12, where default Veeam configuration database was on SQL and not on postregresql yet) create any SQL tasks automatically (for example: shrinking, optimizing database? truncating logs?)
I'm thinking about "buying some time" with connecting with SQL MGMT Studio and selecting Veeam database and shrink DB/files?

[david.domask]

You're very welcome.

There is a database maintenance task that runs weekly if I remember correctly and focuses on index fragmentation and a few other housekeeping tasks, but it does not shrink the database.

I'm a bit doubtful that shrinking will help too much here if the database is truly getting close to the 10 GiB limit -- shrinking relcaims no longer used but allocated space to reclaim space on the filesystem. Try reducing the session history retention, that should get you some more meaningful space back in the database.

[BostjanUNIJA]

David. Thank you very much. We will proceed with migrating from local sql to local postgresql