Veeam Backup & Replication 12
Veeam Explorers User Guide
Related documents
Search

Considerations and Limitations

This section lists considerations and known limitations of Veeam Explorer for PostgreSQL.

General

  • High availability cluster configurations and replication setups of PostgreSQL servers are not supported.
  • Restore, publishing, instant recovery, and export operations of PostgreSQL instances or databases to a point-in-time state require backups of PostgreSQL write ahead log (WAL) files. To allow Veeam Backup & Replication to create PostgreSQL WAL file backups, PostgreSQL instances must have the replica wal_level setting or higher. The minimal wal_level setting does not write information about database transactions and it allows you to create a crash-consistent backup only.
  • Restore, publishing, instant recovery, and export operations of PostgreSQL data from replicas can only recover your data to the latest state of the selected restore point. Replication jobs do not copy PostgreSQL write ahead log (WAL) files so data recovery to a point-in-time state is not supported.
  • Starting from Veeam Backup & Replication 12.1, Veeam Explorer for PostgreSQL supports data recovery from CDP replicas. Consider the following limitations:
  • Restore, publishing, instant recovery, and export operations of PostgreSQL data from CDP replicas can only recover your data to the latest state of the selected long-term restore point. CDP policies do not copy PostgreSQL write ahead log (WAL) files so data recovery to a point-in-time state is not supported.
  • When you recover your data from CDP replicas, you can only use long-term (both application-consistent and crash-consistent) restore points. Short-term restore points are not supported.
  • You can recover your data from a CDP replica if its CDP policy is currently running. During recovery, the CDP policy does not create new long-term restore points and does not delete existing ones. Short-term restore points are still created.
  • You cannot restore application items from a CDP replica in parallel with guest OS file restore, SureReplica, and failover.
  • Mount of Btrfs disks will fail if you perform instant recovery, data restore or data publish operations to the original server. The issue occurs due to restriction for mounting 2 Btrfs disks with identical IDs to the same machine.
  • Starting from Veeam Backup & Replication 12.1, Veeam Explorer for PostgreSQL supports SSH fingerprint validation of target Linux machines with PostgreSQL. For more information on how to configure this feature, see the Linux Hosts Authentication section of the Veeam Backup & Replication User Guide.

If you have selected the more secure, manual validation in the Veeam Backup & Replication console, consider the following:

  • If the target server is unknown or its fingerprint cannot be recognized, you will be able to proceed with the recovery operation after you manually validate the fingerprint in the Veeam Backup & Replication console.
  • If you have already validated the fingerprint of a target server, but you use an alternative network identifier (IPv4, IPv6, FQDN, or hostname) for the same server in a new Veeam Explorer for PostgreSQL session, you must validate the fingerprint again to proceed with the recovery operation.
  • Veeam Explorer for PostgreSQL does not support configuration sub-files (include files such as include_if_exist, include_dir and so on). All PostgreSQL configurations, instance ports in particular, must be specified in a single postgresql.conf file.

Restore

  • Veeam Explorer for PostgreSQL does not support restore over VIX API or vSphere Automation API.
  • Restore of databases that reside in an encrypted file system on the source machine is not supported. In particular, encrypted LVM volumes are not supported.
  • With Veeam Explorer for PostgreSQL, you can restore entire PostgreSQL instances; restore of individual databases is not supported.
  • PostgreSQL on the target machine must be of the same major version as PostgreSQL on the backup. For example, you can restore a PostgreSQL instance based on PostgreSQL 14.1 to a machine with PostgreSQL 14.3.
  • With Veeam Explorer for PostgreSQL, you can only restore PostgreSQL instances from backups of powered on machines.
  • With Veeam Explorer for PostgreSQL, you can only restore PostgreSQL instances that were running at the time of backup.

Note that if you use a Veeam Agent backup job or policy to back up a machine with a shut-down PostgreSQL instance, you can restore the shut-down PostgreSQL instance using Veeam Agent for Linux functionality: volume-level restore, file-level restore or bare metal restore. For more information, see the Performing Restore section of the Veeam Agent for Linux Guide.

  • You can restore a PostgreSQL instance over SSH only, restore using Linux Management Agent is not supported.
  • If you specify another data directory for the restored PostgreSQL instance, services will not be created automatically (including systemd).
  • Before you restore a PostgreSQL instance to another server, make sure PostgreSQL is installed on the target machine.
  • [For Debian] When you restore a PostgreSQL instance to a new data directory, Veeam Explorer for PostgreSQL saves PostgreSQL configuration files to the specified data directory (not to the /etc/postgresql directory). In this case, you will not be able to discover the recovered PostgreSQL instance with the pg_lsclusters utility.

Publish

  • With Veeam Explorer for PostgreSQL, you can publish entire PostgreSQL instances; publishing individual databases is not supported.
  • Before you publish a PostgreSQL instance to another server, make sure PostgreSQL is installed on the target machine.
  • Make sure that the volume with the write cache has enough free disk space to store the changes of the published database. The write cache is stored in the /var/tmp folder on the target server.

Instant Recovery

  • If you plan to perform scheduled or manual switchover, make sure that the volume with the write cache has enough free disk space to store the changes of the published database. The write cache is stored in the /var/tmp folder on the target server.
  • Before you perform instant recovery of a PostgreSQL instance to another server, make sure PostgreSQL is installed on the target machine.
  • With Veeam Explorer for PostgreSQL, you can perform instant recovery of entire PostgreSQL instances; instant recovery of individual databases is not supported.

Export

  • Exporting multiple databases one by one may cause performance issues — do so only if you need to restore each database to a different point-in-time state. To export up to a 1000 databases in parallel, start the export sessions from a published PostgreSQL instance (the only option if you use PowerShell), a backed-up PostgreSQL instance, or from the backed-up PostgreSQL server.
  • You cannot export databases whose pg_database system catalog has the datallowconn parameter set to false. This setting prevents all connections to the database and causes export operations to fail. For example, this is the case for the template0 database, that is used to create new databases — as a template database, it must remain unchanged.
  • PostgreSQL on the staging server must be of the same major version as PostgreSQL on the backup.
  • You can use pg_restore to reconstruct a database from a DUMP file exported with Veeam Explorer for PostgreSQL. If a new database is created in the process and the database in the DUMP file has tablespaces, you must manually create tablespaces with the same names as the ones in the DUMP file. Note that the --no-tablespace argument of the pg_restore utility, which places the reconstructed database in the default tablespace, is not supported for DUMP files exported with Veeam Explorer for PostgreSQL. For more information, see Restoring Exported Database.
View all results across Veeam
Back to document search