Регулярные учения по аварийному восстановлению

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

Цель

Регулярно проверять два сценария восстановления:

• восстановление из снимка Raft в изолированном кластере;
• переключение на DR secondary (Stronghold EE);

и фиксировать фактические время восстановления (RTO) и потерю данных (RPO).

Периодичность

Выполняйте проверки со следующей периодичностью:

Предварительные требования

Для выполнения примера нужны:

• Кластер Stronghold со встроенным Raft-хранилищем.
• Изолированный стенд для восстановления: отдельная сеть без доступа к рабочим базам данных, LDAP и другим системам, которыми управляют механизмы секретов.
• Держатели долей ключа распечатывания или восстановления рабочего кластера. После восстановления снимка нужны именно исходные ключи.
• Для второй части — Stronghold EE и настроенная DR-репликация.

Часть 1. Восстановление снимка в изолированном кластере

Восстановите снимок рабочего кластера в изолированном тестовом кластере и измерьте время восстановления.

1. Получите снимок. Используйте последний автоматический снимок (Stronghold EE):

   d8 stronghold read sys/storage/raft/snapshot-auto/status/<CONFIG_NAME>

   <CONFIG_NAME> — имя конфигурации автоматических снимков.

   Поле last_snapshot_url указывает на последний успешный снимок. Либо сохраните снимок вручную:

   d8 stronghold operator raft snapshot save drill.snap

2. Проверьте целостность снимка:

   d8 stronghold operator raft snapshot inspect -validate drill.snap

3. Разверните на изолированном стенде кластер Stronghold той же или более новой версии со встроенным Raft-хранилищем (подробнее — в разделе «Установка Stronghold в Linux»). Инициализируйте и распечатайте его, войдите временным root-токеном:

   d8 stronghold operator init
   d8 stronghold operator unseal
   d8 stronghold login <TEMPORARY_ROOT_TOKEN>

   <TEMPORARY_ROOT_TOKEN> — начальный root-токен, который вывела команда operator init.

   Если рабочий кластер использует auto-unseal (KMS, HSM или другой seal), настройте на стенде тот же блок seal и предоставьте ему доступ к тому же ключу. Снимок содержит ключи barrier, зашифрованные seal рабочего кластера (core/hsm/barrier-unseal-keys), и после восстановления стенд расшифровывает их через свой seal. С другим ключом распечатать кластер не получится, а snapshot restore без -force отклонит такой снимок. При auto-unseal кластер распечатывается сам после восстановления, и шаг с ручным unseal ниже не нужен.

4. Зафиксируйте время начала восстановления и восстановите снимок:

   d8 stronghold operator raft snapshot restore -force drill.snap

5. При seal Shamir распечатайте кластер исходными ключами рабочего кластера:

   d8 stronghold operator unseal

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

   d8 stronghold login

   Если такого токена нет, сгенерируйте root-токен на стенде. В генерации участвуют держатели долей ключа распечатывания рабочего кластера (при auto-unseal — долей ключа восстановления):

   d8 stronghold operator generate-root -init
   d8 stronghold operator generate-root
   d8 stronghold operator generate-root -decode=<ENCODED_TOKEN> -otp=<OTP>
   d8 stronghold login

   Первая команда запускает генерацию и выводит OTP. Вторую команду выполните по одному разу для каждого держателя доли: она запрашивает долю ключа. После последней доли команда выводит закодированный токен <ENCODED_TOKEN>. Третья команда декодирует его с помощью <OTP> и выводит root-токен. Введите его, когда d8 stronghold login запросит токен.

7. Проверьте данные и зафиксируйте время окончания:

   d8 stronghold status
   d8 stronghold secrets list
   d8 stronghold auth list
   d8 stronghold policy list
   d8 stronghold kv get -mount=secret <CONTROL_SECRET_PATH>

   <CONTROL_SECRET_PATH> — путь к контрольному секрету с отметкой времени. Заранее создайте контрольный секрет в рабочем кластере и регулярно обновляйте в нём отметку времени. Используйте его, чтобы определить RPO: RPO — разница между временем начала восстановления и отметкой времени в восстановленном секрете.

8. Уничтожьте стенд и все копии снимка на нём.

Часть 2. Плановое переключение на DR secondary

Переключите клиентов на DR secondary и верните прежний primary в роль secondary.

Проводите переключение в согласованное окно обслуживания. Не повышайте DR secondary, пока primary активен: в кластере окажется два primary.

1. Убедитесь, что secondary догнал primary. Прочитайте last_wal из статуса репликации primary и last_remote_wal из статуса репликации secondary:

   d8 stronghold read -address="${PRIMARY_ADDR}" -field=last_wal sys/replication/dr/status
   d8 stronghold read -address="${SECONDARY_ADDR}" -field=last_remote_wal sys/replication/dr/status

   Secondary догнал primary, если значения совпадают. PRIMARY_ADDR и SECONDARY_ADDR — адреса primary и secondary.

2. Понизьте текущий primary:

   d8 stronghold write -address="${PRIMARY_ADDR}" -force sys/replication/dr/primary/demote

3. Выпустите DR operation token на secondary по процедуре с долями ключей и повысьте secondary. Команды приведены в разделе «Повышение DR-secondary».

4. Переключите клиентов на новый primary (DNS-запись или балансировщик) и зафиксируйте время.

5. Проверьте работу: вход через OIDC, чтение секретов, выдачу динамических учётных данных и сертификатов.

6. Верните прежний primary в роль secondary. На новом primary выпустите activation-токен:

   d8 stronghold write -address="${SECONDARY_ADDR}" sys/replication/dr/primary/secondary-token id=dr-old-primary

   Команда выводит activation-токен <ACTIVATION_TOKEN>.

7. На прежнем primary, который теперь стал DR secondary, сгенерируйте DR operation token. Вызов update-primary на DR secondary требует этот токен. Команды используют эндпоинты sys/replication/dr/secondary/generate-operation-token/attempt и sys/replication/dr/secondary/generate-operation-token/update:

   d8 stronghold operator generate-root -address="${PRIMARY_ADDR}" -dr-token -init
   d8 stronghold operator generate-root -address="${PRIMARY_ADDR}" -dr-token
   d8 stronghold operator generate-root -address="${PRIMARY_ADDR}" -dr-token -decode=<ENCODED_TOKEN> -otp=<OTP>

   Первая команда запускает генерацию и выводит OTP. Вторую команду выполните по одному разу для каждого держателя доли ключа распечатывания (при auto-unseal — доли ключа восстановления): она запрашивает долю ключа. После последней доли команда выводит закодированный токен <ENCODED_TOKEN>. Третья команда декодирует его с помощью <OTP> и выводит DR operation token <DR_OPERATION_TOKEN>.

   По умолчанию эндпоинты генерации DR operation token требуют аутентификации. Чтобы вызывать их без токена, добавьте generate-operation-token в параметр enable_unauthenticated_access конфигурации сервера.

8. Подключите прежний primary к новому primary:

   d8 stronghold write -address="${PRIMARY_ADDR}" sys/replication/dr/secondary/update-primary token=<ACTIVATION_TOKEN> dr_operation_token=<DR_OPERATION_TOKEN>

9. При необходимости выполните обратное переключение теми же шагами.

Чек-лист учений

После учений проверьте следующие пункты:

• Снимок прошёл inspect -validate.
• Держатели долей ключей доступны, кворум собран за приемлемое время.
• Восстановленный кластер распечатан исходными ключами.
• Контрольный секрет прочитан, RPO измерено.
• Методы аутентификации, политики и mount присутствуют в ожидаемом составе.
• Для DR: secondary повышен, клиенты переключены, прежний primary подключён как secondary.
• Время восстановления (RTO) измерено и сравнено с целевым.
• Изолированный стенд и копии снимка уничтожены.
• Найденные проблемы внесены в регламент восстановления.

Проверка

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

Очистка

После учений удалите тестовый стенд и копии данных:

1. Удалите изолированный кластер и его хранилище.
2. Удалите локальные копии снимка: shred -u drill.snap.
3. Отзовите токены, выпущенные для учений на рабочем кластере.

Дополнительные ресурсы

• Резервное копирование
• Проверка снимка
• Восстановление из снимка
• Автоматические снимки
• Репликация для аварийного восстановления (DR)