§ Barman: PostgreSQL Backup and Recovery Manager.

Barman: PostgreSQL Backup and Recovery. It's simple. Really!

Сегодня я расскажу об еще одном замечательном инструменте для PostgreSQL. Речь пойдет о Barman (PgBarman) - это инструмент для резервного копирования для баз данных PostgreSQL и для восстановления из резервных копий. Кто-то может быть скажет, зачем есть же pg_dump/pg_restore. И будет прав, pg_dump тоже делает резервные копии, а pg_restore выполняет восстановление. Но pg_dump и pg_restore не предоставляют возможности disaster recovery. В подтверждение простой пример: мы сделали pg_dump'ом резервную копию в 9:00, в 15:00 сервер залило водой. В таком случае мы сможем восстановиться на состояние 9:00 и потеряем данные в течение 6 часов работы базы, что может быть совершенно неприемлемо.
Barman же используя встроенные возможности PostgreSQL предоставляет нам возможности избежать такого развития событий. Итак пара слов о Barman:

• позволяет собирать резервные копии с нескольких серверов в одно место;
• предоставляет каталог в котором хранятся резервные копии и архивы WAL;
• позволяет выполнять удаленное восстановление из резервных копий;
• поддерживает политики хранения резервных копий на основе избыточности (redundancy) или окна восстановления (recovery window).

Итак продолжаем, план работ на сегодня:

• планирование общей архитектуры;
• установка barman и его настройка;
• настройка доступа между серверами;
• настройка доступа и архивирования в postgresql;
• общее описание действий доступных в barman;
• создание резервной копии;
• восстановление из резервной копии.

Планирование общей архитектуры. 
Перед тем как приступить следует определить:

1. сервера для которые следует выполнять резервное копирование: k9980, k9981
2. сервер где будут храниться резервные копии и архивы WAL: backup
3. каталог где будут храниться резервные копии: пусть будет /var/lib/barman

О планировании внутренней структуры каталогов за нас уже подумали, barman при первом запуске сам создаст все необходимые подкаталоги для хранения резервных копий и WAL архивов.

Установка, настройка.
Установка будет выполняться в Gentoo Linux, но есть официальная информация от разработчиков что установочные пакеты доступны для Debian/CentOS. В любом случае исходники тоже присутствуют с инструкцией по установке внутри архива. Так что с установкой сложностей не возникнет. Готовый ebuild можно взять здесь. Итак установка выполняется на сервер backup:
# cave resolve barman -x

В процессе установки будет создан пользователь barman с домашним каталогом /var/lib/barman. Под пользователем barman и будут выполняться все работы. 
Теперь следует определить конфигурацию barman. Настройка конфигурации сводится к определению некоторых основных параметров и указанию настроек для каждого сервера для которого следует выполнять резервное копирование.
root@backup # vi /etc/barman.conf
[barman]
barman_home = /var/lib/barman
barman_user = barman
log_file = /var/log/barman/barman.log
compression = gzip

;pre_backup_script = env | grep ^BARMAN
;post_backup_script = env | grep ^BARMAN

;configuration_files_directory = /etc/barman.d
;minimum_redundancy = 0
;retention_policy =
;bandwidth_limit = 4000

[k9980]
description = "k9980-thinsearch-master"
ssh_command = ssh postgres@172.17.99.80
conninfo = host=172.17.99.80 user=postgres
minimum_redundancy = 1
retention_policy = REDUNDANCY 2

[k9981]
description = "k9981-widescope-master"
ssh_command = ssh postgres@172.17.99.81
conninfo = host=172.17.99.81 user=postgres
minimum_redundancy = 1
retention_policy = REDUNDANCY 2

В вышеприведенной конфигурации мы определили 2 сервера с которых будем снимать резервные копии. Хочу заметить что конфигурации можно складывать в отдельные файлы в каталог /etc/barman.d/.

Настройка доступа между серверами.
Для нормальной работы Barman, необходимо настроить возможность двунаправленного SSH подключение с узла сбора резервных копий (backup)  на целевые сервера с базами и в обратную сторону. Более конкретно:

• пользователь barman должен успешно ходить на сервера с базами данных под аккаунтом postgres - собственно выполнение резервных копий;
• пользователь postgres должен успешно ходить на сервер резервных копий под аккаунтом barman - складирование WAL архивов.

Генерируем ключи, парольные фразы не указываем.
barman@backup $ ssh-keygen -t rsa -b 1122

Сгенерированный ключ нужно скопировать в authorized_keys пользователя postgres на каждом узле. Для пользователей postgres нужно повторить процедуру и сгенерировать ключи, после чего скопировать их в authorized_keys пользователя barman.
Перед тем как продолжить, убедитесь что подключение работает в обе стороны.

Настройка доступа и архивирования WAL в PostgreSQL.
Следующий этап, это настройка подключения к postgresql сервисам с узла резервного копирования под пользователем postgres. На этот раз речь об учетной записи внутри базы.
Для этого редактируем pg_hba.conf конфигурации где разрешаем подключение с backup сервера под пользователем postgres (параноики негодуют, я в их числе). Это нужно для выполнения функции pg_start_backup/pg_stop_backup, однако мы то знаем что их можно обернуть в security definer функции.
В моем случае используется md5 авторизация.
root@k9980 # vi /etc/postgresql-9.3/pg_hba.conf
host postgres postgres 172.17.99.82/32 md5

Теперь прописываем реквизиты доступа пользователю barman.
barman@backup $ vi ~/.pgpass
k9980:5432:*:postgres:postgrespass
k9981:5432:*:postgres:pgpasswd
barman@backup $ chmod 600 ~/.pgpass

После правки конфигурации делаем reload для postgres сервиса и проверяем подключение со стороны бэкап узла
barman@backup $ psql -h pg -U postgres

Теперь осталось настроить архивацию WAL журналов. 
На каждом сервере баз данных следует указать следующую конфигурацию с помощью которой postgres будет копировать архивы на backup сервер в соответствующий своему серверу каталог. Путь выбран не случайно и должен совпадать с тем путем который будет создан при первом запуске barman. 
root@k9980 # vi /etc/postgresql-9.3/postgresql.conf
archive_mode = on
archive_command = 'rsync -a %p barman@172.17.99.82:/var/lib/barman/k9980/wals/%f'

После правки следует выполнить перезапуск postgresql.

Общее описание Barman.
Итак, запускаем barman --help и смотрим что нам доступно:
cron - обслуживание задач по удалению старых резервных копий и архивов (должны выполняться периодически через cron);
list-server - просмотр списка серверов для которых выполняется резервное копирование;
show-server - просмотр конфигурации barman для указанного сервера (настройки подключения, каталоги хранения резервных копий и архивов, настройки хранения резервных копий и т.п.);
status - просмотр состояния для указанного сервера (версия PostgreSQL, размещение каталога базы, настройки архивирования, количество резервных копий и т.п.);
check - проверка указанного узла на предмет правильности настроек, включено ли архивирование, компрессия, обеспечивается ли избыточность резервных копий;
backup - запуск процедуры резервного копирования;
list-backup - просмотр списка резервных копий для указанного сервера;
show-backup - просмотр информации о конкретной резервной копии;
list-files - просмотр списка файлов указанной резервной копии;
recover - запуск процедуры восстановления из указанной резервной копии;
delete - удаление указанной резервной копии.

Итак приступим, для начала осмотримся
barman@backup $ barman list-server
barman@backup $ barman show-server k9980

При выполнении этих двух команд будет автоматически созданы необходимые директории для хранения резервных копий и архивов. Еще следует отметить что в параметре incoming_wals_directory будет указан каталог в который должно быть настроено архивирование WAL журналов со стороны postgresql. 

Выполнение резервного копирования
barman@backup $ barman backup k9981
Starting backup for server k9981 in /var/lib/barman/k9981/base/20131029T004147
Backup start at xlog location: 7/AC000028 (0000000100000007000000AC, 00000028)
Copying files.
Copy done.
Asking PostgreSQL server to finalize the backup.
Backup end at xlog location: 7/AC0000F0 (0000000100000007000000AC, 000000F0)
Backup completed

Время выполнения резервного копирования колеблется от некоторых нюансов, первое это от значения checkpoint_timeout и checkpoint_completion_target в postgresql.conf копируемого сервера. Если там указано большое значение, то может сложиться впечатление что barman backup завис. На самом деле это не так, barman ждет выполнения функции pg_start_backup на стороне postgresql (время выполнения которой как раз зависит от указанных параметров). И второе это размер копируемой базы, тут все просто: чем больше база, тем больше время копирования.
После выполнения резервной копии можно потренироваться с остальными командами. 

Выполнение восстановления из резервной копии.
Рассмотрим вполне типичный случай когда требуется восстановить базу данных на удаленном узле. Для этого на удаленном сервере, где требуется восстановить базу данных, создаем каталог для базы и делаем postgres владельцем этого каталога.
root@k9980 # mkdir /srv/pgdb/db/
root@k9980 # chown postgres: /srv/pgdb/db/

После чего запускаем процедуру восстановления на backup сервере.
barman@backup $ barman recover --remote-ssh-command "ssh postgres@172.17.99.80" k9980 20131029T233826 /srv/pgdb/db/
Starting remote restore for server k9980 using backup 20131029T233826 
Destination directory: /srv/pgdb/db/
Copying the base backup.
Copying required wal segments.
The archive_command was set to 'false' to prevent data losses.
Your PostgreSQL server has been successfully prepared for recovery!
Please review network and archive related settings in the PostgreSQL
configuration file before starting the just recovered instance.

Теперь есть два варианта развития событий:
1) Запустить postgresql c каталогом в том состоянии в котором он был скопирован. В этом случае состояние базы будет на момент создания резервной копии.
2) Запустить postgresql в режиме восстановления с заданной конфигурацией, например сделать так чтобы postgresql восстановил себя до последнего возможно состояния с помощью WAL архивов. Таким образом мы можем восстановить состояние базы вплоть до момента аварии.
Рассмотрим второй вариант. На сервере где будет восстанавливаться базу создаем recovery.conf в котором указываем что нужно копировать архивы с backup сервера
# vi /srv/pgdb/db/recovery.conf 
restore_command='scp barman@172.17.99.82:/srv/barman/k9980/wals/%f "%p"'

После чего запускаем postgres и смотрим журнал
# /etc/init.d/postgresql-9.3 start
# tail -f /srv/pgdb/pg_log/postmaster.log
LOG:  database system was interrupted; last known up at 2013-10-30 00:05:58 YEKT
LOG:  starting archive recovery
LOG:  restored log file "0000000100000007000000F0" from archive
LOG:  redo starts at 7/F00000C8
LOG:  consistent recovery state reached at 7/F0000190
LOG:  database system is ready to accept read only connections
LOG:  restored log file "0000000100000007000000F1" from archive
LOG:  restored log file "0000000100000007000000F2" from archive
..............................
LOG:  restored log file "000000010000000800000021" from archive
LOG:  redo done at 8/21199AD0
LOG:  last completed transaction was at log time 2013-10-30 00:17:33.415885+06
LOG:  restored log file "000000010000000800000021" from archive
LOG:  selected new timeline ID: 2
LOG:  archive recovery complete
LOG:  checkpoint starting: end-of-recovery immediate wait
LOG:  checkpoint complete: wrote 32244 buffers (98.4%); 0 transaction log file(s) added, 0 removed, 0 recycled; write=0.434 s, sync=0.143 s, total=0.609 s; sync files=18, longest=0.128 s, average=0.007 s
LOG:  database system is ready to accept connections
LOG:  autovacuum launcher started

Строка "database system is ready to accept connections" говорит о том что все хорошо и восстановление прошло успешно. 
В качестве небольшого бонуса... как я уже говорил Barman использует встроенные средства PostgreSQL, поэтому в качестве конечной точки восстановления можно указать конкретное время, транзакцию или временную линию (timeline). В общем все что доступно в PostgreSQL доступно и в Barman.

На главную "Virtualizing Linux"