Снимки в облаке забыты: как выстроить бэкапы и восстановление

В облачном кабинете всегда найдётся спокойная строка: снимки дисков. Их делают перед обновлением, «на всякий случай» перед пятничным релизом, автоматически по расписанию, которое кто-то включил и забыл. Через полгода финансовый директор спрашивает, почему хранение выросло на десятки или сотни тысяч рублей, а ИТ отвечает: «это же бэкапы». На самом деле это часто не стратегия восстановления, а склад забытых облачные снимки дисков.

Парадокс знакомый многим командам в Yandex Cloud и AWS: счёт за снимки состояния растёт, а уверенности, что бизнес поднимется за нужное время, нет. Восстановление не репетировали, допустимая потеря данных и время восстановления не записаны, копии лежат в том же контуре, что и прод. Финансы злятся на затраты, инженеры боятся чистить, директор думает, что «облако и так защищено».

Почему снимки копятся быстрее, чем регламент

Снимок создать проще, чем согласовать политику хранения. Кнопка в консоли не требует заявки. Разработчик перед экспериментом жмёт снимок состояния и уходит в отпуск. Конвейер выкладки делает pre-выкладка снимок без TTL. После удаления виртуалки orphan-снимки остаются и продолжают тарифицироваться. Default «хранить вечно» удобен психологически и токсичен для бюджета.

• нет владельца строки бэкап хранилище в управление облачными затратами;
• нет единого naming и обязательных тегов (project, env, owner, expires);
• manual снимки состояния без автоудаления;
• путаница: снимок состояния считают полноценным DR;
• чистка откладывается, потому что «вдруг там нужное» — а каталога нет.

Снимки состояния, бэкап и DR — разные слои

Для учётных систем и баз одного crash-consistent снимка часто мало: нужна согласованность приложения. Для ransomware-устойчивости опасны «только снимки рядом с продом»: ошибка или шифровальщик с правами админа добирается и до них.

Как затраты выглядит глазами финансов

Снимки состояния хранилище — отдельная строка, которая ползёт вверх без яркого инцидента. Типичные находки аудита: сотни orphan после удаления VM, дев снимки годичной давности, дубли weekly поверх daily без смысла, репликация «включили и забыли» без политики. Очистка без inventory заканчивается либо страхом, либо удалением нужного откат. Нужен не «разовый sweep», а жизненный цикл: сколько daily/weekly/monthly, какой TTL у manual, кто имеет право создавать вне политики.

Ошибки, которые делают «забытые снимки» нормой

Удалить всё ради экономии в одном спринте. Счёт падает, откатываться становится некуда. Сначала каталог и политика, потом cleanup orphan и просроченных manual.

Считать, что «в облаке снимок состояния = можно не тестировать восстановление». Пока не поднимали диск и не проверяли загрузку сервиса, у вас гипотеза, не защита.

Держать три несвязанных слоя: ручные снимки, продукт бэкапа и выгрузки «на диск админа» — без единого регламент. В инциденте спорят, с чего восстанавливаться.

Не тегировать ресурсы. Без project/env/cost_center нельзя ни возвраты платежей, ни безопасную чистку.

Для 1С и СУБД полагаться только на диск за секунду до патча. Нужен application-aware контур и проверка открытия базы после восстановление.

Рабочая схема жизненный цикл

1. Inventory. Все снимки состояния и бэкап задания: размер, возраст, родительский диск, теги, last восстановление test.
2. Классификация. Prod / stage / dev; для dev — жёсткий потолок числа и TTL.
3. Policy. Например: 7 daily, 4 weekly, 3–12 monthly по требованиям; manual — только с expires ≤ 14 дней.
4. Offsite tier. Ночные копии в Object Storage с понятным retention и ограничением удаления.
5. Алерты. Рост бэкап line item, orphan count, failed задания.
6. Drill. Раз в квартал — подъём из снимка и из бэкап tier с замером времени.

управление облачными затратами без войны ИТ и финансов

Раз в месяц один отчёт на двоих: TB, стоимость, orphan удалены, отклонения от policy, дата последнего успешного восстановление теста. ИТ видит риск, финансы — динамику счета. Экономия 30–60% на строке хранения при сохранении осмысленного retention — нормальный результат наведения порядка, а не «отключили бэкапы».

В Yandex Cloud удобно связать расписания снимков, бакет в Object Storage и billing alerts. В AWS — аналогичная логика жизненный цикл и бюджетов. Инструмент вторичен; важны владельцы и запрет бессрочных manual-копий без заявки в IT.

Гибрид: на своих серверах + облако

Частая картина: прод в серверной, «облако для бэкапа» или наоборот. Тогда снимки состояния локального гипервизора и облачные снимки должны стыковаться в одной политике tier 1/2/3: быстрый локальный откат, offsite на срок, редкие drills. Иначе у вас два склада забытых копий и ни одного проверенного сценария «подняли бухгалтерию к девяти утра».

Чеклист руководителя

• есть ли список снимков и задания с владельцами;
• зафиксированы ли допустимая потеря данных и время восстановления для двух трёх критичных систем;
• есть ли жизненный цикл и запрет вечных manual снимки состояния;
• есть ли копия вне основного контура;
• когда последний раз реально восстанавливали, а не «смотрели, что job зелёный»;
• видит ли финансы тренд бэкап хранилище и лимиты.

FAQ

Можно ли просто удалить всё старше 90 дней? Только после inventory: иначе снесёте единственную точку отката перед кривым релизом. Сначала policy и orphan.

Снимки в Yandex Cloud бесплатны? Нет, хранение тарифицируется. Накопление напрямую бьёт по счёту.

Достаточно ли снимки состояния для аудита и 152 ФЗ? Редко сами по себе: нужны срок хранения, доступ, шифрование, процедура восстановление и доказательства, что она работает.

Что делать разработчикам перед экспериментом? Pre-change снимок через согласованный процесс с TTL, либо отдельный контур — не бесконечная галерея в проде.

Практика восстановление учений без театра

Раз в квартал выбирают одну критичную систему — например, файловый сервер или тестовую копию 1С — и поднимают её из снимка и из Object Storage в изолированной сети. Засекают время до «сервис отвечает». Фиксируют сюрпризы: неверный порядок дисков, просроченный сертификат, забытый DNS, отсутствие лицензии на новом железе. Без этого RTO в презентации остаётся фантазией. Учение не обязано ронять прод: достаточно копии и честного протокола для директора.

Отдельно договариваются, кто имеет право удалять снимки состояния: не «любой с консолью», а роль с журналом. управление облачными затратами и ИТ раз в месяц сверяют orphan count и отклонения от жизненный цикл. Так забытые облачные снимки дисков перестают быть вечной статьёй расходов и ложным чувством безопасности одновременно.

Следующий шаг

Если облачные снимки дисков копятся, финансы требуют сократить счёт, а DR-плана с учениями нет — наведите порядок слоями: каталог, жизненный цикл, offsite, тест восстановления. Экономия и безопасность здесь не враги, пока чистка не подменяет стратегию.

Навести политику хранения и проверить восстановление можно в рамках услуги Бэкапы и восстановление — с понятным отчётом для ИТ и финансового блока.