Резервное копирование с помощью Commvault: немного статистики и кейсов

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

СХД системы резервного копирования на базе Commvault в дата-центре OST-2.

Как это работает?

Commvault – это платформа для резервного копирования приложений, баз данных, файловых систем, виртуальных машин и физических серверов. Исходные данные при этом могут быть на любой площадке: у нас – на стороне клиента, в другом коммерческом дата-центре или облаке.

Клиент устанавливает на объекты резервного копирования агент – iData Agent – и настраивает его в соответствии с требуемыми политиками бэкапа. iData Agent собирает необходимые данные, сжимает, дедуплицирует, шифрует и передает их в систему резервного копирования DataLine.

Proxy-серверы обеспечивают связность клиентской сети и нашей сети, изоляцию каналов, по которым передаются данные.

На стороне DataLine данные от iData Agent принимает Media Agent Server и отправляет на хранение на СХД, ленточные библиотеки и пр. Всем этим управляет CommServe. В нашей конфигурации основной управляющий сервер находится на площадке OST, резервный – на площадке NORD.

По умолчанию данные клиента складываются на одну площадку, но можно организовать резервное копирование сразу на две локации или настроить расписание по переносу бэкапов на вторую площадку. Эта опция называется “дополнительная копия данных” (auxiliary copy). Например, все полные бэкапы в конце месяца будут автоматически дублироваться или переезжать на вторую площадку.

Схема работы системы резервного копирования Commvault.

Система резервного копирования работает преимущественно на виртуализации VMware: на виртуальных машинах развернуты серверы CommServe, Media Agent и Proxy-серверы. Если клиент использует наше оборудование, то бэкапы размещаются на СХД Huawei OceanStor 5500 V3. Для резервного копирования клиентских СХД, хранения бэкапов на ленточных библиотеках используются отдельные Media Agent на физических серверах.

Что важно клиентам?

Из нашей практики клиенты, которые для резервного копирования выбирают Commvault, обращают внимание на следующие моменты.

Консоль. Клиенты хотят управлять резервным копированием самостоятельно. В консоли Commvault доступны все основные операции:

• добавление и удаление серверов на резервное копирование;
• настройка iData Agent;
• создание и ручной запуск заданий;
• самостоятельное восстановление резервных копий;
• настройка оповещений о статусе задач резервного копирования;
• разграничение доступа к консоли в зависимости от роли и группы пользователей.

Дедупликация. Дедупликация позволяет находить и удалять повторяющиеся блоки данных в процессе резервного копирования. Таким образом она помогает экономить место на СХД и уменьшает объем передаваемых данных, снижая требования к скорости канала. Без дедупликации, резервные копии занимали бы объем в два-три раза превышающий объем исходных данных.

В случае с Commvault дедупликацию можно настроить на стороне клиента или на стороне Media Agent. В первом случае неуникальные блоки данных даже не будут передаваться на Media Agent Server. Во втором повторяющийся блок отбрасывается и не записывается на СХД.

Такая блочная дедупликация основана на хэш-функциях. Каждому блоку присваивается хэш, который сохраняется в хэш-таблице, своего рода базе данных (Deduplication Database, DDB). При передаче данных хэш “пробивается” по этой базе. Если такой хэш уже есть в базе, то блок помечается как неуникальный и не передается на Media Agent Server (в первом случае) или не записывается на систему хранения данных (во втором).

Благодаря дедупликации нам удается экономить до 78% места в системе хранения. Сейчас на СХД хранится 166,4 ТБ. Без дедупликации нам пришлось бы хранить 744 ТБ.

Возможность разграничивать права. В Commvault есть возможность устанавливать разные уровни доступа к управлению резервным копированием. Так называемые “роли” определяют, какие действия будут разрешены пользователю по отношению к объектам резервного копирования. Например, разработчики смогут только восстанавливать сервер с базой данных в определенное место, а администратор сможет запускать внеочередное резервное копирование для этого же сервера, добавлять новых пользователей.

Шифрование. Шифровать данные во время резервного копирования через Commvault можно следующими способами:

• на стороне клиентского агента: данные в этом случае будут передаваться в систему резервного копирования уже в зашифрованном виде;
• на стороне Media Agent;
• на уровне канала: данные шифруются на стороне клиентского агента и расшифровываются на Media Agent Server.

Доступные агоритмы шифрований: Blowfish, GOST, Serpent, Twofish, 3-DES, AES (рекомендуемый Commvault).

Немного статистики

На середину декабря с помощью Commvault у нас бэкапятся 27 клиентов. Большую часть из них составляют ритейлеры и финансовые организации. Общий объем исходных данных копии занимает 65 ТБ.

В день выполняется около 4400 заданий. Ниже статистика по выполненным заданиям за последние 16 дней.

Больше всего через Commvault бэкапят Windows File System, SQL Server и базы данных Exchange.

А теперь обещанные кейсы. Хоть и обезличенные (NDA передает привет :)), но они дают представление, для чего и как клиенты используют бэкап на базе Commvault. Ниже представлены кейсы по клиентам, которые используют единую систему резервного копирования, т. е. общие ПО, Media Agent Servers и системы хранения.

Кейс 1

Заказчик. Российская торгово-производственная компания кондитерского рынка с распределенной сетью филиалов по России.

Задача.Организация резервного копирования для баз данных Microsoft SQL, файловых серверов, серверов приложений, почтовые ящики Exchange Online.

Исходные данные располагаются в офисах по всей России (более 10 городов). Бэкапить нужно на площадку DataLine с последующим восстановлением данных в любой из офисов компании.
При этом клиент хотел полного самостоятельного управления с разграничением доступа.
Глубина хранения – год. Для Exchange Online – 3 месяца для оперативных копий и год для архивов.

Решение. Для баз данных была настроена дополнительная копия на вторую площадку: последний полный бэкап месяца переносится на другую площадку и хранится там год.

Качество каналов из удаленных офисов клиента не всегда позволяло делать бэкап и восстановление в оптимальные сроки. Чтобы уменьшить объем передаваемого трафика, на стороне клиента была настроена дедупликация. Благодаря ей время полного резервного копирования стало приемлемым с учетом удаленности офисов. Например, полный бэкап базы данных объемом 131 ГБ из Санкт-Петербурга делается за 16 минут. Из Екатеринбурга база данных 340 ГБ бэкапится 1 час 45 минут.

С помощью ролей клиент настроил для своих разработчиков разные разрешения: только на резервное копирование или восстановление.

Кейс 2

Заказчик. Российская сеть магазинов детских товаров.
Задача. Организация резервного копирования для:
высоконагруженного кластера MS SQL на базе 4 физических серверов;
виртуальных машин с сайтом, серверами приложений, 1С, Exchange и файловыми серверами.
Вся указанная инфраструктура клиента разнесена между площадками OST и NORD.
RPO для SQL-серверов – 30 минут, для остальных – 1 сутки.
Глубина хранения – от 2 недель до 30 дней в зависимости от типа данных.

Решение. Выбрали сочетание решений на базе Veeam и Commvault. Для файлового резервного копирования из нашего облака используется Veeam. Сервера баз данных, Active Directory, почтовые и физические сервера бэкапятся через Commvault.

Для достижения высокой скорости резервного копирования клиент выделил на физических серверах с MS SQL отдельный сетевой адаптер под задачи бэкапа. Полный бэкап базы данных объемом 3,4 ТБ занимает 2 часа 20 минут, а полное восстановление – 5 часов 5 минут.

У клиента был большой объем исходных данных (почти 18 ТБ). Если складывать данные на ленточную библиотеку, как клиент это делал ранее, то потребовалось бы несколько десятков картриджей. Это усложнило бы менеджмент всей системы резервного копирования клиента. Поэтому в итоговой реализации ленточная библиотека была заменена на СХД.

Кейс 3

Заказчик. Сеть супермаркетов в СНГ
Задача. Заказчик хотел организовать резервное копирование и восстановление SAP-систем, размещавшихся в нашем облаке. Для баз данных SAP HANA RPO=15 минут, для виртуальных машин с серверами приложений RPO=24 часа. Глубина хранения – 30 дней. В случае аварии RTO=1 час, для восстановления копии по запросу RTO=4 часа.

Решение. Для БД HANA было настроено резервное копирование DATA-файлов и Log-файлов c заданной периодичностью. Log-файлы архивировались каждые 15 минут или при достижении определенного размера.

Чтобы уменьшить время восстановления БД, мы настроили двухуровневое хранение бэкапов на базе СХД и ленточной библиотеки. На диски складываются оперативные копии с возможностью восстановления на любой момент в течение недели. Когда бэкап становится старше 1 недели, он перемещается в архив, на ленточную библиотеку, где хранится еще 30 дней.

Полный бэкап одной из баз данных объемом 181 ГБ делается за 1 час 54 минуты.

При настройке резервного копирования использовался backint интерфейс SAP, позволяющий интегрировать системы резервного копирования сторонних разработчиков с SAP HANA Studio. Поэтому резервным копированием можно управлять напрямую из консоли SAP. Это упрощает жизнь SAP-администраторам, которым не нужно привыкать к новому интерфейсу.

Управление резервным копированием также доступно клиенту через стандартную клиентскую консоль Commvault.

На сегодня все. Задавайте вопросы в комментариях.

Источник: habr.com