restore-from-backup

Бэкап, который ни разу не восстанавливали, — это не бэкап, а надежда. Поэтому restore- тест — не разовое событие при /setup-backups, а регулярная проверка (см. Шаг R ниже и рефлекс персоны §4.1). </role>

STRICT-режим: без конфига инфры (infra-config.json) и доступа к passphrase не запускаюсь — угадывать, откуда и чем восстанавливать, запрещено (C.2). </context>

Шаг 0: Прочитать конфиг и подключиться к репозиторию (Green)

source .claude/skills/_lib/find-config.sh; find_brain_config; resolve_active_project
RESTIC_REPO="rclone:$(get_config_field backups.rclone_remote):$(get_config_field backups.restic_repo_path)"
export RESTIC_PASSWORD="$(read_from_vault "$(restic_pass_ref)")"   # из менеджера паролей, не в argv/лог
restic -r "$RESTIC_REPO" snapshots --no-lock   # read-only: список снапшотов

Если репозиторий недоступен (нет сети/кред/remote) — STOP, честно сообщаю что нужно (rclone config, passphrase), суррогат не выдумываю (C.9).

Шаг 1: Что и на какой момент восстанавливаем (брифинг Yellow)

Спрашиваю оператора (или беру из запроса): какие данные (какая БД / какие файлы / весь хост), на какой момент (последний снапшот / на дату / конкретный snapshot ID). Показываю человеческим языком: «нашёл N снапшотов, самый свежий — <дата>, ближайший к твоей дате — <ID/дата>». Уточняю куда восстанавливать: по умолчанию — во временное место, НЕ поверх прода.

Шаг 2: Восстановление во ВРЕМЕННОЕ место (Yellow)

RESTORE_TMP="$(mktemp -d /tmp/restore.XXXXXX)"
restic -r "$RESTIC_REPO" restore <snapshot-id> --target "$RESTORE_TMP" --no-lock

Для БД — поднимаю временный контейнер (как делает restore-тест в /setup-backups) и импортирую дамп туда, прод не трогаю.

Шаг 3: Сверка (Green) — данные целые?

• Файлы: размер, контрольные суммы, наличие ключевых путей.
• БД: row counts ключевых таблиц во временном контейнере, сверка с ожиданием/продом; поднимается ли схема, нет ли ошибок импорта.
• Явный вердикт оператору: «восстановленная копия валидна / частична / битая — детали…». Битая копия → не промочу в прод, ищу другой снапшот.

Шаг 4: Промоушен в прод — КРАСНАЯ ЗОНА (только если Шаг 3 = валидно)

Перезапись боевых данных восстановленными — необратима. Полная 4-шаговая процедура §6 персоны:

1. ASSESS — точно ли нужен промоушен? есть ли свежий бэкап ТЕКУЩЕГО состояния (на случай отката отката)? зависимые сервисы остановлены?
2. PROPOSE — план перезаписи, точные команды, откат; обязательные строки «⚠️ ЧТО ТЕРЯЕМ» (текущие боевые данные за период между бэкапом и сейчас) и «⚠️ КОПИЯ: есть/НЕТ» (снапшот текущего состояния перед перезаписью); нет копии — сначала делаю её. Запрос type-to-confirm с именем БД/ресурса, которое оператор вписывает САМ (анти-копипаст, ADR-0014).
3. EXECUTE — снапшот текущего → остановка сервиса → перезапись из проверенной копии → запуск. Ошибка → ОТКАТ к снятому снапшоту, не «дочистка руками».
4. VERIFY & DOCUMENT — сервис поднялся, данные на месте; incidents/YYYY-MM-DD-restore.md.

Шаг R: Плановый restore-тест (Green/Yellow, не ждёт инцидента)

Раз в месяц (ритуал жизни) или по запросу «проверь бэкап» — прогоняю Шаги 0–3 БЕЗ Шага 4: восстанавливаю одну БД во временный контейнер, сверяю row counts, фиксирую дату успешного теста (backups.last_restore_test или отметка в runbook). Если последний успешный restore- тест старше 30 дней — считаю бэкапы непроверенными и говорю об этом оператору прямо.

Failed Attempts (граблекейс)

• «Восстановил сразу поверх прода» — потеряли данные за период между бэкапом и инцидентом без возможности отката. Урок: ВСЕГДА сначала во временное место + сверка + снапшот текущего состояния перед перезаписью. Промоушен — красная зона, не Yellow.
• «Passphrase в команде/логе» — restic-passphrase утёк в историю/лог. Урок: только через RESTIC_PASSWORD из менеджера паролей (как в /setup-backups и /rotate-secrets), не в argv.
• «Бэкап есть, а restore ни разу не пробовали» — в инцидент выяснилось, что репозиторий битый/passphrase потерян. Урок: бэкап без регулярного restore-теста = не бэкап (Шаг R).