Привет, Хабр! Я Саша, в Хайстекс отвечаю за B2B-продажи и давно работаю с облаками и бэкапом. В этой статье хочу рассказать о подходе, который, на мой взгляд, помогает закрыть одну из самых болезненных задач в этой области.
При работе с облачными сервисами часто приходится идти на компромисс: либо хранить дешево, но восстанавливать долго, либо платить за скорость. Допустим, у одного eCommerce-сервиса внезапно упал гипервизор, с ним ушли в офлайн несколько ВМ. Все бэкапы хранились в S3-объектном хранилище. Чтобы восстановить ВМ придется разворачивать ее из архива. На все в среднем уходит около 40 минут. Все это время система заказов лежит, а бизнес считает убытки. С Double Storage мы сделали так, что время восстановления сократилось до 6-8 минут. Что это за технология, как она работает и почему с ней действительно проще – разберем под катом. Технические подробности можем разобрать в комментариях, если будет интерес.
Почему правило 3-2-1 все еще актуально, но этого уже недостаточно
Правило 3-2-1 — это базовый стандарт в резервном копировании. Смысл простой: у вас должно быть минимум три копии данных, при этом они должны храниться на двух разных типах носителей, и хотя бы одна из них должна быть вне основной площадки. Такой подход защищает от большинства инцидентов: сбоев, выхода из строя железа, аварий в ЦОДе и даже человеческого фактора. Но в реальности все упирается в стоимость, скорость восстановления и удобство. Выбор между «ждать час» и «платить больше» – это плохой выбор. Хочется, чтобы и быстро, и без лишних счетов. А на практике все сводилось к двум вариантам:
Объектное хранилище — дешево и удобно, но поднять целую ВМ долго: скачивание, распаковка, развертывание. И вот уже «пара минут» превращаются в сорок.
Блочное хранилище — ВМ стартует из снапшота почти сразу, но дорого: платишь за весь объем диска, даже если занято только 5%. С ростом количества точек восстановления расходы растут кратно.
Мы решили объединить эти подходы. Так появился Double Storage, система, которая хранит множество точек восстановления в объектном или файловом хранилище, в то же время позволяя быстро восстанавливать последние снапшоты из блочного, оптимизируя затраты на хранение.
Вернемся к примеру с eCommerce-сервисом, где упал гипервизор и вместе с ним несколько ВМ. Обычно сценарий восстановления из объектного хранилища занимает около 40 минут. С Double Storage нужные снапшоты автоматически дублируются в блочное, и при похожем инциденте ВМ поднимаются за 6-8 минут, без долгих скачиваний. Просто запуск из снапшота, и прод снова в строю. Платформа автоматически определяет, какие копии стоит продублировать в блочном хранилище (например, последние 1–2 снапшота), а какие можно оставить только в объектном. За счёт этого получается система, где не нужно выбирать между скоростью и стоимостью, свежие данные под рукой, история хранится экономно.
Как работает Double Storage в Хайстекс Акура
После включения Double Storage в настройках системы все работает автоматически. Каждый новый бэкап сначала отправляется в выбранное объектное хранилище: это может быть S3, Selectel, VK Cloud или локальный MinIO. Если включено дублирование, то свежие копии параллельно записываются в блочное хранилище в виде облачных снапшотов, откуда потом можно поднять ВМ за пару минут. Политика хранения задается один раз. В итоге критичные данные всегда под рукой, а история уходит в холодное, дешевое хранилище. На практике – это подъем продакшена за 6-8 минут, дешевое хранение архивов, автоматизация, кроссплатформенность, и возможность восстанавливать как целую ВМ, так и отдельные файлы.
Где экономия и скорость особенно важны
Сегодня все больше компаний переходят на отечественные системы резервного копирования. Причина понятна: меньше зависимостей от внешних вендоров и больше контроля над процессом восстановления. Подход с Double Storage работает и на локальных площадках, и у российских облачных провайдеров, легко масштабируется и не требует дорогостоящей инфраструктуры. Например:
Финансовый сектор, с жесткими требованиями к времени восстановления.
Онлайн-ритейл, где каждую минуту простоя бизнес теряет деньги.
MSP / DRaaS-провайдеры, которым важна экономия на хранении при быстром отклике.
Гибридные инфраструктуры, например, локальный ЦОД + облако.
Сценарии BaaS/DRaaS, когда нужно дать клиенту быстрое восстановление, не тратя лишнее на хранение.
В бэкапе и DR часто все упирается в формальные метрики: тип хранилища, заявленный RTO/RPO, выполнение SLA. Но на практике бизнесу и инженерам важно одно – чтобы данные восстановились быстро и без потерь. Double Storage вырос именно из этого подхода. Не делать правильную схему ради схемы, а разработать инструмент, который помогает достичь цели. В итоге получилось решение, где данные поднимаются быстро, архивы не занимают много места, и всё без сложных обходных решений.
А как у вас организован бэкап? Поделитесь опытом в комментариях.