Статья про то, как CommVault делает бэкап PostgreSQL

В данной статье мы рассмотрим наш опыт использования 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
Softline
54,97
Компания
Поделиться публикацией

Похожие публикации

Комментарии 14

    +1
    а чем ваше решение отличается от штатных средств копирования?
      0
      CommVault — это суровый энтерпрайз, когда количество объектов бекапирования сильно больше количества адекватных спецов, которые могли бы сделать тоже самое используя простые инструменты. Т.е. CommVault для одной базы, какой бы большой она ни была, не нужен.
        0
        А можно вопросик? Zalando — enterprise? А Яндекс? А Авито?

        Просто в моем понимании, суровый энтерпрайз — это какие-то консервативные области вроде авиации, банковского дела, нефтянки. У которых не было необходимости изменяться быстро в прошлом, т.к. и там все ОК. Мои примеры выше — это чисто коммерсы, которые возможно начинали как стартапы.
          0
          В статье сказано, что решение использовалось для бэкапа всех ресурсов компании. Статья только про PostgreSQL.
        0
        Выше в статье по этому поводу есть детальное описание. Кратко:
        1. Используется единое решение для резервного копирования.
        2. Есть возможность перемещать резервные копии на более дешёвые накопители (СХД, ленты и т.п.).
        3. Используется дедупликация для хранения резервных копий, что позволяет экономить пространство на СХД.
        4. В ПО для резервного копирования есть функционал по отслеживанию процесса резервного копирования и оповещения о результатах.
          +1
          А есть размеры копий, который были выполнены «старым» способ и какие они сейчас? Много ли толку от «дедупликация»…
            +1
            Не сравнивали
            0
            У нас, например, 400 гиговая база превращается в 30 гиговый дамп с помощью штатных «компрессоров». И еще скажите, пожалуйста, сильно ли отличается время восстановления из копии в отличии от того же pg_restore?
              0
              Обманул. Дамп весит 20 ГБ.
                +1
                Происходит быстрее раза в два. Естественно в каждом конкретном случае, на это будет влиять много факторов, например скорость сети, СХД и т.п. и будет отличаться.
                –1

                Ничего нового, кроме п.1.
                Все остальное реализуется ± стандартными средствами ОС и БД при помощи небольшого количества работы ops'а по автоматизации.
                Что хуже — CommVault не представляет себе специфику приложений, которые работают с БД… Поэтому кастомные решения выглядят более привлекательно.


                Если же речь про "кровавый" энтерпрайз, который покупает коробки… То вероятность увидеть там Oracle или MS SQL сильно выше, чем PostgreSQL

                0
                Это хорошо подходит для небольших БД, так как сливать раз в сутки бэкап БД размером в 15-20 ТБ уже так не выйдет. С свое время реализовывал бэкап больших БД через снапшоты на хранилках
                  0
                  Верно говорите! А если база на локальных дисках, то можно в общем случае использовать LVM снапшоты или btrfs/zfs-снапшоты, если такая файловая система на дисках.
                  0
                  Можно и 20 и 30 и 100 Тб бэкапить через бэкап системы типа NetBackup или CommVault, просто тут возникают некоторые тонкости и особенности. У нашего клиента есть базы на MSSQL размером в 100 Tb и как бы проблем нет, используется NetBackup, как я уже сказал на таких объёмах есть свои тонкости.

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

                  Самое читаемое