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

О CommVault

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

CommVault защищает, восстанавливает и управляет данными и доступом к ним в физических и виртуальных средах.

О бэкапе PostgreSQL

Для выполнения резервного копирования БД PostgreSQL используется агент (iDataAgent), который устанавливается на сервер, где данная БД работает. Агент предназначен для эффективного управления и защиты важных бизнес-данных в базах данных PostgreSQL. Вы можете использовать этот агент для резервного копирования и восстановления всего сервера PostgreSQL или отдельных баз данных. При необходимости вы также можете восстановить отдельные таблицы.

Основные возможности:

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

Возможности резервного копирования и восстановления, которые можно выполнять в разных режимах:

• iDataAgent предоставляет возможность восстановить весь сервер PostgreSQL. Все базы данных, находящиеся на исходном сервере, могут быть восстановлены на конечном сервере.
• Определяйте отдельную базу данных или группу баз данных в качестве данных субклиента и выполняйте резервное копирование и восстановление.
• Выполняйте резервное копирование только журналов на сервере PostgreSQL. Эти файлы журналов можно использовать для восстановления транзакций базы данных, потерянных из-за сбоя операционной системы или диска.
• Восстанавливайте весь сервер PostgreSQL на определенный момент времени для резервного копирования на основе файловой системы (File System Based Backup).
• Просматривайте и проверяйте состояние операций резервного копирования и восстановления из Job Controller и средства Event Viewer в консоли CommCell. Отслеживайте состояние работ с помощью отчетов (Reports), которые можно сохранять и распространять.
• Используйте резервное копирование на уровне блоков в качестве более быстрого способа резервного копирования данных, поскольку резервное копирование выполняется только для экстентов (или измененных частей базы данных), а не для всей базы данных PostgreSQL.
• Дедупликация на уровне блоков (Block-Level Deduplication). Дедупликация обеспечивает более разумный способ хранения данных, выявляя и удаляя дубликаты в операциях защиты данных.

Архитектура

Схема



Как работает:

В сети разворачивается платформа CommVault в составе управляющего сервера CommServe и отдельного сервера MediaAgent (рекомендуется использовать физический сервер).

На сервер с БД PostgreSQL устанавливается агент (iDataAgent) и настраиваются политики его резервного копирования в соответствии с требованиями. iDataAgent собирает необходимые данные, сжимает, дедуплицирует, при необходимости, шифрует и передает их на MediaAgent.

Далее данные помещаются на СХД, на ленточную библиотеку либо на облачное хранилище.
Для восстановления данные извлекаются из хранилища и копируются на сервер с PostgreSQL.

Настройка в консоли CommVault

Теперь рассмотрим, как это сделать в консоли управления.

1. Для запуска резервного копирования БД в данный момент необходимо в консоли CommCell Browser выбрать:

Client Computers | | PostgreSQL | | DumpBasedBackupSet.

Кликнуть правой кнопкой мыши на папке default в subclient и выбрать Backup.



2. Выбрать Full как тип резервного копирования и выбрать Immediate.

3. Нажать OK. Запустится резервное копирование PostgreSQL.



4. В процессе выполнения задания его состояние можно отслеживать их окна Job Controller консоли CommCell.



5. Как только задание будет выполнено, можно будет посмотреть детали выполненного задания из окна Backup History. Выбрать папку default в subclient и выбрать Backup History.



6. В окне Backup History можно посмотреть следующие данные по выполненным заданиям:

— Ошибки резервного копирования при выполнении задания;
— Элементы, резервное копирование которых прошло удачно;
— Детали задания;
— События;
— Файлы логов;
— Медиа, на которых хранятся данные.

Для чего можно создавать резервные копии

Резервное копирование на основе дампа (Dump Based Backup):

• Системные базы данных PostgreSQL;
• Пользовательские базы данных PostgreSQL;
• Резервное копирование файловой системы (File System Based Backup).

Базы данных PostgreSQL (данные и журналы) (data and logs):

• Файлы логов.

Что не копируется:

• Файлы приложений PostgreSQL (application files);
• Данные операционной системы.

Используйте File System iDataAgent для резервного копирования вышеупомянутых компонентов.

Задача

У клиента было необходимо развернуть платформу CommVault для резервного копирования его сервисов. Одним из сервисов была БД PostgreSQL, которая была развёрнута в кластерной конфигурации из 2-х nodes: Master и Standby. Обе работали на физических серверах.

Особенности конфигурации PostgreSQL у клиента

Кластерная конфигурация PostgreSQL была выбрана для обеспечения отказоустойчивости сервера БД.

Резервное копирование БД PostgreSQL клиент делал с помощью pg_dump.

Схема работы представлена на рисунке ниже:

Настройка резервного копирования при помощи CommVault

Для унификации платформы по резервному копированию и использования преимуществ по хранению резервных копий решили использовать CommVault для резервного копирования БД PostgreSQL.

Т.к. у клиента использовалась кластерная конфигурация PostgreSQL, для резервирования нами было решено использовать вариант файлового резервного копирования File System Based Backup. При этом пришлось отказаться от использования блочного резервного копирования (Block Level Backup), т.к. версия используемого ядра Linux, на котором развёрнут PostgreSQL, оказалась выше официально поддерживаемой CommVault. Ввиду того, что сервис — критичный для организации, график резервного копирования решили делать согласно таблице:

	Полная копия	Transaction logs
График	1 раз в день, в 23 часа	Каждый час в течение 24 часов
Срок хранения копий	7 дней	1 сутки

Общий объём БД составлял более 1,5 Тб и для того, чтобы уложиться в требуемые RTO и RPO, была использована отдельная LAN-сеть для резервного копирования скоростью 10 Гбит/с.

Резервное копирование выполнялось согласно схеме ниже:



Резервные копии брались со Standby-сервера PostgreSQL и хранились на сервере с установленным MediaAgent. Далее, раз в месяц полные копии помещались в облако Amazon со сроком хранения в один год.

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

Особенности настройки резервного копирования PostgreSQL

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

1. Проверить, что на Master- и Standby-нодах выставлены одинаковые настройки сервиса PostgreSQL согласно документации CommVault:
   documentation.commvault.com/commvault/v11_sp14/article?p=21491.htm
2. Проверить, чтобы параметры, указанные в Backup Troubleshooting, соответствовали тем, что указаны по ссылкам:
   documentation.commvault.com/commvault/v11_sp14/article?p=21723.htm
   documentation.commvault.com/commvault/v11_sp14/article?p=21518.htm
3. Убедиться, что права доступа к серверу БД и базам были выставлены согласно следующим требованиям:
   documentation.commvault.com/commvault/v11_sp14/article?p=21523.htm

Восстановление

Резервное копирование — это хорошо. Естественно, нас интересует не только сам процесс его создания, но и восстановления. Ради чего это всё и делается.

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

1. Для восстановления БД на определённый момент времени, чтобы получить доступ к данным, которые, например, могли быть удалены из БД;
2. В случае потери всего кластера БД PostgreSQL.

Для восстановления БД достаточно прочитать документацию по этой ссылке: documentation.commvault.com/commvault/v11_sp14/article?p=21502.htm

Также мы бы акцентировать ваше внимание на следующих особенностях и шагах при восстановлении:

1. ОБЯЗАТЕЛЬНО выполняйте процедуру восстановления вместе с администратором БД PostgreSQL. Это поможет вам избежать неверных действий и быстро решать проблемы, возникающие в процессе восстановления;
2. Восстановление необходимо производить на ноду с ролью Master;
3. При восстановлении обязательно проверить, чтобы после окончания операции не стартовали службы PostgreSQL;
4. В восстановленной ноде поменять настройки на роль Master, т.к. в нашем случае мы делали резервное копирование Standby ноды;
5. На Standby-ноде отключить службы, на Master-ноде их включить, далее включить на Standby-ноде и настроить заново репликацию.

Заключение

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

Надеемся наш опыт поможет вам в настройке резервного копирования администратором БД PostgreSQL.

Авторы:
Сергей Александров, руководитель группы резервного копирования, Softline
Артём Хмеленко, ведущий инженер, Softline