Comments 16
Ребята, кто использовал и pgbarman, и pgbackrest. поделитесь опытом, пожалуйста, что из них лучше и какие нюансы.
пробовали, основываются на одном м том же. В итого бекапим только pg-basebackup
четного инкриминтального в постгресе нет и вроде не предвидится.
а как же wal-g?
На странице проекта в github есть ссылка что wal-g может использоваться и для MySQL, если это так — круто!
Это все на основе WAL, т.е. ты обязан перегонять все wal, что в моем случае проблематично, во первых за день 50% таблиц меняются, во вторых хотелось бы бекапить далеко не все.
Т.е. в postgresql ты обязан все логи передавать на какой-то временный быстрый в плане дисков сервер
Поправьте если я ошибаюсь
Т.е. в postgresql ты обязан все логи передавать на какой-то временный быстрый в плане дисков сервер
Поправьте если я ошибаюсь
Инкрементального нет в силу того что есть гораздо более интересная нативная вещь — непрерывный бэкап (continuous backup), с возможностью отката на любую транзакцию между последним base backup и текущим состоянием. barman это умеет, как и уже упомянутый раньше wal-g.
Есть даже покруче возможность — держать рядом сервер с задержкой транзакций (доступный для выполнения запросов на чтение), который будет отставать от мастера на заданное время.
Есть даже покруче возможность — держать рядом сервер с задержкой транзакций (доступный для выполнения запросов на чтение), который будет отставать от мастера на заданное время.
А в каких кейсах требуется такое заданное отставание?
Круто, но крайне избыточно, если мне нужно иметь pg_basebackup по сути раз в две недели и нет желания плодить сложно управляемые сущности и иметь спец админа для этого и громадные быстрые диски, вместо raid6 на HDD…
И да желательно все в графики с далее-далее-готово, ну понимаете ли так…
Pg backup очень медлителен
Pg basebackup подымается долго, да и 1ну таблицу из него вынимать так себе удовольствие
И да желательно все в графики с далее-далее-готово, ну понимаете ли так…
Pg backup очень медлителен
Pg basebackup подымается долго, да и 1ну таблицу из него вынимать так себе удовольствие
На самом деле, в этом нет ничего сложного — максимум четыре часа на чтение доков и одноразовую настройку с тестами осилит любой кто не боится командной строки, спецадмин или суперскиллы для этого не нужны.
Поскольку почти всё обеспечивается нативно самим Postgres, всё остальное лишь удобная обвязка вокруг этого.
Насчёт дисков… не скажу что нужно что-то супер-пупер. На примере одного из своих проектов — небольшая база около 100 гиг, обновляется примерно на 10% ежедневно, непрервные бэкапы за последние 5 дней (с базовым каждый день и возможностью отката в к любой транзакции в этом интервале) занимают около 250 гиг (бэкап на NAS с ZFS — за счёт компрессии и дедупликации получается такая экономия, сетка 1 Gbps), один базовый бэкап выполняется около 45 минут.
Поскольку почти всё обеспечивается нативно самим Postgres, всё остальное лишь удобная обвязка вокруг этого.
Насчёт дисков… не скажу что нужно что-то супер-пупер. На примере одного из своих проектов — небольшая база около 100 гиг, обновляется примерно на 10% ежедневно, непрервные бэкапы за последние 5 дней (с базовым каждый день и возможностью отката в к любой транзакции в этом интервале) занимают около 250 гиг (бэкап на NAS с ZFS — за счёт компрессии и дедупликации получается такая экономия, сетка 1 Gbps), один базовый бэкап выполняется около 45 минут.
Очередная какая то каша из топора. Пытаюсь понять нужен ли этот pgbackrest. Как я понял он сам wal-файлы мерджит при восстановлении, раз у топикастора не указана команда restore_command, что очень стремно. В чем его преимущество? Инкрементные бэкапы? Так wal-ы по факту и есть инкрементные бэкапы. То что он якобы использует все ядра при компрессии, нет не использует. Равномерной загрузки нет, да и не очень то это надо во время бэкапа все ядра съесть. Постоянно вылетает с ошибкой даже при полном бэкапе ERROR: [082]: WAL segment 000000290000001A0000008A was not archived before the 60000ms timeout. если у вас нет записи в базу и в течении 60сек не прилетел wal. Это маразм! Причем этот ишю еще с 17-го года висит на гитхабе. В общем нахрен это рукотворное творение я наигрался. В топку его, в прод не потяну. Нативная pg_basebackup раз в сутки и архив wal-ов за n-дней.
И по поводу скорости:
sudo -u postgres time pgbackrest --log-level-console=info --stanza=main --type=full backup
10.07user 6.71system 5:28.34elapsed
pg_basebackup --checkpoint=fast -P -Xstream -z -Ft -h 10.103.10.200 -p15432 -U repl -D /1
real 2m18.864s
user 2m13.011s
sys 0m5.643s
ПГ 12, утиль 2.33 сеть 2х10Гбит в бонде.
И по поводу скорости:
sudo -u postgres time pgbackrest --log-level-console=info --stanza=main --type=full backup
10.07user 6.71system 5:28.34elapsed
pg_basebackup --checkpoint=fast -P -Xstream -z -Ft -h 10.103.10.200 -p15432 -U repl -D /1
real 2m18.864s
user 2m13.011s
sys 0m5.643s
ПГ 12, утиль 2.33 сеть 2х10Гбит в бонде.
для инкрементальных бэкапов мне показался проще pg_rman, да и зависимостей у него меньше
Пакет pgbackrest для Debian (и для некоторых других ОС) имеется в официальном репозитории PostgreSQL www.postgresql.org/download/linux/debian.
Единственная, небольшая, проблема данного репозитория, там нет истории версий, как только выходит новая версия, старя исчезает из репозитория.
На хосте-репозиториии pgbackrest (т.е. на том хосте где хранятся резервные копии) и на БД сервере, версии pgbackrest должны в точности совпадать, в противном случае резервное копирование и даже архвиция wal файлов, скорее всего, завершаться с ошибкой. Поэтому есть все основания делать apt-pinning во избежание непредвиденного обновления pgbackrest где-либо.
Единственная, небольшая, проблема данного репозитория, там нет истории версий, как только выходит новая версия, старя исчезает из репозитория.
На хосте-репозиториии pgbackrest (т.е. на том хосте где хранятся резервные копии) и на БД сервере, версии pgbackrest должны в точности совпадать, в противном случае резервное копирование и даже архвиция wal файлов, скорее всего, завершаться с ошибкой. Поэтому есть все основания делать apt-pinning во избежание непредвиденного обновления pgbackrest где-либо.
>> sudo cp /build/pgbackrest-release-2.18/src/pgbackrest /usr/bin
пожалуйста, не делайте так, возьмите хотя бы checkinstall (для сборки пакета deb), если с dpkg-deb разбираться нет времени.
пожалуйста, не делайте так, возьмите хотя бы checkinstall (для сборки пакета deb), если с dpkg-deb разбираться нет времени.
Sign up to leave a comment.
Инкрементальные бэкапы postgresql с pgbackrest — курс молодого бойца от разработчика