Комментарии 32
дамп - это вроде не бэкап?
Статья-то может даже и полезна будет, но "дешего", серьезно? Налего, напраго?
pg_dump не бэкап. Есть неиллюзорная вероятность потерять данные во время снятия дампа.
я думаю многие (особенно новички и админы локалхоста) были бы благодарны за ссылку на статью где внятно и простым языком описана разница, а главное рассказано почему есть вероятность просрать данные
Если кратко, то pg_basebackup позволяет обеспечить восстановление базы на момент последней успешной транзакции(перед запуском pg_basebackup), а в свою очередь pg_dump только на момент завершения, т.е. если во время работы pg_dump создастся таблица и заполнится данными, то есть вероятность что она не попадет в дамп.
Есть именно бэкап бинарный. Но нужно устанавливать более полный режим журнала предзаписи (WAL). Для дампа достаточно minimal, для бинарного бэкапа нужно ставить hot_standby
WAL мне на самом деле не понравился тем что пишет очень жирные журналы, и нужно гарантировать что кто будет их успешно очищать. Однажды за 3 дня журналы стали больше базы в 15 раз. Производительность конечно выше, но тут скорее про что то быстрое и простое в настройке.
В настройках можно выставить количество и объём хранимых журналов. И постгрес сам всё будет подчищать. В этом случае проблема с объёмом журналов может возникнуть только в том случае, если вы настроите реплику со слотом репликации и эта реплика перестанет работать (читай: тянуть к себе wal-ы)
Если система хоть как то нагружена то тут конечно стоит использовать более продвинутые подходы к бэкапу.
У меня на самом деле цели были более прагматичные, я использую бесплатное облако на оракле, они дают вполне неплохое облако в бесплатно пользование размером 4 ядра 24 гига за 0р в месяц, но ядра армовские, некоторые готовые решения просто не имеют пакетов под арм. А мне бы хотелось быть увереным что моя не нагруженная и не очень большая база делает резервные копии и сохраняется где то отдельно от бесплатного оракла.
Ротация wal довольно легко настраивается. И, по-моему, по умолчанию ненужные wal автоматически удаляются. Ненужными они становятся после checkpoint и записи изменений на диск. Держать wal может слот репликации или параметр wal_keep_segments.
Либо у Вас checkpoint не выполнялся, что менее вероятно.
Помню как то настраивал реплику, для какого то сервиса, он по идеи должен был ходить и очищать wal, могу путаться в терминологии, но суть в том, что как то профакапали с этим сервисом, и он не ходил за данными, в и итоге 3 гиговая база разролась до 45г за пару дней и просто закончилось место. Собственно поэтому и избегаю его, так как нужды в производительности нет. А лишние настройки делать не вижу для текущей задачи.
Ооо, спасибо за уточнение, я думал это синонимы по сути. Встроенная утилита внушала доверие и всегда пользовался ей для снятия резервных копий.
А еще можно скриптом стягивать дампики с разных серверов и разворачивать у себя на тестовом сервере.
Средства для бекапа ПГ рассмотрены вот здесь: https://ru-postgres.livejournal.com/66359.html
Предложенное же решение - это рукоблудие и скриптоложество, полезное только автору для набить руку в bash-е, не более того.
https://postgrespro.ru/docs/postgrespro/10/app-pgdump
Есть ключик -F format. Лучше указать формат custom.
Не
shmod +x pg_backup.bashА
сhmod +x pg_backup.bash
Хочу я посмотреть сколько ваш скрипт будет работать на базе хотя бы гигов в 100.
Как уже отметили в комментариях, дамп не есть бэкап. Тут же возникает вопросы. А где пользователи postgresql? Почему дампим только одну базу?
Недавно на YouTube канале компании Postgres Professional была размещена запись вебинара по системам именно бэкапа кластеров postgresql. Рекомендую ознакомиться, но там английский.
Откройте для себя pg_probackup - наверное лучший на сегодня инструмент для бэкапа postgresql.
У меня посложней будет: перебор всех БД на постгре, для каждой делается бэкап (на лету архивируется), который копируется на внешний диск (монтируется по ходу) и другой сервер, который находится в другой части города
Автоматизированные бэкапы postgresql