В предыдущих постах мы делились инструкцией по настройке резервного копирования И репликация на базе Veeam. Сегодня мы хотим поговорить о резервном копировании с помощью Commvault. Инструкций не будет, но мы расскажем, что и как уже резервируют наши клиенты.
Система резервного копирования СХД на базе Commvault в дата-центре ОСТ-2.
Как это работает?
Commvault — это платформа для резервного копирования приложений, баз данных, файловых систем, виртуальных машин и физических серверов.Исходные данные могут находиться на любой площадке: на стороне нашего клиента, в другом коммерческом дата-центре или в облаке.
Клиент устанавливает агент на объекты резервного копирования – Агент iData – и настраивает его в соответствии с необходимыми политиками резервного копирования.
iData Agent собирает необходимые данные, сжимает, дедуплицирует, шифрует и передает их в систему резервного копирования DataLine. Прокси-серверы обеспечить связность клиентской сети с нашей сетью, изоляцию каналов, по которым передаются данные.
На стороне DataLine принимаются данные от iData Agent. Сервер медиаагента и отправляет на хранение в системы хранения, ленточные библиотеки и т.д. Все это управляется Коммсерве .
В нашей конфигурации основной сервер управления расположен на площадке OST, а резервный сервер — на площадке NORD. По умолчанию данные клиента хранятся на одной площадке, но вы можете организовать резервное копирование сразу в две площадки или настроить расписание переноса резервных копий на вторую площадку.
Эта опция называется «вспомогательная копия».
Например, все полные резервные копии в конце месяца будут автоматически продублированы или перемещены на второй сайт. 
Схема работы системы резервного копирования Commvault.
Система резервного копирования работает преимущественно на виртуализации VMware: серверы CommServe, Media Agent и Proxy развернуты на виртуальных машинах.
Если клиент использует наше оборудование, то резервные копии размещаются на системе хранения данных Huawei OceanStor 5500 V3. Для резервного копирования клиентских систем хранения и хранения резервных копий в ленточных библиотеках на физических серверах используются отдельные Media Agents.
Что важно для клиентов?
По нашему опыту, клиенты, выбирающие Commvault для резервного копирования, обращают внимание на следующие моменты.Консоль.
Клиенты хотят сами управлять резервными копиями.
Все основные операции доступны в консоли Commvault:
- добавление и удаление серверов для резервного копирования;
- настройка iData Agent;
- создание и ручной запуск задач;
- самостоятельное восстановление резервных копий;
- настройка уведомлений о статусе задач резервного копирования;
- ограничение доступа к консоли в зависимости от роли и группы пользователей.
Дедупликация.
Дедупликация позволяет находить и удалять повторяющиеся блоки данных в процессе резервного копирования.
Таким образом, это помогает экономить место на системах хранения и уменьшает объем передаваемых данных, снижая требования к скорости канала.
Без дедупликации резервные копии заняли бы в два-три раза больше объема исходных данных.
В случае с Commvault дедупликацию можно настроить на стороне клиента или на стороне медиа-агента.
В первом случае неуникальные блоки данных даже не будут передаваться на сервер медиаагента.
Во втором повторяющийся блок отбрасывается и не записывается в систему хранения.
Эта дедупликация блоков основана на хэш-функциях.
Каждому блоку присваивается хэш, который хранится в хеш-таблице, своего рода базе данных (база данных дедупликации, DDB).
При передаче данных хеш «взламывается» через эту базу данных.
Если такой хэш уже существует в базе данных, то блок помечается как неуникальный и не передается на сервер медиаагента (в первом случае) или не записывается в систему хранения данных (во втором).
Благодаря дедупликации нам удается сэкономить до 78% места в системе хранения.
На данный момент на СХД хранится 166,4 ТБ.
Без дедупликации нам пришлось бы хранить 744 ТБ.
Возможность разграничить права.
Commvault имеет возможность устанавливать различные уровни доступа к управлению резервным копированием.
Так называемые «роли» определяют, какие действия будут допустимый пользователя по отношению к объектам резервного копирования.
Например, разработчики смогут восстановить сервер с базой данных только в определенное место, а администратор сможет запустить внеочередное резервное копирование этого же сервера и добавить новых пользователей.
Шифрование.
Зашифровать данные во время резервного копирования через Commvault можно следующими способами:
- на стороне клиентского агента: данные в этом случае будут переданы в резервную систему в зашифрованном виде;
- на стороне Медиа-агента;
- на канальном уровне: данные шифруются на стороне агента клиента и расшифровываются на сервере медиаагента.
Немного статистики
По состоянию на середину декабря у нас есть 27 клиентов, выполняющих резервное копирование с помощью Commvault. Большинство из них — розничные торговцы и финансовые учреждения.Общий объем исходных данных копии — 65 ТБ.
В день выполняется около 4400 задач.
Ниже представлена статистика по выполненным заданиям за последние 16 дней.
Наиболее часто используемые резервные копии с помощью Commvault — это файловая система Windows, базы данных SQL Server и Exchange. 
А теперь обещанные дела.
Хоть и обезличенные (NDA передает привет :)), они дают представление о том, почему и как клиенты используют резервное копирование на базе Commvault. Ниже приведены случаи клиентов, которые используют одну систему резервного копирования, т. е.
общее программное обеспечение, серверы медиа-агентов и системы хранения.
Дело 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 и файлов журнала было настроено с указанной частотой.
Файлы журналов архивировались каждые 15 минут или по достижении определенного размера.
Для сокращения времени восстановления базы данных мы настроили двухуровневое хранилище резервных копий на базе системы хранения и ленточной библиотеки.
Рабочие копии хранятся на дисках с возможностью восстановления в любой момент в течение недели.
Когда резервная копия становится старше 1 недели, она перемещается в архив, в ленточную библиотеку, где хранится еще 30 дней.
Полное резервное копирование одной из баз данных объемом 181 ГБ выполняется за 1 час 54 минуты.
При настройке резервного копирования мы использовали интерфейс SAP backint, который позволяет интегрировать сторонние системы резервного копирования с SAP HANA Studio. Таким образом, резервными копиями можно управлять непосредственно из консоли SAP. Это облегчает жизнь администраторам SAP, которым не нужно привыкать к новому интерфейсу.
Управление резервным копированием также доступно заказчику через стандартную клиентскую консоль Commvault. 
Это все на сегодня.
Задавайте вопросы в комментариях.
Теги: #Резервное копирование #Хранение данных #Сжатие данных #Восстановление данных #резервное копирование #DataLine #Commvault #дедупликация #резервное копирование базы данных
-
Прозрачные Процессы Удаленного Тестирования
19 Oct, 24 -
Сегодняшние Проблемы С Гласными В Gmail
19 Oct, 24 -
Эпоха Плоских Потолочных Микрофонов
19 Oct, 24
