Катастрофоустойчивость на практике: почему резервные ЦОД и копии данных не гарантируют восстановление бизнеса

1 час назад

© Сгенерировано ИИ

Октябрьские атаки на дата-центры «Яндекса» и последовавшие перебои в работе облачных сервисов вновь поставили перед бизнесом вопрос о надёжности резервной инфраструктуры. Исследование Orion soft, опубликованное ещё до этих событий, показывает, что большинство крупных российских компаний используют средства репликации и планируют действия на случай аварий, однако далеко не все регулярно проверяют возможность восстановления. Эксперты «Инфосистемы Джет», GreenMDC и K2 Cloud рассказали RUБЕЖ, почему наличие резервного ЦОД само по себе не обеспечивает непрерывность работы, какие риски возникают при территориальном распределении инфраструктуры и что определяет стоимость катастрофоустойчивых решений.

Атаки на ЦОД выявили проблему восстановления сервисов

В октябре 2026 года беспилотники атаковали три дата-центра «Яндекса» в Сасове Рязанской области, Калуге и Владимире. Инциденты привели к остановке вычислительных площадок и перебоям в работе сервисов компании и её корпоративных клиентов.

Восстановление инфраструктуры продолжалось несколько недель. К 23 октября инженеры Yandex Cloud вернули доступ к 90,47% клиентских данных. Часть информации и связанных с ней сервисов перенесли на новую площадку, а доступ к ним открывали поэтапно. Кроме того, «Яндекс» сообщил о сохранности трех суперкомпьютеров, которые удалось вывезти из пострадавших ЦОД для последующего развёртывания на других объектах.

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

Как ранее писал RUБЕЖ, корпоративные клиенты восстанавливали работу сервисов поэтапно. В частности, поставщик решений для охранного мониторинга «Си-Норд» после переноса инфраструктуры на резервную площадку сначала восстановил приём событий от центров охраны, а затем возвращал доступность остальных функций.

На этом фоне 14 октября заместитель президента — председателя правления «Ростелекома» Валерий Ермаков на форуме РБК Tech предложил создавать специальные резервные площадки — так называемые ЦОД «судного дня», предназначенные для хранения копий данных и восстановления цифровых сервисов после масштабных аварий.

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

Параллельно обсуждаются меры физической защиты вычислительной инфраструктуры. Как сообщал RUБЕЖ, после атак на дата-центры «Яндекса» Минцифры и Минобороны начали прорабатывать дополнительные меры защиты ЦОД.

Однако увеличение числа площадок решает лишь часть проблемы. Для бизнеса не менее важно, сможет ли инфраструктура продолжить работу после потери основного ЦОД и сколько времени займет восстановление критичных систем.

Компании внедряют резервирование, но редко проверяют восстановление

По данным исследования Orion soft, опубликованного 5 октября, 86,9% крупных российских компаний имеют хотя бы частично спланированные сценарии аварийного восстановления (Disaster Recovery, DR), а 91,3% используют средства репликации данных.

В исследовании участвовали 93 представителя крупных предприятий нефтегазовой, энергетической, финансовой, промышленной, транспортной и других отраслей.

Для большинства опрошенных продолжительность простоя строго ограничена. У 87,7% организаций время восстановления после аварии (Recovery Time Objective, RTO) является регламентированным параметром. При этом 41,5% респондентов ориентируются на восстановление в течение часа, ещё 46,2% допускают простой в несколько часов.

Несмотря на распространённость средств резервирования, регулярно проверяют их работу далеко не все. Только 34,4% компаний проводят учения по аварийному восстановлению чаще двух раз в год. Ещё 37,6% организаций либо вовсе не тестируют соответствующие системы, либо ограничились однократной проверкой при внедрении.

Кроме того, для 68,1% опрошенных основным способом восстановления остаются резервное копирование и ручной перезапуск виртуальных машин.

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

Директор по развитию бизнеса Orion soft Максим Березин обращает внимание на риски ручного восстановления: большое количество операций повышает вероятность ошибок, особенно в условиях аварии. По его оценке, для организаций со строгими требованиями к RTO необходимы средства автоматизированного переключения и восстановления виртуальной инфраструктуры.

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

Почему второй дата-центр может не обеспечить непрерывность работы

Руководитель отдела системной архитектуры «Инфосистемы Джет» Александр Локтионов считает, что при проектировании инфраструктуры необходимо заранее предусматривать полную недоступность или компрометацию основной площадки.

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

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

Однако территориальное разделение оборудования не гарантирует независимости площадок. Два ЦОД могут использовать общие каналы связи, компоненты управления, системы хранения или другие инфраструктурные элементы, отказ которых способен одновременно повлиять на обе площадки.

«Само по себе наличие нескольких дата-центров не обеспечивает устойчивости, если они зависят от общих компонентов, отказ которых может затронуть все площадки одновременно», — подчеркивает Александр Локтионов.

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

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

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

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

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

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

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

Децентрализация ЦОД: скорость строительства и новые ограничения

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

Генеральный директор GreenMDC Федор Клименко в интервью RUБЕЖ отметил усиление интереса к территориальному распределению инфраструктуры после октябрьских атак. По наблюдениям компании, заказчики все чаще рассматривают создание дополнительных площадок вне крупнейших центров концентрации вычислительных ресурсов, однако значительная часть таких проектов пока находится на стадии предварительной проработки.

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

Главным преимуществом этого подхода Клименко называет сокращение сроков реализации проектов. По его словам, GreenMDC реализует проекты префаб-ЦОД вместимостью до 200 серверных шкафов за девять месяцев под ключ, включая сборку на площадке. Для сравнения, строительство традиционного капитального объекта, по оценке эксперта, занимает от полутора лет.

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

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

Эксперт подчеркивает необходимость развития отказоустойчивых каналов связи, включая оптоволоконную инфраструктуру и подключения к точкам обмена трафиком. Без достаточной сетевой связности размещение вычислительных мощностей в регионах не обеспечит требуемого уровня доступности сервисов.

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

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

Сколько стоит создание дополнительной площадки

Экономика резервирования во многом определяется тем, какие функции должна выполнять дополнительная площадка.

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

По оценке Федора Клименко, для верхнеуровневого расчета стоимости префаб-ЦОД вместимостью более 30 серверных шкафов можно ориентироваться примерно на 10 млн рублей на одну стойку мощностью 10 кВт. Речь идет об отказоустойчивом ЦОД с необходимой инженерной инфраструктурой. При этом расходы на присоединение к энергетическим сетям и подключение каналов связи в указанную оценку не входят.

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

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

Однако создание резервного ЦОД не всегда означает необходимость строительства собственного объекта. Возможны аренда мощностей у коммерческого оператора, использование облачной инфраструктуры или комбинированная модель. Выбор зависит от требований к доступности, допустимого времени восстановления, объема данных и степени контроля, необходимой заказчику.

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

Где хранить резервные данные и какие ограничения учитывать

Территориальное распределение инфраструктуры ставит перед бизнесом ещё один вопрос: насколько далеко можно размещать резервные мощности и допустимо ли использовать зарубежные облачные площадки?

Руководитель практик 1С и кибербезопасности K2 Cloud Анжелика Захарова отмечает, что иностранная резервная площадка потенциально позволяет снизить зависимость от инцидентов в пределах одной страны. Однако её использование необходимо оценивать с учётом российского законодательства о персональных данных и особенностей конкретной информационной системы.

По словам Захаровой, изменения законодательства, вступившие в силу 1 июля 2025 года, существенно ограничивают возможность размещения персональных данных россиян за рубежом, в том числе их резервных копий. Эксперт считает, что для большинства компаний, работающих с персональными данными, зарубежное резервирование не подходит.

«Наличие основной базы данных в России само по себе не означает, что её копию можно хранить за рубежом», — подчеркивает Анжелика Захарова.

При этом требования локализации персональных данных необходимо отличать от правил их трансграничной передачи. Часть 5 статьи 18 Федерального закона № 152-ФЗ устанавливает ограничения на использование зарубежных баз данных при сборе персональных данных граждан России, тогда как трансграничная передача регулируется статьей 12 этого закона. Правомерность конкретной схемы резервирования зависит от выполняемых операций и применимых требований.

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

О предложении Ассоциации больших данных разработать единые правила резервного хранения персональных данных россиян в зарубежных ЦОД и правовых ограничениях такой модели RUБЕЖ ранее рассказывал в отдельном материале с комментарием Анжелики Захаровой.

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

«Оператор может иметь ограниченные возможности контролировать действия администраторов иностранного провайдера, получать журналы событий и расследовать инциденты», — отмечает Анжелика Захарова.

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

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

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

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

Как оценить реальную готовность к аварии

Октябрьские инциденты и результаты исследования Orion soft показывают, что оценивать катастрофоустойчивость только по наличию резервного ЦОД, копий данных или средств репликации недостаточно.

Для бизнеса ключевыми параметрами остаются RTO — допустимое время восстановления сервиса — и RPO, определяющий допустимый объем потери данных в результате аварии.

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

Исследование Orion soft выявляет два параллельных обстоятельства: для большинства опрошенных время восстановления строго регламентировано, однако регулярные учения чаще двух раз в год проводят лишь 34,4% организаций.

Александр Локтионов подчеркивает необходимость совместной подготовки ИТ-подразделений и бизнеса к возможным сбоям. Речь идет не только о техническом восстановлении виртуальных машин, но и о заранее согласованных планах обеспечения непрерывности бизнеса (BCP) и восстановления после аварий (DRP).

Такие планы должны учитывать последовательность запуска приложений, зависимости между сервисами, доступность каналов связи, порядок восстановления данных и действия ответственных сотрудников.

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

«Главный критерий защищенности — подтвержденная способность сохранить данные и восстановить критичные сервисы за фиксированное время», — резюмирует Александр Локтионов.

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

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