Работа pg_probackup в Windows

[ykurenkov]

Посмотрел много видео с конференций о pg_probackup. Прочитал инструкцию на сайте PostgresPro. Настроил бэкапирование:

pg_probackup add-instance -B %BACKUP_DIR% -D %PGDATA% --instance %INSTANCE% pg_probackup backup -B %BACKUP_DIR% --instance %INSTANCE% --backup-mode=FULL --stream --progress -d postgres

В %BACKUP_DIR% появился директорий backups и внутри его %INSTANCE% со структурой директориев с архивами.

pg_probackup show -B %BACKUP_DIR%

Выводит список бэкапов. Всё хорошо. А вот как из этих бэкапов восстанавливаться?

Команда

pg_probackup restore -B %BACKUP_DIR% --instance %INSTANCE%

создаёт %PGDATA% с pg_wal и recovery.conf. Естественно в не пустом %PGDATA% initdb отказывается создавать кластер. Если же сначала создать кластер, то pg_probackup restore сообщает:

ERROR: restore destination is not empty: “D:\PGDATA\test\”

Как же использовать pg_probackup для восстановления?

Вот вывод на консоль pg_probackup restore:

VERBOSE: Thread [0]: Need to switch to segno next to 0/20000000, current LSN 0/20000028
LOG: Thread [0]: Opening WAL segment "D:/IBIS_BACKUPS/PGBACKUPS/wal/IBIS/000000010000000000000020"
INFO: Backup PN61N8 WAL segments are valid
INFO: Backup PN61N8 is valid.
LOG: restoring database from backup 2019-02-19 12:45:26+05
LOG: there is no file tablespace_map
LOG: restore directories and symlinks...
LOG: create directory "pg_wal"
LOG: Start thread for num:3
VERBOSE: Restoring file D:\IBIS_BACKUPS\PGBACKUPS\backups\IBIS\PN5XJQ\database/backup_label, is_datafile 0, is_cfs 0
VERBOSE: Restored file D:\IBIS_BACKUPS\PGBACKUPS\backups\IBIS\PN5XJQ\database/backup_label : 223 bytes
VERBOSE: Restoring file D:\IBIS_BACKUPS\PGBACKUPS\backups\IBIS\PN5XJQ\database/pg_wal/00000001000000000000001A, is_datafile 0, is_cfs 0
VERBOSE: Restored file D:\IBIS_BACKUPS\PGBACKUPS\backups\IBIS\PN5XJQ\database/pg_wal/00000001000000000000001A : 16777216 bytes
VERBOSE: Restoring file D:\IBIS_BACKUPS\PGBACKUPS\backups\IBIS\PN5XJQ\database/pg_wal/00000001000000000000001B, is_datafile 0, is_cfs 0
VERBOSE: Restored file D:\IBIS_BACKUPS\PGBACKUPS\backups\IBIS\PN5XJQ\database/pg_wal/00000001000000000000001B : 16777216 bytes
LOG: restore PN5XJQ backup completed
LOG: restoring database from backup 2019-02-19 14:13:56+05
LOG: there is no file tablespace_map
LOG: restore directories and symlinks...
LOG: Start thread for num:1
VERBOSE: Restoring file D:\IBIS_BACKUPS\PGBACKUPS\backups\IBIS\PN61N8\database/backup_label, is_datafile 0, is_cfs 0
VERBOSE: Restored file D:\IBIS_BACKUPS\PGBACKUPS\backups\IBIS\PN61N8\database/backup_label : 223 bytes
LOG: restore PN61N8 backup completed
LOG: ----------------------------------------
LOG: creating recovery.conf
INFO: Restore of backup PN61N8 completed.

pg_probackup из сборки PostgresPro_10.6.1_64.bit.exe
pg_probackup 2.0.24 (Postgres Pro 10.6.1 standard)

[gsmolk]

Спасибо за фидбэк.
Сейчас подготовим бинари 2.0.26

[gsmolk]

Готово:
https://oc.postgrespro.ru/index.php/s/ikfqgfjBO5n15aE

[gsmolk]

Если возникнут какие-либо вопросы - пишите.

[ykurenkov]

Есть не вопросы, а скорее информация. Попробовал присланные бинарники. Поведение под виндой не поменялось pg_probackup в --backup-mode=FULL копирует из %PGDATA% в %BACKUP_DIR%]backups%INSTANCE%\ИМЯ_БЭКАПА\database только pg_wal и создаёт backup_label. Больше никаких файлов кроме нескольких WAL и backup_label там нет.

Собрал с утра под Ubuntu - там при FULL копирует $PGDATA. Но и тут проблема:

INFO: Progress: (1296/1297). Process file "/var/lib/pgpro/std-10/data/base/16384/16407"
INFO: Progress: (1297/1297). Process file "/var/lib/pgpro/std-10/data/base/16384/16385"
INFO: Data files are transfered
INFO: wait for pg_stop_backup()
WARNING:  pg_stop_backup still waiting for all required WAL segments to be archived (60 seconds elapsed)
HINT:  Check that your archive_command is executing properly.  pg_stop_backup can be canceled safely, but the database backup will not be usable without all the WAL segments.

Бэкап завершается с ошибкой. arrchive_command закомментарена.

WARNING: Cancel request sent
ERROR: pg_stop_backup doesn't answer in 300 seconds, cancel it
WARNING: Backup PN9Y47 is running, setting its status to ERROR
WARNING: backup in progress, stop backup
INFO: Validate backups of the instance 'TEST'
WARNING: Backup PN9Y47 has status ERROR. Skip validation.
WARNING: Some backups are not valid

Включил архивацию WAL

# WAL archiving
archive_mode    = on
archive_timeout = 60            # force a logfile segment switch after this
                                # number of seconds; 0 disables


#archive_command = 'copy /Y %p C:\\IBIS_PGARCHIVE\\//%f'
#max_standby_archive_delay = 10s
archive_command = 'pg_probackup archive-push -B /var/lib/postgresql/PROBAK  --instance TEST --wal-file-path %p --wal-file-name %f'

Прописал archive_command - бэкап выполнился. Что я делаю не так? Из документации на сайте не очевидно, что archive_command надо включать. И не понятно зачем включать архивацию?

[gsmolk]

Есть не вопросы, а скорее информация. Попробовал присланные бинарники. Поведение под виндой не поменялось pg_probackup в --backup-mode=FULL копирует из %PGDATA% в %BACKUP_DIR%]backups%INSTANCE%\ИМЯ_БЭКАПА\database только pg_wal и создаёт backup_label. Больше никаких файлов кроме нескольких WAL и backup_label там нет.

А можете выполнить FULL бэкап с опцией --log-level-console=verbose и прислать весь выхлоп?
Выглядит как какая-то локальная проблема, перед передачей бинарей я прогнал на них все тесты, бэкапилось и восстанавливалось всё корректно.

Прописал archive_command - бэкап выполнился. Что я делаю не так? Из документации на сайте не очевидно, что archive_command надо включать. И не понятно зачем включать архивацию?

бэкапу для восстановления в консистентное состояние нужен WAL.
По умолчанию pg_probackup снимает бэкапы в архивном режиме доставки WAL, т.е. он полагается на архивирование:
https://postgrespro.ru/docs/enterprise/9.6/app-pgprobackup#setting-up-archive-backups
Если архивирование не настроено, то можно снять автономную копию с помощью опции '--stream'. В этом случае необходимый WAL будет стримится по протоколу репликации.

[ykurenkov]

backup.log

[gsmolk]

А какие файлы и директории присутствуют в 'D:\IBIS_BACKUPS\PGBACKUPS\backups\IBIS\PNBSN5\database/' ?

[ykurenkov]

 Том в устройстве D не имеет метки.
 Серийный номер тома: 8C6C-80CA

 Содержимое папки D:\IBIS_BACKUPS\PGBACKUPS\backups\IBIS\PNBSN5

22.02.2019  17:29    <DIR>          .
22.02.2019  17:29    <DIR>          ..
22.02.2019  16:45               665 backup.control
22.02.2019  16:45               439 backup_content.control
22.02.2019  16:45    <DIR>          database
               2 файлов          1 104 байт

 Содержимое папки D:\IBIS_BACKUPS\PGBACKUPS\backups\IBIS\PNBSN5\database

22.02.2019  16:45    <DIR>          .
22.02.2019  16:45    <DIR>          ..
22.02.2019  16:45               223 backup_label
22.02.2019  16:45    <DIR>          pg_wal
               1 файлов            223 байт

 Содержимое папки D:\IBIS_BACKUPS\PGBACKUPS\backups\IBIS\PNBSN5\database\pg_wal

22.02.2019  16:45    <DIR>          .
22.02.2019  16:45    <DIR>          ..
22.02.2019  16:45        16 777 216 000000010000000000000039
22.02.2019  16:45        16 777 216 00000001000000000000003A
               2 файлов     33 554 432 байт

     Всего файлов:
               5 файлов     33 555 759 байт
               8 папок  1 980 139 986 944 байт свободно

[gsmolk]

Пробэкап перед стартом бэкапа составляет массив файлов и директорий, которые содержатся в PGDATA.
У Вас этот массив содержит 0 файлов.
Похоже, что файловая система не дает сделать listing файлов в директории, а pg_probackup это не детектит(что является багом). Какая у Вас ОС? Какие права существуют на директорию PGDATA?

[ykurenkov]

Полный доступ дан всем пользователям от безисходности. Windows Server 2016 Standart x64.

[gsmolk]

А там файлы, случайно, не скрытые?

[gsmolk]

Сделал бинарь с дополнительным отладочным сообщением:
https://oc.postgrespro.ru/index.php/s/wxGOJgI4yzlH0O6

Сделайте им, пожалуйста, бэкап и пришлите выхлоп

[gsmolk]

И пришлите еще, пожалуйста, скриншот с Advanced Security для PGDATA

[gsmolk]

Поставил PostgresPro 10.6.1 на Windows 2016 и запустил бэкап - успешно выполнился, файлы скопированы. Версия с проблемой с правами выглядит всё более вероятной.

[gsmolk]

Смог воспроизвести: отобрал у юзера, совершающего бэкап, право на 'List Folder Content', оставив при этом право на чтение.
Со своей стороны, постараемся разобраться, почему это не приводит к ошибке в opendir().