What this migration actually does

Veeam used SQL Server as the only configuration database option for years. In v12 they added PostgreSQL support. In v13, PostgreSQL is the default for all new installations, and it is the only supported option for the Linux Software Appliance. If you have an existing VBR server running on SQL Server and want to move to the Linux Appliance - or simply want to drop the SQL Server dependency - this is the process.

It is not a live database conversion. Veeam does it through a backup and restore cycle: you create a configuration backup from your existing instance, then restore it to a PostgreSQL instance using the Migrate mode in the Configuration Restore wizard. The VBR server stays on the same machine. All infrastructure, jobs, credentials, schedules, and settings carry over. The only thing that changes is what database engine VBR connects to.

When you need to do it and when you can skip it

You have to do it if you are moving to the Linux Software Appliance. The appliance supports PostgreSQL only. There is no path from a Windows VBR installation to the Linux Appliance without migrating the configuration database first.

You should do it if you are running a dedicated SQL Server instance that exists only to serve VBR. That is licensing overhead and a patching surface that disappears once you move to PostgreSQL.

You can skip it for now if you are on the bundled SQL Express and staying on Windows. SQL Express has a 10 GB database size cap, which covers most environments. If you are nowhere near that limit and have no plans to move to the Linux Appliance, the migration is optional today. That said, Veeam has stated SQL Server support will eventually be discontinued post-v13, so plan to make the move at some point regardless.

Note: V13 on Windows continues to support both Microsoft SQL Server and PostgreSQL. The Linux Appliance is PostgreSQL only.

Prerequisites

You need a running PostgreSQL instance that VBR can connect to. For a Windows VBR server, the v13 installer offers to set up a local PostgreSQL instance during installation. If you installed v13 from scratch on Windows, you likely already have one. If not, you can install PostgreSQL manually - Veeam includes a PostgreSQL installer in the ISO atRedistr\x64\PostgreSQL\. VBR v13 supports PostgreSQL 14 and 15.

The PostgreSQL account you specify in the restore wizard needs permission to create databases on that instance. The defaultpostgressuperaccount works.

The template1 system database in PostgreSQL must use UTF-8 encoding. This is the default for any PostgreSQL install, but if you are pointing at a pre-existing instance, confirm it before proceeding.

VBR must currently be connected to its SQL Server database with no errors. Open the console and confirm the Jobs view shows your existing configuration cleanly before starting.

Step 1 - Stop and disable all jobs

In the VBR console, go to the Jobs view. For every job that is running, right-click and stop it. For every scheduled job, right-click and disable it. Do this for backup jobs, backup copy jobs, replication jobs, and agent management jobs. Check the Restore view and cancel any active restore sessions. If you use tape, stop anything active in Home > Tape Jobs as well.

Once everything is idle and disabled, wait a few minutes before proceeding. Some jobs run brief cleanup tasks after the main session writes, and those need time to finish.

Step 2 - Create a configuration database backup

From the main menu in the VBR console (hamburger icon, top left), select Configuration Backup. Confirm the "Enable configuration backup to the following repository" checkbox is selected and a valid repository is chosen. Then click Backup Now to create an immediate backup. You want a fresh backup that captures the current state.

Watch the status bar at the bottom. When the backup completes, the Configuration Backup window shows the timestamp of the last successful backup. Note the repository it wrote to - you will point the restore wizard at that location next.

Step 3 - Restore in Migrate mode to PostgreSQL

From the main menu, select Configuration Backup, then click Restore. This opens the Configuration Restore wizard.

Select Migrate, not Restore

The wizard shows two options: Restore and Migrate. Select Migrate. The Restore option puts you back on the same engine you are currently running. Migrate is what lets you change engines. If you pick Restore by mistake, cancel out and restart the wizard.

Point to the backup file you just created

Browse to the repository where the configuration backup was written and select the most recent backup. If it was encrypted, you will be prompted for the password here.

Select PostgreSQL and enter the instance details

On the Target Database tab, change the database engine from Microsoft SQL Server to PostgreSQL. Enter the hostname or IP of your PostgreSQL server. If PostgreSQL is running locally on the VBR server, enterlocalhost. Enter the port (default is 5432). Enter a name for the new database -VeeamBackupis typical. Specify the PostgreSQL account credentials. Veeam will tell you if the database does not yet exist and will create it during the process - that is expected.

Start the migration and wait

Review the summary and click Restore. Veeam stops its services, creates the PostgreSQL database, migrates all configuration data from the backup file into it, updates its own service configuration to point at the new engine, and restarts. This takes several minutes. When it completes, the console reconnects automatically. You are now running on PostgreSQL.

Step 4 - Reactivate Enterprise Manager keyset

This step only applies if you use the Data Encryption feature and your VBR server is connected to Veeam Backup Enterprise Manager. If neither applies, skip to Step 5.

After the migration, Enterprise Manager still sees your VBR server but the encryption key association is broken because the configuration database moved. To fix it: in the EM web console, open Configuration, go to Settings, open the Key Management tab, find your keyset in the Managed Keys section, and click Activate.

Skip this and you will get key-related errors the next time an encrypted restore runs through Enterprise Manager.

Step 5 - Finish configuration and verify

Work through these checks before re-enabling your jobs.

First, re-enable the configuration backup. Go to Main Menu > Configuration Backup, confirm the scheduled backup is enabled with a valid repository, and click Backup Now to verify it runs successfully against the new PostgreSQL database.

Second, check the Backup Infrastructure view. All managed servers, repositories, and proxies should show as healthy. If any component shows a warning, right-click it and rescan. The migration regenerates some internal certificates, and a rescan updates the component's stored certificate fingerprint.

Third, if you have local repositories on the VBR server itself and they show as empty after migration, add them back using the same path. Veeam will rescan and find the existing backup files. This is documented behavior after a configuration database migration, not a sign that data was lost.

Once the infrastructure view is clean, re-enable your jobs. Run one manually to confirm full end-to-end operation before handing it back to the schedule.

PostgreSQL tuning after migration

If you installed PostgreSQL manually rather than through the Veeam installer, the default PostgreSQL configuration is not tuned for VBR workloads. Veeam provides a PowerShell cmdlet that calculates and outputs recommended PostgreSQL configuration values for your hardware:Set-VBRPSQLDatabaseServerLimits -DumpToFile C:\temp\pg-recommended.txt. Run that and review the output. Apply the values to your PostgreSQL instance'spostgresql.auto.conffile using psql. If VBR set up PostgreSQL during installation, the tuning is handled automatically and you do not need to do this manually.

Migrating Enterprise Manager separately

Starting in v13, VBR and Enterprise Manager no longer need to run the same database engine. If VBR migrates to PostgreSQL and EM stays on SQL Server, EM continues collecting data from that VBR server without interruption. This was a hard requirement in v12 but the limitation was removed in v13.

If you want to migrate EM's database as well, that is a separate process documented in the Veeam Backup Enterprise Manager Guide. One important sequencing rule: if you need to both upgrade EM to a newer version and migrate its database engine, upgrade first and then migrate the engine. Both operations cannot be performed simultaneously.

After migrating EM's database, you must reconnect EM using the Configuration Database Connection Settings utility, and update the credentials for each VBR server listed in EM's Configuration section. EM does not migrate historical collection data - it re-collects fresh data from VBR servers on the first run after migration.

Gotchas that will get you

Originally published at anystackarchitect.com