pg_probackup3 allows you to take full or incremental backups and provides all necessary features for backup management:
FULL backups. They contain all the data files required to restore the database cluster.
Incremental backups. They operate at the page level, only storing the data that has changed since the previous backup. It allows you to save disk space and speed up the backup process as compared to taking full backups. It is also faster to restore the cluster by applying incremental backups than by replaying WAL files. pg_probackup3 supports the following modes of incremental backups:
DELTA backup. In this mode, pg_probackup3 reads all data files in the data directory and copies only those pages that have changed since the previous backup. This mode can create read-only I/O load equal to that of a full backup.
PTRACK backup. In this mode, Postgres Pro tracks page changes on the fly. Continuous archiving is not necessary for it to operate. Each time a relation page is updated, this page is marked in a special PTRACK bitmap. Tracking implies some minor overhead on the database server operation, but speeds up incremental backups significantly.
Guaranteed data integrity in backups: pg_probackup3 can take only physical online backups, and online backups require WAL for consistent recovery. So regardless of the chosen backup mode (FULL or DELTA), any backup taken with pg_probackup3 must use one of the following WAL delivery modes:
STREAM. Such backups include all the files required to restore the cluster to a consistent state at the time the backup was taken. Regardless of continuous archiving having been set up or not, the WAL segments required for consistent recovery are streamed via the replication protocol during backup and included into the backup files. That's why such backups are called autonomous, or standalone.
ARCHIVE. Such backups rely on continuous archiving to ensure consistent recovery. This is the default WAL delivery mode.
To manage backup data, pg_probackup3 creates a backup catalog. This is a directory that stores all backup files with additional meta information, as well as WAL archives required for point-in-time recovery. The list of backups stored in the catalog as well as the list of all WAL timelines and the corresponding meta information can be derived in plain text or in the JSON format.
You can store backups for different instances in separate subdirectories of a single backup catalog. pg_probackup3 allows storing backups both on local disks and in network file systems. It provides support for working through the following network storage protocols:
NFS version 3 and 4
S3 based on MinIO object, Amazon S3, and VK Cloud storage. Backup data is transferred to and from S3 without saving it in intermediate locations thus eliminating the need of having a large temporary storage.
WebDav
SAMBA
FTP/SFTP
Retention: Managing WAL archive and backups in accordance with retention policy. You can configure retention policy based on recovery time or the number of backups to keep, as well as specify time to live (TTL) for a particular backup. Expired backups can be merged or deleted.
Multithreading: It is possible to run backup,
restore, merge,
delete, catchup,
and validate
processes on multiple parallel threads.
Remote operations: Backing up Postgres Pro instance located on a remote system or restoring a backup remotely.
External directories: Backing up files and directories
located outside of the Postgres Pro data
directory (PGDATA), such as scripts, configuration
files, logs, or SQL dump files.
Partial restore:
Restoring only the specified databases
Point-in-time recovery (PITR)