Postgres Pro Backup Enterprise
3.43.33.23.13.0
RUENRU EN
3.3. Восстановление кластера
Пред. НаверхГлава 3. ИспользованиеНачало След.

3.3. Восстановление кластера #

3.3.1. Частичное восстановление
3.3.2. Выполнение восстановления на момент времени (PITR)

Примечание

В то время как файлы резервных копий могут передаваться из разных источников (файловая система, S3 или SSH SFTP), восстановление каталога данных PGDATA сервера Postgres Pro производится в локальную файловую систему.

Чтобы восстановить кластер баз данных из резервной копии, выполните команду restore как минимум со следующими параметрами:

pg_probackup3 restore -B каталог_копий --instance=имя_экземпляра -i ид_резервной_копии

Здесь:

  • каталог_копий — каталог, в котором хранятся все файлы резервных копий и метаданные.

  • имя_экземпляра — имя экземпляра резервной копии кластера, который будет восстановлен.

  • ид_резервной_копии определяет, из какой резервной копии будет восстановлен кластер.

Если вы восстанавливаете копию ARCHIVE или выполняете восстановление PITR, pg_probackup3 создаёт файл конфигурации восстановления после копирования всех файлов данных в целевой каталог. Этот файл включает необходимые для восстановления параметры, за исключением пароля, заданного в primary_conninfo; если он требуется, его нужно дополнительно задать вручную или воспользоваться параметром --primary-conninfo. pg_probackup3 сохраняет эти параметры в файле probackup_recovery.conf в каталоге данных и подключает его в postgresql.auto.conf.

Если восстанавливалась копия типа STREAM, восстановление завершается сразу, и кластер возвращается в согласованное состояние на момент времени, в который была сделана резервная копия. Для копий типа ARCHIVE Postgres Pro воспроизводит все имеющиеся в архиве сегменты WAL, в результате чего восстанавливается самое последнее состояние кластера на текущей линии времени. Это поведение можно изменить, определив параметры точки восстановления для команды restore как описывается в Раздел 3.3.2.

Если кластер, подлежащий восстановлению, содержит табличные пространства, pg_probackup3 по умолчанию восстанавливает их в исходные расположения. Чтобы сменить расположения табличных пространств, воспользуйтесь параметром --tablespace-mapping/-T. В противном случае при восстановлении кластера на том же сервере произойдёт ошибка, если эти табличные пространства будут использоваться, так как восстанавливаемые данные нужно будет записать в те же каталоги.

Используя параметр --tablespace-mapping/-T, вы должны задать абсолютные пути к старому и новому каталогу табличного пространства. Если путь содержит знак равно (=), экранируйте его обратной косой чертой. Данный параметр может указываться неоднократно для перемещения нескольких табличных пространств. Например:

pg_probackup3 restore -B каталог_копий --instance имя_экземпляра -D каталог_данных -j 4 -i ид_резервной_копии -T каталог_табл_пространства1=новый_каталог_табл_пространства1 -T каталог_табл_пространства2=новый_каталог_табл_пространства2

3.3.1. Частичное восстановление #

Можно восстанавливать определённые базы данных с помощью параметров частичного восстановления с командой restore. Ниже представлены все возможные варианты частичного восстановления.

3.3.1.1. Частичное восстановление по имени #

Если вы настроили частичное восстановление прежде, чем создавать резервные копии, вы можете восстанавливать отдельные базы данных, используя параметры --db-include-name и --db-exclude-name.

Чтобы восстановить только определённые базы данных, выполните команду restore со следующими параметрами:

  pg_probackup3 restore -B каталог_копий --instance=имя_экземпляра --db-include-name=имя_бд

Параметр --db-include-name можно указывать многократно. Например, чтобы восстановить только базы db1 и db2, выполните следующую команду:

  pg_probackup3 restore -B каталог_копий --instance=имя_экземпляра --db-include-name=db1 --db-include-name=db2

Чтобы исключить одну или несколько баз из числа восстанавливаемых, используйте параметр --db-exclude-name:

  pg_probackup3 restore -B каталог_копий --instance=имя_экземпляра --db-exclude-name=имя_бд

Параметр --db-exclude-name можно указывать многократно. Например, чтобы исключить из числа восстанавливаемых только базы db1 и db2, выполните следующую команду:

  pg_probackup3 restore -B каталог_копий --instance=имя_экземпляра --db-exclude-name=db1 --db-exclude-name=db2

Примечание

После успешного запуска кластера Postgres Pro восстановленные определения исключённых баз данных можно удалить с помощью команды DROP DATABASE.

Чтобы максимально быстро разделить один кластер, содержащий несколько баз данных, на разные кластеры, можно выполнить частичное восстановление исходного кластера в виде ведомого, передав ключ --restore-as-replica для определённых баз данных.

Примечание

Базы template0 и template1 восстанавливаются всегда.

Предупреждение

Параметры --db-exclude-name и --db-include-name использовать вместе нельзя.

3.3.1.2. Частичное восстановление по OID #

Можно восстанавливать определённые базы данных без дополнительной подготовки с помощью параметров --db-include-oid и --db-exclude-oid.

Чтобы восстановить только определённые базы данных, выполните команду restore со следующими параметрами:

pg_probackup3 restore -B каталог_копий --instance=имя_экземпляра --db-include-oid=dboid

Параметр --db-include-oid можно указывать многократно. Например, чтобы восстановить только базы db1 и db2 с OID dboid1 и dboid2, соответственно, выполните следующую команду:

pg_probackup3 restore -B каталог_копий --instance=имя_экземпляра --db-include-oid=dboid1 --db-include-oid=dboid2

Чтобы исключить одну или несколько баз из числа восстанавливаемых, используйте параметр --db-exclude-oid:

pg_probackup3 restore -B каталог_копий --instance=имя_экземпляра --db-exclude-oid=dboid

Параметр --db-exclude-oid можно указывать многократно. Например, чтобы исключить из числа восстанавливаемых только базы db1 и db2 с OID dboid1 и dboid2, соответственно, выполните следующую команду:

pg_probackup3 restore -B каталог_копий --instance=имя_экземпляра --db-exclude-oid=dboid1 --db-exclude-oid=dboid2

Примечание

После успешного запуска кластера Postgres Pro восстановленные определения исключённых баз данных можно удалить с помощью команды DROP DATABASE.

Чтобы максимально быстро разделить один кластер, содержащий несколько баз данных, на разные кластеры, можно выполнить частичное восстановление исходного кластера в виде ведомого, передав ключ --restore-as-replica для определённых баз данных.

Примечание

Базы template0 и template1 восстанавливаются всегда.

Предупреждение

Параметры --db-exclude-oid и --db-include-oid использовать вместе нельзя.

3.3.2. Выполнение восстановления на момент времени (PITR) #

Если вы настраивали непрерывное архивирование WAL до создания резервных копий, вы можете восстановить состояние кластера на любой момент времени (до заданной точки восстановления), используя с командой restore параметры точки восстановления.

Для восстановления на момент времени может использоваться копия типа STREAM или ARCHIVE, но при этом обязательно наличие архива WAL с момента создания копии или более раннего.

  • Чтобы восстановить состояние кластера на определённый момент времени, укажите это время в параметре --recovery-target-time, в формате timestamp. Например:

    pg_probackup3 restore -B каталог_копий --instance=имя_экземпляра --recovery-target-time="2024-04-10 18:18:26+03"

  • Чтобы восстановить текущее или последнее возможное состояние кластера, передайте в параметре --recovery-target-time значение current или latest, соответственно:

    pg_probackup3 restore -B каталог_копий --instance=имя_экземпляра --recovery-target-time="latest"

  • Чтобы восстановить состояние кластера до определённой транзакции, воспользуйтесь ключом --recovery-target-xid:

    pg_probackup3 restore -B каталог_копий --instance=имя_экземпляра --recovery-target-xid=687

  • Чтобы восстановить состояние кластера до определённой позиции в журнале (LSN), воспользуйтесь ключом --recovery-target-lsn:

    pg_probackup3 restore -B каталог_копий --instance=имя_экземпляра --recovery-target-lsn=16/B374D848

  • Чтобы восстановить состояние кластера до заданной именованной точки восстановления, воспользуйтесь ключом --recovery-target-name:

    pg_probackup3 restore -B каталог_копий --instance=имя_экземпляра --recovery-target-name="before_app_upgrade"

  • Чтобы восстановить последнее возможное состояние, исходя из содержимого архива WAL, передайте в параметре --recovery-target-stop значение latest:

    pg_probackup3 restore -B каталог_копий --instance=имя_экземпляра --recovery-target-stop="latest"

  • Чтобы восстановить самое раннее из возможных согласованное состояние кластера, передайте в параметре --recovery-target-stop значение immediate:

              pg_probackup3 restore -B каталог_копий --instance=имя_экземпляра --recovery-target-stop='immediate'
Пред. Наверх След.
3.2. Монтирование каталога резервных копий с помощью FUSE Начало 3.4. Управление каталогом резервных копий
3.3. Restoring a Cluster
Prev UpChapter 3. UsageHome Next

3.3. Restoring a Cluster #

3.3.1. Partial Restore
3.3.2. Performing Point-in-Time (PITR) Recovery

Note

While backup files for restore can be retrieved from different sources (the file system, S3, or SSH SFTP), pg_probackup3 can only restore the Postgres Pro server PGDATA to a local file system.

To restore the database cluster from a backup, run the restore command with at least the following options: 

pg_probackup3 restore -B backup_dir --instance=instance_name -i backup_id

Where:

  • backup_dir is the backup catalog that stores all backup files and meta information.

  • instance_name is the backup instance for the cluster to be restored.

  • backup_id specifies the backup to restore the cluster from.

If you restore ARCHIVE backups or perform PITR, pg_probackup3 creates a recovery configuration file once all data files are copied into the target directory. This file includes the minimal settings required for recovery, except for the password in the primary_conninfo parameter; you have to add the password manually or use the --primary-conninfo option, if required. pg_probackup3 writes recovery settings into the probackup_recovery.conf file and then includes it into postgresql.auto.conf.

If you are restoring a STREAM backup, the restore is complete at once, with the cluster returned to a self-consistent state at the point when the backup was taken. For ARCHIVE backups, Postgres Pro replays all available archived WAL segments, so the cluster is restored to the latest state possible within the current timeline. You can change this behavior by using the recovery target options with the restore command, as explained in Section 3.3.2.

If the cluster to restore contains tablespaces, pg_probackup3 restores them to their original location by default. To restore tablespaces to a different location, use the --tablespace-mapping/-T option. Otherwise, restoring the cluster on the same host will fail if tablespaces are in use, because the backup would have to be written to the same directories.

When using the --tablespace-mapping/-T option, you must provide absolute paths to the old and new tablespace directories. If a path happens to contain an equals sign (=), escape it with a backslash. This option can be specified multiple times for multiple tablespaces. For example: 

pg_probackup3 restore -B backup_dir --instance=instance_name -D data_dir -j 4 -i backup_id -T tablespace1_dir=tablespace1_newdir -T tablespace2_dir=tablespace2_newdir

3.3.1. Partial Restore #

You can restore particular databases using partial restore options with the restore command. The sections below describe all supported partial restore methods.

3.3.1.1. Partial Restore by Name #

If you have enabled partial restore before taking backups, you can restore specific databases by name using the --db-include-name and --db-exclude-name options.

To restore only the specified databases, run the restore command with the following options: 

  pg_probackup3 restore -B backup_dir --instance=instance_name --db-include-name=dbname

The --db-include-name option can be specified multiple times. For example, to restore only the databases db1 and db2, run the following command: 

  pg_probackup3 restore -B backup_dir --instance=instance_name --db-include-name=db1 --db-include-name=db2

To exclude one or more databases from restore, use the --db-exclude-name option: 

  pg_probackup3 restore -B backup_dir --instance=instance_name --db-exclude-name=dbname

The --db-exclude-name option can be specified multiple times. For example, to exclude the databases db1 and db2, run the following command: 

  pg_probackup3 restore -B backup_dir --instance=instance_name --db-exclude-name=db1 --db-exclude-name=db2

Note

After the Postgres Pro cluster is successfully started, drop the excluded databases using the DROP DATABASE command.

To decouple a single cluster containing multiple databases into separate clusters with minimal downtime, run partial restore of the cluster as a standby using the --restore-as-replica option for specific databases.

Note

The template0 and template1 databases are always restored.

Warning

Options --db-exclude-name and --db-include-name cannot be used together.

3.3.1.2. Partial Restore by OID #

You can restore particular databases without any special preparations using the --db-include-oid and --db-exclude-oid.

To restore the specified databases only, run the restore command with the following options: 

pg_probackup3 restore -B backup_dir --instance=instance_name --db-include-oid=dboid

The --db-include-oid option can be specified multiple times. For example, to restore only the db1 and db2 databases with OIDs dboid1 and dboid2, respectively, run the following command: 

pg_probackup3 restore -B backup_dir --instance=instance_name --db-include-oid=dboid1 --db-include-oid=dboid2

To exclude one or more databases from restore, use the --db-exclude-oid option: 

pg_probackup3 restore -B backup_dir --instance=instance_name --db-exclude-oid=dboid

The --db-exclude-oid option can be specified multiple times. For example, to exclude the db1 and db2 databases with OIDs dboid1 and dboid2, respectively, from restore, run the following command: 

pg_probackup3 restore -B backup_dir --instance=instance_name --db-exclude-oid=dboid1 --db-exclude-oid=dboid2

Note

After the Postgres Pro cluster is successfully started, drop the excluded databases using the DROP DATABASE command.

To decouple a single cluster containing multiple databases into separate clusters with minimal downtime, run partial restore of the cluster as a standby using the --restore-as-replica option for specific databases.

Note

The template0 and template1 databases are always restored.

Warning

Options --db-exclude-oid and --db-include-oid cannot be used together.

3.3.2. Performing Point-in-Time (PITR) Recovery #

If you have enabled continuous WAL archiving before taking backups, you can restore the cluster to its state at an arbitrary point in time (recovery target) using recovery target options with the restore command.

You can use both STREAM and ARCHIVE backups for point-in-time recovery as long as the WAL archive is available at least starting from the time the backup was taken.

  • To restore the cluster state at the exact time, specify the --recovery-target-time option, in the timestamp format. For example: 

    pg_probackup3 restore -B backup_dir --instance=instance_name --recovery-target-time="2024-04-10 18:18:26+03"

  • To restore the current or latest cluster state, set the --recovery-target-time option value to current or latest, respectively: 

    pg_probackup3 restore -B backup_dir --instance=instance_name --recovery-target-time="latest"

  • To restore the cluster state up to a specific transaction ID, use the --recovery-target-xid option: 

    pg_probackup3 restore -B backup_dir --instance=instance_name --recovery-target-xid=687

  • To restore the cluster state up to the specific LSN, use --recovery-target-lsn option: 

    pg_probackup3 restore -B backup_dir --instance=instance_name --recovery-target-lsn=16/B374D848

  • To restore the cluster state up to the specific named restore point, use --recovery-target-name option: 

    pg_probackup3 restore -B backup_dir --instance=instance_name --recovery-target-name="before_app_upgrade"

  • To restore the backup to the latest state available in the WAL archive, use --recovery-target-stop option with latest value: 

    pg_probackup3 restore -B backup_dir --instance=instance_name --recovery-target-stop="latest"

  • To restore the cluster to the earliest point of consistency, use --recovery-target-stop option with the immediate value: 

              pg_probackup3 restore -B backup_dir --instance=instance_name --recovery-target-stop='immediate'
Prev Up Next
3.2. Mounting a Backup Directory with FUSE Home 3.4. Managing the Backup Catalog
FAQ