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

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

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

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

Шаг 1. Определите область охвата, управление и ответственность

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

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

Вот некоторые критерии, которые вы можете рассмотреть:

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

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

Даже если серьезный инцидент произошел в ИТ-отделе, процесс восстановления затрагивает многие части организации, от исполнительного руководства до PR-команд и юридических отделов. Вот основные действия для успешного управления и распределения ответственности:

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

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

Шаг 2. Оцените риски и угрозы

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

Cloudflare’s November 18, 2025 outage — отличный пример того, как сторонние сервисы могут стать единой точкой отказа, даже если ваша собственная ИТ-инфраструктура остается полностью работоспособной. Программный сбой, связанный с конфигурацией, нарушил основной сетевой трафик и затронул сервисы, включая CDN, службы безопасности и аутентификацию.

Как только у вас появится список, задайте два простых вопроса:

Насколько вероятно, что это произойдет?
Что произойдет, если это случится?

Для оценки вероятности большинству компаний достаточно простой шкалы: низкая, средняя или высокая. Чтобы ранжировать риски, подумайте о том, как часто каждый инцидент происходил в прошлом и как часто он случается в вашей отрасли. Становится ли это тенденцией? Например, банки сейчас сталкиваются с большим количеством мошенничества с использованием ИИ, чем в прошлые годы, потому что ИИ может сделать аферы более убедительными. Напротив, здравоохранение больше страдает от программ-вымогателей, утечек данных и фишинга.

Затем оцените, насколько организация подвержена угрозе. Есть ли у вас эффективные превентивные и защитные меры, такие как MFA, резервное копирование данных или сегментация сети? Каковы точки дополнительной уязвимости? (Это могут быть разнообразные цифровые активы, такие как облачные среды, системы ИИ и учетные записи пользователей). Ответы помогут вам назначить рейтинг риска для каждой угрозы и понять приоритеты.

Сегодня внедрение ИИ добавляет новый уровень к ИТ-устойчивости. Системы ИИ могут стать целями для злоумышленников и вредоносного ПО, что делает их важным фактором при планировании устойчивости. В то же время плохо защищенные модели, данные, интеграции или вспомогательная инфраструктура могут создать новые уязвимости. В отчете IBM говорится, что 97% компаний заявляют, что у них нет достаточного управления доступом к ИИ. В то же время 78% директоров по информационной безопасности создают специальные группы безопасности для ИИ-агентов.

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

Шаг 3. Оцените влияние на бизнес и приоритеты восстановления

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

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

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

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

Шаг 4. Определите RTO, RPO и метрики восстановления

Определение целевого времени восстановления (RTO), целевой точки восстановления (RPO), максимально допустимого времени простоя (MTD) и метрик восстановления позволяет установить измеримые требования к процессу восстановления. Вы переходите от ожиданий и неопределенности к четким временным рамкам, что дает вам твердую почву при оценке эффективности восстановления.

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

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

MTD — это бизнес-ограничение, которое определяет максимально возможный период, в течение которого бизнес может терпеть сбой, прежде чем последствия станут слишком серьезными. Он должен быть больше, чем RTO, чтобы дать бизнесу некоторый запас времени на случай возникновения осложнений в процессе восстановления.

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

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

Шаг 5. Составьте карту ИТ-активов, инфраструктуры и зависимостей

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

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

платежное приложение
базы данных
серверы приложений
сетевые подключения
службы идентификации
облачная среда
внешние платежные провайдеры

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

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

Примечание: Не храните конфиденциальные данные, такие как учетные данные и секреты, в документе по аварийному восстановлению (DR).

Шаг 6. Разработайте стратегию восстановления

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

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

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

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

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

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

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

Типы стратегий аварийного восстановления

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

Резервное копирование и восстановление данных

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

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

Pilot light

Стратегия «пилотного света» (pilot light) предполагает поддержание небольшой, базовой версии вашей производственной ИТ-среды в другом месте или в облаке. Вы выбираете ее, когда вам нужно достаточно быстрое восстановление, но вы не можете позволить себе затраты на полноценную параллельную среду. В целом, «пилотный свет» быстрее, чем резервное копирование и восстановление данных, но сложнее и дороже. Это компромисс между стоимостью и временем восстановления.

Эта стратегия подходит вам, если ваш бизнес может допустить несколько часов простоя, вы хотите контролировать расходы на аварийное восстановление (DR) или вам нужен низкий показатель RPO. Тем не менее, стратегия не будет эффективной, если вам требуется практически мгновенное восстановление, вы не можете допустить даже нескольких минут простоя или у вас очень ограниченный опыт в ИТ.

Теплый резерв (warm standby)

В то время как «пилотный свет» включает в себя минимальную среду DR, «теплый резерв» поддерживает нечто большее, чем просто основу — большая часть резервной среды уже запущена. Тем не менее, «теплый резерв» не является полномасштабной копией вашей производственной среды: он поддерживает минимальное развертывание, способное обрабатывать запросы, но не рассчитанное на производственную нагрузку.

Эта стратегия подходит компаниям, которые отдают приоритет быстрому восстановлению, но могут допустить от нескольких минут до нескольких часов простоя, требуют низкого RPO и нуждаются в балансе между скоростью восстановления и стоимостью. Однако «теплый резерв» не может гарантировать немедленное восстановление, а его среда DR обладает меньшей мощностью, чем производственная. Этот метод дороже предыдущих вариантов, имеет среднюю или высокую сложность и требует регулярного тестирования, мониторинга и обслуживания.

Активный/пассивный (active/passive)

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

Тем не менее, пассивная инфраструктура часто не приносит никакой или почти никакой бизнес-ценности во время нормальной работы, но требует постоянного обслуживания и соответствующих затрат. Переключение операций занимает время и требует регулярного тестирования. Кроме того, если вам нужно восстановить данные из резервной копии перед запуском пассивной среды или вторичная инфраструктура требует дополнительных операций перед приемом «живого» трафика, это может увеличить время восстановления. Убедитесь, что эти увеличения остаются в пределах допустимых лимитов RTO/RPO и соответствуют бизнес-целям.

Мультирегиональный активный/активный (multi-region active/active)

Следуя этой стратегии, бизнес развертывает производственную среду в нескольких местах. Каждая среда обрабатывает рабочие нагрузки и обслуживает пользователей. Когда происходит сбой, рабочая нагрузка перераспределяется на незатронутые регионы с минимальными нарушениями. Мультирегиональный подход «активный/активный» обеспечивает высочайший уровень отказоустойчивости и доступности, практически нулевое время простоя и очень низкий RPO.

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

Инфраструктура против данных в сценариях аварийного восстановления

Технологическая экосистема бизнеса имеет несколько взаимосвязанных уровней: инфраструктура (вычисления, хранилища, сети, облачные ресурсы), приложения (ERP, CRM, электронная коммерция, расчет заработной платы) и данные. При планировании аварийного восстановления рассматривайте эти уровни отдельно, учитывая их зависимости. Каждый из них может иметь разные стратегии восстановления и требования к RTO, но последовательность восстановления все равно важна, поскольку восстановление одного уровня может зависеть от доступности другого.

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

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

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

Шаг 7. Разработайте исполняемые руководства по восстановлению (runbooks)

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

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

Основные компоненты руководства по восстановлению:

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

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

Шаг 8. Установите коммуникацию и координацию

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

Хорошая структура определяет, как команда восстановления общается во время инцидента и какие каналы использует; как владельцы бизнеса координируют действия с ИТ-командами; и как компания связывается с клиентами и поставщиками. Чтобы облегчить этот процесс, вы можете подготовить шаблоны для каждого случая. Это ускорит коммуникацию в стрессовых ситуациях.

Основные результаты этапа 8 включают:

План каналов связи
Процедуры координации бизнеса и ИТ
Список экстренных контактов
Процедуры уведомления
Коммуникационные материалы

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

Этап 9. Тестирование, измерение и постоянное улучшение

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

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

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

Основная идея тестирования заключается в том, чтобы выяснить, может ли компания восстановить систему в рамках требований к восстановлению, определенных планом DR и применимыми целевыми уровнями обслуживания (SLO). Если ответ отрицательный — например, тест показывает, что вы можете восстановить критические службы за 2,5 часа, когда ваш RTO составляет всего 2 часа, — рассмотрите корректирующие действия, чтобы устранить этот разрыв.

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

Подводя итоги

Аварийное восстановление является частью более широкой структуры, известной как планирование непрерывности бизнеса. Надежная стратегия восстановления ИТ охватывает реалистичные риски, отображает ваши критически важные системы, технологии и зависимости, а также включает практические шаги по восстановлению основных служб. Практический план остается доступным во время сбоев, гарантируя, что ключевые данные для восстановления регулярно обновляются с учетом изменений в бизнесе.

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