Учения на резервных копиях: как я научился не бояться
У меня годами жила уютная иллюзия: cron делает дамп, дамп уезжает на другой сервер, значит «бэкапы есть». Иллюзия лопнула в тот день, когда мне потребовалось восстановить одну таблицу из архива, а в архиве оказался дамп, сделанный до появления этой таблицы, да ещё и с битой кодировкой. С тех пор раз в квартал я провожу учения.
Формат учений
Свежая виртуалка из снапшота «чистой системы», архив с холодного хранения, таймер на один час. Задача — поднять сервис и сверить контрольную сумму одной живой записи. Если за час не поднял — учения провалены, пишу, что именно мешало, и правлю процедуру.
Три грабли, которые нашёл только на практике
Первая. Пути в конфигах. Архив содержит абсолютные пути старой машины.
Теперь в архив всегда кладётся маленький RESTORE.md с картой «старый путь → новый путь».
Вторая. Ключи. TLS-сертификаты и SSH-ключи лежали отдельно от данных — и отдельно от моей памяти. Теперь секретный комплект едет вместе с архивом, зашифрованный отдельным паролем.
Третья. Самая обидная: порядок старта. База вставала раньше веб-сервера, веб-сервер падал при старте, cron его поднимал через десять минут, а таймер учений уже засекал отказ. Завёл явный скрипт поднятия с зависимостями.
Чек-лист учений
1. Развернуть чистую систему из снапшота 2. Скачать архив с холодного хранения 3. Проверить sha256 архива 4. Развернуть по RESTORE.md, не импровизируя 5. Поднять сервис, проверить health-эндпоинт 6. Сверить контрольную запись 7. Записать: сколько заняло, что мешало 8. Удалить всё, оставить заметку
Смысл не в том, чтобы восстановить «идеально». Смысл в том, что после третьих учений ты точно знаешь, сколько времени займёт настоящий инцидент, и спишь спокойно. А перед третьими — не спишь.