Несколько историй последнего года отлично показывают, что такое «данные пропали, а резервных копий не осталось». За последний год с атаками на ценные данные столкнулись как минимум три компании, которые понесли серьезные убытки:

• Сеть «Верный» подверглась хакерской атаке. Три дня почти в 1000 магазинов не работала оплата картами, а также терминалы самообслуживания. Не функционировали онлайн-сервисы — сайт и приложение. Убытки оценивались в 140 млн. рублей в день (сторонняя оценка на основе данных по выручке).

• Служба доставки СДЭК подверглась атаке шифровальщика. Пункты выдачи не обрабатывали посылки в ручном режиме, чтобы не допустить ошибок. В итоге они не работали несколько дней. Убытки по сторонним подсчетам могли достичь 1 млрд. рублей.

• А совсем недавно с вирусом шифровальщиком столкнулся медиахолдинг ВГТРК, в который входят множество телевизионных каналов. Ему пришлось прекратить онлайн-вещание, также были недоступны ряд сервисов.

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

Какие есть варианты резервирования данных

Начнем с базовых вещей.

Обеспечить целостность и доступность данных можно с помощью резервных копий.

Резервное копирование — один из обязательных аспектов отказоустойчивости. Это способ сохранить необходимые для работы сервиса данные для восстановления после сбоя, целенаправленной атаки или допущенной ошибки. Создавая резервную копию, мы, фактически, фиксируем целостное консистентное состояние данных. Но это не «бесплатно» — на создание копии необходимо выделять ресурсы и место в хранилище.

Объем необходимых ресурсов зависит от множества факторов, в частности, от максимально допустимого времени простоя бизнеса, т.е. от настроек резервного копирования и типа сохраняемых данных. Например, отсутствие четкой структуры в данных делает процесс более дорогим с точки зрения вычислительных ресурсов. Поэтому настройка резервного копирования всегда начинается с постановки бизнес-задачи — что именно надо хранить (сколько данных мы можем потерять без угрозы для бизнеса) и как быстро восстанавливать после сбоя. Это так называемая концепция RTO RPO.

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

Отталкиваясь от бизнес-задачи, необходимо планировать:

• Полноту копирования данных. Чтобы ускорить копирование, можно делать инкрементальные бэкапы.

• Метод и длительность хранения копий. Какие именно копии и за какой период стоит хранить.

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

• Процессы восстановления. Из каких — полных или инкрементальных — копий восстанавливаются данные, как быстро восстановить только часть данных и т.п.

• и многое другое.

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

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

Реплики бывают как локальные (в рамках одного хранилища), так и удаленные. Когда мы переходим от резервирования данных в одном дата-центре к их копированию в географически удаленные дата-центры, мы по сути обращаемся к метрокластеру. Это наиболее дорогая технология, которая обеспечивает высокую отказоустойчивость, поскольку это тот самый «план Б» на случай полного уничтожения дата-центра. Метрокластеры должны обеспечивать репликацию в режиме реального времени.

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

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

А можно отдать задачу на аутсорсинг специализированным сервисам. С учетом нехватки кадров на рынке в последнее время растет спрос как раз на сторонние сервисы, особенно когда об отказоустойчивости задумывается бизнес не из ИТ. В этом случае не надо брать на себя покупку и обслуживание систем, но придется платить за резервирование по принципу абонентской подписки. И этот подход вовсе не освобождает от необходимости выстраивать в компании процессы резервного копирования и восстановления — определять кто, когда создает копии, где и сколько они хранятся и т.п. Ответы на эти вопросы, как правило, лежат в плоскости оценки рисков компании. Условно, готовы ли мы потерять эти данные и как быстро нужно их восстановить.

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

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

Сегодня виртуализация — одна из базовых технологий организации ИТ-инфраструктуры. Развертывание на одном физическом сервере нескольких виртуальных машин (ВМ) под управлением гипервизора оптимизирует утилизацию ресурсов физического сервера. Для быстрого восстановления после аварий целесообразно сохранять копии не только данных, с которыми работает сервис, но и самой виртуальной инфраструктуры на уровне ВМ или всего гипервизора. Так же следует обеспечить надежное резервирование внутренних данных платформы виртуализации.

Большинство систем резервного копирования состоят из стандартных компонент — хранилища, серверов резервного копирования, бэкап-клиентов, сервера управления и т.п. В зависимости от сложности ИТ-инфраструктуры, они могут включать множество звеньев.

Как это выглядит на практике

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

Расскажу, зачем это нужно, на примере нашей системы управления виртуализацией VMmanager. Мы заложили в нее отказоустойчивость на уровне платформы. Можно развернуть гипервизор, настроить кластер и сразу же приступать к настройке доступности (действий в случае отказа отдельных компонент, а также последующего автоматического восстановления). Но кроме того VMmanager интегрирован с инструментом для резервного копирования виртуальных машин RuBackup.

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

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

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

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

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