srvpg:5432:pgbackup:postgres:password

ха, а теперь и psql перестал )
наверно у меня руки ... )

так, с psql разобрался, если в .pgpass написать конкретную базу (в моем случае pgbackup), то только для нее пароль подставляется, а для остальных просит пароль
исправил на:
srvpg:5432:*:postgres:password
теперь psql подключается без проблем, но pg_receivewal так и не хочет

все работает нормально, я сам тормоз
я когда поменял имя базы на *, заодно поменял fqdn-имя сервера на короткое (srv, как в hosts) - ну а флаг -h fqdn.domain.name не исправил )

Дак pg_receivexlog требует креденталы к виртуальной базе replication

ну так, я сначала базу конкретную (и не ту прописал), а потом еще с именами сервера начудил - вот и не работало )

Получилось в итоге?

конечно, все работает

Здравствуйте. Подскажите, стоит ли переходить на более новую версию с версии postgres9.4 или лучше оставить как есть?

Впечатлило частичное восстановление одной базы на нужное время.

Правда почему-то вчера вечером, пока разбирался не получалось с PITR - в восстановленной копии не создавался recovery.conf. То ли сегментов не хватало, то ли с параметрами запуска что-то напутал.

Да, кстати, протестировал восстановление на 8 дельтах от полного - разница о времени не заметна.
Единственное, что немного смущает - это валидация.
Сам бэкап снимается / восстанавливается примерно 35-40 минут (100Гб размер data, 30 баз 1С - огромная куча таблиц, 800000 файлов архивируется), а валидация занимает еще 15-20 минут.  На бэкапном хосте обычный диск HDD (пара в raid1), а восстановление тестировал на тот же диск, где архив лежит.

Но в целом все отлично работает.
Раньше негде было разместить архив, т.к. место для бэкапов подключалось по sshfs. При таком количестве файлов все просто умирало напрочь. Так что мой вариант был только дампы складывать.
Сейчас для бэкапов отдельный хост и проблем нет.

p.s. Спасибо за консультации!

> Правда почему-то вчера вечером, пока разбирался не получалось с PITR - в восстановленной копии не создавался recovery.conf
>
Если вспомните параметры запуска, то буду очень признателен

> Да, кстати, протестировал восстановление на 8 дельтах от полного - разница о времени не заметна.
>
Попробуйте сравнить восстановление последней дельты и полного бэкапа

> Единственное, что немного смущает - это валидация.
>
Валидация по умолчанию очень параноидальная, её можно ускорить флагом --skip-block-validation

Стоит, но нужно тщательно спланировать миграцию.

вот тут засада - я держал несколько сеансов с консолью и история сохранилась не с того сеанса, где restore ковырял
возможно поэтому и получилось, что команду набрал заново.

еще нюанс - я wal архив начал собирать перед последними дельтами
сами бэкапы делаю в режиме STREAM
и когда не получалось восстановление pitr уже хотел писать спрашивать, а оно взяло и получилось
единственное запомнил, что во время одной из попыток заметил, что появляется recovery.conf, но потом исчезает

Ну я так и сравниваю - разница 2-3 минуты (полное восстановление), при полном 35 минут, последняя дельта 37-38 минут. Прадва там суммарно не особо много накопилось 2 дня. Просто наделал в разное время несколько раз DELTA, PAGE, чтобы посмотреть как и что.
А на частичном восстановлении небольшой базы (1,5Гб) вообще не заметно разницы.

Ну при экспериментах я ее вообще отключаю.
А так ночью пусть она колбасится сколько хочет.

чет странно, pbk так не делает

ну если вдруг мне не почудилось (вполне мог mc протормозить и показать содержимое каталога от другой попытки, а потом резко обновить экран - содержимое recovery.conf я посмотреть не успел, возможно это просто глюк был) и удастся воспроизвести - напишу

было бы круто