Экономия на бэкапах и её реальная цена

MAATRIX

Раз в квартал в переписке с владельцем небольшого проекта всплывает одна и та же фраза: «бэкапы — это лишние расходы, у нас и так всё на RAID, обойдёмся». Обычно так говорит человек, который ещё не терял продакшн-базу целиком и не объяснял клиентам, почему их заказы пропали. Экономика тут довольно жёсткая: маленькая гарантированная плата против редкого, но катастрофического по последствиям события. Если считать честно, а не «на глаз», отказ от резервного копирования почти всегда оказывается самой дорогой из всех доступных стратегий — просто счёт за неё приходит не сразу и не одной строкой.

Сколько на самом деле стоит бэкап

Стоимость бэкапа — это не абстрактная «плата за диск», а сумма нескольких конкретных статей:

• Место хранения копий. Если бэкапы сжаты и дедуплицированы (так делают borgbackup, restic, kopia), реальный объём на диске обычно заметно меньше суммы всех снапшотов — совпадающие блоки между версиями не хранятся повторно. Точный коэффициент экономии зависит от того, как часто и насколько сильно меняются данные у вас конкретно, поэтому нет смысла называть универсальный процент — но порядок величины стоит прикинуть на тестовом прогоне перед тем, как считать бюджет.
• Плата за отдельный сервис бэкапов, если вы не поднимаете его сами — стороннее объектное хранилище (S3-совместимое), управляемый бэкап-сервис или отдельный VPS под архив. Здесь важно не путать тариф на «обычный» диск с тарифом на холодное хранилище — они считаются по-разному, и конкретные цифры нужно смотреть в прайсе конкретного провайдера на момент аренды, а не ориентироваться на цифры из старых статей.
• Исходящий трафик, если копия хранится за пределами сети провайдера основного сервера — при восстановлении вам придётся скачать весь объём данных обратно, и это тоже стоит денег и времени.
• Время администратора на настройку, ротацию, шифрование и — что критично — периодическую проверку восстановления. Именно эта статья расходов чаще всего игнорируется, а именно из-за неё бэкапы годами лежат «на всякий случай», ни разу не будучи развёрнутыми обратно.

Итоговая формула простая:

Стоимость_бэкапа = Хранилище + Сервис_бэкапов (если сторонний) + Трафик + Время_на_обслуживание

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

Сколько стоит потеря данных, когда бэкапа нет

Здесь расходы делятся на два принципиально разных сценария.

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

Восстановление невозможно. Это самый тяжёлый и, к сожалению, частый случай для баз данных: при повреждении файловой структуры СУБД или при перезаписи блоков диска новыми данными исходную информацию не восстановит уже никто. В этом случае у вас остаётся только ручное восстановление того, что получится собрать из смежных источников — переписки с клиентами, email-уведомлений, логов платёжной системы, памяти сотрудников. Часть данных — история заказов, персональные настройки клиентов, накопленные бонусы, черновики, внутренняя переписка — не восстановится никогда, сколько бы времени вы на это ни потратили.

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

Простой бизнеса — самая недооценённая статья расходов

Разговор о потере данных почти всегда сводится к «сколько стоит восстановить диск», но диск — не главная статья расходов. Главная — это простой.

Пока сервис не работает, а он не работает всё время, пока данные не собраны заново, вы одновременно теряете:

• Упущенную выручку — заказы, которые клиенты сделали бы, но не смогли, и просто ушли к конкурентам.
• Оплату труда простаивающих сотрудников — служба поддержки, менеджеры, разработчики, которые физически не могут работать без данных, но зарплату всё равно получают.
• Стоимость экстренных работ — восстановление в разгар инцидента почти всегда дороже планового обслуживания: приходится привлекать сторонних специалистов по срочному тарифу, работать по ночам, откладывать другие задачи.

Практический способ прикинуть порядок цифр для своего проекта:

Стоимость_простоя = (Упущенная_выручка_в_час + ФОТ_простаивающих_в_час) × Длительность_простоя_в_часах

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

Репутационный урон и юридические риски

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

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

Юридические риски. Если среди утраченных данных были персональные данные клиентов, ответственность может выйти за пределы репутационных потерь. В России это требования 152-ФЗ, в Европе — GDPR с обязанностью уведомлять регулятора и субъектов данных об инциденте в короткий срок и с риском серьёзных штрафов при доказанной халатности в защите данных. Если у вас есть клиенты или пользователи из ЕС, стоит заранее свериться с требованиями — этому посвящён отдельный материал про требования к персональным данным в ЕС для сервера. Отдельно — договорные риски: если у вас B2B-контракты с SLA по сохранности данных, их нарушение может означать не просто недовольство клиента, а прямые штрафные санкции по договору.

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

Бэкап как страховка: считаем ожидаемую стоимость риска

Самый честный способ сравнить экономию на бэкапах с их стоимостью — посчитать ожидаемую стоимость риска, а не сравнивать конкретный месячный счёт с абстрактным «а вдруг обойдётся».

Логика та же, что у любой страховки: вы платите маленькую гарантированную сумму, чтобы не платить (с некоторой вероятностью) огромную негарантированную. Формула:

Ожидаемая_стоимость_без_бэкапа = P(потеря данных) × Полная_цена_потери
Ожидаемая_стоимость_с_бэкапом = Стоимость_бэкапа (гарантированно) + P(бэкап тоже не спас) × Полная_цена_потери

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

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

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

Отдельно стоит учесть второе слагаемое — P(бэкап тоже не спас). У бэкапа без регулярной проверки восстановления эта вероятность не нулевая и иногда пугающе высокая: копия может годами создаваться «успешно» по логам, но при попытке восстановления оказаться битой, неполной или несовместимой с текущей версией софта. Про такой случай на практике есть отдельный разбор — бэкапы шли год и оказались нерабочими. Бэкап без периодического тестового восстановления — это не страховка, а иллюзия страховки: вы платите взнос, но не проверили, что полис вообще действует.

«У меня же RAID, зачем ещё бэкап» — частая псевдоэкономия

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

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

RAID не защищает вас от:

• Случайного удаления или порчи данных. Команда rm -rf не по той папке, ошибочный DROP TABLE, баг в скрипте миграции — RAID синхронно реплицирует любое изменение на все диски массива, включая удаление. Второй диск не «откатит» ошибку — он просто аккуратно повторит её.
• Шифровальщиков и логической порчи. Если файловая система или содержимое файлов повреждены программно, RAID честно сохранит эту порчу на всех дисках одновременно.
• Отказа контроллера или всего сервера целиком. Сгоревший RAID-контроллер, кража сервера, пожар или затопление в дата-центре выводят из строя весь массив разом — совпадающая копия на всех дисках не спасает, если физически недоступны все диски сразу.
• Молчаливой деградации без мониторинга. RAID может работать в деградированном режиме (один диск уже отказал) неделями, если никто не следит за статусом массива — а второй отказ в этом окне означает полную потерю данных без всякого шанса на восстановление штатными средствами. Реальный пример такого сценария — диск в RAID сыпался месяц, пока мониторинг молчал.

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

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