План Б Железного человека. Резервное копирование и DR 2025

У каждого крепкого бизнеса должны быть решения, обеспечивающие защиту и восстановление данных в случае различных ЧП.

План Б Железного человека. Резервное копирование и DR 2025
© It-world

Параноидальная предусмотрительность – одна из основных черт характера Тони Старка, главного героя комиксов и фильмов о Железном Человеке. У него всегда есть запасные костюмы/модули, дистанционные системы управления, аварийные протоколы и тому подобное. Возможность в любой непонятной ситуации переключиться на План Б, должна лежать в основе любого современного бизнеса, эффективность которого зависит от надежности ИТ-инфраструктуры — а это почти любой современный бизнес. Когда что-то пошло не так — кибератака, вирус, программа-вымогатель, физическое повреждение инфраструктуры — должен быть эффективно реализован план восстановления.

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

Экспертное мнение От бэкапа к устойчивости данных Классический бэкап больше не защищает бизнес от реальных угроз. Компании переходят от точечных СРК к платформам устойчивости данны

План Б Железного человека. Резервное копирование и DR 2025. Рис. 1

Для предотвращения этого компании могут внедрять у себя как решения для резервного копирования данных (бэкап), так и программно-аппаратные комплексы для хранения архивов (ленточные библиотеки) и даже сервисы аварийного восстановления (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. И чтобы их достичь, используют разные методы резервного копирования в рамках общей стратегии.

Три, два, один

Принцип 3-2-1 звучит как обратный отсчет до старта, но на самом деле это стратегия резервирования, сочетающая две копии данных на локальных носителях и еще одну в удаленном хранилище. Локальные копии могут размещаться на одной площадке, но на разных носителях, а третья — в удаленном ЦОДе или в облачном хранилище.

При таком подходе, если с первым хранилищем что-то произошло, то данные можно восстановить за минимальное время. Если же доступ к ЦОДу полностью потерян, то данные можно восстановить из резервной копии в облаке. Считается, что стратегия «3-2-1» надежно гарантирует сохранность критически важных данных.

Используемые в рамках стратегии методы резервного копирования могут быть принципиально разными в зависимости от скорости, объема занимаемого пространства и удобства восстановления данных. Рассмотрим их последовательно.

Методы резервного копирования

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

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

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

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

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

Примеры комбинированных стратегий:

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

Отечественные решения

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

Этим требованиям соответствуют такие платформы, как RuBackup, чьи возможности были упомянуты ранее, и «Кибер Бэкап», которые предлагают комплексные решения для резервного копирования и защиты данных. Кроме них, на рынке представлены и другие проверенные решения. Например, ПО СРК и ВД «Береста» фокусируется на совместимости с российским технологическим стеком. Это предпочтительный выбор для организаций, которые уже перешли или активно внедряют отечественные ОС (Astra Linux), СУБД (PostgreSQL), среды виртуализации (zVirt) и приложения (например, 1С), обеспечивая для них максимально надежную и оптимизированную защиту данных. Предлагается резервное копирование виртуальных машин, СУБД, контейнеров и приложений, поддерживается широкий спектр хранилищ — от локальной файловой системы до объектных хранилищ S3 и ленточных библиотек.

Как было отмечено, RuBackup выделяется своей универсальностью и модульной архитектурой, что позволяет гибко адаптировать решение под различные задачи. Среди его преимуществ: высокая отказоустойчивость, горизонтальная масштабируемость, электронная подпись резервных копий, совместимость с отечественными и зарубежными ОС, полноценная работа с ленточными библиотеками (включая LTFS), модульная архитектура, открытый API для разработки модулей резервного копирования и восстановления, удобство и простота развертывания и администрирования. Кроме того, разработчики выражают готовность проводить оперативную доработку модулей резервного копирования под информационные системы заказчиков. Добавим наличие сертификата 4-го уровня защиты информации от ФСТЭК, что важно для использования в значимых объектах КИИ, в государственных информационных системах, автоматизированных системах управления производственными и технологическими процессами (АСУ ТП), а также в информационных системах персональных данных для обеспечения их технологической независимости и защищенности.

Решения от «Кибер Бэкап» также имеют свои преимущества, включая поддержку широкого спектра платформ и операционных систем, централизованное управление, встроенные функции дедупликации для экономии места и специальные технологии для ускорения резервного копирования и восстановления. В частности, решение использует собственные запатентованные механизмы для обеспечения высокой скорости резервного копирования даже очень больших баз данных PostgreSQL и PostgresPro без использования их нативных механизмов. Еще одна важная особенность - гибкий подход к резервному копированию виртуальных машин, который поддерживает как резервное копирование на уровне гипервизора, так и использование агентов. «Кибер Бэкап» также реализует проверку целостности резервных копий и включает специализированный модуль для защиты от программ-вымогателей. Решение обладает открытым API, полноценно работает с ленточными устройствами и сертифицировано ФСТЭК по 4-му уровню защиты информации. Пользователи отмечают удобный интерфейс, простоту и скорость установки – базовая настройка займет всего час при использовании графического инсталлятора.

Стоит отметить и универсальное решение Handy Backup, которое также входит в реестр российского ПО. Решение поддерживает шифрование данных, резервирование с использованием российских облачных сервисов и отличается гибкостью в выборе хранилищ — от локальных дисков и NAS до S3-совместимых облачных сервисов, что позволяет легко реализовывать гибридные схемы резервного копирования.

Решение специализируется на резервном копировании данных рабочих станций пользователей, виртуальных и физических серверов и популярных приложений. Оно хорошо подходит для малого и среднего бизнеса, фокусируясь на защите файлов, электронной почты (включая IMAP-сервисы и файлы Outlook), а также данных с сайтов на распространенных CMS, таких как Joomla или WordPress. Такая направленность, дополненная поддержкой широкого спектра хранилищ, делает Handy Backup оптимальным выбором для организаций, где важна защита не только серверов, но и конечных рабочих мест и прикладных данных.

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

Disaster Recovery (восстановление после сбоев)

Сервис Disaster Rеcovery (DR) считается более перспективным подходом к обеспечению живучести систем, чем простой бэкап. Этот подход предусматривает создание дублирующей инфраструктуры, которая активируется при выходе из строя основной, подобно тому, как включается резервное питание от генератора при сбоях в электросети.

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

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

Это достигается за счет технологий репликации данных и готовых решений, таких как Disaster Recovery as a Service (DRaaS). Однако важно понимать, что это не просто резервное копирование (бэкап), а более комплексная система, включающая автоматизацию, синхронизацию и подготовку инфраструктуры для немедленного использования.

Для реализации DR, аналогичного работе резервного питания от генератора, потребуется:

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

Решения DR от российских разработчиков

Поставщики DRaaS, такие как VK Cloud, наиболее полно реализуют второй из описанных подходов — предоставление готовой инфраструктуры для аварийного восстановления в своих ЦОДах. Их ключевое отличие от других решений в модели оплаты (pay-as-you-go) и полной ответственности провайдера за готовность резервной площадки.

В описании VK Cloud Backup акцент делается на резервное копирование, а не на полноценное аварийное восстановление инфраструктуры. Однако у поставщика есть лендинг, где рекламируется сервис Cloud Disaster Recovery, который позволяет: настраивать репликацию данных, создавать планы аварийного восстановления, автоматизировать тестирование процессов восстановления, осуществлять failover (переключение на резерв) и failback (возврат к основной инфраструктуре).

Таким образом, Cloud Disaster Recovery от VK Cloud — это пример классического DRaaS, который обеспечивает не просто резервное копирование, а именно оркестрацию аварийного переключения, что позволяет достичь минимальных значений RTO и RPO для виртуальных инфраструктур, размещенных в их экосистеме.

Разработчики других on-prem и гибридных решений также заявляют о наличии компонентов для аварийного восстановления (DRP).

Среди отечественных поставщиков решений для резервного копирования и восстановления отметим RuBackup, который, будучи универсальной платформой, также поддерживает DRP в разделе «Аварийное восстановление» в интерфейсе. Инструмент позволяет создавать планы восстановления, выбирать ресурсы и места для восстановления, а также настраивать автозапуск планов, что делает его комплексным решением как для ежедневного бэкапа, так и для организации DR.

«Кибер Бэкап» поддерживает возможность репликации данных, что может быть частью стратегии DR. Однако важно понимать, что «Кибер Бэкап» — это прежде всего мощное решение для резервного копирования, и его DR-модуль не является сервисом DRaaS в общепринятом понимании. Его суперсила — гранулярное (поэлементное) восстановление файлов и данных, а не моментальный запуск целых систем, как в классическом DRaaS. Тем не менее, решение позволяет настроить мгновенный запуск виртуальных машин из резервной копии, если нужно оперативно восстановить работоспособность критически важных сервисов. В контексте создания отказоустойчивой инфраструктуры для государственного сектора и крупного бизнеса стоит обратить внимание на такие платформы, как ПО СРК и ВД «Береста». Его архитектура, включая поддержку политик хранения (HSM) и работу с различными типами хранилищ, закладывает основу для построения отказоустойчивых сценариев, что особенно важно для государственного сектора и корпораций, стремящихся к полной технологической независимости.

Таким образом, если вам нужна именно дублирующая инфраструктура с минимальным временем восстановления, то стоит рассмотреть специализированные DR-решения или DRaaS. Для критически важных систем часто используют комбинацию бэкапа и DR: бэкап для защиты данных, DR — для обеспечения непрерывности бизнеса. Перед выбором решения важно определить целевые показатели RTO и RPO, учитывая специфику вашего бизнеса и бюджет. Также рекомендуется регулярно тестировать план восстановления, чтобы убедиться в его работоспособности.

Заключение

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

Как показывает анализ рынка, есть широкий выбор решений от российских компаний. Это экосистемные BaaS-решения, такие как «Бэкап Яндекс 360». Малому и среднему бизнесу может подойти решение от Handy Backup. Универсальные on-prem платформы резервного копирования вроде RuBackup и «Кибер Бэкап» обеспечат комплексную защиту разнородной инфраструктуры, а решения для государственного сектора и крупных корпораций, подобные ПО «Береста», способны обеспечить как ежедневное резервное копирование, так и полноценное аварийное восстановление.

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