To set up the cluster for STREAM backups, complete the following steps:

To set up the cluster for[STREAM](#stream-mode) backups, complete the following steps:

- Grant the REPLICATION privilege to the backup role:

If you are planning to take PAGE backups in STREAM mode, you still have to configure WAL archiving as explained in the section[Setting up continuous WAL archiving](#setting-up-continuous-wal-archiving).

Once these steps are complete, you can start taking FULL, PAGE, DELTA and PTRACK backupsinSTREAM mode.

Once these steps are complete, you can start taking FULL, PAGE, DELTA and PTRACK backupswith[STREAM](#stream-mode) WAL mode.

ARCHIVE backups require[continious WAL archiving](https://www.postgresql.org/docs/current/continuous-archiving.html) to be enabled. To set up continious archiving in the cluster, complete the following steps:

Making backups in PAGE backup mode, performing[PITR](#performing-point-in-time-pitr-recovery) and making backups with[ARCHIVE](#archive-mode) WAL delivery mode require[continious WAL archiving](https://www.postgresql.org/docs/current/continuous-archiving.html) to be enabled. To set up continious archiving in the cluster, complete the following steps:

- Make sure the[wal_level](https://www.postgresql.org/docs/current/runtime-config-wal.html#GUC-WAL-LEVEL) parameter is higher than`minimal`.

- If you are configuring archiving on master,[archive_mode](https://www.postgresql.org/docs/current/runtime-config-wal.html#GUC-ARCHIVE-MODE) must be set to`on`. To perform archiving on standby, set this parameter to`always`.

- Set the[archive_command](https://www.postgresql.org/docs/current/runtime-config-wal.html#GUC-ARCHIVE-COMMAND) parameter, as follows:

Where*backup_dir* and*instance_name* refer to the already initialized backup catalog instance for this database cluster and optional parameters[remote_options](#remote-mode-options) should be used to archive WAL to the remotemachine. For details about all possible`archive-push` parameters, see the section[archive-push](#archive-push).

Where*backup_dir* and*instance_name* refer to the already initialized backup catalog instance for this database cluster and optional parameters[remote_options](#remote-mode-options) should be used to archive WAL to the remotehost. For details about all possible`archive-push` parameters, see the section[archive-push](#archive-push).

Once these steps are complete, you can starttaking FULL, PAGE, DELTA and PTRACK backups inARCHIVEmode.

Once these steps are complete, you can startmaking backups with ARCHIVE WAL mode, backups inPAGE backupmode and perform[PITR](#performing-point-in-time-pitr-recovery).

If you are planning to make PAGE backups and/or backups with[ARCHIVE](#archive-mode) WAL mode from a standby of a server, that generates small amount of WAL traffic, without long waiting for WAL segment to fill up, consider setting[archive_timeout](https://www.postgresql.org/docs/current/runtime-config-wal.html#GUC-ARCHIVE-TIMEOUT) PostgreSQL parameter**on master**. It is advisable to synchronize the value of this setting with pg_probackup option`--archive-timeout`.

- To perform STREAM backup on standby, complete all steps in section[Setting up STREAM Backups](#setting-up-stream-backups)

- To perform ARCHIVE backup on standby, complete all steps in section[Setting up continuous WAL archiving](#setting-up-continuous-wal-archiving)

Once these steps are complete, you can start taking FULL, PAGE, DELTA or PTRACK backupsof appropriate WAL deliverymethod: ARCHIVE or STREAM, from the standby server.

Once these steps are complete, you can start taking FULL, PAGE, DELTA or PTRACK backupswith appropriate WAL deliverymode: ARCHIVE or STREAM, from the standby server.

Backup from the standby server has the following limitations:

- Backup in STREAM mode can be taken from standby of a server, that generates small amount of WAL traffic, without long waiting for WAL segment to fill up.

If[data checksums](https://www.postgresql.org/docs/current/runtime-config-preset.html#GUC-DATA-CHECKSUMS) are enabled in the database cluster, pg_probackup uses this information to check correctness of data files during backup. While reading each page, pg_probackup checks whether the calculated checksum coincides with the checksum stored in the page header. This guarantees that the PostgreSQL instance and backup itself are free of corrupted pages.

Note that pg_probackup reads database files directly from filesystem, so under heavy write load during backup it can show false positive checksum failures because of partial writes. In case of page checksumm mismatch, page is readed again and checksumm comparison repeated.