Ни как при старте PostgreSQL 13.4 не могу заставить его

восстановиться из журнала, сделал один UPDATE после полного бекапа (его штатным типа rsync), накатил Backup и перезапустил с конфигом восстановления
postgresql.conf
Пробовал по простому, как в документации
restore_command = 'cp /archive/pg_wal/%f %p'
recovery_target_timeline = 'latest'
Поменял на другую, что бы увидеть лог, но файла нет, значит ни чего не выполнялось
restore_command = 'echo /archive/pg_wal/%f | tee -a /tmp/logrecovery.log | xargs cp -t %p'Что можно ещё посмотреть?
Откуда получается такой список %f файлов, оно само догадывается, воспринимая перед этим символы как путь? Или требуется ещё конфиг?

1) Из какого журнала вы хотите его восстановить? 2) Как вы этот журнал получали? 2.5) И что там лежыт, отличающегося от wal бэкапа? 3) Что за "конфиг восстановления", что там изменено? 4) Что пишэт в логи при старте с этим конфигом?

Вот так сервер делает WAL posgresql.conf archive_mode = on archive_command = 'cp /pgdata/main/pg_wal/%f /archive/pg_wal/%f' archive_timeout = 60 ls /archive/pg_wal/* /archive/pg_wal/000000010000000000000001 /archive/pg_wal/000000010000000000000002 ...... /archive/pg_wal/00000001000000000000001B.00000028.backup -- тут точка когда я сняд Backup /archive/pg_wal/00000001000000000000001C -- вот тут мой update есть /archive/pg_wal/00000001000000000000001D На развёрнутой БД из Backup, эта директория есть, доступы на чтение и запись есть. В логи ошибки не пишет, когда в конфиги есть ошибка, то пишет и ругается на эту строчку. log_min_messages - это усилить глубину вывода лога? А то он сейчас закоментирован.

А, так recovery_target_time или recovery_target_lsn надо сказать — иначе зачем он что-то проверять в archive полезет.

Спасибо, буду пробовать )

Посмотрел ещё раз postgresql.conf Нашёл, что эксперементировал с recovery_target_timeline = 'latest' Почитал ещё раз статью https://severalnines.com/database-blog/point-time-postgresql-database-restoration Он пишет, что конфигурация по восстановению описывается в recovery.conf Вот сделал свою и подложил это файл в восстановленную БД restore_command = 'cp /archive/pg_wal/%f %p' recovery_target_time = 'Sat Nov 13 08:48:15 UTC 2021' recovery_target_action = 'shutdown' recovery_end_command = 'mv /pgdata/main/recovery.conf /pgdata/main/recovery.done' Да БД отключается, в лог - using recovery command file "recovery.conf" is not supported user=,db=,app=,client=LOG: database system was shut down at 2021-11-14 06:55:25 UTC user=,db=,app=,client=FATAL: using recovery command file "recovery.conf" is not supported user=,db=,app=,client=DEBUG: shmem_exit(1): 1 before_shmem_exit callbacks to make user=,db=,app=,client=DEBUG: shmem_exit(1): 6 on_shmem_exit callbacks to make user=,db=,app=,client=DEBUG: proc_exit(1): 2 callbacks to make user=,db=,app=,client=DEBUG: exit(1) user=,db=,app=,client=DEBUG: shmem_exit(-1): 0 before_shmem_exit callbacks to make user=,db=,app=,client=DEBUG: shmem_exit(-1): 0 on_shmem_exit callbacks to make user=,db=,app=,client=DEBUG: proc_exit(-1): 0 callbacks to make

https://fluca1978.github.io/2019/07/08/PostgreSQL12Recovery.html According to the documentation for the upcoming version 12, the recovery.conf file has gone! The release note states it clearly: the server will not start if recovery.conf is in place and all the configuration parameters have moved to the classic postgresql.conf (or included files). Боль, печаль....

recovery.conf было до кажэтся 11 включительно. Теперь это всё пишэтся в postgresql.conf recovery_target_timeline='latest' не делает ничего, поскольку это дефолт. Кроме того, у вас всё равно один таймлайн. И, кстати, к параметрам, которые я вам предложыл указать, он не относится.

Да спасибо. Нашёл как раз, что в 12 всё в одном файле и нет больше recover.conf -> recovery.done Беру дату создания последнего файла в /archive/pg_wal -rw-------. 1 1000760000 2000 16777216 2021-11-14 10:24:58.370004220 +0000 000000010000000000000020 date -u --date='2021-11-14 10:24:58' Модифициую postgresql.conf на восстановленной БД restore_command = 'cp /archive/pg_wal/%f %p' recovery_target_action = 'shutdown' recovery_target_time = 'Sun Nov 14 10:24:58 UTC 2021' И магия не срабатывает, как починить такую магию? Вот кусочек лога client=LOG: redo starts at 0/1D0000D8 client=DEBUG: end of backup reached client=CONTEXT: WAL redo at 0/1E000028 for XLOG/BACKUP_END: 0/1D0000D8 client=LOG: consistent recovery state reached at 0/1E000050 client=DEBUG: could not open file "pg_wal/00000001000000000000001F": No such file or directory client=LOG: redo done at 0/1E000050 client=DEBUG: resetting unlogged relations: cleanup 0 init 1Лог Целиком https://paste.centos.org/view/ea72d88d

А, ну да, чо это я. pg_wal от бэкапа надо было почистить, чтобы он эти сегменты из архива брал (он считает, что в pg_wal лежат последние всегда). Да, кстати, вы заметили, что он сегмент 1F переписал ужэ, его надо восстановить как-то?

Неа всё тестовое, спасибо, могу пробовать там пока не полысею )