Установка Bacula + PostgreSQL на Centos 7

Bacula — кроссплатформенное клиент-серверное программное обеспечение, позволяющее управлять резервным копированием, восстановлением, и проверкой данных по сети для компьютеров и операционных систем различных типов.

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

Создаем файл с содержимым:

Далее нам надо отключить SELinux, т.к. судя по ответу разработчиков в релизной на сегодняшней день версии 9.4.4 они еще не допилили связь Bacula и SELinux

Установка и настройка PostgreSQL 10

Добавляем репозиторий PostgreSQL 10

Устанавливаем PostgreSQL 10, инициализируем БД сервер

Запускаем сервис и добавляем его в автозагрузк

Создаем пользователя PostgreSQL «bacula» и задаем ему пароль «bacula»

Настраиваем PostgreSQL
Раскоментируем строку listen_addresses

Настраиваем подключения к базе

Установка Bacula 9.4.4

Выполняем скрипты, для корректной работы Bacula с PostgreSQL

Делаем симлинки для удобства управления, запускаем службу и смотрим статус

Создаем директории для бэкапов / ресторов (к ним можно примонтировать NFS-хранилище)

Создаем директории для логов

Теперь надо отредактировать конфиги Bacula, прописать наш пароль

Настройка ресурса Director

Найдите ресурс Director и настройте его для прослушивания ip-адреса. Для этого добавьте в раздел строку DirAddress.

Настройка локальных задач

Задачи Bacula (job) выполняют резервное копирование и восстановление данных. Ресурсы задания – это подробные данные о том или ином задании: имя клиента, файлы для бэкапа или восстановления (FileSet) и многое другое.
Найдите ресурс Job с именем BackupClient1. Замените значение в строке Name именем BackupLocalFiles.

Затем найдите ресурс Job с именем RestoreFiles. В строке Name укажите имя RestoreLocalFiles, а в строке Where – каталог /bacula/restore.

Файлы для бэкапа

FileSet определяет список файлов и каталогов, которые нужно включить или исключить из резервного копирования.
Найдите ресурс FileSet по имени Full Set (под комментарием # List of files to be backed up). Сюда нужно внести следующие изменения:

• Добавить сжатие gzip.
• В разделе Include заменить /usr/sbin в строке File на /.
• В конце раздела Exclude добавить строку File = /bacula.

Настройка каталога

Ресурс Catalog определяет БД, к которой будет подключаться Director.
Найдите ресурс Catalog по имени MyCatalog (под комментарием Generic catalog service). Обновите значение dbpassword и укажите пароль пользователя MySQL/PostgeSQL bacula.
Еще надо добавить адрес, иначе при проверке (sudo bacula-dir -tc /opt/bacula/etc/bacula-dir.conf) нет конекта к базе

Настройка пула

Ресурс Pool определяет набор хранилищ, используемых Bacula для записи резервных копий. В данном случае в качестве томов хранения используются файлы. Обновите метки, чтобы локальные резервные копии были правильно помечены.

Сохраните и закройте файл. Настройка компонента Bacula Director завершена.

Настройка Storage Daemon

Надо настроить Storage Daemon, чтобы система Bacula понимала, где хранить файлы.

Откройте конфигурационный файл SD.

Настройка устройства хранения

Во всех файлах надо поменять пароль на наш «bacula«

Резервное копирование PostgreSQL. Бэкап базы PostgreSQL. Восстановление PostgreSQL.

Резервное копирование баз данных PostgreSQL. Как сделать автоматический бэкап PostgreSQL с помощью Bacula? Восстановление PostgreSQL.

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

Бэкап PostgreSQL с помощью Bacula имеет широкую применимость. Bacula Enterprise Edition позволяет производить бэкап PostgreSQL на Windows, поскольку имеет соответствующий агент. С помощью данной утилиты также возможно резервное копирование базы 1С на PostgreSQL.

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

Ключевые преимущества резервного копирования и восстановления PostgreSQL с Bacula:

• Возможность создания бэкапов и восстановления базы PostgreSQL с помощью дампов, а также поддержка технологии восстановления PostgreSQL до заданной контрольной точки (PITR)
• В режиме восстановления PostegreSQL до заданной контрольной точки (PITR), утилита поддерживает создание как инкрементальных, так и дифференциальных бэкапов PostgreSQL
• Утилита для бэкапа PostgreSQL автоматически запускает процедуру резервного копирования важной информации, такой как информация о конфигурации БД, определения пользователей, или табличные пространства
• Резервное копирование PostgreSQL работает с базами 1С

Как сделать бэкап PostgreSQL: PITR или Dump?

Custom	Dump	PITR
Возможность восстанавливать отдельные объекты PostgreSQL (таблица, схема )	Да	Нет	Нет
Скорость резервного копирования PostgreSQL	Медленно	Медленно	Быстро
Скорость восстановления PostgreSQL	Медленно	Очень Медленно	Быстро
Размер бэкапа PostgreSQL	Маленькая	Маленькая	Большая
Возможность восстановления PostgreSQL в любой точке времени	Нет	Нет	Да
Инкриментальные/Дифференциальные резервные копии PostgreSQL	Нет	Нет	Да
Резервное копирование PostgreSQL без остановки базы данных	Да	Да	Да
Консистентность бэкапа PostgreSQL	Да	Да	Да
Возможность восстановления на предыдущую версию PostgreSQL	Нет	Да	Да
Возможность восстановления на более новую версию PostgreSQL	Да	Да	Нет

Чаще всего режимы резервного копирования баз PostgreSQL через Dump и PITR комбинируют.

Уровни резервного копирования PostgreSQL в PITR

Когда при бэкапе базы данных PostgreSQL используется режим PITR, при разных уровнях копирования (инкрементальный, дифференциальный, полный) будут выполнены следующие действия:

• При полном резервном копировании базы PostgreSQL плагин сделает полную резервную копию директории data и всех WAL файлов, которые есть на данный момент;
• При инкрементальном резервном копировании PostgreSQL будет переведен на новый WAL файл и будут сделаны резервные копии всех WAL файлов, которые были созданы с момента последнего резервного копирования баз данных PostgreSQL
• При дифференциальном бэкапе PostgreSQL будет сделана резервная копия всех WAL файлов и файлов data с момента последнего бэкапа PostgreSQL

Резервное копирование PostgreSQL в режиме Dump

Плагин для резервного копирования баз PostgreSQL генерирует следующие файлы в резервной копии для одной базы “test”:

Файл	Контекст	Коммент
roles.sql	Глобальный	Список всех пользователей, их паролей и остальных опция
postgresql.conf	Глобальный	PostgreSQL конфигурация кластера
pg_hba.conf	Глобальный	Конфигурация подключений клиентов
pg_ident.conf	Глобальный	Конфигурация подключений клиентов
tablespaces.sql	Глобальный	Конфигураця TableSpace
createdb.sql	База данных	Скрипт создания базы данных
schema.sql	База данных	Схема Базы данных
data.sqlc	База данных	Дамп базы данных в формате “custom”(содержит все, что необходимо для восстановления)
data.sql	База данных	Резервная копия база данных в формате dump

Автоматическое резервное копирование баз PostgreSQL доступно на всех 32/64-разрядных платформах Linux:

• CentOS5/6/7
• Redhat 5/6/7
• Ubuntu LTS
• Debian Squeeze
• Suse 11

Резервное копирование PostgreSQL запускается вместе с ПО Bacula Enterprise версии 6.0.6 или выше и поддерживает резервное копирование БД PostgreSQL версий 8.x, 9.0.x и 9.1.x..

Настройка Bacula 9 + Baculum 9 для PostgreSQL 9.6

Содержание

Установка PostgreSQL [ править ]

Установим PostgreSQL версии 9.6:
Для этого на сервере выполним команду:

Запустим сервис и добавим его в автозагрузку.

Включение службы по умолчанию:

Настройка PostgreSQL [ править ]

Настройка журналов WAL [ править ]

Для работы с Bacula на сервере PostgreSQL должно быть настроено онлайн резервирование (PITR): Если в настройках сервера включено ведение журналов упреждающей записи (WAL), то появляется возможность резервного копирования на уровне файловой системы с копированием журналов. В этом случае при сбое мы можем восстановить базу от контрольной точки до произвольного момента времени, после контрольной точки, с помощью файлов журналов. Подробнее об этом можно почитать здесь
Для того, чтобы PostgreSQL начал писать файлы журналов необходимо изменить конфигурационный файл сервера /var/lib/pgsql/data/postgresql.conf следующим образом:

archive_command — это команда выполняемая сервером над журналом который надо архивировать. %p заменяется полным путем к файлу, %f заменяется именем файла. Простейшая команда это ‘test ! -f /mnt/server/archivedir/%f && cp %p /mnt/server/archivedir/%f’ она проверяет не был ли файл уже архивирован, и если не был то копирует его в каталог /mnt/server/archivedir/
Создадим каталог для архивных журналов и установим нужные права:

Также создадим каталог для нашего скрипта архивирования журналов:

Рассмотрим файл /var/lib/pgsql/bin/copy_wal.sh

Скрипт проверяет состояния резервного копирования журналов и архивирует журналы в каталог /var/lib/pgsql/wals , все свои действия он пишет в /var/lib/pgsql/wals/wal-c-log.log
Установим нужные права на скрипт:

Теперь перезапустим сервер базы данных:

Со временем в каталоге /var/lib/pgsql/wals будут появляться файлы вида:

Если они появляются значит журналирование настроены правильно.

Онлайн резервное копирование [ править ]

Используя Low Level API [ править ]

Использование низкоуровневого API подразумевает следующие шаги:
1. Убедитесь что журналирование включено и работает
2. Подключитесь к базе от имени суперпользователя:

Для начала резервного копирования выполните следующий запрос:

Этот запрос может выполняться длительное время, так как создается контрольная точка и минимизируется влияние на текущие операции.
Чтобы начать резервное копирование как можно быстрее (используя все ресурсы для создания контрольной точки) выполните команду с параметром true :

Пример вывода команды pg_start_backup:

3. Теперь можно делать файловое резервное копирование каталога с базой данных ( /var/lib/pgsql/data ) любыми удобными инструментами (cp, rsync и т.д.)
4. После окончания резервирования подключитесь к базе снова и введите команду:

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

5. Теперь остается в дополнение к файловой резервной копии добавить файлы журналов, созданные во время резервирования. Для удобства в каталоге с журналами будет создан файл вида 000000010000001A00000020.00000028.backup , в котором находится информация о резервной копии. Первая часть имени этого файла

обозначает имя первого журнала WAL необходимого для воcстановления базы. Журналы с меньшим именем могут быть удалены.

С помощью команды pg_basebackup [ править ]

Так же резервную копию можно создать использую команду pg_basebackup. Эта команда создает копию в виде файлов или архива tar.
Для ее работы необходимо дополнительно настроить сервер базы данных ( /var/lib/pgsql/data/postgresql.conf ):

И разрешить подсоединение пользователю postgres для репликации раскомментировать нужную строчку в файле /var/lib/pgsql/data/pg_hba.conf :

Перезапустите сервер баз данных:

Пример использования команды:

Описание параметров команды:

• -D — каталог для архивации (должен быть пустой)
• -F — формат вывода (t — tar архив)
• -z — сжимает выходной файл gzip
• -U — пользователь для подключения к базе
• -w — не запрашивать пароль
• -с — режим создания контрольной точки (fast — быстрая)
• -l — метка резервной копии

После выполнения команды в каталоге /var/lib/pgsql/backup появится архив base.tar.gz . А в каталоге с журналами будет создан файл с описанием резервной копии. В дополнение к резервной копии необходимо копировать архивы журналов.

Восстановление из резервной копии [ править ]

Для восстановления из резервной копии, сделанной с помощью механизма Continuous Archiving, потребуется архив с базовой резервной копией и файлы журналов WAL.
1. Остановите сервер.
2. Если позволяет свободное место временно скопируйте каталог с базой данных. Если места недостаточно сохраните как минимум содержимое подкаталога pg_xlog каталога базы данных, так в нем хранятся не архивированные журналы WAL.
3. Восстановите все файлы из архива с резервной копией. Проверьте права и владельца файлов. Они должны принадлежать пользователю от имени которого запускается сервер PostgreSQL.
4. Удалите все файлы из восстановленного подкаталога pg_xlog , так как содержащиеся там файлы журналов устарели.
5. Скопируйте не архивированные файлы журналов сохраненные в п.2 в подкаталог pg_xlog восстановленной базы данных. Проверьте права и владельца.
6. В каталоге базы данных /var/lib/pgsql/data создайте файл recovery.conf . Файл должен иметь права 600 и владельца от имени которого запускается сервер. Запустите сервер PostgreSQL. Если восстановление по какой-то причине прервется просто запустите сервер еще раз. После окончания восстановления файл recovery.conf переименуется в файл recovery.done , чтобы исключить повторный запуск восстановления. Сервер готов к работе.
В файле recovery.conf должна быть прописана как минимум одна команда restore_command , которая указывает откуда берутся файлы журналов.
Предположим что резервную копию мы разархивировали в каталог /var/lib/pgsql/data
Архивные журналы находятся в каталоге /var/lib/pgsql/wal
Журналы архивировались командой archive_command = ‘gzip /var/lib/pgsql/wal/%f’
Тогда файл recovery.conf должен содержать следующую строку:

Также можно задать момент времени до которого нужно проводить восстановление:

Если метку времени не задавать будет выполнено восстановление на сколько это возможно.

Настройка клиента [ править ]

В каталоге /etc/bacula создадим следующие скрипты:
pre-base-backup.sh:

Этот скрипт создает полную копию базы данных и выполняется перед выполнением задачи резервного копирования базы.

Этот скрипт удаляет созданную копию базы данных и будет выполнен после задачи резервного копирования базы.

Этот скрипт создает файл backup_in_progress и выполняется перед выполнением задачи резервного копирования журналов. Этот файл нужен, чтобы во время резервного копирования PostgreSQL не архивировал новые журналы (copy_wal.sh)

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

Установка Bacula [ править ]

Установка на сервере:

Установка на клиенте:

Настройка Bacula [ править ]

Генерация базы данных PostgreSQL при помощи скриптов [ править ]

В bacula присутствуют скрипты для создания базы, пользователя и таблиц.
Для того чтобы задать пароль для пользователя bacula необходимо отредактировать следующую строку в файле /usr/share/bacula/scripts/grant_postgresql_privileges :

В противном случае пользователь создастся без пароля.
Создаём базу данных bacula и пользователя bacula:

Создаём таблицы базы данных:

Установим права пользователя bacula:

Настройка конфигурационных файлов [ править ]

Настройка Director [ править ]

За настройку Bacula Director отвечает файл /etc/bacula/bacula-dir.conf :

Установим пароль для доступа к Director в файле /etc/bacula/bacula-dir-password.conf :

Настройка Storage [ править ]

Конфигурационный файл хранилищ /etc/bacula/bacula-sd.conf :

Установим пароль для доступа к хранилищу в файле /etc/bacula/bacula-sd-password.conf :

В каталоге /etc/bacula/storage.d расположен файл описания типа хранилища file.conf

Настройка Bacula User Agent (Console) [ править ]

Конфигурационный файл хранилищ /etc/bacula/bconsole.conf :

Настройка Client [ править ]

Конфигурационный файл клиента /etc/bacula/client.d/client1.conf :

Установим пароль для доступа к клиенту в файле /etc/bacula/bacula-fd-password.conf :

Настройка FileStorage [ править ]

В каталоге /etc/bacula/device.d находится файл с описанием устройства:
filestorage.conf

Каталог /home/backup должнен существовать и принадлежать пользователю bacula:

Описание наборов файлов [ править ]

В каталоге /etc/bacula/fileset.d находятся описания списков файлов для резервирования:
catalog.conf

Описание задач [ править ]

В каталоге /etc/bacula/job.d находятся описания списков файлов для резервирования:

backupcatalog.conf — Делает дамп базы и резервирует его:

bacula.conf — делает полный бэкап:

defaultjob.conf — описывает параметры задачи по умочанию:

restore.conf — восстанавливает файлы:

Описание пулов [ править ]

Пул объединяет в себе несколько томов, чтобы отдельная резервная копия не была ограничена объемом тома.
Том это отдельная единица в которую ведется запись, может быть файлом или лентой.
В каталоге /etc/bacula/pool.d содержится:

default.conf — описывает пул по умолчанию:

1. Default pool definition

Проверка конфигурационных файлов [ править ]

Проверить корректность конфигурационных файлов bacula director можно так:

Автозапуск сервиса [ править ]

На сервере. Запустим и добавим в автозапуск сервис:

В случае, если хранилище настроено там же, где и Director, необходимо запустить

Проверка работоспособности [ править ]

Для управления bacula используется специальная утилита bconsole.

Для проcмотра статуса всех компонентов введем status:

Создание резервной копии [ править ]

Для создания резервной копии введем команду run:

За ходом выолнения можно наблюдать при помощи команды status:

Восстановление из резервной копии [ править ]

Для восстановления резервной копии используется команда restore:

Файлы востановленны в каталог /tmp/bacula-restores

Установка Baculum [ править ]

Baculum- web интерфейс Bacula. Установим необходимые пакеты на сервере:

Далее включим сайты baculum-api.conf и baculum-web.conf в apache2:

Включаем следующие модули для работы baculum web c помощью команд:

Добавляем пользователя apache2 в группу bacula:

Запустим сервис httpd2:

Для работы с bconsole веб серверу даём право запускать необходимые бинарники без пароля:

Переходим по ссылке http://IPадрес:9096 и попадаем в интерфейс настройки baculum-api:

Логин по-умолчанию: admin
Пароль по-умолчанию: admin

Выбираем язык —> Настраиваем доступ к базе данных

Настраиваем интерфейс для выполнения команд в bconsole:

Настраиваем Config API

Далее выберите Use HTTP Basic authentication введите логин пароль. Save.