Veeam Backup & Replication Database
Veeam Backup & Replication stores all information about backup infrastructure, jobs settings, job history, sessions, the tape catalogue and other configuration data in a Database server often referred to as the “Configuration Database”
When planning the Veeam Backup & Replication deployment, you must choose the placement of the configuration database. It may be either a local or a remote Database Server.
Please see the following recommendations to ensure your Veeam setup will scale to the size of your infrastructure.
Database Engine
Starting from Veeam Backup & Replication v12, you can also use PostgreSQL instead of Microsoft SQL Server. In fact the default installation will now install PostgreSQL. This decision was made because Microsoft SQL Express edition came with a lot of limitation in terms of scaling (eg max 10 GB Database size). PostgreSQL does not have these limitations while it does not require additional licensing either. Additionally, the default installation will automatically tune the database for Veeam Backup & Replication.
However, since v12 is the first version to support PostgreSQL, it is still recommended to use Microsoft SQL Server when you backup more than 5000 VMs.
Also, if you have implemented High Availability as discussed in Database placement section and you have no licensing concerns, there is no hard requirement to migrate to PostgreSQL.
If you are in a complex environment with multiple Veeam Backup & Replication servers and Veeam Enterprise Manager, consider that all of them must use the same Database Engine.
Database placement
There may still be scenarios where a remote DB Server is the better choice then a local install:
- High Availability - Microsoft SQL Clustering and AlwaysOn Availability Group on external SQL Servers can be used for configuration database high availability. Please refer to the following KB article for the configuration details
- Licensing - Some enterprises have dedicated virtual clusters for SQL Server due to licensing constraints. In such cases, you may place the Veeam configuration database on existing instances to lower the overall TCO. Alternatively, if you are well below 5000 VMs, consider using PostgreSQL.
- DB Load Management - By separating the database you can avoid race conditions between the Veeam Backup & Replication server software and the database engine. It will be easier to pinpoint performance issues.
Migrating / Using PostgreSQL
Migrating to PostgreSQL is not a straight forward process and requires careful planning. All backup servers must be based on the same database engine as Veeam Backup Enterprise Manager (PostgreSQL or Microsoft SQL Server).
- Upgrade Veeam Enterprise Manager and then upgrade all Veeam Backup & Replication servers to v12 including all the latest patches.
- Migrate the Veeam Enterprise Manager to Postgres
- Migrate the Veeam Backup & Replication server to Postgres
It is also important to understand that if you are installing a new Veeam Backup & Replication Server in an existing environment and you are not planning to migrate fully to PostgreSQL, you must explicitly install/use a Microsoft SQL Server.
Finally, if you are planning on using PostgreSQL, it is recommended to always download the latest supported PostgreSQL installer instead of the default one shipped with the Veeam Backup & Replication installer.
If you do so, do not forget to tune the database by using the corresponding PowerShell utility.
Sizing
It is recommended that you can use the same sizing guidelines for both Microsoft SQL and PostgreSQL.
Veeam Backup & Replication may consume high amounts of CPU and RAM while processing backup or replication jobs. To achieve better performance and load balancing it is necessary to provide sufficient RAM and CPU resources to Veeam components.
Remember to add additional resources, if the backup server is responsible for multiple roles, such as repository server or backup proxy.
Please follow these guidelines:
| Number of concurrently running jobs | CPU | RAM |
|---|---|---|
| Up to 25 | 2 | 4GB |
| Up to 50 | 4 | 8GB |
| Up to 100 | 8 | 16GB |
Note: Concurrently running jobs include any job type with a continuous schedule such as Backup Copy Jobs.
When running more than 100 jobs concurrently increase the amount of resources by 2 CPU cores and 4GB of RAM for every 25 concurrently running jobs.
File-to-Tape
When using file-to-tape jobs, a dedicated NVME drive is recommended for the configuration database that is not used for anything else.
The RAM sizes required can be found here: Link
Do not use SQL Express single jobs with over 1,000,000 files in 1000 folders as it will have a significant performance penalty.
General recommendations
It is recommended to place the configuration database on a fast, resilient storage subsystem, preferred flash, unless performing File-to-Tape (Use NVME, see above).
High-performance storage for backing the configuration database will result in overall increased processing performance.
Jobs with a lot of metadata such as very large SharePoint farms with thousands of sites, SQL Server instances with many databases or Files-to-Tape jobs may increase the I/O requirements for the configuration database.
Disk space usage
500 VMs use around 10GB disk space for the configuration database (Approx 20.48MB per VM)
File-to-tape requires 850MB of additional capacity per 1,000,000 files. Note that all versions from all backups need to be counted.
Microsoft SQL DB Staging Server
It is possible to leverage a remote SQL Server as staging server during restores in Veeam Explorer products.
With SQL Express as the configuration database it is possible to use it as the staging server if the databases are under 10GB. When using PostgreSQL as the configuration database or if the database is over 10GB you will need to either use the target Microsoft SQL server or another remote Microsoft SQL server during restores in the Veeam Explorer products.
If you are using the explorers extensively, you might want to consider a full Microsoft SQL Server on the backup server for lowest latency and highest performance.