Проблемы резервного копирования и восстановления данных в облачных средах

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

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

Отметим ряд других выводов этого документа:

  • В принятии решений о защите данных все большую роль начинают играть специалисты, не входящие в ИТ-отделы.

  • Миграция рабочих нагрузок между облаком и локальными системами — это не односторонний процесс.

  • Организации осознают необходимость резервного копирования контейнерных и SaaS-приложений, таких как Office 365.

Кроме того, отмечается, что организации сталкиваются с многочисленными сложностями в попытках использовать или даже просто протестировать возможности публичного облака для аварийного восстановления (Disaster Recovery, DR). Так, более половины (54%) из 1550 опрошенных ИТ-руководителей заявили о трудностях при конфигурации сети для тестирования. Среди других проблем, связанных с аварийным восстановлением, 47% респондентов выделили обеспечение связи пользователей внутри офисных помещений, 43% обратили внимание на защиту удаленных площадок от кибератак или несанкционированного доступа, а 42% – на подключение удаленно работающих пользователей.

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

Резюмируя, можно заключить, что рехостинг вышедших из строя серверов и возобновление работы из другой точки – трудновыполнимая задача. Но еще сложнее, если такой сервер отключается в локальном ЦОДе, а вновь подключается уже в облачной инфраструктуре. Ключевой вопрос как для тех, кто уже использует облачное аварийное восстановление, так и для тех, кто только собирается это сделать: как переподключить сети для обеспечения продуктивного доступа без рисков безопасности? Задача усложняется, если отказ затронул не всю площадку, в результате чего пользователи одновременно работают частично со старыми серверами, а частично – с перезапущенными.

Функции переноса данных в инструментах аварийного восстановления обеспечивают поддержку облачного DR, облегчая резервное копирование, восстановление и перенос рабочих нагрузок между разными ИТ-средами — облаками, ЦОДами, контейнерами и гибридными средами.

Кто отвечает за перенос?

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

В исследовании также описаны подходы к возобновлению деятельности. Большинство участников опроса (40%) восстанавливают данные on premises, подключая их в облаке и запуская приложения локально. Четверть респондентов берут данные из внешних хранилищ и закачивают. Участники третьей группы (22%) выполняют восстановление в облаке с использованием заранее сконфигурированных серверов, которые запускаются сами, но сетевая часть требует ручного управления.

Хотя переход к использованию облачных ИТ-инфраструктур для большинства организацией неизбежен, существует много архитектур, способных выступить в качестве базы для стандартизации. Раньше практически все организации строили свои вычисления на системах среднего класса, потом использовали NetWare, а затем Windows. Следующим шагом стала виртуализация на базе VMware. Сегодня компании развивают различные сценарии, такие как IaaS, SaaS, PaaS и контейнеры, каждый из которых имеет свои плюсы и предъявляет свои требования к защите данных.

SaaS и контейнеры

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

Среди перечисленных администраторами SaaS доводов в пользу защиты данных в Office 365 — возможность отреагировать на случайное удаление данных (58%) и подготовка к возможным кибератакам (57%). За ними следуют опасения относительно злонамеренных действий пользователей и других внутренних угроз (48%), потребность в расширенных возможностях восстановления (44%) и выполнение нормативных требований (43%).

По моим оценкам 66% администраторов SaaS и 44% администраторов IaaS заявляют, что их организации либо уже осуществляют резервное копирование контейнеризированных приложений, либо выбирают для этого соответствующее решение. Большинство участников исследования отметило, что данные о состоянии их контейнеризированных приложений хранятся в отдельном месте и там же осуществляется их резервное копирование. Еще 53% администраторов IaaS и 34% администраторов SaaS заявили, что в их контейнеризированных приложениях нет данных, которые нуждаются в резервном копировании, или они не производят резервное копирование, потому что их контейнерная архитектура является нативно устойчивой.

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

Похожие статьи