TOC

Как создавать резервные копии, восстанавливать и переносить базы данных PostgreSQL с помощью Barman в CentOS 7

Вступление

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

Одной из важнейших задач поддержки среды PostgreSQL является регулярное резервное копирование баз данных. Резервные копии являются частью процесса аварийного восстановления (DR) для любой организации. Это важно по нескольким причинам:

  • Защита от потери данных из-за отказа базовых компонентов инфраструктуры, таких как хранилище или сам сервер

  • Защита от повреждения данных и нежелательной или злонамеренной потери данных

  • Миграция производственных баз данных в среды разработки или тестирования

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

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

Краткое введение в методы резервного копирования PostgreSQL

Прежде чем приступить к настройке Barman, давайте немного рассмотрим типы резервных копий, доступных для PostgreSQL, и их использование. (Для еще более широкого обзора стратегий резервного копирования, прочитайте нашу статью о effective резервных копий .)

PostgreSQL предлагает два типа методов резервного копирования:

  • Логические резервные копии

  • Физические резервные копии

Логические резервные копии похожи на снимки базы данных. Они создаются с помощью утилиты + pg_dump + или + pg_dumpall +, поставляемой с PostgreSQL. Логические резервные копии:

  • Резервное копирование отдельных баз данных или всех баз данных

  • Резервное копирование только схем, только данных, отдельных таблиц или всей базы данных (схемы и данные)

  • Создайте файл резервной копии в собственном двоичном формате или в простом сценарии SQL

  • Может быть восстановлено с помощью утилиты + pg_restore +, которая также поставляется с PostgreSQL

  • Не предлагать * восстановление на момент времени (PITR) *

Это означает, что если вы делаете логическое резервное копирование вашей базы данных в 2:00 утра, когда вы восстанавливаете из нее, восстановленная база данных будет такой же, какой была в 2:00 утра. Невозможно остановить восстановление в определенный момент времени, например, в 1:30. Если вы восстанавливаете резервную копию в 10:00, вы потеряли данные за восемь часов.

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

  • Предложение восстановления на момент времени

  • Создайте резервную копию содержимого каталога data PostgreSQL и файлов _WAL (Write Ahead Log)

  • Занять больше места на диске

  • Используйте команды PostgreSQL + pg_start_backup + и + pg_stop_backup +. Тем не менее, эти команды должны быть в сценарии, что делает физическое резервное копирование более сложным процессом

  • Не создавайте резервные копии отдельных баз данных, только схем и т. Д. Это подход «все или ничего»

Файлы WAL содержат списки transactions (INSERT, UPDATE или DELETE), которые происходят с базой данных. Фактические файлы базы данных, содержащие данные, находятся в каталоге данных. Поэтому, когда дело доходит до восстановления на определенный момент времени из физической резервной копии, PostgreSQL сначала восстанавливает содержимое каталога данных, а затем воспроизводит поверх него транзакции из файлов WAL. Это приводит базы данных в согласованное состояние во времени.

  • Как работают резервные копии Barman *

Традиционно администраторы баз данных PostgreSQL писали свои собственные сценарии резервного копирования и планировали задания `+ cron + 'для реализации физического резервного копирования. Бармен делает это стандартным способом.

  • Barman * или * Backup and Recovery Manager * - это бесплатный инструмент резервного копирования PostgreSQL с открытым исходным кодом от 2ndQuadrant - профессиональной компании по разработке решений Postgres. Barman был написан на Python и предлагает простой, интуитивно понятный метод физического резервного копирования и восстановления для вашего экземпляра PostgreSQL. Некоторые преимущества использования Barman:

  • Это абсолютно бесплатно

  • Это хорошо поддерживаемое приложение и профессиональная поддержка доступна от поставщика

  • Освобождает DBA / Sysadmin от написания и тестирования сложных скриптов и заданий + cron +

  • Может создавать резервные копии нескольких экземпляров PostgreSQL в одном центральном месте

  • Может восстановить тот же экземпляр PostgreSQL или другой экземпляр

  • Предлагает механизмы сжатия для минимизации сетевого трафика и дискового пространства

цели

В этом руководстве мы создадим три дроплета DigitalOcean, установим PostgreSQL 9.4 на две из этих машин и установим Barman на третью.

Один из серверов PostgreSQL будет нашим основным сервером базы данных: здесь мы создадим нашу производственную базу данных. Второй экземпляр PostgreSQL будет пустым и будет рассматриваться как резервный компьютер, на котором мы можем восстановить данные из резервной копии.

Сервер Barman будет взаимодействовать с основным сервером базы данных и выполнять физическое резервное копирование и архивирование WAL.

Затем мы будем эмулировать «катастрофу», удалив таблицу из нашей действующей базы данных.

Наконец, мы восстановим резервную копию экземпляра PostgreSQL с сервера Barman на резервный сервер.

Предпосылки

Чтобы следовать этому руководству, вам нужно будет создать три дроплета DigitalOcean (или ваши собственные серверы Linux), каждый из которых имеет не менее * 2 ГБ ОЗУ * и 2 ядра ЦП. Мы не будем вдаваться в детали создания капельки; Вы можете найти дополнительную информацию here.

Все три сервера должны иметь одинаковую ОС (* CentOS 7 * x64 bit).

Мы будем называть машины следующим образом:

  • * main-db-server * (мы будем обозначать его IP-адрес как)

  • * standby-db-server * (мы будем обозначать его IP-адрес как)

  • * barman-backup-server * (мы будем обозначать его IP-адрес как)

Фактические IP-адреса машин можно узнать с панели управления DigitalOcean.

Вы также должны настроить пользователя sudo на каждом сервере и использовать его для общего доступа. Большинство команд будут выполняться как два разных пользователя (* postgres * и * barman *), но вам также потребуется пользователь sudo на каждом сервере, чтобы вы могли переключаться на эти учетные записи. Чтобы понять, как работают привилегии sudo, см. Этот учебник DigitalOcean о включении доступа sudo ,

Шаг 1 - Установка серверов баз данных PostgreSQL

Сначала мы настроим среду базы данных, установив PostgreSQL 9.4 на * main-db-server * и * standby-db-server *.

Пожалуйста, выполните шаги по установке PostgreSQL из this учебник стека LEPP , Из этого урока вам необходимо:

  • Следуйте разделу * Шаг первый - Установка PostgreSQL *

  • Следуйте разделу * Шаг второй - Настройка PostgreSQL *

В шаге 2 - Настройка PostgreSQL * вместо внесения изменений в файл + pg_hba.conf +, чтобы разрешить доступ к базе данных для веб-сервера, добавьте эту строку, чтобы сервер Barman мог подключиться, используя * barman-backup- IP-адрес сервера *, за которым следует + / 32 +:

host    all     all     /32        trust

Это настраивает PostgreSQL для принятия любого соединения, поступающего с сервера Barman.

Остальным инструкциям в этом разделе можно следовать как есть.

Убедитесь, что вы установили PostgreSQL на * main-db-server * и * standby-db-server *, и что вы разрешили доступ к ним обоим с * barman-backup-server *.

Далее мы добавим несколько примеров данных на основной сервер базы данных.

Шаг 2 - Создание базы данных и таблиц PostgreSQL

После того, как PostgreSQL будет установлен и настроен на обеих машинах, мы добавим несколько примеров данных на * main-db-server *, чтобы имитировать производственную среду.

На * main-db-server * переключитесь на пользователя * postgres *:

sudo su - postgres

Запустите утилиту + psql + для доступа к серверу базы данных:

psql

В командной строке + psql + выполните следующие команды, чтобы создать базу данных и перейти к ней:

CREATE DATABASE mytestdb;
\connect mytestdb;

Выходное сообщение сообщит вам, что вы теперь подключены к базе данных + mytestdb + как пользователь + postgres +.

Затем добавьте две таблицы в базу данных:

CREATE TABLE mytesttable1 (id integer NULL);
CREATE TABLE mytesttable2 (id integer NULL);

Они называются + mytesttable1 + и + mytesttable2 +.

Выйдите из инструмента клиента, набрав + \ q + и нажав + ENTER +.

Шаг 3 - Установка Бармена

Теперь мы установим Barman на резервный сервер, который будет контролировать и хранить наши резервные копии.

Выполните этот шаг на * barman-backup-server *.

Для этого вам сначала необходимо установить следующие репозитории:

  • Дополнительные пакеты для репозитория Enterprise Linux (EPEL)

  • RPM-репозиторий PostgreSQL Global Development Group

Выполните следующую команду для установки EPEL:

sudo yum -y install epel-release

Запустите эти команды для установки репозитория PostgreSQL:

sudo wget http://yum.postgresql.org/9.4/redhat/rhel-7Server-x86_64/pgdg-centos94-9.4-1.noarch.rpm
sudo rpm -ivh pgdg-centos94-9.4-1.noarch.rpm

Наконец, запустите эту команду для установки Barman:

sudo yum -y install barman

Бармен установлен! Теперь давайте удостоверимся, что серверы могут безопасно соединяться друг с другом.

Шаг 4 - Настройка SSH-соединения между серверами

В этом разделе мы установим SSH-ключи для безопасного соединения без пароля между * main-db-server * и * barman-backup-server *, и наоборот.

Аналогично, мы установим SSH-ключи между * standby-db-server * и * barman-backup-server *, и наоборот.

Это сделано для того, чтобы PostgreSQL (на обоих серверах баз данных) и Barman могли «общаться» друг с другом во время резервного копирования и восстановления.

Для этого урока вам необходимо убедиться:

  • Пользователь * postgres * может удаленно подключиться с * main-db-server * к * barman-backup-server *

  • Пользователь * postgres * может удаленно подключиться с * standby-db-server * к * barman-backup-server *

  • Пользователь * barman * может удаленно подключиться с * barman-backup-server * к * main-db-server *

  • Пользователь * barman * может удаленно подключиться с * barman-backup-server * к * standby-db-server *

Мы не будем вдаваться в подробности того, как работает SSH. Существует very очень хорошая статья о DigitalOcean об основах SSH, на которую вы можете сослаться.

Все команды, которые вам понадобятся, включены сюда.

Мы покажем вам, как это сделать один раз, чтобы настроить соединение для пользователя * postgres * для подключения с * main-db-server * к * barman-backup-server *.

С * main-db-server * переключитесь на пользователя * postgres *, если он еще не является текущим пользователем:

sudo su - postgres

Выполните следующую команду, чтобы сгенерировать пару ключей SSH:

ssh-keygen -t rsa

Примите местоположение по умолчанию и имя для файлов ключей, нажав + ENTER.

Дважды нажмите + ENTER +, чтобы создать закрытый ключ без какой-либо парольной фразы.

Как только ключи сгенерированы, в домашнем каталоге пользователя * postgres * будет создан каталог + .ssh + с ключами в нем.

Теперь вам необходимо скопировать открытый ключ SSH в файл + author_keys + в каталоге * barman * пользователя + .ssh + на * barman-backup-server *.

Выполните следующую команду для вывода содержимого открытого ключа пользователя * postgres *:

cat ~/.ssh/id_rsa.pub

Скопируйте содержимое вывода.

Переключитесь на консоль, подключенную к серверу * barman-backup-server * и переключитесь на пользователя * barman *:

sudo su - barman

Выполните следующие команды, чтобы создать каталог + .ssh +, установить его разрешения, скопировать содержимое открытого ключа в файл + author_keys + и, наконец, сделать этот файл читаемым и доступным для записи:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
echo "" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Убедитесь, что вы вставили длинную строку открытого ключа, начинающуюся с + ssh-rsa + между кавычками, вместо ++.

Вы скопировали ключ на удаленный сервер.

Теперь, чтобы проверить соединение, переключитесь обратно на * main-db-server * и проверьте соединение оттуда:

ssh barman@

После первоначального предупреждения о том, что подлинность удаленного сервера неизвестна, и вы принимаете приглашение, необходимо установить соединение между сервером * main-db-server * и * barman-backup-server *. В случае успеха выйдите из сеанса, выполнив команду + exit +.

exit

  • Вам нужно установить соединения с ключом SSH еще три раза. * Вы можете пропустить создание каталога + .ssh +, если он уже создан (хотя это и не нужно).

  • Выполните те же команды еще раз, на этот раз с * standby-db-server * на * barman-backup-server *

  • Запустите их в третий раз, на этот раз от пользователя * barman * на * barman-backup-server * и от пользователя * postgres * на * main-db-server *

  • Наконец, запустите команды для копирования ключа от пользователя * barman * на * barman-backup-server * пользователю * postgres * на * standby-db-server *

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

С * standby-db-server *:

ssh barman@

С * barman-backup-server *:

ssh postgres@

С * barman-backup-server *:

ssh postgres@

Шаг 5 - Настройка Barman для резервного копирования

Теперь вы настроите Barman для резервного копирования вашего основного сервера PostgreSQL.

Основной файл конфигурации для BARMAN - + / etc / barman.conf +. Файл содержит раздел для глобальных параметров и отдельные разделы для каждого сервера, для которого требуется создать резервную копию. Файл по умолчанию содержит раздел для примера сервера PostgreSQL с именем * main *, который закомментирован. Вы можете использовать его в качестве руководства для настройки других серверов, резервное копирование которых вы хотите выполнить.

Откройте + / etc / barman.conf + в текстовом редакторе как ваш * пользователь sudo * (пользователь * barman * имеет к нему только доступ для чтения):

sudo vi /etc/barman.conf

Глобальные параметры определены в разделе + [barman] +. В этом разделе внесите следующие изменения. Готовые значения показаны под пунктами маркированного списка:

  • Раскомментируйте строку для + обжатия + ​​и оставьте значение по умолчанию + gzip. + Это означает, что файлы PostgreSQL WAL - при копировании в каталог резервных копий - будут сохранены в сжатом виде gzip.

  • Раскомментируйте строку для + reuse_backup + и оставьте значение по умолчанию + link +. При создании полных резервных копий сервера PostgreSQL Barman попытается сэкономить место в каталоге резервных копий, создавая инкрементные резервные копии на уровне файлов. Это использует rsync и жесткие ссылки. Создание инкрементных полных резервных копий имеет то же преимущество, что и любой метод дедупликации данных: экономия времени и дискового пространства.

  • Раскомментируйте строку для + instant_checkpoint + и установите ее значение в + true +. Этот параметр гарантирует, что когда Barman начнет полное резервное копирование, он запросит PostgreSQL выполнить + CHECKPOINT +. Контрольная точка гарантирует, что любые измененные данные в кеше памяти PostgreSQL будут записаны в файлы данных. С точки зрения резервного копирования это может добавить некоторую ценность, потому что BARMAN сможет создавать резервные копии последних изменений данных

  • Раскомментируйте строку для + basebackup_retry_times + и установите значение + 3 +. При создании полной резервной копии Barman попытается подключиться к серверу PostgreSQL три раза, если по какой-либо причине операция копирования не удалась

  • Раскомментируйте строку для + basebackup_retry_sleep + и оставьте значение по умолчанию + 30 +. Между каждой попыткой будет задержка в 30 секунд

  • Раскомментируйте строку для + last_backup_maximum_age + и установите ее значение в +1 +1 DAYS +.

Новые настройки должны выглядеть именно так:

Выдержки из /etc/barman.conf

[barman]
barman_home = /var/lib/barman

. . .

barman_user = barman
log_file = /var/log/barman/barman.log
compression = gzip
reuse_backup = link

. . .

immediate_checkpoint = true

. . .

basebackup_retry_times = 3
basebackup_retry_sleep = 30
last_backup_maximum_age = 1 DAYS

То, что мы делаем здесь, это:

  • Сохранение расположения резервной копии по умолчанию

  • Указание того, что резервное пространство должно быть сохранено. Журналы WAL будут сжаты, а базовые резервные копии будут использовать инкрементное копирование данных.

  • Бармен повторит попытку три раза, если по какой-либо причине полное резервное копирование завершится неудачно.

  • Возраст последнего полного резервного копирования для сервера PostgreSQL не должен быть старше 1 дня

В конце файла добавьте новый раздел. Его заголовок должен содержать + [main-db-server] + в квадратных скобках. (Если вы хотите выполнить резервное копирование большего количества серверов баз данных с помощью Barman, вы можете создать такой блок для каждого сервера и использовать уникальное имя заголовка для каждого.)

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

Добавьте эти параметры в новый блок:

Выдержка из /etc/barman.conf

[main-db-server]
description = "Main DB Server"
ssh_command = ssh postgres@
conninfo = host= user=postgres
retention_policy_mode = auto
retention_policy = RECOVERY WINDOW OF  days
wal_retention_policy = main

Настройки + retention_policy + означают, что Barman автоматически перезаписывает старые файлы полной резервной копии и журналы WAL, сохраняя при этом достаточное количество резервных копий для периода восстановления в течение 7 дней. Это означает, что мы можем восстановить весь сервер базы данных в любой момент времени за последние семь дней. * Для производственной системы вам, вероятно, следует установить это значение выше, чтобы иметь под рукой более старые резервные копии. *

Вам нужно будет использовать IP-адрес * main-db-server * в параметрах + ssh_command + и + conninfo +. В противном случае вы можете точно скопировать вышеуказанные настройки.

Окончательная версия измененного файла должна выглядеть следующим образом, за исключением всех комментариев и неизмененных настроек:

Выдержки из /etc/barman.conf

[barman]
barman_home = /var/lib/barman

. . .

barman_user = barman
log_file = /var/log/barman/barman.log
compression = gzip
reuse_backup = link

. . .

immediate_checkpoint = true

. . .

basebackup_retry_times = 3
basebackup_retry_sleep = 30
last_backup_maximum_age = 1 DAYS

. . .

[main-db-server]
description = "Main DB Server"
ssh_command = ssh postgres@
conninfo = host= user=postgres
retention_policy_mode = auto
retention_policy = RECOVERY WINDOW OF 7 days
wal_retention_policy = main

Сохраните и закройте файл.

Затем мы убедимся, что наш * main-db-server * настроен на создание резервных копий.

Шаг 6 - Настройка файла postgresql.conf

На * main-db-server * должна быть выполнена последняя конфигурация для включения режима резервного копирования (или архивирования).

Во-первых, нам нужно найти значение входящего каталога резервного копирования с * barman-backup-server *. На сервере Barman переключитесь на пользователя * barman *:

sudo su - barman

Запустите эту команду, чтобы найти каталог для входящей резервной копии:

barman show-server main-db-server | grep incoming_wals_directory

Это должно вывести что-то вроде этого:

barman show-server command outputincoming_wals_directory: /var/lib/barman/main-db-server/incoming

Запишите значение + входящего_каталога ; в этом примере это ` / var / lib / barman / main-db-server / входящий +`.

Теперь переключитесь на консоль * main-db-server *.

Переключитесь на пользователя * postgres *, если он еще не является текущим пользователем.

Откройте файл + postgresql.conf в текстовом редакторе:

vi $PGDATA/postgresql.conf

Сделайте следующие изменения в файле:

  • Раскомментируйте параметр + wal_level + и установите его значение в + archive + вместо + minimal +

  • Раскомментируйте параметр + archive_mode + и установите для него значение + on + вместо + off +

  • Раскомментируйте параметр + archive_command + и установите для него значение + 'rsync -a% p barman @: /% f' + вместо + '' +. Используйте IP-адрес сервера Barman. Если вы получили другое значение для +coming_wals_directory +, используйте его вместо

Выдержки из postgresql.conf

wal_level = archive                     # minimal, archive, hot_standby, or logical

. . .

archive_mode = on               # allows archiving to be done

. . .

archive_command = 'rsync -a %p barman@:/%f'                # command to use to archive a logfile segment

Вернитесь к своему * пользователю sudo *.

Перезапустите PostgreSQL:

sudo systemctl restart postgresql-9.4.service

Шаг 7 - Тестирование Бармена

Пришло время проверить, правильно ли настроены все настройки Barman и можно ли подключиться к * main-db-server *.

На * barman-backup-server * переключитесь на пользователя * barman *, если это не текущий пользователь. Выполните следующую команду, чтобы проверить соединение с вашим основным сервером базы данных:

barman check

Обратите внимание, что если вы ввели другое имя в квадратных скобках для блока сервера в файле + / etc / barman.conf + в шаге 5, вы должны использовать это имя вместо этого.

Если все в порядке, вывод должен выглядеть так:

barman check command outputServer main-db-server:
       PostgreSQL: OK
       archive_mode: OK
       wal_level: OK
       archive_command: OK
       continuous archiving: OK
       directories: OK
       retention policy settings: OK
       backup maximum age: FAILED (interval provided: 1 day, latest backup age: No available backups)
       compression settings: OK
       minimum redundancy requirements: OK (have 0 backups, expected at least 0)
       ssh: OK (PostgreSQL server)
       not in recovery: OK

Не беспокойтесь о резервном максимальном возрасте + FAILED. Это происходит потому, что мы настроили Barman так, чтобы последняя резервная копия не была старше 1 дня. Резервное копирование еще не выполнено, поэтому проверка не удалась.

Если какой-либо из других параметров находится в состоянии + FAILED, вам следует продолжить расследование и устранить проблему, прежде чем продолжить.

Причиной сбоя проверки может быть несколько причин: например, Barman не может войти в экземпляр Postgres, Postgres не настроен для архивации WAL, SSH не работает между серверами и т. Д. Какой бы ни была причина, ее необходимо устранить до того, как произойдет резервное копирование. Выполните предыдущие шаги и убедитесь, что все соединения работают.

Чтобы получить список серверов PostgreSQL, настроенных с помощью Barman, выполните следующую команду:

barman list-server

Прямо сейчас это должно просто показать:

Выход

main-db-server - Main DB Server

Шаг 8 - Создание первой резервной копии

Теперь, когда у вас есть готовый Barman, давайте создадим резервную копию вручную.

Выполните следующую команду как пользователь * barman * на * barman-backup-server *, чтобы создать первую резервную копию:

barman backup

Опять же, значение ++ - это то, что вы ввели в качестве заголовка блока сервера в файле + / etc / barman.conf + на шаге 5.

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

Выход

Starting backup for server  in /var/lib/barman/main-db-server/base/20151111T051954
Backup start at xlog location: 0/2000028 (000000010000000000000002, 00000028)
Copying files.
Copy done.
Asking PostgreSQL server to finalize the backup.
Backup size: 26.9 MiB. Actual size on disk: 26.9 MiB (-0.00% deduplication ratio).
Backup end at xlog location: 0/20000B8 (000000010000000000000002, 000000B8)
Backup completed
Processing xlog segments for
       Older than first backup. Trashing file 000000010000000000000001 from server
       000000010000000000000002
       000000010000000000000002.00000028.backup

Расположение файла резервной копии

Так где же сохраняется резервная копия? Чтобы найти ответ, перечислите содержимое каталога + / var / lib / barman +:

ls -l /var/lib/barman

Там будет один каталог: + main-db-server +. Это сервер, который Barman в настоящее время настроен для резервного копирования, и его резервные копии находятся там. (Если вы сконфигурируете Barman для резервного копирования других серверов, для каждого сервера будет создан один каталог.) В каталоге + main-db-server + будет три подкаталога:

  • + base +: здесь хранятся базовые файлы резервных копий.

  • + входящий +: PostgreSQL отправляет свои завершенные файлы WAL в этот каталог для архивации

  • + wals +: Бармен копирует содержимое каталога +coming + в каталог + wals +

Во время восстановления Barman восстановит содержимое из каталога + base в каталог данных целевого сервера. Затем он будет использовать файлы из каталога + wals +, чтобы применить изменения транзакции и привести целевой сервер в согласованное состояние.

Список резервных копий

Существует специальная команда Barman для вывода списка всех резервных копий для сервера. Эта команда + barman list-backup +. Запустите следующую команду, чтобы увидеть, что она возвращает для нашего ++:

barman list-backup
Outputmain-db-server 20151111T051954 - Wed Nov 11 05:19:46 2015 - Size: 26.9 MiB - WAL Size: 0 B

  • Первая часть вывода - это имя сервера. В этом случае + main-db-server +

  • Вторая часть - длинное буквенно-цифровое значение - это идентификатор резервной копии. Идентификатор резервной копии используется для уникальной идентификации любой резервной копии, которую делает Barman. В данном случае это ++. * Вам понадобится идентификатор резервной копии для следующих шагов *

  • Третья часть информации сообщает вам, когда была сделана резервная копия

  • Четвертая часть - размер базовой резервной копии (в данном случае 26,9 МБ)

  • Пятая и последняя часть строки дает размер архива WAL

Чтобы увидеть более подробную информацию о резервном копировании, выполните эту команду, используя имя сервера и идентификатор резервной копии (в нашем примере ++) из предыдущей команды:

barman show-backup

Подробный набор информации будет показан:

OutputBackup :
 Server Name            :
 Status                 : DONE
 PostgreSQL Version     : 90405
 PGDATA directory       : /var/lib/pgsql/9.4/data

 Base backup information:
   Disk usage           : 26.9 MiB (26.9 MiB with WALs)
   Incremental size     : 26.9 MiB (-0.00%)
   Timeline             : 1
   Begin WAL            : 000000010000000000000002
   End WAL              : 000000010000000000000002
   WAL number           : 1
   WAL compression ratio: 99.84%
   Begin time           : 2015-11-11 05:19:44.438072-05:00
   End time             : 2015-11-11 05:19:46.839589-05:00
   Begin Offset         : 40
   End Offset           : 184
   Begin XLOG           : 0/2000028
   End XLOG             : 0/20000B8

 WAL information:
   No of files          : 0
   Disk usage           : 0 B
   Last available       : 000000010000000000000002

 Catalog information:
   Retention Policy     : VALID
   Previous Backup      : - (this is the oldest base backup)
   Next Backup          : - (this is the latest base backup)

Чтобы подробнее узнать, какие файлы попадают в резервную копию, выполните следующую команду:

barman list-files

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

Шаг 9 - Планирование резервного копирования

В идеале ваши резервные копии должны выполняться автоматически по расписанию.

На этом шаге мы автоматизируем наши резервные копии и сообщим Barman выполнить обслуживание резервных копий, чтобы удалить файлы, более старые, чем политика хранения. Чтобы включить планирование, запустите эту команду как пользователь * barman * на * barman-backup-server * (при необходимости переключитесь на этого пользователя):

crontab -e

Откроется файл + crontab + для пользователя * barman *. Отредактируйте файл, добавьте эти строки, затем сохраните и выйдите:

cron

30 23 * * * /usr/bin/barman backup
* * * * * /usr/bin/barman cron

Первая команда будет запускать полное резервное копирование * main-db-server * каждую ночь в 23:30. (Если вы использовали другое имя для сервера в файле + / etc / barman.conf +, используйте это имя.)

Вторая команда будет запускаться каждую минуту и ​​выполнять операции обслуживания как файлов WAL, так и базовых файлов резервных копий.

Шаг 10 - Имитация «Бедствия»

Теперь вы увидите, как вы можете восстановить из резервной копии, которую вы только что создали. Чтобы проверить восстановление, давайте сначала смоделируем сценарий «катастрофы», когда вы потеряли некоторые данные.

  • Мы бросаем столик здесь. Не делайте этого в производственной базе данных! *

Вернитесь к консоли * main-db-server * и переключитесь на пользователя * postgres *, если он еще не является текущим пользователем.

Запустите утилиту + psql +:

psql

В командной строке + psql + выполните следующую команду, чтобы переключить контекст базы данных на + mytestdb +:

\connect mytestdb;

Далее перечислите таблицы в базе данных:

\dt

Вывод покажет таблицы, которые вы создали в начале этого урока:

Output            List of relations
Schema |     Name     | Type  |  Owner
--------+--------------+-------+----------
public | mytesttable1 | table | postgres
public | mytesttable2 | table | postgres

Теперь выполните эту команду, чтобы удалить одну из таблиц:

drop table mytesttable2;

Если вы теперь выполните команду + \ dt + снова:

\dt

Вы увидите, что остается только + mytesttable1 +.

Это тип ситуации потери данных, когда вы хотите восстановить данные из резервной копии. В этом случае вы восстановите резервную копию на отдельном сервере: * standby-db-server *.

Шаг 11 - Восстановление или миграция на удаленный сервер

Вы можете следовать этому разделу, чтобы восстановить резервную копию или перенести вашу последнюю резервную копию PostgreSQL на новый сервер.

Перейдите на * standby-db-сервер *.

Во-первых, остановите службу PostgreSQL от имени пользователя sudo. (Перезапуск захлебнется, если вы попытаетесь запустить восстановление во время работы службы.)

sudo systemctl stop postgresql-9.4.service

Как только служба остановится, перейдите на * barman-backup-server *. Переключитесь на пользователя * barman *, если он еще не является текущим пользователем.

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

barman show-backup  latest

Выход

Backup :
 Server Name            :
 Status                 : DONE
 PostgreSQL Version     : 90405
 PGDATA directory       : /var/lib/pgsql/9.4/data

 Base backup information:

. . .

   Begin time           :
   End time             : 2016-01-14 17:35:55.054673-05:00

Из полученных данных запишите идентификатор резервной копии, напечатанный в первой строке (++ выше). Если резервная копия + latest + содержит нужные данные, вы можете использовать + latest + в качестве идентификатора резервной копии.

Также проверьте, когда была сделана резервная копия, из поля + Begin time + (++ выше).

Затем выполните эту команду, чтобы восстановить указанную резервную копию с * barman-backup-server * на * standby-db-server *:

barman recover --target-time ""  --remote-ssh-command "ssh postgres@"         /var/lib/pgsql/9.4/data

Здесь довольно много опций, аргументов и переменных, поэтому давайте объясним их.

  • + - target-time" "+: использовать время начала из команды + show-backup +

  • + - remote-ssh-command" ssh postgres @ "+: использовать IP-адрес * standby-db-server *

  • ++: использовать имя сервера базы данных из вашего файла + / etc / barman.conf +

  • ++: используйте идентификатор резервной копии из команды + show-backup + или используйте + latest +, если это именно то, что вам нужно

  • + / var / lib / pgsql / 9.4 / data +: путь, по которому вы хотите восстановить резервную копию. Этот путь станет новым каталогом данных для Postgres на резервном сервере. Здесь мы выбрали каталог данных по умолчанию для Postgres в CentOS. Для реальных случаев использования выберите подходящий путь

Для успешной операции восстановления вы должны получить следующий вывод:

Выход из Barman Recovery

Starting remote restore for server   using backup
Destination directory: /var/lib/pgsql/9.4/data
Doing PITR. Recovery target time:
Copying the base backup.
Copying required WAL segments.
Generating recovery.conf
Identify dangerous settings in destination directory.

IMPORTANT
These settings have been modified to prevent data losses

postgresql.conf line 207: archive_command = false

Your PostgreSQL server has been successfully prepared for recovery!

Теперь снова переключитесь на консоль * standby-db-server *. Как пользователь * sudo *, запустите службу PostgreSQL:

sudo systemctl start postgresql-9.4.service

Так и должно быть!

Давайте проверим, что наша база данных работает. Переключитесь на пользователя * postgres * и запустите утилиту + psql +:

sudo su - postgres
psql

Переключите контекст базы данных на + mytestdb + и перечислите таблицы в нем:

\connect mytestdb;
\dt

Выход

           List of relations
Schema |     Name     | Type  |  Owner
--------+--------------+-------+----------
public | mytesttable1 | table | postgres
public | mytesttable2 | table | postgres
(2 rows)

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

В зависимости от более широкой стратегии восстановления вы можете перейти на * standby-db-server * или проверить работоспособность восстановленной базы данных, а затем снова пройти через этот раздел, чтобы восстановить * main -db-сервер *.

Для восстановления на любом другом сервере просто убедитесь, что вы установили PostgreSQL и установили соответствующие подключения к серверу Barman, а затем следуйте этому разделу, используя IP-адрес целевого сервера восстановления.

Заключение

В этом уроке мы увидели, как установить и настроить Barman для резервного копирования сервера PostgreSQL. Мы также узнали, как восстановить или перенести данные из этих резервных копий.

При внимательном рассмотрении Barman может стать центральным хранилищем для всех ваших баз данных PostgresQL. Он предлагает надежный механизм резервного копирования и простой набор команд. Однако создание резервных копий - это только половина дела. Вы всегда должны проверять свои резервные копии, восстанавливая их в другом месте. Это упражнение следует делать периодически.

Некоторые вопросы по встраиванию Barman в вашу стратегию резервного копирования:

  • Сколько экземпляров PostgreSQL будет сохранено?

  • На сервере Barman достаточно дискового пространства для размещения всех резервных копий в течение указанного срока хранения? Как вы можете контролировать сервер для использования пространства?

  • Должны ли все резервные копии для разных серверов запускаться одновременно или они могут быть распределены в течение непикового периода? Одновременное резервное копирование всех серверов может привести к ненужной нагрузке на сервер Barman и сеть.

  • Надежна ли скорость сети между сервером Barman и серверами Postgres?

Еще один момент, о котором следует помнить: Barman не может создавать резервные копии и восстанавливать отдельные базы данных. Он работает на уровне файловой системы и использует подход «все или ничего». Во время резервного копирования весь экземпляр со всеми файлами данных копируется; при восстановлении все эти файлы восстанавливаются. Точно так же вы не можете делать резервные копии только для схемы или только для данных с Barman.

Поэтому мы рекомендуем вам разработать стратегию резервного копирования, чтобы в ней использовались как логические резервные копии с + pg_dump + или + pg_dumpall +, так и физические резервные копии с Barman. Таким образом, если вам нужно быстро восстановить отдельные базы данных, вы можете использовать резервные копии + pg_dump +. Для восстановления на момент времени используйте резервные копии Barman.

Related