Что объединяет супергероя в броне и современный бизнес, полностью зависимый от данных? Параноидальная предусмотрительность и готовый «План Б» на случай катастрофы. В материале IT-World — разбор отечественных решений для резервного копирования и аварийного восстановления, которые станут вашим «железным костюмом» в мире киберугроз.
У каждого крепкого бизнеса должны быть решения, обеспечивающие защиту и восстановление данных в случае различных ЧП.
Параноидальная предусмотрительность – одна из основных черт характера Тони Старка, главного героя комиксов и фильмов о Железном Человеке. У него всегда есть запасные костюмы/модули, дистанционные системы управления, аварийные протоколы и тому подобное. Возможность в любой непонятной ситуации переключиться на План Б, должна лежать в основе любого современного бизнеса, эффективность которого зависит от надежности ИТ-инфраструктуры — а это почти любой современный бизнес. Когда что-то пошло не так — кибератака, вирус, программа-вымогатель, физическое повреждение инфраструктуры — должен быть эффективно реализован план восстановления.
К сожалению, мир не становится безопаснее. Защита данных и возможность восстановления после сбоев — все более актуальные направления информационной безопасности любой организации. Потеря критически важных данных может привести не только к убыткам, но и к полной остановке бизнес-процессов.
Экспертное мнение
От бэкапа к устойчивости данных
Классический бэкап больше не защищает бизнес от реальных угроз. Компании переходят от точечных СРК к платформам устойчивости данны
Для предотвращения этого компании могут внедрять у себя как решения для резервного копирования данных (бэкап), так и программно-аппаратные комплексы для хранения архивов (ленточные библиотеки) и даже сервисы аварийного восстановления (DRaaS), дублирующие функционал основной ИТ-инфраструктуры в случае сбоя.
Цель этого материала — показать ИТ-директорам, какие продукты и сервисы для защиты сохранности данных реально доступны на рынке, какие сценарии восстановления они поддерживают и в какой мере соответствуют требованиям импортонезависимости и безопасности.
Три пути
Есть три подхода к обеспечению безопасности данных:
- Корпоративные платформы резервного копирования и восстановления данных;
- Облачные DRaaS-сервисы, которые предлагают аварийное восстановление в ЦОДах российских провайдеров;
- Гибридные сценарии, где решения, работающие на серверах предприятия работают в связке с решениями DRaaS.
Чтобы понять, какой из них подходит вашему предприятию, нужно провести тщательный анализ потребностей в резервном копировании и восстановлении. Начать можно с трех ключевых вопросов, которые в самом упрощенном виде звучат как «Что? Где? Когда?». Что нужно сохранять в резервных копиях? Где их размещать? Когда или как часто должно происходить резервирование? Проработка этих вопросов поможет сформировать стратегию и выбрать методы резервного копирования.
Первый вопрос, что должно бэкапиться, очень важен для выбора между универсальными и специализированными решениями. Компании может быть необходимо делать резервные копии физических носителей, баз данных, виртуальных машин или же иметь полностью готовую к работе инфраструктуру, на которую можно переключиться, пока идет восстановление основной.
Такие платформы, как RuBackup, предлагают широкий универсальный охват: от резервирования рабочих мест, прикладных систем и СУБД до виртуальных машин, физических серверов и облачных хранилищ, что делает решение подходящим для комплексной защиты разнородной ИТ-инфраструктуры. В то же время, есть экосистемные решения. Например, «Бэкап Яндекс 360» специализируется на резервном копировании данных конкретного облачного сервиса — Яндекс 360 для бизнеса, включая почту, календари и диски.
Второй важный вопрос — где нужно размещать резервные копии вышеперечисленного или даже критически важной для непрерывности бизнеса ИТ-инфраструктуры? Для создания бэкапов, как правило, используют решения, ориентированные на использование оборудования в локальных ЦОДах. Для дублирующих систем — облачные DRaaS-сервисы.
Современные компании часто используют облачную ИТ-инфраструктуру. При этом поставщики облачных решений обычно гарантируют лишь функционал, работоспособность и безопасность предоставляемого в облаке ПО, но не самих данных (за редкими исключениями). Любая информация в облачном хранилище может быть случайно или намеренно удалена. Поэтому компании необходимо либо самостоятельно проводить резервное копирование, либо применять сервис BaaS (Backup-as-a-Service). В некоторых случаях такое решение может иметь ограниченную функциональность — резервное копирование только в облако того же провайдера, который эту услугу предоставляет, или же с недостаточной частотой создания резервной копии.
Локальные копии помогут максимально оперативно восстановить данные при физическом отказе оборудования или кибератаке. На этапе проектирования такой системы важно подобрать современное оборудование и программное обеспечение, которое будет поддерживать оптимальные сценарии резервирования и восстановления. При этом нужно учитывать сроки хранения и скорость работы с данными. Например, для финансовых учреждений законодательство РФ требует хранения данных клиентов в течении пяти и более лет несмотря на то, что вероятность использования таких архивных данных становится со временем все ниже. В таком случае учреждения могут размещать резервные копии данных на жестких дисках, а архивную информацию о счетах и транзакциях постепенно вытеснять в библиотеку на ленточных накопителях.
Третий вопрос — когда или как часто выполняются задачи резервного копирования — прорабатывается в связке с первым. Очевидно, например, что актуализировать резервную копию базы данных нужно чаще, чем делать копии программного обеспечения. Поэтому сценарии и способы резервного копирования разрабатываются с учетом двух ключевых показателей: RTO и RPO, которые необходимо учитывать при составлении расписания для системы резервного копирования.
Показатель RPO (Recovery Point Objective) — это «глубина потери данных». Он определяет, какое максимальное количество данных компания готова потерять в случае сбоя. Так, если RPO установлен в один час, значит, при аварии вы потеряете данные только за последний час. Исходя из этого параметра определяют, как часто делать резервные копии: если RPO = 1 час, бэкапы должны создаваться каждый час.
RTO (Recovery Time Objective) — это «время на восстановление». С помощью этого параметра определяют, сколько времени может пройти с момента сбоя до полного возврата системы в рабочее состояние. Например, если RTO равен двум часам, значит, после аварии потребуется два часа на то, чтобы восстановить работу сервиса.
На практике же для критически важных систем (например, базы данных онлайн магазина) RPO и RTO задают минимальными: бэкапы каждые 15 минут, восстановление за 30 минут.
Для менее важных данных (архивных отчетов, виртуальных машин) можно установить RPO в один день и RTO в 4 часа — это сэкономит ресурсы. Таким образом, уменьшение RPO повышает защиту от потери данных. А сокращение показателя RTO минимизирует простой бизнеса. Оба параметра подбирают индивидуально для каждого сервиса — с учетом того, насколько он важен для компании, сколько стоит его восстановление, какие ресурсы (время, деньги, техника) доступны для резервирования. Также следует учитывать требования регуляторов. Например, для банков RPO может быть строго ≤ 5 мин.
Итак, для различных типов данных могут быть установлены различные RTO/RPO. И чтобы их достичь, используют разные методы резервного копирования в рамках общей стратегии.