Acronis Disaster Recovery

Acronis Disaster Recovery — это дополнение к Acronis Cyber Protect Cloud, которое хранит готовые к запуску копии защищаемых рабочих нагрузок в Acronis Cloud и поднимает эти копии в облаке в момент сбоя. Отличие от резервного копирования таково: резервная копия хранит данные, а аварийное восстановление поддерживает работу сервиса. Продуктивный failover, тестовый failover без влияния на продуктив, последовательный запуск по runbook и варианты site-to-site VPN управляются из одной консоли.

Цели определены и официально: спецификация Acronis Advanced Disaster Recovery прямо указывает цель RPO и RTO менее 15 минут благодаря механизму RunVM (спецификация Acronis Advanced Disaster Recovery, 2022). Эта цифра — не гарантия, а расчётная рабочая точка архитектуры; фактическое значение зависит от частоты репликации, размера рабочей нагрузки, пропускной способности канала и проектирования runbook.

Обоснование таких инвестиций скрыто в данных о том, насколько затягивается простой. По данным IBM Cost of a Data Breach Report 2025, 65% организаций до сих пор не восстановились после утечки полностью; среди тех, кто заявил о полном восстановлении, у 76% процесс занял более 100 дней, у 26% — более 150 дней, и лишь 2% справились менее чем за 50 дней (IBM & Ponemon, 2025). Тот же отчёт оценивает среднюю мировую стоимость утечки данных в 4,44 млн долл. США (в 2024 году — 4,88 млн долл. США); средняя стоимость инцидентов с шантажом и программами-вымогателями при раскрытии информации злоумышленником составляет 5,08 млн долл. США.

Поэтому аварийное восстановление — тема не только землетрясения или пожара, но и программ-вымогателей. Согласно отчёту Acronis H2 2025 Cyberthreats Report, во втором полугодии 2025 года в мире было публично раскрыто более 7600 жертв программ-вымогателей; самыми активными группами стали Qilin (962 жертвы), Akira (726) и Cl0p (517) (Acronis Cyberthreats Report H2 2025). Sora Yazılım ведёт проекты аварийного восстановления в рамках семейства решений Acronis вместе с этапами определения охвата, проектирования runbook, учений и управляемой эксплуатации.

В чём разница между Acronis Disaster Recovery и классическим резервным копированием?

Короткий ответ: при резервном копировании данные хранятся и записываются обратно по запросу на восстановление; при аварийном восстановлении готовая к запуску копия рабочей нагрузки ждёт в облаке и вводится в строй командой failover. Резервное копирование улучшает RPO, аварийное восстановление — преимущественно RTO. Они не альтернативы друг другу; Disaster Recovery строится поверх уже действующей подписки Acronis Cyber Protect и уже созданных резервных копий.

Между ними есть ещё один промежуточный уровень — Instant Restore. Виртуальная машина запускается прямо из резервной копии уровня диска, содержащей операционную систему; во время работы машины её диски эмулируются из резервной копии, а место в хранилище требуется только под возникающие изменения. Acronis рекомендует держать такую временную машину не более трёх дней, после чего удалить её или преобразовать в постоянную виртуальную машину (руководство пользователя Acronis Cyber Protect Cloud). Instant Restore использует ресурсы вашего собственного гипервизора; Disaster Recovery же получает ресурсы из Acronis Cloud, поэтому в сценариях, когда продуктивная площадка полностью недоступна, работает только он.

Это разграничение проясняет и решение о покупке. Организациям, которым нужна защита только от потери данных, достаточно ядра резервного копирования на стороне Acronis Cyber Backup. Для рабочих нагрузок, где время простоя напрямую превращается в потерю выручки или сервиса, требуется возможность failover. На практике организации классифицируют рабочие нагрузки: критичные включаются в охват Disaster Recovery, остальные защищаются резервным копированием и Instant Restore.

Каковы реальные цели RTO и RPO и от чего они зависят?

Короткий ответ: официальная цель — RPO и RTO менее 15 минут (спецификация Acronis Advanced Disaster Recovery, 2022), однако это значение зависит от трёх переменных. Первая — частота репликации: чем чаще обновляется точка восстановления, тем уже RPO. Вторая — проектирование runbook: сколько серверов, в каком порядке и с какими зависимостями поднимаются, определяет RTO. Третья — сеть: если не решён вопрос, как пользователи и интегрированные системы будут обращаться к копии в облаке, сервис не считается работающим, даже если серверы запущены.

Поэтому работу по постановке целей мы выполняем в разрезе рабочих нагрузок. Для каждого приложения мы ищем письменные ответы на три вопроса: какая потеря данных в минутах допустима, за сколько минут сервис должен подняться и какой ручной рабочий процесс будет действовать в течение этого времени. Хотя на рынке иногда встречается формулировка о верхней границе «RPO от 15 минут до 1 часа», в официальной спецификации Acronis такой верхней границы нет; указана единственная цель — менее 15 минут. Поэтому мы рассматриваем цель не как обещание, а как рабочую точку, которую нужно подтверждать учениями.

Ещё один важный момент — на какую точку восстановления выполняется failover. Среди возможностей, официально добавляемых пакетом Advanced Disaster Recovery, есть и «failover на точку восстановления, не содержащую вредоносного ПО». В сценарии с программой-вымогателем это принципиально: самая свежая точка восстановления может относиться к моменту, когда злоумышленник уже находился в системе. Чтобы этот контроль работал, резервные копии нужно сканировать; такая возможность появляется с дополнением Acronis Advanced Security + EDR. Кроме того, с сентября 2024 года во всех хранилищах Acronis-hosted неизменяемое хранилище в режиме Governance со сроком хранения 14 дней активно по умолчанию (Acronis Cyber Protect 16 Web Help), то есть точка восстановления, на которую будет выполняться failover, обладает устойчивостью к удалению.

Как работает failover в облаке и как устанавливается сетевое подключение?

Короткий ответ: резервная копия защищаемой рабочей нагрузки реплицируется в Acronis Cloud, по команде failover эта копия запускается в облаке как виртуальная машина и обслуживает пользователей через канал между сетью организации и облаком. На сетевом уровне есть две базовые модели: расширение локальной сети в облако через защищённый VPN-туннель или режим cloud-only, работающий без установки VPN-устройства. Согласно официальной документации, через защищённый VPN-туннель в облако можно расширить не более 23 локальных сетей (руководство пользователя Acronis Cyber Protect Cloud).

Выбор сетевой модели зависит от архитектуры приложений. В средах, где серверы в облаке должны отображаться в том же IP-диапазоне, что и продуктивная сеть, и где есть интеграции, привязанные к фиксированным IP-адресам, предпочтителен site-to-site VPN. Если достаточно поднять лишь несколько независимых серверов, режим cloud-only разворачивается быстрее и требует меньше компонентов. Точкой терминации туннеля на стороне организации обычно служит имеющийся межсетевой экран; если IPsec-туннель строится на устройстве вроде Fortinet FortiGate, поведение правил маршрутизации, NAT и DNS в сценарии failover нужно протестировать заранее.

Согласно официальной спецификации пакета Advanced Disaster Recovery, стандартная защита Cyber Protect Cloud включает резервное копирование файлов, образов и приложений, локальное восстановление через Instant Restore, тестовый failover и VPN-подключение только к облаку; пакет добавляет к этому продуктивный и тестовый failover в Acronis Cloud, вариант развёртывания без VPN-устройства, многосайтовый IPsec VPN и L2 site-to-site OpenVPN, множественные шаблоны runbook, пользовательскую настройку DNS, аварийное восстановление для DHCP-серверов и failover на точку восстановления, не содержащую вредоносного ПО.

Разграничение в таблице опирается на списки «уже входит» и «добавляется пакетом» из собственной спецификации Acronis Advanced Disaster Recovery (спецификация Acronis Advanced Disaster Recovery, 2022). На практике чаще всего упускают из виду DNS: даже если копия в облаке поднялась, но разрешение имён продолжает указывать на старый адрес, сервис до пользователя не доходит. Поэтому пользовательская настройка DNS и значения TTL — неотъемлемая часть проектирования runbook.

Как проводятся тестовый failover и учения по аварийному восстановлению?

Короткий ответ: тестовый failover — это запуск облачных копий в изолированной сети без вмешательства в продуктивную среду. Цель — увидеть не то, включаются ли серверы, а то, что сервис оказывается сквозным образом: открывается ли приложение, подключается ли оно к базе данных, может ли пользователь войти в систему, отвечают ли интеграции. Официальная спецификация перечисляет тестовый failover среди возможностей, входящих в Cyber Protect Cloud; продуктивный и тестовый failover в Acronis Cloud, а также автоматический тестовый failover с ежемесячным или еженедельным расписанием поставляются с пакетом Advanced Disaster Recovery.

Смысл учениям придаёт реалистичность сценария. Мы используем такую структуру: сначала пишется исходный сценарий (например, полная потеря доступа к основному дата-центру), затем по этому сценарию выполняется runbook, после чего для каждого шага измеренное время сравнивается с целевым, и в конце отклонения превращаются в список корректирующих действий. Отчёт об учениях представляется бизнес-подразделениям, потому что цель RTO определяет не техническая команда, а владелец бизнес-процесса.

Частоту учений задаёт и практическое ограничение со стороны лицензии. Подписка Disaster Recovery включает определённое количество compute point, и failover вместе с тестовым failover расходуют этот пул; согласно официальной базе знаний по лицензированию, годовая подписка на одну рабочую нагрузку включает 2000 compute point, и 2000 баллов примерно соответствуют двум неделям использования failover или тестирования в год (База знаний поддержки Acronis 73387, 2026). Это комфортный бюджет для нескольких серьёзных учений в год, но он не рассчитан на постоянно включённые тестовые среды.

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

Как лицензируется Acronis Disaster Recovery и каковы его предварительные условия?

Короткий ответ: дополнение лицензируется на каждую рабочую нагрузку и требует действующей подписки Acronis Cyber Protect и облачного развёртывания. В зависимости от срока подписки оно включает определённый пул compute point: годовая подписка на рабочую нагрузку даёт 2000, трёхлетняя — 6000, пятилетняя — 10 000 compute point, а хранилище для аварийного восстановления не ограничено (База знаний поддержки Acronis 73387, 2026).

Условие облачного развёртывания — не техническая деталь, а архитектурное ограничение. В официальной документации Acronis аварийное восстановление как услуга входит в список возможностей, доступных только при облачном развёртывании; в том же списке находятся cloud-to-cloud резервное копирование Microsoft 365 и Google Workspace, резервное копирование в публичное облако, EDR, Cyber Scripting, удалённый рабочий стол и инвентаризация оборудования (Acronis Cyber Protect 16 Web Help). Следовательно, если вы эксплуатируете локальный сервер управления только с Acronis Cyber Protect 16, для аварийного восстановления вам нужно перейти на сторону Acronis Cyber Protect Cloud или выстроить гибридную модель.

Какие возможности охватывает локальное, а какие облачное управление, подробно перечислено в сравнительной базе знаний Acronis: некоторые возможности — целевое хранилище на ленте, Acronis Storage Node, PXE-сервер и Forensic Mode — доступны только на локальной стороне, а некоторые, например EDR и DLP Device Control, — только в облаке (База знаний поддержки Acronis 73376, 2025). В гибридных проектах мы решаем, какая рабочая нагрузка управляется из какой консоли, опираясь именно на эту таблицу. Мы предпочитаем говорить не о цене, а об охвате: коммерческое предложение готовим после того, как определены число рабочих нагрузок, целевой RTO и частота учений.

На каких данных и решениях должен строиться план непрерывности бизнеса?

Короткий ответ: перед выбором технологии идёт анализ влияния на бизнес. Пока не определено, сколько часов может простаивать каждый процесс, во сколько обходится час простоя, от каких приложений зависит процесс и в каком порядке эти приложения зависят друг от друга, цели RTO и RPO остаются случайными числами. Самая частая ошибка, которую мы видим в проектах аварийного восстановления, — назначение одинаковой цели всем серверам и, как следствие, неоправданный рост и стоимости, и сложности.

Обоснование плана дают и данные об угрозах. В отчёте Verizon 2025 Data Breach Investigations Report проанализированы 22 052 инцидента безопасности и 12 195 подтверждённых утечек данных из 139 стран; программы-вымогатели присутствовали в 44% рассмотренных утечек и встречались в 88% утечек у малого и среднего бизнеса, тогда как у крупных организаций показатель составил 39%. Медианный размер выкупа снизился до 115 000 долл. США, при этом 64% пострадавших организаций выкуп не заплатили (Verizon DBIR 2025). Возможность не платить выкуп напрямую зависит от наличия копии, к которой можно вернуться, и работающего плана восстановления.

В техническом каркасе плана вместе стоят три средства контроля. Неизменяемое хранилище защищает точку возврата, не позволяя удалить резервную копию. Шифрование не даёт прочитать копию: в шифровании резервных копий Acronis алгоритм AES работает в режиме Galois/Counter (GCM) со случайно сгенерированным 256-битным ключом; ключ шифруется алгоритмом AES-256 с использованием хеша SHA-2 (256 бит) от пароля, а сам пароль нигде не сохраняется — ни на диске, ни в резервных копиях (Acronis Cyber Protect 16 Web Help). Третье средство — failover, обеспечивающий непрерывность сервиса. Отсутствие одной из трёх опор снижает ценность двух остальных.

Письменный результат плана тоже должен быть конкретным: инвентарь рабочих нагрузок и классы критичности, цели RTO/RPO для каждой нагрузки, шаги и порядок runbook, план изменений в сети и DNS, зоны ответственности за решения и коммуникацию, календарь учений и процедура failback. Этот документ мы создаём вместе с проектом и обновляем после каждых учений.

На что обратить внимание в контексте KVKK, размещения данных и Турции?

Короткий ответ: KVKK (закон Турции о защите персональных данных) не предписывает конкретный продукт, но прямо ожидает быстрого возобновления деятельности после сбоя. Раздел «Резервное копирование персональных данных» «Руководства по безопасности персональных данных», выпущенного Управлением по защите персональных данных Турции, указывает: при повреждении, уничтожении или хищении данных оператор данных обязан в кратчайший срок возобновить деятельность, используя резервные копии; рекомендуется разрабатывать стратегии резервного копирования данных против программ-вымогателей; доступ к резервным копиям персональных данных должен быть только у системного администратора, а резервные копии наборов данных обязательно должны храниться вне сети (Руководство KVKK по безопасности персональных данных).

Измеримым эквивалентом формулировки «возобновить деятельность в кратчайший срок» является цель RTO; эквивалентом требования «хранить вне сети» — копия в облаке. Аварийное восстановление — единственное средство контроля, закрывающее оба пункта одновременно. При этом вопрос о том, где физически будут находиться данные и вычислительные ресурсы для failover, является отдельным. В официальном списке дата-центров Acronis под заголовком «Acronis Cloud DC» присутствует и Стамбул; список охватывает регионы Америки, Европы и Ближнего Востока, Азиатско-Тихоокеанского региона и Африки, а кроме того Acronis перечисляет локации Google Cloud Platform и Microsoft Azure (Acronis Cyber Cloud Data Centers). Какой регион может быть назначен вашему тенанту и оказывается ли услуга аварийного восстановления в этом регионе, мы подтверждаем вместе с Acronis в начале проекта.

В регулируемых отраслях требуется ещё одна подготовка: записи об учениях должны быть пригодны для аудита. Отчётность по результатам тестового failover, измеренным временам и корректирующим действиям позволяет отвечать на вопросы аудитора не «у нас есть план», а «мы запускали план такого-то числа и измерили такое-то время». Это одна из самых осязаемых отдач от инвестиций в аварийное восстановление.

Стоит напомнить, что копию в облаке тоже нужно защищать. Поскольку после failover работающие серверы становятся продуктивной нагрузкой, ожидается, что средства защиты конечных точек и серверов действуют и там; в организациях, использующих серверно-ориентированные решения вроде Trend Micro Deep Security, поведение этого продукта в части лицензий и политик в сценарии failover следует спланировать заранее. Для тех, кто хочет собрать в той же консоли ещё и управление обновлениями и инвентаризацию, мы совместно рассматриваем дополнение Acronis Advanced Management.

Поделитесь списком критичных рабочих нагрузок, допустимым временем простоя и вашей текущей конфигурацией Acronis; вместе определим, какие рабочие нагрузки должны войти в охват Acronis Disaster Recovery, какая сетевая модель подходит и каким будет календарь учений. Подготовим предложение с охватом, проектированием runbook и шагами внедрения. Свяжитесь с нами через страницу контактов — мы работаем с технической поддержкой на турецком языке, учениями по аварийному восстановлению и сопровождением после внедрения.