При выборе облака для размещения сервисов и приложений обычно изучают доступную информацию о том, как устроена инфраструктура провайдера. Дублированные вводы питания и сеть, дизель-генераторы, SLA с множеством девяток, надёжные СХД, сертификаты Uptime Institute – всё это успокаивает при оценке рисков. Это впечатление во многом справедливо: облачные провайдеры обычно уделяют много внимания надёжности ЦОДов. Но надёжность площадки и сохранность данных клиента – не одно и то же. В облаке ответственность разделена: провайдер отвечает за доступность платформы, а защита приложений и аварийное восстановление (DR) остаются за клиентом. Риски при этом те же, что на собственной площадке: отказы оборудования, вредоносное ПО, ошибки администраторов. Компенсация по публичному SLA провайдера, как правило, ограничена стоимостью услуги и не покрывает потери от простоя сервиса и утраты данных.
Резервное копирование средствами провайдера защищает от многих проблем, но не от всех: копии хранятся в том же облаке, что и основные данные, и могут оказаться с ними в одном домене отказа. Домен отказа – это набор ресурсов, которые выходят из строя одновременно из-за одного события. В облаке таким доменом может оказаться не стойка и не машинный зал, а целый ЦОД, облако провайдера или один клиентский аккаунт. Если основные данные и копии находятся в одном домене отказа, одно событие затрагивает их одновременно.
Вопрос в том, где хранится резервная копия: внутри облака провайдера или за его пределами?
В этой статье разберём основные риски по зонам ответственности, посмотрим и сравним три способа хранить резервную копию и организовать аварийное восстановление вне облака, на своей инфраструктуре.
Какие риски остаются на стороне клиента вне зоны ответственности провайдера
Риски разделим по зонам ответственности: часть возникает на стороне клиента, часть – на стороне инфраструктуры провайдера. Сначала разберём каждый из них, затем сведём их в таблицу и отметим, какие варианты хранения копий от них защищают.
Ошибки конфигурации. В мае 2024 года из-за ошибки сотрудников Google Cloud была удалена облачная подписка пенсионного фонда UniSuper, включая копии в двух регионах. Фонд, в котором более 640 тысяч участников, восстанавливал работу сервисов около двух недель. Данные удалось восстановить только благодаря резервным копиям, которые хранились в другом облаке.
Однотипное оборудование. В системах хранения часто используются накопители из одной партии и одной версии прошивки. Дефект, общий для партии, проявляется у многих устройств одновременно: в 2019 году HPE выпустила бюллетень о сбое прошивки ряда SAS SSD после 32 768 часов работы. Механизмы отказоустойчивости (RAID, репликация) рассчитаны на независимые отказы, и от одновременного отказа они защищают не всегда. Пока копия лежит на таком же оборудовании, она делит риск с основными данными. Если основная и резервная СХД собраны на однотипных накопителях и введены в эксплуатацию одновременно, то подобный дефект может уничтожить обе копии сразу.
Изъятие оборудования. Когда правоохранительные органы изымают серверы провайдера, страдают и клиенты, которые к делу никакого отношения не имеют. Известны случаи, когда изымали сотни серверов (Хабр). При изъятии оборудования клиент может разом лишиться доступа и к основным данным, и к резервным копиям, если те хранятся у того же провайдера.
Организационные причины. Изменение условий договора, приостановка доступа по требованиям регуляторов, уход провайдера с рынка. Инфраструктура остаётся исправной, но доступ к ней ограничен на время или насовсем. Доступ к копиям в той же учётной записи ограничивается вместе с доступом к основным данным. Такие риски реализовались весной 2022 года у клиентов, которые пользовались услугами облачных провайдеров прекративших работу на территории РФ.
Хакерские атаки
Шифровальщик внутри ВМ.
Взлом учётной записи в облаке. Если злоумышленник завладел учётной записью клиента у облачного провайдера, он получает доступ и к резервным копиям, которые хранятся в этом же аккаунте. Одна учётная запись – и не остаётся ни прода, ни копий.
Взлом самого провайдера: через инсайдера или уязвимость в платформе.
Копия вне облачной учётной записи остаётся доступной, даже если клиентская учётная запись скомпрометирована.
Риск | Бэкап в ту же зону доступ-ности | Бэкап в другую зону доступ-ности | Бэкап на свою площадку или облако другого провай-дера | Репликация на свою площад-ку или в облако другого провай-дера | Примеры реализации риска |
Зона ответственности клиента | |||||
Шифровальщик / вредоносное ПО внутри ВМ | ✅ | ✅ | ✅ | ✅ (если есть реплика до момента зараже-ния) | Генпрокуратура РФ: причиной сбоя в работе «Аэрофлота» стала хакерская атака |
Ошибка администратора клиента (удалил ВМ) | ✅ | ✅ | ✅ | ✅ | sudo rm -rf, или Хроника инцидента с базой данных GitLab.com от 2017/01/31 |
Взлом учётной записи клиента в облаке | ❌ | ❌ | ✅ | ✅ | |
Зона ответственности облачного провайдера | |||||
Отказ системы хранения (дефект прошивки SSD или СХД) | ✅ | ✅ | ✅ | ✅ | |
Гибель ЦОДа (пожар, стихийное бедствие) | ❌ | ✅ | ✅ | ✅ | В Страсбурге сгорел дата-центр OVH SBG2 Пожар в государственном дата-центре Южной Кореи Данные в дата‑центрах Amazon были безвозвратно утеряны после атаки беспилотников |
Изъятие оборудования у провайдера правоохраните-льными органами | ❌ | ⚠️ | ✅ | ✅ | |
Администрати-вные проблемы с провайдером (банкротство, санкции, блокировка аккаунта) | ❌ | ❌ | ✅ | ✅ | Блокировка аккаунта у крупного провайдера Google Cloud уже в третий раз блокирует аккаунт моей компании |
Ошибка администрирования у облачного провайдера | ❌ | ❌ | ✅ | ✅ | Инцидент у хостинг-провайдера Cloudmouse: удаление виртуальных серверов клиентов |
Шифровальщик / вредоносное ПО в инфраструктуре провайдера | ❌ | ❌ | ✅ | ✅ | Danish hosting firms lose all customer data in ransomware attack MskHost объявил о банкротстве после взлома и утечки данных клиентов |
От части рисков из таблицы – ошибок администратора, вредоносного ПО внутри ВМ, единичных отказов оборудования – защищает обычное резервное копирование, в том числе внутри облака. С остальными так не получится: копия у того же провайдера от них не спасает.
У всех этих случаев общая черта: основные данные и копии находились в одном домене отказа – на однотипном оборудовании, под управлением одного провайдера или в одном аккаунте. Одно событие затрагивает их одновременно. Снизить такие риски можно, только вынеся копию за пределы этого домена отказа – к другому провайдеру или на свою инфраструктуру.
Как хранить копии и организовать DR вне облака провайдера
Для защиты приложений и сервисов за пределы облака провайдера рассмотрим три наиболее известных, на наш взгляд, способа защиты: встроенные средства резервного копирования самих приложений; внешняя система резервного копирования (СРК), развёрнутая на резервной площадке; гостевая репликация с помощью агента внутри облачной ВМ. Разберём сильные и слабые стороны каждого.
Способ 1. Средства резервного копирования на уровне приложения
Используются возможности самого приложения, работающего в облаке: встроенные механизмы создания резервных копий (дампы, журналы транзакций, штатные утилиты). Такие механизмы есть у всех популярных СУБД, поэтому подход применим практически к любой базе данных.
Плюсы:
Консистентность. Копия гарантированно целостна на уровне приложения.
Цена. Как правило, такой способ не требует покупки лицензий.
Минусы:
Ограниченная применимость. Не каждое приложение имеет встроенные инструменты для создания резервных копий или реплик без остановки.
Не включает весь набор данных. Сделать копию облачной ВМ целиком таким способом нельзя. Настройки ОС и окружения приходится копировать отдельно. Часто только при аварийном восстановлении обнаруживается, что отсутствует какой-то важный файл конфигурации: о нём забыли, когда настраивали регулярное резервное копирование.
Сложное аварийное восстановление. Восстановление нельзя выполнить, не имея глубокого понимания механики работы этого приложения. Шагов много, автоматизации почти нет: нужно восстановить данные из копии, настроить сеть, обеспечить правильный порядок запуска сервисов.
Нет универсальности. Каждое приложение копируется и восстанавливается по-разному, разными инструментами со своими особенностями.
Примеры ПО со встроенными средствами резервного копирования: PostgreSQL, MySQL/MariaDB, Oracle Database, MS SQL Server, MongoDB, ClickHouse, GitLab (gitlab-backup).
Способ 2. Внешняя СРК на резервной площадке
Публичное облако не даёт клиенту доступа к гипервизору, поэтому безагентное копирование через API гипервизора здесь недоступно. Внешней СРК остаётся агентский способ: в каждую облачную ВМ устанавливается агент резервного копирования, который копирует:
прикладное ПО – через модули интеграции;
все данные на дисках ВМ – блочным способом, с возможностью восстановления ВМ на другую платформу (так умеют не все СРК).
Плюсы:
Консистентность. Модули интеграции с прикладным ПО позволяют получать консистентные копии приложений.
Включает полный набор данных. Некоторые СРК умеют агентским способом делать полные копии ВМ, включая данные ОС, которые можно восстановить на другой платформе (Veeam, Кибер Бэкап).
Централизация. Если резервные копии делаются уже развёрнутой на своей площадке СРК, то получаем единую точку управления и мониторинга резервного копирования собственной инфраструктуры и части, вынесенной в облако.
Минусы:Нет автоматизации восстановления. При аварии данные восстанавливаются из бэкапа, сетевые параметры перенастраиваются вручную, сервисы вручную запускаются в правильном порядке.
Время восстановления. Процесс восстановления данных (копирования из хранилища резервных копий) сам по себе может занимать часы, а если нужно восстановить одновременно много объектов инфраструктуры – дни.
Примеры ПО: Veeam Backup & Replication, Кибер Бэкап, RuBackup, NetBackup, Commvault и другие.
Способ 3. Аварийное восстановление с гостевой репликацией
В качестве примера решения для автоматизированного аварийного восстановления с агентской репликацией возьмём MIND Guard #guest.
Исходная ВМ работает в публичном облаке, а резервная ВМ находится на инфраструктуре клиента или в другом облаке. На резервной площадке разворачивается контроллер (специальная ВМ для управления), через который настраивается репликация из облака. В исходную ВМ устанавливается агент MIND Guard. Он делает моментальные снимки дисков ВМ и отправляет их по сети на резервную площадку, поддерживая постоянно актуальную копию. Из облака через интернет передаются изменения с момента последней синхронизации, поэтому объём трафика равен объёму изменившихся данных.
Плюсы:
Консистентность. Благодаря снапшотам копия данных ВМ как минимум crash-consistent. Используя возможности запуска пользовательских скриптов до и после снятия снапшота, можно получить application-consistent копию.
Включает полный набор данных. Реплика содержит полную копию всех дисков облачной ВМ.
Универсальность. Таким методом можно реализовать аварийное восстановление любых приложений. Единообразие подхода важно для средних и крупных инфраструктур.
Автоматизация восстановления. Переключение на резервную площадку, настройка сетевых параметров резервных машин и запуск ВМ в правильном порядке с учётом зависимостей автоматизируются с помощью планов аварийного восстановления. Достаточно запустить план – дальше всё происходит без ручных операций.
Время переключения. Резервная инфраструктура – это асинхронные реплики защищаемых ВМ, готовые к запуску. Во время аварийного восстановления не нужно копировать большие объёмы данных, как это происходит при восстановлении из резервной копии. Достижимое время восстановления сокращается до минут.
Тестовое переключение без влияния на источник. Резервную ВМ можно запустить в тестовом режиме и убедиться, что репликация работает как ожидается, не дожидаясь аварии.
Обратное переключение (failback). После восстановления работоспособности инфраструктуры публичного облака репликацию можно развернуть в обратном направлении и вернуть нагрузку.
Точки восстановления. На приёмнике хранится до 12 точек – состояний ВМ на разные моменты времени. Если на источнике случилась логическая ошибка (повреждение или удаление данных, атака шифровальщика) и она уже успела реплицироваться, приёмник можно откатить к точке до инцидента и переключиться на неё.
Контроль RPO. В веб-интерфейсе контроллера видны реальный и целевой RPO. Можно настроить уведомления при превышении RPO (например, если изменения перестали успевать передаваться по сети на приёмник).
Минусы:Нужны постоянно работающие ВМ на резервной площадке, которые принимают изменения с источников. Это плата за быстрое аварийное восстановление.
Зависимость от драйверов. Агенту нужны драйверы под конкретный дистрибутив и версию ядра. Обновить ОС можно только после того, как производитель выпустит под неё новые драйверы.
Вывод:
Облачный провайдер отвечает за то, чтобы ВМ работала и была доступна по сети, а сохранность данных и восстановление после аварии остаются за клиентом. Копии внутри того же облака закрывают часть рисков, но не те, при которых основные данные и копии оказываются в одном домене отказа: ошибки на стороне провайдера, изъятие оборудования, блокировку или взлом аккаунта. Поэтому хотя бы одна копия должна храниться за пределами облака провайдера – на своей инфраструктуре или в облаке другого провайдера.
Самый простой способ получить такую копию – средства резервного копирования самих приложений. Как правило, они не требуют лицензий и дают консистентную копию, но не захватывают ОС и окружение, а восстановление сложное и требует ручной работы.
Внешняя СРК копирует облачные ВМ агентским способом и даёт единую точку управления для всей инфраструктуры. Но аварийное восстановление на другую площадку по-прежнему выполняется вручную и может занимать часы, а при массовой аварии – дни.
Гостевая репликация при помощи MIND Guard держит на резервной площадке готовые к запуску реплики ВМ, а переключение выполняется по плану аварийного восстановления. Время восстановления сокращается до минут, но на резервной площадке нужны постоянно работающие ВМ-приёмники. Для одной-двух ВМ или отдельных баз данных чаще всего достаточно средств приложения или СРК. Если в облаке много связанных ВМ или приоритетна скорость восстановления, то лучше подойдёт MIND Guard.
Комментарии 0