Можно ли копировать PostgreSql с базами данных утилитой robocopy?

Question

[Илья]

Есть сервер PostgreSql, на нем вертится база 1С, нужно наладить резервное копирование базы и индексов, от прошлого админа остался батник которым он бэкапил всю эту кухню утилитой robocopy. Вот задаюсь вопросом насколько это безопасный и рабочий вариант, подойдет ли он как альтернатива pgdump, или стороннему софту для резервного копирования?

Comments

[Диана]

Странно, а чем же pgdump вас не устроил? Ведь скриптом вызвать pgdump и сливать дампы в любое место, а дальше хоть robocopy, хоть чем другим. ))

[Илья]

Кто же говорит что не устроил?) Pgdump - классика для postgre, просто увидел как с помощью robocopy, СУБД вместе с базами клонируют и решил уточнить насколько это эффективно.

[Диана]

)) ну я бы не стала так делать.. Думаю что штатный дамп намного безопаснее и корректнее! )

[shurshur]

PrilForReal, это крайне стрёмный способ бэкапа, так как для использования бэкапа потребуется база данных такой же версии с таким же конфигом и ещё не факт что нормально взлетит.

[Илья]

shurshur, Субд имеете ввиду?

[shurshur]

PrilForReal, под словом "база данных" иногда подразумевают саму базу с данными, а иногда софт, на которым она крутится (та самая "СУБД"). Да, иногда это может вызывать неопределённость, но крайне редко.

Answer 1

[Евгений]

БД - это файлы на диске. Выключите БД, скопируйте файлы, включите БД. Это называется холодный бэкап. И это самое надёжное, что вы можете придумать.

А вот если вы хотите горячий бэкап, без выключения БД, то это уже другая история.

Comments

[Сергей Горностаев]

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

[Евгений]

Сергей Горностаев, да что вы.
https://www.postgresql.org/docs/current/backup-fil...

[Илья]

То есть ночью например, когда в базе никто не работает, можно закрыть все незавершенные сеансы 1С и смело копировать все файлы базы? Еще такой нюанс: меня смутило что этим батником копировалась вся папка C:/Program Files/PostgreSQL и СУБД в это время работала, остается ли она неизменной пока нет активных пользователей? И возможно ли из такой копии развернуть СУБД с базами?

[Евгений]

PrilForReal, вот это правильные уточнения. Нет, так действительно нельзя. Даже если нет пользовательских сессий, мы не можем гарантировать, что файлы БД не изменяются. Я бы утверждал наоборот: они гарантированно изменяются, что не позволит получить конситентную копию. Только выключать экземпляр БД полностью и потом копировать.

Скорее всего в расписании было выключение БД, которое потом потерялось и осталось только копирование батником.

[Melkij]

Снимать файловый бекап при запущенной базе можно. Это делают все серьёзные утилиты бекапа postgresql: pgbackrest, wal-g, barman и прочие. Но для этого нужно соблюдать правила, которые требует сама база. К внимательному прочтению. Вот если у базы не попросить потребные данные для файлового бекапа - то это к приключениям и бекап выполнен неверно.

Только в случае постгреса эти файлы не переносимы, развернуть их на другом сервере не выйдет.

Ограниченно переносимы.
Развернуть на подходящем сервере выйдет. Это просто частный случай настройки потоковой репликации. Копируется именно физический PGDATA, а не логический дамп.
Основные ограничения: совпадение критичных для бинарной совместимости флагов компиляции. Сюрприз, даже другая аппаратная архитектура может не быть препятствием. Мы однажды с amd64 на arm64 перевозили базу физической репликацией даже.

[Илья]

Melkij, А акронис справится если снапшот всего раздела системного делать, там помимо ОС также и СУБД с базами и конфиги все серверные, считай двух зайцев одним снапшотом?

[Melkij]

смотря на сколько корректно атомарный снэпшот при этом получается (и не выключали ли fsync, как 1с-ники обожают себе отстреливать ноги). В идеальном случае получается crash recovery, аналогичный сбою по питанию. С точки зрения СУБД ситуация ожидаемая, но тестировать бекап на возможность восстановиться из него всё равно нужно будет.