UMGUM.COM (лучше) 

Bacula + PostgreSQL backup ( Резервное копирование баз PostgreSQL с помощью Bacula. )

12 ноября 2010  (обновлено 29 декабря 2014)

OS: Linux Debian Lenny/Squeeze/Wheezy.
Application: Bacula v.3.2/v.5.2.

Резервирование "баз данных", например MySQL, PostgreSQL, MSQL с помощью Bacula возможно производить с помощью встроенной возможности Bacula исполнения произвольных "скриптов" на стороне сервера или клиента до и после процедуры непосредственного резервного копирования.

Всё элементарно: пишем скрипт, осуществляющий "дамп" базы данных на стороне клиента в целевую директорию, в общем порядке резервируем получившийся файл, после завершения операции резервирования удаляем временный файл "дампа".

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


Для PostgreSQL резервное копирование и применение данных стандартно осуществляется утилитами создания "дампа", например, входящей в состав комплекта программного обеспечения сервера PostgreSQL утилитой pg_dump. Необходимо оперировать от имени пользователя, который имеет право чтения всех таблиц на сервере.

В MySQL в консоли очень просто предоставить произвольному пользователю определённые ограниченные права доступа ко всем объектам СУБД используя символ "*" как шаблон. Сделать это так же просто в PostgreSQL я, как ни бился, не смог. Можно применить скрипт, перебирающий названия имеющихся сущностей в заданном диапазоне и индивидуально назначающий для них особые права доступа, но нашем случае, тогда, когда клиент Bacula работает на компьютере с правами суперпользователя, проще создавать "дамп" базы от имени пользователя "postgres", изначально имеющего полный доступ ко всем ресурсам.

Вносим пользователя "postgres" в список доверенных и не требующих авторизации. Делается это с помощью редактирования строки описывающей метод авторизации пользователя в файле "/etc/postgresql/8.3/main/pg_hda.conf":

# cat /etc/postgresql/8.3/main/pg_hba.conf

....
local  all  postgres  trust
....

Заставим Postgres перечитать свои конфигурационные файлы для применения изменений:

# /etc/init.d/postgresql-8.3 reload

Создаем скрипт, непосредственно осуществляющий создание резервной копии:

# mkdir -p /etc/bacula/custom
# touch /etc/bacula/custom/make-dump-pgsql.sh
# chmod ugo+x /etc/bacula/custom/make-dump-pgsql.sh

# cat /etc/bacula/custom/make-dump-pgsql.sh

#!/bin/bash

DATE=`date +"%Y-%m-%d %H:%M:%S"`
USER="postgres"
RESULT="/tmp/pgsqldump.tmp.sql"
LOG="/var/log/pgsqldump.log"

# Создаём файл, куда будут записываться данные (pg_dump почему-то сам его не создаёт)
touch ${RESULT}

pg_dumpall --verbose --clean --inserts --ignore-version --file="${RESULT}" --username="${USER}" 2>> ${LOG}

exit 0

Где опции pg_dumpall:

"--verbose" - указание осуществлять детализированный вывод;
"--clean" - указание зачищать базу перед вставкой данных;
"--inserts" - применяем режим создания "дампа" с командой insert на каждую строку вместо более компактного режима по умолчанию с одним insert на всю таблицу;
"--ignore-version" - игнорировать разницу в версиях программного обеспечения PostgreSQL.

Теперь, после того, как мы убедимся в работоспособности скрипта на стороне клиента, применим его со стороны сервер Bacula. В конфигурациионном файле "/etc/bacula/bacula-dir.conf" в конфигурации задания ("Job") соответствующего клиента добавим указания на запуск скрипта предварительного создания "дампа" баз данных и команды удаления временного файла "дампа" после исполнение резервного копирования:

# cat /etc/bacula/bacula-dir.conf

....
Job {
  Name = "job-backup-test.domain.local"
  Type = Backup
  ....
  ClientRunBeforeJob = "/etc/bacula/custom/make-dump-pgsql.sh"
  ClientRunAfterJob = "/bin/rm -rf /tmp/pgsqldump.tmp.sql"
  ....

В описании области резервирования указываем файл "дампа":

# cat /etc/bacula/bacula-dir.conf

....
FileSet {
  Name = "file-set-test.domain.local"
  Include {
....
    File = "/etc"
    File = "/home"
    File = "/tmp/pgsqldump.tmp.sql"
....

Вот и всё. Должен заметить то, что создание "дампа" для PostgreSQL по моим наблюдениям более ресурсоёмкая процедура, чем для MySQL и делать это нужно ночью.

А вообще, для тех, кто не бросил чтение и дошёл до конца, замечу: регулярное (раз в день или два дня) резервирование объёмных (более гигабайта) баз данных с помощью создания полного "дампа" - глупость. Наиболее оптимально применение резервирования так называемых "бинарных" журналов операций (располагающихся в директориях "$PGDATA/pg_сlog" и "$PGDATA/pg_xlog"). Тогда, при крахе части или всех данных, проще поднять полные журналы операций и восстановить по ним базы.


Заметки и комментарии к публикации:


Оставьте свой комментарий ( выразите мнение относительно публикации, поделитесь дополнительными сведениями или укажите на ошибку )