Почему бэкап — это не DR

Часто из-за экономии компании для Disaster Recovery используют резервное копирование и пребывают в уверенности, что позаботились о послеаварийном восстановлении.

В сегодняшней статье мы разберемся с задачами бэкапа и Disaster Recovery, а также выясним, чем чревата подмена одного другим.

Для чего делают бэкап

Резервное копирование данных (бэкап) — это процесс создания копии данных на отдельном носителе или в другом месте с целью восстановления этих данных в случае их потери, повреждения или других непредвиденных ситуаций.

Благодаря бэкапу можно восстановить данные после их потери, повреждения, например, из-за:

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

Таким образом, главная задача резервного копирования — обеспечить безопасность и сохранность информации, минимизируя риски потери важных данных.

Для чего нужен Disaster Recovery (DR)

Disaster Recovery (DR) — это стратегия и процедуры, направленные на быстрое восстановление инфраструктуры, приложений и данных после серьезного сбоя или катастрофы. Важный элемент DR — резервная площадка. Это может быть другой дата-центр или инфраструктура в облаке. На резервной площадке заранее создается дубль основной инфраструктуры со всеми необходимыми настройками и доступами, настраивается синхронизация данных между основной и резервной площадками. Благодаря этому в случае аварии можно быстро переключиться на резервную площадку и продолжить работу.

Главная задача Disaster Recovery — обеспечить быстрое восстановление работоспособности ИТ-систем и дать компании гарантию того, что она сможет работать непрерывно, несмотря на атаки, сбои, аварии и прочие инциденты.

Задачи — это не единственное, в чем отличаются бэкап и DR. Есть еще и важные технические аспекты. В первую очередь это возможности решений в части RTO и RPO.

RTO и RPO

Прежде чем сосредоточимся на возможностях бэкапа и DR в части этих показателей, давайте вспомним, что они означают. У этих терминов есть технические и бизнес-аспекты.

RTO (Recovery Time Objective) — целевое время восстановления. С точки зрения бизнеса, этот показатель определяет максимальное допустимое время, которое бизнес может позволить себе на восстановление после сбоя без ущерба для операций и репутации. Техническая часть RTO влияет на стратегии и инструменты, используемые для восстановления. Например, если RTO составляет 1 час, значит нам нужно такое решение, которое восстановит работоспособность ИТ-сервиса за это время. Таким образом, бизнес должен определить, сколько он сможет обойтись без определенной бизнес-функции, а ИТ-команда уже подбирает соответствующее решение.

RPO (Recovery Point Objective) — целевая точка восстановления. Для бизнеса этот показатель означает, сколько данных он готов потерять в случае сбоя или катастрофы (например, данные за день или только за час). На язык технарей это переводится как: с какой частотой нужно делать бэкапы или синхронизировать данные между основной и резервной площадкой. Например, если RPO составляет 4 часа, это означает, что бэкапы должны создаваться как минимум каждые 4 часа.

У инструментов бэкапа и DR разные возможности по RTO и RPO.

RTO и RPO в бэкапе

У резервного копирования RTO и RPO скромнее. Максимальная частота создания резервных копий зависит от многих факторов, таких как:

• производительность дисковой подсистемы, на которой расположены данные, которые требуется сохранить;
• производительность системы резервного копирования (СРК).

Минимальное RPO для бэкапа грубо можно оценить в 5 минут, если, например, речь идет об инкременте или бэкапе логов СУБД. Чаще всего RPO бэкапа будет сильно больше. Если вы бэкапите большие массивы данных или объемные виртуальные машины с частотой раз в 5 минут, то система резервного копирования (СРК) просто не будет успевать обрабатывать такие объемы. Задача на бэкап виртуальной машины объемом 1 ТБ не сможет отработать за 10 минут. СРК будет пропускать задачи, пока не сделает текущую. Таким образом, требуемая частота резервного копирования не будет соблюдаться.

RTO для резервного копирования также определяется несколькими аспектами: типом бэкапа (полный, инкрементный), объемом данных, готовностью инфраструктуры, где будет развернута резервная копия. Если восстановление из бэкап не тестируется регулярно (а это важно делать), то в процессе может оказаться, что данные повреждены и нужно брать другой, более ранний бэкап и начинать все сначала.

RTO и RPO в Disaster Recovery

У DR более широкие возможности благодаря механизму синхронизации (репликации). Если при асинхронной репликации можно рассчитывать на RPO 5 минут, то в решениях с синхронной репликацией между основной и резервной площадками можно добиться RPO близкого к нулю. Это означает, что в любой момент времени на обеих площадках находятся идентичные копии данных. В случае отказа одной и переключения на другую площадку мы не потеряем данные.

RTO в DR более предсказуемый, чем при восстановлении из бэкапа. В случае с DR мы имеем уже заранее подготовленную и настроенную инфраструктуру, где реплика данных или виртуальной машины находится в режиме ожидания и готова подхватить работу практически с любого места, если мы говорим о таких инструментах, как Veeam Cloud Connect Replication и VMware Cloud Availability.

Есть решения, подобные катастрофоустойчивому облаку, которые позволяют сделать переключение на резервную площадку и продолжить там работу уже через 2,5 минуты.

Решения с нулевым RPO и RTO в несколько минут дорогостоящие, так как требуют полного дублирования оборудования и инфраструктуры на обеих площадках. Обычно к ним прибегают компании, для которых даже незначительный простой несет бОльшие убытки, чем стоимость таких решений.

Почему бэкап на заменяет DR

Представим ситуацию. Компания делает бэкап виртуальных машин и данных, полагая, что это застрахует от любых непредвиденных ситуаций. Однако, когда произошел серьезный сбой в их основном дата-центре, виртуальная инфраструктура стала недоступна и бэкапы просто негде было развернуть. Даже если в этой истории бэкапы лежали бы на другой площадке, все равно ушло бы время, чтобы развернуть необходимую инфраструктуру с нужными сетевыми настройками и интеграциями на новой площадке. Наконец, время уйдет на разворачивание самой резервной копии (а она может завестись не с первого раза). В итоге у вас будут целые данные, но простой может быть непрогнозируемым.

Ошибка команды ИТ в этом примере в том, что с помощью бэкапа она хотела решить другую задачу, которую обычно решают инструментами Disaster Recovery (DR).

Почему DR не заменяет бэкап

Почему бэкап не годится для задач Disaster Recovery, мы вроде разобрались. Но вот почему DR-инструменты не могут закрыть задачи защиты данных? Ведь кажется, что можно тогда всесильный DR использовать и для этих целей. Приведем простой пример. Компания использует резервную площадку для восстановления и с заданной периодичностью отправляет туда реплики виртуальных машин. В корпоративную сеть попадает вирус-шифровальщик, который шифрует все, что попадается на его пути. Резервная площадка с репликами тут не поможет, так как туда скопируется такая же зашифрованная версия виртуальной машины.

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

Важный момент заключается в том, что DR-решения будут априори дороже, так как требуют х2 ресурсов. Если у вас нет высоких требований к скорости восстановления, то это будет напрасная переплата.

Вывод: DR и бэкап дополняют друг друга, но не заменяют

Disaster Recovery обеспечивает более эффективные и приемлемые RTO с RPO, чем бэкап. Бэкап же помогает защитить данные от потери.

DR должен быть в портфеле ИТ-инструментов компании, которая хочет обеспечить непрерывность бизнес-процессов наряду с защитой данных.

Действуя в обоих направлениях, бизнес получает 2 весомых преимущества:

1. Максимально полный инструментарий для быстрого восстановления инфраструктуры с приемлемыми показателями RTO и RPO.
2. Копию данных, которую можно использовать в случае утери или порчи.