Правила эффективного резервного копирования и аварийного восстановления из облака

Актуальность резервного копирования

Востребованность систем резервного копирования обусловлена четырьмя основными негативными факторами. Первый – это различные поломки, которые могут происходить при эксплуатации ИТ- инфраструктуры. Независимо от того, насколько современное и качественное оборудование установлено в организации, какой бы уровень отказоустойчивости ни был заявлен производителем, – никто не застрахован от выхода из строя хостов, отдельных дисков, дисковых массивов и других компонентов. Второй – риск масштабной катастрофы, которая приведет к выходу из строя целого дата-центра или конкретной зоны доступности. Третий – огромное количество вредоносного ПО, от которого необходимо защищаться. Вирусы так же могут стать причиной выхода из строя серверного оборудования и потери данных. Четвертый – человеческий фактор. Сбой может произойти по случайным обстоятельствам, например в результате плановых аварийно-восстановительных работ, а также из-за злонамеренных действий сотрудников.

При выборе технологии резервного копирования важно учитывать, что в период восстановления из резервных копий какое-то время система будет недоступна. Как отмечает эксперт группы архитектуры решений Cloud.ru Юлий Новиков, на эффективность восстановления влияют несколько метрик. Во время штатного поведения информационной системы делаются ее периодические бэкапы. Временной интервал между последним бэкапом и моментом сбоя (Recovery Point Objective, RPO) определяет, какой объем данных может быть потерян и из какой точки компания может восстановиться. Когда произошла аварийная ситуация, определенное время занимает принятие решения: в результате мониторинга специалисты понимают, что ошибка произошла, оценивают риски, которые она несет, выбирают инструмент и переходят к настройке  параметров для старта восстановительных работ. Следующие метрики – это RTO (Recovery Time Objective, целевое время восстановления) и WRT (Work Recovery Time, время, необходимое на восстановление работоспособности бизнес-функций).

«К последнему относятся, например, сетевые настройки, настройки правил взаимодействия информационных систем друг с другом и т. д. На это тоже надо закладывать время. Нужно понимать, что после восстановления резервных копий информационная система не восстанавливается сама по себе. Специалистам необходимо провести ряд определенных шагов, и только после этого система будет готова к работе, окажется идентичной той системе, которая была до аварии», – пояснил Юлий Новиков.

Варианты резервного копирования в облако Cloud.ru

Согласно общепринятому правилу бэкапирования, хотя бы одна из сделанных резервных копий должна храниться в удаленном от основной системы хранения месте или на другом носителе – в частности, в облаке. Например, в портфеле сервисов Cloud.ru есть два основных инструмента, с помощью которых клиент может обеспечить резервное копирование и аварийное восстановление данных: Veeam Backup and Replication (VBR) и Veeam Cloud Connect (VCC). Также имеется нативный инструмент для проведения репликаций: VMware Cloud Director Availability (vCDA).

Агентский бэкап с помощью инструментов Veeam и сервиса Cloud.ru можно организовать, если инфраструктура компании развернута on prem или в облаке стороннего провайдера. Если у клиента нет собственной системы резервного копирования на базе Veeam (VBR), ему необходимо установить на уровне операционной системы программу-агент, которую предоставляет Cloud.ru. Далее клиент настраивает определенные политики в соответствии с собственными требованиями, и резервные копии начинают сохраняться в облачном репозитории провайдера.

В случае, если у клиента установлена собственная система VBR, он может настроить резервное копирование в облако Cloud.ru прямо в собственной панели управления.

В свою очередь, репликация с помощью инструмента vCDA может происходить на собственной площадке клиента на базе VMware, либо Cloud.ru предоставляет модуль vCDA через свою техническую поддержку бесплатно, без необходимости приобретения дополнительных лицензий. Провайдер сообщает клиенту параметры site name и endpoint, с помощью которых настраивается пиринг (связанность) между площадками. После этого можно начинать настраивать репликацию в облаке Cloud.ru.

В инструменте Veeam тоже можно настроить репликацию, но в этом случае важно учитывать два нюанса. Во-первых, репликация через Veeam будет работать, только если у клиента есть собственный сервис VBR. Во-вторых, это возможно только в инфраструктуре на базе VMware. С Hyper-V, KVM и другими сторонними решениями она не работает.

Сценарии и особенности применения бэкапов и репликации

Функциональное отличие резервного копирования от репликации заключается в том, что при бэкапе резервные копии складываются непосредственно в репозиторий, а репликация – это, условно говоря, запись «живых» изменений инфраструктуры заказчика в хранилище облачного провайдера. То есть в случае с резервным копированием происходит снимок конкретного состояния виртуальной машины на конкретный момент времени. В случае с репликацией запись изменений происходит непрерывно.

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

«В Cloud.ru клиент может получить все эти сервисы, но управление ими останется на его стороне. Мы сейчас видим много запросов, когда компания готова отдать на аутсорс какую-то часть сервисов – например, потому, что хочет сфокусироваться на развитии собственных сервисов и решении бизнес-задач. В данном случае наши партнеры, такие, как ОБИТ, могут взять на себя задачи по управлению сервисами, их настройке, согласованию с клиентом сроков и времени восстановления», – добавил Юлий Новиков.