LINUX.ORG.RU
ФорумAdmin

PostgreSQL и bacula: годится ли одно для другого?


0

1

Возникла у меня недобрая мысль, что использовать bacula для бэкапа PostgreSQL конечно можно, но только эта мега-крутая система запихивания файлов на ленточный накопитель не решит и 10-й части проблемы, потому что кроме тупо копирования в случае полного бэкапа и создания diff-патчей в случае инкрементального ничего толком не умеет. На мой взгляд, система бэкапа - тупое, унылое и бесполезное поделие, которое при отсутствии каких-то особо высоки запросов можно реализовать и парой скриптов на BASH, если эта самая система бэкапа умеет работать только на уровне файлов и ничего не знает о собственно приложениях, которые их создают.
Например, bacula могла бы, вообще говоря, знать о том, что PostgreSQL способен вести журнал изменений, на основании которого и можно было бы делать инкрементальный бэкап. Мало того, у разработчиков bacula наверное мозг бы вынесло начисто, если бы они задумались над тем, что SQL-формат pg_dump'а фактически бесполезен (если это залить потом psql'ем, в большинстве случаев будет туча ошибок и нерабочая база), а с бинарного формата нормально diff не снимешь: ведь файл может изменяться произвольным образом и при этом будет выглядеть, как совершенно другой, нежели неделю назад - и это при том, что фактически там 99% данных всё те же самые.

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

А как реализовали бэкап баз Postgres'а вы?

★★★★★

Мало того, у разработчиков bacula наверное мозг бы вынесло начисто, если бы они задумались над тем, что SQL-формат pg_dump'а фактически бесполезен (если это залить потом psql'ем, в большинстве случаев будет туча ошибок и нерабочая база)

Откуда инфа?

Deleted
()
Ответ на: комментарий от Deleted

Да очень просто: я пробовал так поступать с нашей базой, и бинарный дамп заливался отлично, а SQL-ный - создавал кривую базу из-за ошибок неких зависимостей (relations).

DRVTiny ★★★★★
() автор топика
Ответ на: комментарий от DRVTiny

Вероятно, у тебя радиус кривизны рук выше допустимых значений.

jessey
()
Ответ на: комментарий от Bragin

Ну копируй тогда xlog. Вполне себе бинарные дифы.

Судя по докам Postgres'а, так делать можно, хотя собственно конечная цель - восстановление из бэкапа, достигается весьма нетривиально в 8 неслабых таких шагов по инструкции (ведь целью бэкапа является именно restore, а не просто забивание дискового пространства чем-то гипотетически полезным, что часто на поверку оказывается мусором).

Вопрос скорее в том, что...

а) Неужели всё это реально каждый сисадмин пишет с нуля везде, где юзают Postgres?
б) Если (а) верно, что вообще дикость какая-то, то неужели ещё ни один из этих админов не выложил свои наработки в OpenSource, чтобы другие не трахали себе мозги этим и бэкапили одной командой на основании простенького конфига, а ресторили ещё проще и быстрее, чем бэкапили?
в) Есть подозрение, что большинство админов просто не заморачиваются над правильной политикой бэкапа, которая заключается в том, что копия самой базы должна делаться крайне редко, а бэкап обязан быть процентов на 80 инкрементальным (состоять из xlog'ов). Пункт (в) очень доходчиво объясняет (а) и (б)
г) Нахрена, простите, вообще нужна bacula, если она кроме тупого копирования файлов и запуска написанных пользователем скриптов, не умеет?. У bacula мега-понтовая документация и конфиги весьма впечатляют, но всё это в итоге сводится к откровенному «пшику»: нужно написать сотню-другую строк кода, чтобы это заработало в любой мало-мальски сложной инфраструктуре!

DRVTiny ★★★★★
() автор топика
Последнее исправление: DRVTiny (всего исправлений: 2)
Ответ на: комментарий от Deleted

pg_dump'ом с опцией не помню какой, plain text дающей на выходе. У нас ещё структура самой базы довольно интересная: 5 схем, 75 таблиц, сложные взаимосвязи между ними...

DRVTiny ★★★★★
() автор топика
Последнее исправление: DRVTiny (всего исправлений: 1)

А как реализовали бэкап баз Postgres'а вы?

Просто и топорно. Написал скрипт, который делает дамп, сжимает gzip'ом и заливает его на Amazon S3.

Alve ★★★★★
()
Ответ на: комментарий от DRVTiny

Не вижу ни каких проблем. Делаешь раз в неделю фулбекап бинарных данных, а потом копируй себе на здаровье xlog. Накотить xlog не разу не сложно. А местами даже быстрее чем востоноваливать из текста.

Хотя у меня и с pg_dump проблем не было не разу. Это вообще шатное средтво при переходе на новую ветку слоника. По моему ты в этом топике уже больше набил клавной чем требуется для реализации бэкапа бакулой.

Bragin
()
Ответ на: комментарий от Bragin

Хотя у меня и с pg_dump проблем не было не разу. Это вообще шатное средство при переходе на новую ветку слоника.

А оно умеет делать «патчи» (дифф-бэкапы)? Нет. Ну так и чего же тогда? Я делал backup на bacula. Ничего хорошего: делал pg_dump в один и тот же файл и бэкапил его. На самом деле это не вариант абсолютно.

DRVTiny ★★★★★
() автор топика

Задача бэкапа - восстановить данные, когда другими средствами их восстановить невозможно. Как правило, их приходится восстанавливать с нуля, и до того состояния, в каком была база в момент последнего бэкапа. В этом плане непонятно, чем могут помочь инкрементальные бэкапы. Вероятность возникновения ошибки больше, длительность восстановления - тоже больше, усилий - тоже больше.

SQL-формат pg_dump'а фактически бесполезен

У меня не было ни единого случая, чтобы база не восстановилась из SQL бэкапа, если база та же самая. Если у тебя какие-то проблемы, то надо указать версию pg и выложить схему, которая не заливается, это серьёзный баг. Вообще, SQL формат (в pg он называется plain) предназначен для того, чтобы можно было редактировать дамп. Он заливается куда медленнее, чем бинарный, поэтому его нежелательно использовать для бэкапов.
Вообще, начнем вот с чего: какая версия pg стоит? В девятке всё уже совсем хорошо.

UFO-man
()
Ответ на: комментарий от UFO-man

Ещё задачи бэкапа - минимизировать место, занимаемое этим бэкапом, минимизировать влияние процесса бэкапа на рабочий процесс и минимизировать потерянные данные (между последним бэкапом и аварией). Инкрементальные бэкапы улучшают эти показатели.

Legioner ★★★★★
()
Ответ на: комментарий от DRVTiny

Не вижу чем оно отличается от моего предложения.

Я вот тут подумал. Ведь в утилите cat нет встроенного браузера. По моему дикость какая-та.

Bragin
()
Ответ на: комментарий от Bragin

Bragin, система бэкапа всё-таки занимается резервным копированием данных. Если bacula будет резервно копировать
PG_DATA=/var/lib/postgresql/%VERSION%, то из такого бэкапа восстановиться будет если и возможно, то проблематично... Хотя xlog'и там есть и вроде бы есть какой-то хитрый трюк с созданием пустого файла recovery.conf в PG_DATA...

Может быть, всё не так плохо и действительно можно на файловом уровне делать бэкап постгреса и не заморачиваться над консистентностью, потому что она будет обеспечена откатом по xlog'ам?

Хотя даже если и так, то не будут ли дифф-бэкапы слишком большими из-за того, что данные в бинарном виде лежат в PG_DATA?

P.S. Я на самом деле с нормальным бэкапом постгреса раньше дела не имел, так что мне скорее интересно, как сделать правильно, нежели покритиковать что бы то ни было.

DRVTiny ★★★★★
() автор топика
Ответ на: комментарий от UFO-man

У меня не было ни единого случая, чтобы база не восстановилась из SQL бэкапа, если база та же самая.

Только ведь неспроста pg_restore не работает с plain форматом? ;)

DRVTiny ★★★★★
() автор топика
Ответ на: комментарий от DRVTiny

Bragin

Bacul-a хорошо делает что она должна. Тебе всегото нужно перед стартом запускать скрипт через ClientRunBeforeJob и ClientRunAfterJob. Формировать все что нужно а дальше уже бэкапить. Если тебе нужны бинарные данные и инкрименты к ним, то делай как я говарил выше.

Например раз в месяц. Для задания фул-бэкпа ClientRunBeforeJob с примерно с таким скритом

psql -c «SELECT pg_start_backup('label', true)»
rsync -C -a -c --delete --exclude postgresql.conf --exclude postmaster.pid \ --exclude postmaster.opts --exclude pg_log \ --exclude recovery.conf --exclude recovery.done \ /var/lib/postgresql/9.1/main/ /tmp/bacula/pg
psql -c «SELECT pg_stop_backup()»


ClientRunAfterJob rm -rf /tmp/bacula/pg/
дальше тебе нужнен архив pg_xlog В postgresql.conf archive_mode = on # allows archiving to be done archive_command = 'cp %p /YOUR_ARHIVE_DIR/%f'
А дальше архивируй инкрементально /YOUR_ARHIVE_DIR/
В итоге ты получаешь бинарный инкрементальный бэкап, реализовать все это займет меньше времени которого ты потратил на ругань bacul-ы.

Bragin
()
Ответ на: комментарий от DRVTiny

Нахрена, простите, вообще нужна bacula, если она кроме тупого копирования файлов и запуска написанных пользователем скриптов, не умеет?.

А что, кроме этого, должна делать система бекапа?

sin_a ★★★★★
()
Ответ на: комментарий от sin_a

А что, кроме этого, должна делать система бекапа?

Система бэкапа без встроенного skype неполноцена.

Bragin
()
Ответ на: комментарий от DRVTiny

Только ведь неспроста pg_restore не работает с plain форматом? ;)

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

AnDoR ★★★★★
()

система бэкапа - тупое, унылое и бесполезное поделие, которое при отсутствии каких-то особо высоки запросов можно реализовать и парой скриптов на BASH

в простейшем случае да. А когда ты захочешь всякие инкрементальные бэкапы или умение работать с приложениями (в частности с базами данных) то эти пара скриптов превращаются в монстра.

SQL-формат pg_dump'а фактически бесполезен (если это залить потом psql'ем, в большинстве случаев будет туча ошибок и нерабочая база)

омг, вы что-то делаете не так. Кстати, а это не ваш случай? «Important: If your database schema relies on OIDs (for instance, as foreign keys) you must instruct pg_dump to dump the OIDs as well. To do this, use the -o command-line option.»

Короче, твой вариант это прочитать http://www.postgresql.org/docs/9.2/static/backup.html . Ну и если уж захотелось скрестить с бакулой то поискать как это прикручивали к бакуле.

Хотя я бакулу не люблю. Для тупой бэкапилки файлов слишком громоздка, хрупка и наворочена. Я юзаю rsnapshot.

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

всякие инкрементальные бэкапы или умение работать с приложениями
умение работать с приложениями

Bacula НЕ умеет. Тчк.

DRVTiny ★★★★★
() автор топика
Ответ на: комментарий от sin_a

А что, кроме этого, должна делать система бекапа?

Иметь модульную структуру (1 целевое приложение = 1 модуль) С помощью модулей иметь «интерфейс» к целевым приложениям, позволяющий делать то, что нужно, а не копирование файликов, которое как раз в 9 случаях из 10-ти as is не подходит.

Проще говоря, если ПО для бэкапа умеет работать только с файлами, то пусть и называется «ПО для бэкапа файловой системы».

DRVTiny ★★★★★
() автор топика
Ответ на: комментарий от DRVTiny

если ПО для бэкапа умеет работать только с файлами, то пусть и называется «ПО для бэкапа файловой системы»

Bacula is relatively easy to use and efficient, while offering many advanced storage management features that make it easy to find and recover lost or damaged files.

Jaga ★★★
()
Ответ на: комментарий от true_admin

А кто умеет?

ArcServe умеет, Tivoli много чего умеет и с DB2/Oracle'ом дружит. Просто файлики имхо можно и в SVN хранить, всё понятнее и доступнее, чем гипертрофированный tar с выносящей мозг, но морально и физически устаревшей многосвязной клиент-серверной архитектурой.

DRVTiny ★★★★★
() автор топика
Ответ на: комментарий от sin_a

А что можно бекапить кроме файлов?

Вопрос в том, что на момент «хочу бэкапить» НУЖНЫХ файлов как правило нет, нужно что-то сделать, и чаще всего весьма немало, чтобы файлики в нужном состоянии появились. А для этого нужны хэндлеры на стороне бэкап-решения, коих в к бакуле не прилагается, а предполагается, что они каждый раз должны наново писаться, что есть пионерство какое-то.

DRVTiny ★★★★★
() автор топика
Ответ на: комментарий от DRVTiny

ArcServe умеет

то что 3гига в free trial весит? Неплохо для «самопальных bash скриптов». Кстати, а как именно оно бэкапит постгрес?

Просто файлики имхо можно и в SVN хранить

мне парочку ТБ файликов в svn, пожалуйста.

true_admin ★★★★★
()
Ответ на: комментарий от sin_a

Как бы к любому динамически дописываемому бинарному формату. Собственно, причём здесь вообще SQL? Вон OpenLDAP возьмите или какие-нибудь чудо-логи репликации. Нельзя просто так на ходу выдёргивать у приложения файлы и наивно полагать, что оно потом их за милу душу схватает. Нужно найти общий язык с приложением, а этого bacula и близко не умеет. Примерно по той же причине меня вымораживает DRBD: в стандартной поставке идут скрипты «так, для примеру просто, в продакшн другие быть должны», но при этом вся логика восстановления после split-brain лежит на этих скриптах. RedHat бы порвали на тряпки, если бы их Gluster предлагал высасывать из пальца какие-то башовые скрипты для того, что он вообще-то сам обязан уметь делать (по возможности продолжать корректно работать после падения одной ноды или нескольких).

DRVTiny ★★★★★
() автор топика
Ответ на: комментарий от DRVTiny

SQL здесь при том, что с него начался вопрос. И для него, насколько мне известно, есть свои утилиты сброса дампов, у каждого свой. И было бы странно ожидать от посторонней программы хорошо делать дамп базы данных, вместо того что бы воспользоваться штатной утилитой.

Для ldap, полагаю, тоже есть аналогичная утилита. Если он тоже не позволяет скопировать файлы.

Насколько мне известно, это и называется unix way. Каждая программа умеет делать только одно, но делает это хорошо.

sin_a ★★★★★
()
Ответ на: комментарий от sin_a

Насколько мне известно, это и называется unix way.

Это не UNIX-way, это случай, когда программа (bacula) выдаёт себя за то, чем не является. На деле же такая вещь должна включать в себя подключаемый модуль для работы с Postgres (написанный, возможно, посторонними людьми), который будет уметь делать копирование полное всей PG_DATA, копирование частое WAL-данных + конечно восстанавливаться из этого должна уметь. А сейчас bacula - это что-то наподобие ядра ОС, которое даёт тебе прямой доступ к in/out в порты ввода-вывода устройств, но не имеет архитектуры для подключения модулей-драйверов устройств. Хочешь работать с жёстким диском? Учи как устроен SATA, как работает DMA и всё прочее. Очень удобно!

DRVTiny ★★★★★
() автор топика
Ответ на: комментарий от DRVTiny

На деле же такая вещь должна включать в себя подключаемый модуль для работы с Postgres (написанный, возможно, посторонними людьми)

А что не так с pgdump?

sin_a ★★★★★
()
Ответ на: комментарий от DRVTiny

Небольшие базы можно бекапить каждый день целиком, а большие базы никто не бекапит потому что они либо разшардены с резервированием либо у них есть один или несколько hot standby.

anonymous
()
22 апреля 2013 г.
Ответ на: комментарий от DRVTiny

ArcServe умеет, Tivoli много чего умеет и с DB2/Oracle'ом дружит.

Ну вы сравнили. Коммерческая версия бакулы тоже имеет плагин для бекапа постгреса, он весьма гибкий, умеет правильно делать как бинарные бекапы, так и дампы. Работает надежно и удобно с огромными терабайтными базами и высокой загрузкой. Также там есть и Oracle и MSSql. А вот community версией бакулы бекапить постгрес проблематично, если он большой и под нагрузкой. С небольшими базами и с небольшой нагрузкой проблем никаких нет - на вики бакулы расписано несколько методов - все они легко прикручиваются и нормально работают. Кстати, смотрел на Tivoli - там плагин сторонний, показался более громоздким, проблемным, умеет только бинарные бекапы делать. Ну и про цену в сравнении с коммерческой бакулой просто помолчим - там по-моему в десятки раз отличается не в пользу тиволи.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.