Если облако станет недоступно: как подготовить 1С, CRM, почту и другие критичные сервисы

Начать стоит с инвентаризации критичных данных.
Для каждой системы необходимо выяснить:

• Где размещены основные данные и их резервные копии?
• Можно ли получить копии при недоступности основного провайдера?
• Поддерживается ли восстановление на другой платформе?
• Как часто создаются копии и когда проверялась их пригодность?

Здесь есть важный технический нюанс.
Например, согласно документации Yandex Cloud Backup, копии этого сервиса хранятся во внутренних бакетах Object Storage, а восстановление выполняется средствами самого Cloud Backup. Прямого доступа к файлам резервных копий и бакетам у пользователя нет.
Поэтому при планировании восстановления за пределами провайдера необходимо отдельно проверить, какие инструменты позволяют создавать независимые копии в пригодном для переноса формате.
Для виртуальных серверов, баз данных и приложений существуют разные способы резервного копирования. Выбор зависит от операционной системы, СУБД, используемого облака и требований к целостности данных.
Практическое действие: убедитесь, что у критичных систем есть доступные для восстановления копии, которые можно использовать вне основной инфраструктуры.

Предположим, резервная копия базы 1С сохранилась. Следующий вопрос – где запустить саму систему?
Для восстановления могут потребоваться:

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

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

1. Восстановление из независимых копий

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

Что учитывать: меньше постоянных затрат на резервную инфраструктуру, но больше времени требуется на восстановление и запуск сервисов.

2. Подготовленная резервная среда

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

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

3. Резервный работающий контур

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

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

Подобные сценарии применяются в международной практике аварийного восстановления. Например, AWS выделяет подходы backup and restore, pilot light и warm standby в зависимости от требований к времени восстановления и затратам.
Для разных приложений одной компании могут подходить разные схемы. Бухгалтерская система, клиентский портал и внутренний файловый архив необязательно должны восстанавливаться с одинаковой скоростью.

С виртуальными машинами и управляемой компанией инфраструктурой обычно больше возможностей для организации независимого резервирования.
С SaaS-продуктами ситуация сложнее: серверной частью управляет поставщик, а доступные механизмы экспорта и восстановления зависят от конкретной платформы.
Корпоративная почта
Для Яндекс 360, VK WorkSpace и других облачных почтовых решений стоит заранее выяснить:

• Возможно ли независимо сохранять письма и вложения?
• Какие данные доступны для экспорта: переписка, контакты, календари, настройки?
• Можно ли импортировать полученные данные в альтернативную почтовую систему?
• Как быстро получится восстановить отправку и получение новых писем на корпоративном домене?

Один из вариантов – заранее подготовить резервную почтовую систему, которую можно активировать при длительной недоступности основной.
Для переключения потребуются доступная альтернативная платформа, управление DNS-записями домена, настройка маршрутизации почты и проверка доставки сообщений.
При этом запуск резервной почты сам по себе не гарантирует доступ к исторической переписке. Возможности её переноса нужно проверять отдельно.
Облачная CRM
Для CRM важно определить состав данных, которые компания может регулярно выгружать: клиенты, сделки, задачи, документы, история взаимодействий.
Далее необходимо проверить формат экспорта, доступность интеграций и возможность использования информации вне исходной платформы.
Например, в облачном Битрикс24 предусмотрено восстановление данных из резервных копий через техническую поддержку, но эта функция не равнозначна готовому резервному экземпляру CRM на собственном сервере.
В некоторых ситуациях разумным временным решением может стать заранее подготовленный доступ к основным клиентским данным и альтернативный порядок обработки обращений.
Практическое действие: для каждого критичного SaaS-сервиса определите, какие функции необходимо сохранить при сбое и какими средствами этого можно добиться.

У разных компаний требования к восстановлению будут существенно различаться.
Для интернет-магазина длительная недоступность системы заказов может означать прямые потери выручки. Для внутреннего архива документов несколько часов простоя могут оказаться приемлемыми.
В инженерной практике для таких задач используют два показателя:
RTO (Recovery Time Objective) – целевое время, за которое необходимо восстановить работу системы.
RPO (Recovery Point Objective) – максимально допустимый период потери данных, выраженный во времени.
Например, компания может установить для системы заказов целевое время восстановления два часа, а допустимую потерю данных – 15 минут. Эти показатели становятся требованиями к архитектуре, частоте сохранения данных и резервным ресурсам.
Важно понимать, что RTO и RPO сначала задаются как цели. Возможность их достижения необходимо подтверждать испытаниями.
На основе требований можно выбрать экономически оправданный сценарий для каждой системы, определить приоритеты восстановления и избежать избыточных затрат.

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

• Удалось ли восстановить работоспособность приложения?
• Сколько времени заняли все операции?
• Какой объём последних изменений отсутствует в восстановленной копии?
• Какие действия потребовали ручного вмешательства?
• Что потребуется изменить, чтобы уложиться в согласованные сроки?

Google Cloud в своих рекомендациях по Disaster Recovery отдельно подчёркивает необходимость проверять работоспособность всего приложения после восстановления данных, включая критичные инфраструктурные сервисы.
По итогам испытаний обновляют инструкции и устраняют выявленные ограничения.

Когда доступ к облачной инфраструктуре пропал, хаотичные попытки срочной миграции могут привести к дополнительным проблемам. Лучше последовательно оценить ситуацию.
1. Уточните масштаб инцидента. Проверьте официальную информацию провайдера, определите доступные и недоступные сервисы, зафиксируйте состояние систем.
2. Найдите доступные источники данных. Установите, какие независимые резервные копии имеются и когда они были созданы. Сохраните их целостность до начала восстановительных работ.
3. Определите приоритеты. Согласуйте с бизнесом, какие системы нужны в первую очередь: обработка заказов, CRM, 1С, корпоративная почта или другие приложения.
4. Оцените альтернативные ресурсы. Проверьте доступные вычислительные мощности, лицензии, сетевые подключения и возможность запуска систем на другой площадке.
5. Запускайте восстановление по согласованному сценарию. Перед переключением пользователей убедитесь в корректности данных и настройте контроль возврата к основной инфраструктуре.
Если независимых копий нет, восстановление может зависеть от действий самого облачного провайдера. Поэтому главную часть подготовки важно провести до инцидента.

Для первичной оценки достаточно ответить на несколько вопросов:

1. Какие сервисы остановят работу компании при недоступности облака?
2. Где хранятся их резервные копии и можно ли получить их независимо от провайдера?
3. Есть ли ресурсы, на которых можно запустить критичные системы?
4. Как быстро они должны заработать и сколько данных допустимо потерять?
5. Когда в последний раз проводилось испытание восстановления?

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