В этой статье мы рассмотрим наш опыт использования CommVault для резервного копирования PostgreSQL. Для этого мы разберем небольшую часть одного из наших прошлых проектов, где мы настроили резервное копирование базы данных PostgreSQL у клиента.
О компании CommVault
CommVault — это единая масштабируемая платформа, обеспечивающая интегрированную защиту данных и управление контентом.Платформа поддерживает программные модули с функциями резервного копирования и восстановления данных, архивирования, дедупликации, репликации, иерархического распределения носителей и шифрования.
Модули платформы работают с корпоративным контентом из различных источников и обеспечивают сквозной поиск информации в корпоративной среде и ее постоянную доступность даже из архивов благодаря единой интеллектуальной индексации документов в виртуальном хранилище.
Платформа также оснащена передовыми инструментами аналитики, которые формируют отчеты о действиях пользователей и приложений, а также о функционировании инфраструктуры.
CommVault защищает, восстанавливает и управляет данными и доступом в физических и виртуальных средах.
О резервном копировании PostgreSQL
Для резервного копирования базы данных PostgreSQL используется агент (iDataAgent), который устанавливается на сервер, на котором работает база данных.Агент предназначен для эффективного управления и защиты критически важных бизнес-данных в базах данных PostgreSQL. Вы можете использовать этот агент для резервного копирования и восстановления всего сервера PostgreSQL или отдельных баз данных.
При необходимости вы также можете восстановить отдельные таблицы.
Основные особенности:
PostgreSQL iDataAgent обеспечивает гибкость резервного копирования баз данных в различных режимах и их восстановление за минимальное время.Вы можете в любое время выполнить полную резервную копию или резервную копию всего сервера PostgreSQL, отдельных баз данных или архивных журналов.
Возможности резервного копирования и восстановления, которые можно выполнять в разных режимах:
- iDataAgent предоставляет возможность восстановить весь сервер PostgreSQL. Все базы данных, расположенные на исходном сервере, можно восстановить на целевом сервере.
- Определите одну базу данных или группу баз данных в качестве данных субклиента и выполните резервное копирование и восстановление.
- Создавайте резервные копии журналов только на сервере PostgreSQL. Эти файлы журналов можно использовать для восстановления транзакций базы данных, потерянных из-за сбоя операционной системы или диска.
- Восстановите весь сервер PostgreSQL до определенного момента времени для резервного копирования на основе файловой системы.
- Просмотрите и проверьте состояние операций резервного копирования и восстановления с помощью контроллера заданий и средства просмотра событий в консоли CommCell. Отслеживайте статус своей работы с помощью отчетов, которые можно сохранять и распространять.
- Используйте резервное копирование на уровне блоков как более быстрый способ резервного копирования данных, поскольку резервное копирование выполняется только для экстентов (или измененных частей базы данных), а не для всей базы данных PostgreSQL.
- Дедупликация на уровне блоков.
Дедупликация обеспечивает более разумный способ хранения данных за счет выявления и удаления дубликатов в операциях защиты данных.
Архитектура
Схема
Как это работает: Платформа CommVault разворачивается в сети в составе сервера управления CommServe и отдельного сервера MediaAgent (рекомендуется использовать физический сервер).
На сервере с базой данных PostgreSQL устанавливается агент (iDataAgent) и его политики резервного копирования настраиваются в соответствии с требованиями.
iDataAgent собирает необходимые данные, сжимает, дедуплицирует, при необходимости шифрует и передает их MediaAgent. Далее данные помещаются в систему хранения, ленточную библиотеку или облачное хранилище.
Для восстановления данные извлекаются из хранилища и копируются на сервер с PostgreSQL. Конфигурация в консоли CommVault Теперь рассмотрим, как это сделать в консоли управления.
1. Чтобы запустить резервное копирование базы данных в данный момент, необходимо в консоли CommCell Browser выбрать: Клиентские компьютеры | | PostgreSQL | | DumpBasedBackupSet. Щелкните правой кнопкой мыши по папке по умолчанию В субклиент и выбери Резервное копирование .
2. Выберите Полный в качестве типа резервной копии и выберите Немедленный .
3. Нажмите ХОРОШО .
Резервное копирование начнется PostgreSQL .
4. Пока задача выполняется, ее статус можно отслеживать в их окнах.
Контролер заданий консоли КомСелл .
5. После завершения задачи вы можете просмотреть подробную информацию о выполненной задаче в окне История резервного копирования .
Выберите папку по умолчанию В субклиент и выбери История резервного копирования .
6. В окне История резервного копирования Вы можете просмотреть следующие данные о выполненных задачах:
— Ошибки резервного копирования при выполнении задачи;
— элементы, резервное копирование которых прошло успешно;
— Подробности задачи;
- События;
- Лог-файлы;
— Носители, на которых хранятся данные.
Почему вы можете создавать резервные копии Резервное копирование на основе дампа:
- системные базы данных PostgreSQL;
- Пользовательские базы данных PostgreSQL;
- Резервное копирование на основе файловой системы.
- Лог-файлы.
- Файлы приложений PostgreSQL (файлы приложений);
- Данные операционной системы.
Задача
Клиенту необходимо было развернуть платформу CommVault для резервного копирования своих сервисов.Одним из сервисов была база данных PostgreSQL, которая была развернута в конфигурации кластера из двух узлов: Master и Standby. Оба работали на физических серверах.
Особенности конфигурации PostgreSQL клиента Конфигурация кластера PostgreSQL была выбрана для обеспечения отказоустойчивости сервера базы данных.
Клиент сделал резервную копию базы данных PostgreSQL с помощью pg_dump.
Схема работы представлена на рисунке ниже: 
Настройка резервного копирования с помощью CommVault
Чтобы унифицировать платформу резервного копирования и воспользоваться преимуществами хранения резервных копий, мы решили использовать CommVault для резервного копирования базы данных PostgreSQL. Поскольку клиент использовал конфигурацию кластера PostgreSQL; для резервного копирования мы решили использовать опцию резервного копирования на основе файловой системы.При этом нам пришлось отказаться от использования блочного резервного копирования (Block Level Backup), поскольку используемая версия ядра Linux, на котором развернут PostgreSQL, оказалась выше официально поддерживаемой CommVault. В связи с тем, что услуга критична для организации, мы решили составить график резервного копирования по таблице:
| Полная копия | Журналы транзакций | |
|---|---|---|
| Расписание | Один раз в день, в 23:00. | Каждый час в течение 24 часов |
| Срок хранения копии | 7 дней | 1 день |
Резервное копирование выполнялось по схеме ниже: 
Резервные копии были взяты с резервного сервера PostgreSQL и сохранены на сервере с установленным MediaAgent. Далее раз в месяц полные копии размещались в облаке Amazon со сроком хранения один год.
Все необходимые настройки были выполнены и резервное копирование успешно завершено.
Особенности настройки резервного копирования PostgreSQL При установке и настройке резервного копирования мы столкнулись с некоторыми трудностями, которые перечислены ниже.
Думаю, будет полезно учесть эти особенности при выполнении подобных проектов и при настройке администраторов баз данных PostgreSQL.
- Убедитесь, что главный и резервный узлы имеют одинаковые настройки службы PostgreSQL согласно документации CommVault: document.commvault.com/commvault/v11_sp14/articleЭp=21491.htm
- Убедитесь, что параметры, указанные в разделе «Устранение неполадок резервного копирования», соответствуют указанным в ссылках: document.commvault.com/commvault/v11_sp14/articleЭp=21723.htm document.commvault.com/commvault/v11_sp14/articleЭp=21518.htm
- Убедитесь, что права доступа к серверу базы данных и базам данных установлены в соответствии со следующими требованиями: document.commvault.com/commvault/v11_sp14/articleЭp=21523.htm
Естественно, нас интересует не только процесс его создания, но и восстановление.
Зачем это все делается? В данной ситуации, исходя из нашего опыта, клиенту может потребоваться восстановление в 2 случаях:
- Восстановить базу данных на определенный момент времени, чтобы получить доступ к данным, которые, например, могли быть удалены из базы данных;
- В случае потери всего кластера базы данных PostgreSQL.
- ОБЯЗАТЕЛЬНО выполните процедуру восстановления совместно с администратором базы данных PostgreSQL. Это поможет вам избежать неправильных действий и быстро решить проблемы, возникающие в процессе восстановления;
- Восстановление необходимо выполнять на узле с ролью Master;
- При восстановлении обязательно проверьте, чтобы службы PostgreSQL не запускались после завершения операции;
- В восстанавливаемом узле измените настройки на роль Master, поскольку в нашем случае мы сделали резервную копию узла Standby;
- Отключите службы на резервном узле, включите их на главном узле, затем включите их на резервном узле и перенастройте репликацию.
Заключение
В этой статье мы не учли резервное копирование самой ОС Linux и других систем.Это следует делать отдельно.
В документации CommVault это подробно описано.
Если наша статья вызовет интерес и будет много запросов, мы обязательно опишем, как сделать резервную копию других систем.
Напишите в комментариях, какие системы были бы вам интересны.
Надеемся, наш опыт поможет вам в настройке резервного копирования администратору базы данных PostgreSQL. Авторы: Сергей Александров, руководитель группы резервного копирования Softline Артём Хмеленко, ведущий инженер Softline Теги: #Backup #postgresql #backup #Commvault #Softline #Softline
-
Курсы Mcse 2003 – Обзор
19 Oct, 24 -
Templatemonster.com. Теперь На Русском
19 Oct, 24 -
Изучайте Английский Дешево И Эффективно
19 Oct, 24 -
Crc И Номера Ячеек
19 Oct, 24 -
Устали Регистрироваться?
19 Oct, 24
