Как перенести резервное копирование в облако и не переплачивать за инфраструктуру

Многие компании годами копят железо под бэкапы, платят за электричество, держат отдельного администратора — и всё равно оказываются без рабочей копии в нужный момент. Другие переезжают в облако, ожидая экономии, а получают счёт, который неприятно удивляет уже на второй месяц. Проблема почти никогда не в самой идее хранить данные удалённо, а в том, как это хранение устроено.

В этой статье расскажем, как перенести бэкапы в облако так, чтобы это было и надёжнее, и дешевле, чем содержать собственный сервер.

Почему on-premise-бэкапы обходятся дороже, чем кажется

Собственная инфраструктура бэкапа выглядит контролируемой: железо куплено, лицензии оплачены, бюджет зафиксирован. Реальная стоимость владения раскладывается на статьи, которые редко сводят в одну строчку:

• Амортизация. СХД или резервный сервер стоимостью 500 000–800 000 рублей списывается за 3–5 лет. Через пять лет оборудование нужно менять, и капитальные расходы повторяются независимо от того, вырос ли объём данных вдвое.
• Электроэнергия. Сервер бэкапа мощностью 250 Вт потребляет около 2 200 кВт·ч в год. При тарифе 6–8 рублей за кВт·ч это 13 000–17 000 рублей ежегодно только на питание, без охлаждения стойки, которое в среднем удваивает потребление ЦОД.
• Администрирование. Мониторинг заданий, тесты восстановления, обновление агентов, разбор ошибок реалистично занимают 2–4 часа в неделю. При стоимости специалиста 120 000–180 000 рублей в месяц это 15 000–35 000 рублей ежегодно только на задачи по бэкапу.
• Лицензии ПО. Корпоративные продукты для резервного копирования лицензируются по числу виртуальных машин или агентов и требуют ежегодного продления.

TCO on-prem-бэкапа на три года — капзатраты плюс 40–60% сверху на эксплуатацию. Облачное хранение того же объёма при правильно выбранных классах и настроенных lifecycle policies часто оказывается сопоставимым или дешевле уже на третий год.

Единая точка отказа

Если резервные копии лежат в той же серверной, что и боевые серверы, это второй экземпляр данных в одной точке риска. Пожар, затопление, кража оборудования или отказ стойки уничтожают прод и бэкап одновременно.

Ransomware усиливает угрозу: 96% атак-вымогателей целенаправленно ищут резервные копии, а в 2025 году вымогательское ПО участвовало в 44% подтверждённых взломов против 32% годом ранее. Восстановление при нетронутом бэкапе обходится примерно в 375 000 долларов, при скомпрометированном — около 3 млн долларов. Разница в восемь раз определяется именно архитектурой хранения — локальный СХД с сетевым доступом шифруется при атаке на домен так же легко, как рабочие станции, и физическая или логическая изоляция бэкапа здесь обязательна.

Правило 3-2-1 и роль облака

Правило 3-2-1 сформулировал фотограф Питер Кро в 2005 году, позднее его популяризовал Veeam: три копии данных на двух разных носителях, одна из которых — offsite, то есть копия данных хранится физически отдельно от основной инфраструктуры: на другой площадке, в другом здании или в другом городе, а не в той же серверной, где находятся рабочие серверы. Последний пункт соблюдают реже всего.

Локальный NAS закрывает первые два условия: несколько копий, разные носители. Offsite-хранение требует либо второй площадки, либо ленточной библиотеки с физической доставкой, либо облака — из этих трёх вариантов облако даёт минимальные операционные расходы при сопоставимой надёжности.

К 2025–2026 годам отраслевой стандарт сместился к расширению 3-2-1-1-0: добавляется требование иметь одну копию в неизменяемом (immutable) или изолированном (air-gapped) хранилище и гарантированный ноль ошибок при проверке восстановления. Именно immutable и air-gapped-бэкапы статистически переживают атаки-вымогатели. Object Storage с включённым Object Lock решает эту задачу.

Как выстроить облачный бэкап без переплаты: архитектурные решения

Переплата в облаке появляется не из-за цены хранения, а из-за трёх ошибок в архитектуре: данные годами лежат в горячем классе, lifecycle policy не настроена, egress-трафик при восстановлении не заложен в бюджет.

Для большинства СМБ с объёмом до 10–20 ТБ прямой бэкап в Object Storage с настроенной lifecycle policy даёт оптимальное сочетание стоимости и управляемости. Enterprise с десятками петабайт и жёсткими RTO чаще выбирает гибрид.

Object Storage как основа экономного бэкапа

Object Storage принципиально отличается от блочного хранения: оплата идёт за фактически занятое место, а не за зарезервированный том. Нет ограничений IOPS, которые определяют стоимость блочных дисков, поэтому не приходится заранее угадывать объём и переплачивать за неиспользованную ёмкость.

Object Storage поддерживает два класса хранения:

• Hotbox — горячий класс для данных с частым доступом. Подходит для последних резервных копий, где нужен быстрый RTO.
• Icebox — холодный класс, используется для хранения бэкапов, логов, архивов и других редко используемых данных. Стоимость хранения здесь заметно ниже, чем в горячем классе, а трафик — дороже.

Отдельно стоит учитывать, что в облаке нет отдельного класса Glacier как бакета. Для сценариев долгосрочного хранения используется сервис Cloud Backup, который создаёт собственный бакет. При этом стоимость хранения в нём может отличаться (и в ряде случаев быть выше), чем при использовании стандартных классов Object Storage, что важно учитывать при проектировании стратегии бэкапа.

Egress-трафик становится отдельной статьёй расходов, о которой часто забывают. Восстановление 10 ТБ у крупных провайдеров (AWS, Azure, GCP) может стоить 700–1 100 долларов только за трафик, а при регулярных тестах восстановления сумма увеличивается кратно.

Lifecycle Policies: основной инструмент экономии

Главная причина переплаты — бессрочное хранение всех версий по цене горячего класса. Без lifecycle policy бакет растёт, тариф копится, а трёхлетние данные стоят столько же, сколько вчерашний снимок.

Lifecycle policy автоматически переводит объекты между классами по возрасту:

• 0–7 дней — горячий класс (Hotbox), быстрые восстановления при инцидентах последней недели.
• 8–30 дней — стандартный класс, еженедельные точки восстановления, доступ за минуты.
• 31–360 дней — холодный класс (Icebox), ежемесячные и квартальные точки, запросы редки.
• Старше 360 дней — архивный класс (Glacier) или удаление по retention-политике.

Разница между горячим и архивным классом — примерно в 5–10 раз по цене. Lifecycle-настройку логично задать сразу при создании бакета: менять её задним числом для уже накопленных петабайт сложнее, чем заложить правильную схему с первого дня.

Версионирование и retention без раздувания объёма

Версионирование объектов защищает от случайного удаления и позволяет откатиться к нужной точке, но без настроек retention превращается в неконтролируемый рост объёма — каждая версия хранится отдельно и тарифицируется.

Практическая политика хранения, которую стоит зафиксировать до миграции:

• Ежедневные инкременты — 14 дней.
• Еженедельные полные — 3 месяца.
• Ежемесячные полные — 12 месяцев.
• Ежегодные полные — по требованию регулятора.

Политику реализуют двумя способами: через lifecycle rules в Object Storage (надёжнее, не зависит от агента) и через встроенные retention-настройки самого ПО бэкапа. Совместное использование обоих уровней даёт запас прочности — даже если агент ошибётся с ротацией, lifecycle rule удалит устаревший объект.

При хранении персональных данных граждан РФ выбор облака ограничен дополнительными требованиями: ЦОД должен находиться в России, инфраструктура — соответствовать 152-ФЗ.

План миграции

Миграция бэкапов в облако — это последовательность из пяти шагов, где каждый предыдущий задаёт рамки следующего.

1. Инвентаризация. Для каждого источника данных фиксируем объём и темп прироста, RPO (допустимая потеря данных, определяет частоту бэкапа), RTO (допустимое время восстановления, определяет класс хранения для свежих копий) и требования регуляторов — для персональных данных граждан РФ это хранение на территории России по 152-ФЗ.

2. Выбор инструмента. Пример S3-совместимых решений без привязки к вендору:

• Veeam Backup & Replication — стандарт для VMware и Hyper-V, подключает Object Storage как Scale-out Backup Repository.
• Acronis Cyber Backup — агентская модель для физических и виртуальных машин с поддержкой S3.
• Bareos / Bacula — open source для команд с DevOps-экспертизой.
• Cloud Backup VK Cloud — встроенные снапшоты для ВМ и баз PostgreSQL/MySQL внутри VK Cloud без установки агентов.
• Restic / Duplicati — лёгкие open source-инструменты для файловых бэкапов напрямую в S3.

3. Создание хранилища. Бакет под бэкапы создаётся отдельно от рабочих данных, с сервисным аккаунтом, у которого есть права только на запись — так бэкапы нельзя удалить даже при утечке ключей. Lifecycle policy и версионирование настраиваются сразу, до подключения агента.

4. Настройка агента и первый бэкап. Object Storage подключается как S3-совместимый target, расписание задаётся по RPO. Первый полный бэкап самый долгий — его лучше запускать в нерабочее время или с ограничением пропускной способности, чтобы не забивать production-канал.

5. Проверка восстановления. Бэкап, который ни разу не восстанавливали, остаётся предположением. Проверяют тестовое восстановление отдельного файла, восстановление ВМ в изолированном окружении, фактический RTO против целевого и фиксируют процедуру в runbook.

Как считать стоимость: типичные ошибки

Бюджет облачного бэкапа чаще всего ошибается не в цене за гигабайт, а в трёх статьях:

• Исходящий трафик (egress). Чтение при восстановлении тарифицируется отдельно от загрузки. При регулярных тестах egress добирает 20–30% сверху к счёту, а разовое восстановление 10 ТБ стоит порядка 700–1 100 долларов только за трафик. В VK Cloud класс Glacier даёт бесплатный исходящий трафик.
• Хранение версий без lifecycle policy. При ежедневных инкрементах за год можно накопить объём в 10–20 раз больше фактического, и весь он идёт по тарифу горячего хранилища.
• Избыточные классы хранения. Бэкапы годичной давности в горячем классе — переплата в 3–5 раз по сравнению с холодным.

Пример на 5 ТБ данных за год: первый полный бэкап (5 ТБ, стандартный класс, разовая загрузка), ежедневные инкременты (~50 ГБ × 14 дней, горячий класс), еженедельные полные (~350 ГБ × 12 недель, переход в холодный класс через 30 дней), ежемесячные полные (5 ТБ × 12, переход в архивный класс через 90 дней), плюс egress по объёму реальных восстановлений.

On-prem против облака за три года: on-prem — капзатраты каждые 3–5 лет на оборудование, круглосуточные расходы на электричество и охлаждение, 2–4 часа в неделю на обслуживание, лицензии по числу ВМ, бесплатное локальное восстановление. Облако — без капзатрат, электричество и охлаждение уже в тарифе, минимальная нагрузка на обслуживание, лицензии зависят от инструмента, восстановление платное через egress. Для большинства СМБ с объёмом 1–20 ТБ облако при правильной настройке становится экономичнее со второго года.

Безопасность облачных бэкапов

Облако само по себе не делает бэкап ни безопасным, ни уязвимым — всё решают настройки:

• Шифрование. At-rest на стороне хранилища (SSE) и in-transit по защищённому каналу (TLS). Для чувствительных данных добавляют client-side encryption, при котором провайдер видит только шифротекст.
• Минимум прав. Сервисный аккаунт агента получает права только на запись и чтение конкретного бакета, без удаления. Учётные данные бэкапа отделяют от production-учёток, при работе с персональными данными учитывают 152-ФЗ.
• Object Lock. Реализует принцип WORM (Write Once Read Many) — объект блокируется от изменения и удаления на заданный срок, даже для администратора с полными правами. VK Cloud Object Storage поддерживает Object Lock в режимах Compliance, Governance и Legal Hold. Именно неизменяемые копии переживают атаки-вымогатели, тогда как бэкапы с правом удаления шифруются вместе с продом.