Backup of Database Systems

You can instruct Veeam Agent for Linux to create consistent backups of Veeam Agent computers that run one of the supported database systems using application-aware processing..

Supported Database Systems

• MySQL
• Oracle

Veeam Agent processes the Oracle database system using internal components: oralib and oracleproxy.

• PostgreSQL

Veeam Agent processes the PostgreSQL database system using an internal component: pgsqlagent.

To learn how processing of database systems works, see the Backup of Database Systems section in the Veeam Agent for Linux User Guide.

Backup of Database Archived Logs

If you back up the Oracle or PostgreSQL database system using a backup job managed by Veeam backup server, Veeam Backup & Replication can also back up archived logs. You can use archived logs to restore the database system to the necessary state up to the certain operation. Veeam Backup & Replication backs up archived logs in the similar way as in a backup job for VMs, with the same requirements and limitations.

To learn more about backup of Oracle database archived logs, see Oracle Log Backup.

To learn more about backup of PostgreSQL database archived logs, see PostgreSQL Log Backup.

Considerations and Limitations

Consider the following about application-aware and database processing:

• Nosnap Veeam Agent for Linux and nosnap Veeam Agent for Linux on Power do not support application-aware processing and cannot be used to back up database systems.
• Application-aware processing and database processing options are available if you have selected the Server option at the Job Mode step of the wizard.
• Application-aware processing and database processing options are available if you have selected the Entire computer or Volume level backup option at the Backup Mode step of the wizard.

• If there are multiple database systems on the Veeam Agent computer, consider the following:

• Veeam Agent supports processing of multiple PostgreSQL or Oracle database systems on one Veeam Agent computer.
• Veeam Agent does not support processing of multiple MySQL database systems on one Veeam Agent computer.
• Veeam Agent does not support processing of multiple database systems of different types on one Veeam Agent computer.

• Veeam Agent does not support 32-bit database systems installed on a 64-bit Linux OS.

• Available script settings depend on the options that you have selected at the Job Mode and Backup Mode steps of the wizard. To learn more, see Backup Job and Snapshot Scripts.

Requirements and Limitations of MySQL Processing

• Veeam Agent for Linux supports processing of MySQL database systems version 5.7 – 9.7.

• Configurations with multiple MySQL installations or instances on the same machine are not supported.
• MySQL Cluster versions are not supported.
• MySQL tables that use non-transactional storage engines, such as MyISAM, MEMORY, ARCHIVE or CSV, must be locked while Veeam Agent creates the system snapshot. InnoDB tables are transactional and are captured consistently by the snapshot. Veeam Agent does not lock InnoDB tables by default.

To detect and lock non-InnoDB tables, the MySQL account used by Veeam Agent must have the following privileges:

• SELECT — Required to read table metadata and detect non-InnoDB tables. Grant this privilege on every database that contains such tables. If the account lacks SELECT on a database, Veeam Agent cannot detect or lock its non-InnoDB tables. Processing completes successfully, but these tables may be captured in an inconsistent state.
• LOCK TABLES — Required to lock detected non-InnoDB tables. Grant this privilege on every database that contains such tables. If the account can detect a table but cannot lock it, MySQL database system processing fails. If successful application processing is not required, processing completes with a warning and the tables remain unlocked.
• FLUSH_TABLES or RELOAD — Required to run the FLUSH TABLES ... WITH READ LOCK statement. This privilege must be granted instance-wide, ON *.*. If non-InnoDB tables are detected but the account has neither privilege, locking fails and MySQL database system processing fails. If successful application processing is not required, processing completes with a warning and the tables remain unlocked. FLUSH_TABLES is available in MySQL 8.0.23 and later. For earlier MySQL versions and MariaDB, use RELOAD.

To obtain information about the privileges that are assigned to an account, use MySQL functionality — for example, the SHOW GRANTS statement. To learn more, see MySQL documentation.

Requirements and Limitations for Oracle Processing

• Oracle Database versions 11g – 26ai are supported for all operating systems supported by Veeam Agent for Linux. To learn more, see System Requirements.
• Automatic Storage Management (ASM) is not supported.

• Oracle Real Application Clusters (RAC) are not supported.

• Oracle Grid Infrastructure is not supported.

• Oracle Database Express Edition (XE) is not supported.

• SAP on Oracle is not supported.

• Oracle Database architectures with Data Guard are not supported.

General Requirements and Limitations for PostgreSQL Processing

• Veeam Agent supports processing of PostgreSQL database systems version 14 – 18.

• Veeam Agent supports backup of PostgreSQL clusters managed by Patroni, for backup jobs managed by Veeam Backup & Replication only. To learn more, see Requirements and Limitations for Processing PostgreSQL Clusters below. Veeam Agent does not support other high availability cluster configurations and replication setups of PostgreSQL servers.

• In PostgreSQL 15 and earlier, Veeam Agent does not support configuration sub-files that are specified in the include, include_dir and include_if_exist options in the postgresql.conf file. All PostgreSQL configurations, instance ports in particular, must be specified in the single postgresql.conf file.

Starting from PostgreSQL 16, the pg_hba.conf and pg_ident.conf files can also have configuration sub-files specified in the include, include_dir and include_if_exist options. Veeam Agent does not support these configuration sub-files either. Make sure that in PostgreSQL 16 and later all configurations are specified only in the postgresql.conf, pg_hba.conf and pg_ident.conf files.

Requirements and Limitations for Processing PostgreSQL Clusters

Veeam Agent supports consistent backup of PostgreSQL clusters managed by Patroni, an open-source tool that automates and manages high availability (HA) for PostgreSQL clusters, providing automatic failover, leader election and cluster health monitoring. Consider the following requirements and limitations:

• Patroni cluster processing is supported only for backup jobs managed by Veeam backup server. For backup jobs managed by Veeam Agent, Veeam Agent treats each Patroni cluster node as a standalone PostgreSQL instance and skips Patroni-specific processing.
• Only Linux-based operating systems are supported.
• PostgreSQL database system versions 14 – 18 are supported. PostgreSQL instances running earlier versions are skipped from processing.
• Patroni versions starting from 4.0.6 are supported.
• The patronictl utility must be installed on the database system.
• Veeam Agent always detects Patroni cluster awareness automatically; this behavior cannot be disabled.
• Veeam Agent does not support using a network share as a temporary location for log shipping — doing so causes WAL files to be backed up twice.
• If a cluster node becomes unreachable, Veeam Agent cannot collect WAL files from that node.
• If the PostgreSQL instance terminates unexpectedly (which also stops Patroni) and PostgreSQL does not create a .partial WAL file, a gap occurs in the backed-up log chain for that period.

How Patroni Cluster Processing Works

Veeam Agent uses role-aware processing to back up PostgreSQL databases in Patroni clusters. During backup, Veeam Agent detects whether each cluster node is the primary or a replica and applies the PostgreSQL preparation strategy appropriate for that role. This allows Veeam Agent to process both primary and replica nodes. For log backup, Veeam Agent uses the same role-aware logic to capture WAL files from the primary node and support point-in-time recovery.

Role detection is required because WAL files are generated only on the primary node, and the pg_start_backup()function cannot be called on replica nodes. Since node roles can change, for example during switchover, Veeam Agent automatically rescans the cluster topology while processing physical and virtual machines for which application-aware processing is enabled, and adjusts the strategy if roles change.

To process a Patroni cluster, Veeam Agent performs the following operations:

1. Detects Patroni processes in the operating system and determines the Patroni configuration.
2. Uses patronictl to retrieve general cluster information and determine the role of each cluster node: primary or replica.
3. Verifies that the primary node is included in the backup job. This is required for WAL shipping.
4. On replica nodes, triggers a checkpoint to determine the redo log sequence number, or LSN.
5. On the primary node, calls the pg_start_backup() function to determine the LSN range for the backup.

Related Topics

• MySQL Processing Settings
• Oracle Processing Settings
• PostgreSQL Processing Settings