Выполняю резервное копирование при помощи pg_dump, при этом, при восстановлении ругается. Хотя база как-то восстанавливается и открывается при этом в режиме предприятие.

Прочитал вот здесь: http://www.gilev.ru/pg_dump/
Пишут, что pg_dump не лучшая идея, лучше pg_dumpall.

Хорошо, сделал резервную копию всего экземпляра сервера Postgres.
А как из него восстановить конкретную базу?

https://habr.com/ru/companies/otus/articles/710094/

(2) Там нет ответа на этот вопрос

Неправильный вариант, восстановить все базы, всего экземпляра и pg_dump -ом перенести нужную куда нужно. Правильный вариант один инстанс- одна база, восстановил и все. Я пользуюсь dump -ом, но у меня все маленькое.

(3) "Неправильный вариант, восстановить все базы, всего экземпляра"

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

Попробуйте восстановить в новую(созданную базу) или с опцией "Clean before restore". Пользуюсь pg_dump в таком сценарии без проблем.

(0) >при этом, при восстановлении ругается

надеюсь восстанавливаешь в чистую пустую (или новую) базу
а не в уже существующую?
если база уже с данными - сначала надо ее очистить
или лучше удалить и создать заново

(6) Да, в чистую.

(5) Та же фигня

>>при восстановлении ругается
Что пишет? Может, это и не ошибки вовсе, а просто "безвредные сообщения", подлежащие игнорированию.

(9) Ошибки типа таких:

pg_restore: error: could not execute query: ERROR: index "_reference98_2" does not exist
Command was: DROP INDEX public._reference98_2;


pg_restore: error: could not execute query: ERROR: table "_inforgchngr2311" does not exist
Command was: DROP TABLE public._inforgchngr2311;

pg_restore: error: could not execute query: ERROR: table "_inforgchngr2274" does not exist
Command was: DROP TABLE public._inforgchngr2274;

Бекап делали в момент реструктуризации базы?

(11) нет, во время обычной работы

(0) Как же хорошо доверить все это адммину).
Ps. MS SQL сам могу,очень удобная штука,жаль что они нас так кинули.PG только скриптом бэкап написал на сохранение,есть заготовка в интернете.Админ грозится что владееет магией восстановления)

(13) Ага, смотрю постгрес и понимаю как было хорошо, когда было хорошее ПО :-)

(11) бэкап PgSQL в момент реструктуризации это тушите свет
я так однажды базу прода запорол
повезло что бэкап оказался рабочий, хотя реструктуризация упала и запорола базу

(14) PgSQL хорошее ПО
но не очень юзер-френдли ибо опенсорсное бесплатное

Тогда мне не понятно, зачем при восстановлении бекапа удалять индексы и таблицы

(17) потому что этот вот "бэкап" (логический) - фактически текст, последовательность sql команд для воссоздания базы
включите туда в самое начало команды очистки базы (удаления всех индексов, таблиц и прочего) если надо

(18)+ в статье в (1) все описано
если надо можно делать физический (бинарный) бэкап вместо логического (текстового)
но это требует остановки службы PgSQL

у MSSQL предусмотрена частичная остановка или точнее восстановление из физического бэкапа одной базы на лету
в PgSQL нет

но кто/что вам мешает для каждой отдельной базы поднимать отдельный экземпляр службы PgSQL?
понятно на разных портах

(10) Для чистой базы --clean не нужен, там нечего удалять.
Из инструкции(pg_restore):
"--clean
Прежде чем восстанавливать объекты базы данных, выполните команды DROP для всех восстанавливаемых объектов. Этот параметр полезен для перезаписи существующей базы данных. Без дополнительного указания --if-exists при этом могут выдаваться безвредные сообщения об ошибках, если таких объектов не окажется в целевой базе данных."
Я же говорил, что безвредные сообщения...

Продолжаем.
Сделал резервную копию кластера через pg_dumpall.

Восстанавливаю:
postgres-# psql -X -f "C:\_BackUp\AllServer\allBackUp.sql"

никаких сообщений не выдает. Как узнать работает ли вообще это?

(21)  => Как узнать работает ли вообще это?

Потестить хорошенько? Типа например несколько раз сделать такой бэкап во время пиковой нагрузки на проде или вообще во время реструктуризации для совсем уж полной уверенности, лол.

(0) При восстановлении из консоли PostgreSQL, было замечено, что самое лучшее восстановление, это
1. Иметь бэкап. готовый
2. удалить базу в PostgreSQL.
3. Создать базу с тем же именем в PostgreSQL.
4. Восстанавливаем, без каких либо лишних галочек, типо той же "Clean before restore"... Нечего не трогаем, все по умолчанию :)
...
И вуаля, восстановление проходит без какой либо ошибки.
А в других вариантах, стоит тронуть какую либо галочку при восстановлении, сыпется куча сообщений, или бэкап вовсе не восстанавливается :)

(22) Как потестить?

Скопировал кластер.
Удалил несколько баз.
Восстанавлиаю кластер обратно.

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

(23) так и делаю, но восстановление говорит, что закончилось неуспешно, ошибки из (10).

При этом база создается, из 1с запускается