Есть клиент с 8-кой на postgresql под windows.
Админ пытается мне доказать что у него какие то сложности с бекапами на postgre, что настраивать там сложно, а восстанавливать еще сложнее.
Поэтому занимается тем, что выгоняет пользователей и бекапит через выгрузку данных. И вообще он с кем то советовался и так делать правильно. Ну вот что есть.
Я с postgresql не работал, лезть туда не хочу. Мне своих забот хватает.
Если есть какие то методики и личный опыт - напишите!

У админа сложности не с бекапами, а со знанием пг.

(1) В этом я не сомневаюсь. Но надо как то спасать положение :)

(2) Займись сам сисадминством. Почитай книжки... Потом его выгонишь и возьмёшь себе его зп )

А цель-то какая?

сначала невредно понять, что именно было админом сделано, какие результаты были получены и почему они были признаны неудовлетворительными. А то, может, он нихрена и не делал, а просто настроил выгрузку dt, потому что так проще.

(3) Я админством неплохо занимаюсь, но вот лезть в его ПГ не хочу, мне своих MS SQL хватает :)

(0) на винде не пробовал, но общая логика врят ли сильно отличается от linux. Если без изысков создавать полные бэкапы с именем файла, равным текущей дате, то одна команда в планировщике спасет отцов русской демократии. Восстанавливать проще всего в новую пустую базу, созданную не из консоли администрирования серверов 1с, а из PGadmin, например.
Если база небольшая, то можно бэкапить в папку, которая синхронизируется с облаком.

я в свое время pg_dump'ом делал. Из геморроя натыкался на то, что на большие блобы иногда не хватало памяти при бэкапе. Позже прочитал как это обходить, но уже было не надо. В принципе, инфы в сети много, вот например https://postgrespro.ru/docs/postgrespro/9.5/app-pgdump

На винде не представляю, какие там особые сложности могут быть - не работал.
На линуксе несколько лет безпроблемно жил на pg_dump'е. Это почти нормальный фулл-бэкап, не требующий выгона пользователей. Достаточно быстро работает.
Кто живет на постгри в полный рост - те поднимают каждую базу в отдельной виртуалке и юзают pg_basebackup. В отличие от pg_dump это бинарный бэкап и позволяет делать бэкапы транзакций. Но работает только для всего кластера целиком.

(0) тебе батники или статью на ифострате? )

Вспомнилось, Резервное копирование и восстановление баз 1С на postgresql

Хотя какие-то тонкости с pg_restore я смутно припоминаю. Если в девственно пустую базу его поднимать - чего-то там одинэске не хватало. Так как это не бинарный бэкап а фактически скрипт, то не все что надо там создавалось по структуре. Поэтому я делал так - один раз создал пустую базу через сервер приложений и потом использовал ее как шаблон при создании новых пустых баз. Вот в такую пустую базу восстановление из pg_restore было беспроблемным.

(0) если обычный бэкап (не онлайн) - вообще никаких проблем бэкапить в винде программой pgdump.
Ну единственный момент: если будет производиться реструктуризация ИБ - бэкап может быть непригоден для восстановления.

примеры есть тут: Восстановление базы 1С из дампа PosgreeSQL

Если админ не вкурил ПГ, то:
1.на другом любом компе проверь что из бэкапов база разворачивается.
2.а базы-то обслуживаются? Без обслуживания скорость у версионников очень быстро начинает деградировать.

Всем спасибо, то что надо. Отправлю, пусть изучает.

Какая нужна лицензия или какой продукт нужно приобрести, чтобы появилась возможность скачать postgresql с пользовательского логина?
Комплект разработчика + мини-сервер почему-то не позволяют это сделать.

(15) https://releases.1c.ru/total - насколько сталкивался - там каталог Технологические дистрибутивы доступен весь полностью с любым действующим логином

1. Делаете архивирование журнала транзакций и гоните его на сервер резервного копирования (хранилище лога транзакций и актуального pg_basebackup).
2. На сервере горячего поднимаете реплику основной базы.
3. Сервер резервного копирования, Сервер горячего резерва, и Боевой сервер - это три разных физических сервера.

На практике эти три пункта позволяют
а) восстановить состояние БД вплоть до "за 1сек до до краха основного сервера".
б) восстановить БД на состояние позавчера до обеда.
в) В случае выхода из строя одного звена быстро восстановить работоспособносить и иметь при этом резервирование.
г) В случае выхода 2-х звеньев, просто восстановить БД.
д) сервер резервного копирования может быть удален и связан низкосростным каналом, у меня 10мбит.

4. Что касается pg_dumpa, то я создаю через консоль администрирования сервера пустую ИБ и для неё БД (потом ИБ удаляю, а БД оставляю). Если нужно восстановить резервную копию из pg_dump'а  то я это БД-заготовку копирую из консоли psql и уже в неё накатываю архив. Заготовку делаю для каждой версии платфомы.

5. pg_damp делаю автоматически, храню 10 ежедневных копий 10 ежемесячных (я параноик)

В сочетании с п.1-2 п.3 дает мне 99.99% уверености, что я смогу восстановить ИБ при любом раскладе.

Это все автоматизировано, и мониторится Zabbix'ом.

Минус только один, если придут автоматчики в офис, то никакая тетя Валя не успеет уничтожить всю черную бухгалтерию)

(16) Тоже так думал. Ни у кого не встречал недоступности postgresql для скачивания. Оказывается есть такое - мини-сервер можно купить, а скачать бесплатный postgresql нельзя.