Резерв Yandex Cloud в другом облаке: копию ещё нужно суметь поднять

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

Разделите восстановление через Yandex Cloud Backup и сценарий, рассчитанный на недоступность сервисов Yandex Cloud. В первом случае нужны доступ к Cloud Backup и подходящий ресурс; во втором — копия, ключи и порядок запуска, доступные независимо от основной площадки. Для обоих сценариев результатом проверки должна стать работа приложения с измеренной потерей данных и временем восстановления.

Определите границы Cloud Backup

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

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

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

Подготовьте машину и сеть для восстановления

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

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

При восстановлении через Cloud Backup внешнему ресурсу требуется доступ в интернет даже в режиме средства восстановления Recovery Bootable Media. Проверьте маршруты и правила доступа именно после загрузки этого средства, а затем повторите сетевую проверку в обычной операционной системе. Приложению могут понадобиться и отдельные настройки: адреса баз данных, разрешённые соединения, сертификаты и маршрут, по которому к резервной площадке попадут пользователи.

Выведите данные на независимую площадку

Selectel предлагает аварийное восстановление в своё облако для инфраструктуры другого облачного провайдера или локальной площадки. Наличие такой услуги не означает автоматического переноса туда внутренних копий Cloud Backup. До выбора схемы согласуйте, каким инструментом создаётся доступная извне копия, в каком формате она передаётся и на какой ресурс восстанавливается.

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

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

Проведите пробный запуск при недоступной основной площадке

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

1. Выберите конкретную внешнюю копию и запишите время последнего изменения данных, которое удаётся в ней подтвердить.
2. Создайте целевую машину и сеть по сохранённой конфигурации, не используя управление основной площадкой.
3. Восстановите данные, загрузите систему, проверьте тома и запустите компоненты приложения в нужном порядке.
4. Направьте тестовый адрес на резервную среду и выполните контрольную операцию с чтением, записью и повторным чтением.
5. Запишите ожидание доступа, передачи данных, изменения сети, загрузки и проверки приложения.

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

Сопоставьте потерю данных и время простоя с допустимыми пределами

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

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

Читайте также:

• Yandex Cloud или Selectel: одинаковые ядра ещё не дают одинаковый счёт
• 1000 рублей могут вывести на биржу — но не заменят финансовый резерв
• Сначала резерв, потом акции: как новичку не сорвать инвестиционный план