Подписка на бэкап-сервис против своего хранилища: расчёт по объёму

MAATRIX

Объём резервных копий почти у любого проекта растёт со временем, а не остаётся постоянным — новые снапшоты, новые версии баз, новые файлы пользователей. Пока данных немного, облачный бэкап-сервис с оплатой за гигабайт выглядит удобным и дешёвым решением: платишь только за то, что реально хранишь, ничего не администрируешь. Но у тарифа «за ГБ в месяц» есть неприятное свойство — он растёт линейно вместе с объёмом, тогда как свой сервер с диском под резервные копии стоит примерно одинаково что при 200 ГБ, что при 1,5 ТБ, пока хватает места на диске. Разберём честную методику расчёта: как устроены тарифы облачных бэкап-сервисов, сколько стоит свой сервер под эту задачу, и главное — при каком объёме данных кривые пересекаются.

Как устроены тарифы облачных бэкап-сервисов

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

Базовая переменная почти везде одна — цена за гигабайт хранимых данных в месяц, обозначим её p. На неё дальше накручиваются модификаторы:

• Пороговые планы вместо честного полёта по ГБ. Многие сервисы продают не абстрактные гигабайты, а пакеты — например, «до 500 ГБ» за фиксированную сумму, и превышение этого порога на 1 ГБ означает переход на следующий пакет целиком, а не доплату за один гигабайт. Реальная стоимость поэтому скачками, а не плавной прямой.
• Плата за исходящий трафик при восстановлении. Загрузка данных в облако обычно бесплатна или дешева, а вот скачивание при реальном восстановлении после инцидента — отдельная и часто заметная статья расходов, которую легко упустить при первом взгляде на прайс.
• Частота версионирования и хранения снапшотов. Если сервис хранит не только последнюю копию, а историю версий за N дней, фактический занимаемый объём на биллинге может быть заметно больше объёма одной актуальной копии — здесь важно смотреть не на «сколько весят мои данные», а на «сколько версий сервис реально хранит одновременно».
• Уровни хранения (горячее/холодное). Часть провайдеров даёт более дешёвый тариф для архивных данных, к которым обращаются редко, но с платой за ускоренное восстановление, если копия вдруг понадобилась срочно. Тарифы горячего и холодного хранения обычно различаются в разы, и путать их при прикидке бюджета — частая ошибка.
• Минимальная плата за место, даже вне объёма. Некоторые тарифы включают фиксированную часть (за само наличие аккаунта, минимальное число хранимых машин или устройств) поверх переменной части за объём.

Итоговая формула стоимости облачной подписки в месяц для объёма данных V (в ГБ):

Стоимость_облака(V) = Фикс_плата + p × V + Трафик_восстановления(при инциденте)

Мы намеренно не подставляем сюда актуальные цифры конкретных сервисов — рынок бэкап-услуг пересматривает прайсы, курс валют контракта нестабилен, а точную цену за ГБ на текущий момент вы получите за пару минут на сайте нужного провайдера. Для методики расчёта важна не конкретная цифра p, а сам факт: это переменная часть, которая растёт линейно вместе с объёмом хранимых данных, без потолка.

Сколько стоит свой сервер под резервное хранилище

Альтернатива — не облачная подписка, а отдельный сервер (или дополнительный диск на существующем), где вы держите резервные копии сами: локально через rsync/rclone, или через выделенный инструмент вроде borgbackup, restic, kopia или urbackup.

Прямые статьи расходов здесь принципиально другие:

Ключевое отличие от облачной подписки: цена сервера с диском под резервные копии — почти константа в границах одного тарифного плана. Сервер с 1 ТБ диска стоит одну и ту же сумму в месяц независимо от того, занято на нём 200 ГБ или 950 ГБ бэкапов — вы платите за выделенный объём, а не за фактически использованный. Рост стоимости происходит скачками — только когда данные перерастают текущий диск и нужно переходить на следующий тарифный план с бо́льшим объёмом хранилища.

Если бэкапы сжаты и дедуплицированы — а именно так работают borgbackup, restic и kopia, — реальный объём на диске обычно заметно меньше суммы всех логических снапшотов, потому что повторяющиеся блоки между версиями не хранятся дважды. Это ещё сильнее увеличивает эффективный запас, который даёт один и тот же диск. Пошаговая настройка такого сервера с нуля — в статье VPS для бэкапов и архива: что выбрать и как настроить, а требования к ресурсам под конкретный объём разобраны отдельно в материале сколько ресурсов нужно VPS для бэкапов и архива.

Формула стоимости своего хранилища в месяц:

Стоимость_своего(V) = Цена_сервера_с_диском(ступенчато по тарифу) + Часы_админа × Ставка_часа

Часы администратора на 1 ГБ или на 100 ГБ практически не отличаются — настройка ротации и мониторинга занимает примерно одно и то же время что для 200 ГБ бэкапов, что для 1,5 ТБ. Это и есть главное структурное отличие от облачной модели: у своего сервера издержки почти не зависят от объёма, у облака — зависят напрямую.

Точка перелома: при каком объёме свой сервер выгоднее подписки

Раз стоимость облака растёт линейно с объёмом (p × V), а стоимость своего сервера в границах тарифа почти постоянна (C), у этих двух прямых на графике «расходы / объём» неизбежно есть точка пересечения. До неё выгоднее облако, после — свой сервер.

Найти эту точку алгебраически просто. Приравняем расходы:

Фикс_плата + p × V = C + Часы_админа × Ставка_часа

V_перелома = (C + Часы_админа × Ставка_часа − Фикс_плата) / p

Где:

• V_перелома — объём в ГБ, начиная с которого свой сервер дешевле подписки;
• C — месячная стоимость сервера с диском нужного объёма;
• p — цена облачного тарифа за ГБ в месяц;
• Часы_админа × Ставка_часа — реальная стоимость обслуживания своего решения в пересчёте на деньги.

Практический смысл формулы: чем выше p (цена облачного ГБ) и чем ниже стоимость своего сервера и его обслуживания, тем раньше — при меньшем объёме — наступает точка перелома. И наоборот: если облачный тариф уже сам по себе дешёвый за ГБ, а часы администратора считать по рыночной ставке, точка перелома может отодвинуться на объёмы, которые небольшому проекту просто не нужны.

Важный нюанс, который часто упускают: формула считает точку перелома для уже достигнутого объёма, а не для объёма через год. Если данные растут на несколько десятков процентов в год (обычная ситуация для растущего проекта с базами и файлами пользователей), правильнее строить не одну точку, а график на 12-24 месяца вперёд по прогнозируемой траектории роста V(t) — и смотреть, когда линия облака пересечёт линию своего сервера с учётом этого роста, а не только текущего снимка.

Иллюстративный пример: как считается, а не сколько это стоит в вашем случае

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

Предположим (это допущение для иллюстрации, а не факт рынка):

• облачный бэкап-сервис берёт p = 5 ₽ за ГБ в месяц, без фиксированной платы;
• сервер с диском на 1 ТБ под резервное хранилище стоит C = 1200 ₽ в месяц;
• администрирование такого сервера — около 1,5 часа в месяц по ставке 2000 ₽/час.

Стоимость своего решения:

1200 + 1,5 × 2000 = 4200 ₽/мес — фиксированно, пока данные помещаются в 1 ТБ

Точка перелома:

V_перелома = 4200 / 5 = 840 ГБ

При таких условных вводных облако выгоднее, пока данных меньше 840 ГБ, а после этого порога свой сервер с диском на 1 ТБ становится дешевле — и продолжает быть дешевле вплоть до заполнения диска, то есть до 1 ТБ, после чего придётся переходить на следующий тарифный план сервера, и расчёт нужно делать заново с новым C.

Обратите внимание, насколько сильно результат зависит от вводных: если у вас уже есть сервер под другие задачи (VPN, CI/CD, внутренние сервисы) и вы просто добавляете диск под бэкапы, C в формуле — это не полная цена сервера, а только предельная стоимость дополнительного диска, что сдвигает точку перелома сильно ниже. И наоборот — если вы никогда не администрировали резервное копирование и рыночная ставка часа для вас высокая, точка перелома уходит на объёмы, которых у небольшого проекта может не быть вовсе.

Что теряете при переходе на свой сервер

Экономия по формуле выше — только часть картины. Свой сервер под бэкапы — это не «включил и забыл», а операционная ответственность, которую облачный сервис снимает с вас за деньги.

Администрирование резервного копирования становится вашей задачей целиком:

• настройка ротации и retention-политики (сколько версий хранить и как долго) — нужно решить и поддерживать самостоятельно, подробный ориентир есть в материале сколько хранить бэкапы и какая ротация;
• шифрование копий и управление ключами — если ключ шифрования потерян вместе с сервером, сами бэкапы становятся бесполезным набором байт;
• периодическая проверка восстановления — бэкап, который никогда не разворачивали обратно, не факт что рабочий. Реальный случай, когда это выяснилось слишком поздно, разобран в материале бэкапы шли год и оказались нерабочими;
• мониторинг самого процесса бэкапа — облачный сервис сам сообщает об ошибке синхронизации, у своего решения за это отвечает cron-задача и алерты, которые нужно настроить и не забыть проверить, что они действительно приходят.

Географическое резервирование копий — отдельная и не всегда очевидная статья. Правило «3-2-1» (минимум три копии, на двух разных типах носителей, одна физически в другом месте) применимо к бэкапам независимо от того, где они хранятся — но у облачного сервиса геораспределение обычно уже встроено в инфраструктуру провайдера, а при своём сервере вам придётся сознательно разворачивать вторую копию в другом дата-центре или у другого провайдера самостоятельно. Практический разбор того, как соблюсти это правило без лишних трат, — в статье правило 3-2-1 для бэкапов дёшево. Держать все копии на одном сервере — это не резервное копирование, а иллюзия резервного копирования: при отказе именно этого сервера или площадки вы теряете всё разом.

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

Это не аргумент против своего сервера — многие технические команды справляются с этим списком без проблем, если резервное копирование уже часть их процессов. Это аргумент за честный учёт: сравнивать нужно не «облако стоит X ₽» против «свой сервер стоит Y ₽», а полную стоимость владения с учётом времени, которое реально требуется на все перечисленные задачи.

Когда выгоднее подписка, а когда свой сервер

Свести разбор к практическому ориентиру:

Облачная подписка обычно предпочтительнее, если:

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

Свой сервер под резервное хранилище обычно выгоднее, если:

• объём данных уже превысил точку перелома и продолжает расти — тогда экономия увеличивается со временем, а не разово;
• в компании уже есть администрируемая инфраструктура (VPN, CI/CD, внутренние сервисы) — процессы обновления и мониторинга уже выстроены, добавить ещё один диск под бэкапы — предельные, а не стартовые издержки;
• нужен полный контроль над данными и место хранения принципиально важно (требования по локализации, договорные условия с клиентами);
• команда готова инвестировать время в проверяемое, регулярно тестируемое резервное копирование, а не поставить cron-задачу один раз и забыть.

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

Частые вопросы