Цена восстановления: считаем не хранение бэкапа, а время возврата в строй

MAATRIX

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

Почему «дешёвый бэкап» — это ловушка

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

В этот момент выясняется, что «дешёвое» хранилище было дешёвым именно потому, что оптимизировано под запись и долгое хранение, а не под быстрое чтение больших объёмов. Скачивание десятков или сотен гигабайт с холодного архива, распаковка, разворачивание базы, проверка целостности — всё это время, в течение которого сервис не работает. И это время стоит денег: упущенные заказы, недоступный API для клиентов, штрафы по SLA, отток пользователей, которые ушли к конкуренту, пока у вас крутился прогресс-бар восстановления.

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

Что такое RTO и чем оно отличается от RPO

В индустрии резервного копирования есть два ключевых показателя, и их часто путают.

RPO (Recovery Point Objective) — это точка, на которую вы можете откатиться, то есть сколько данных вы готовы потерять. Если бэкап делается раз в сутки в 3:00, а авария случилась в 14:00, вы теряете 11 часов изменений — это и есть RPO в данном случае.

RTO (Recovery Time Objective) — это время, за которое система должна вернуться к работе после начала восстановления. Не время до момента аварии, а именно длительность самого процесса: от команды «начинаем восстановление» до момента «сервис снова принимает трафик и работает штатно».

Эта статья — про RTO, потому что именно он определяет, сколько часов (или дней) бизнес будет простаивать во время восстановления. RPO отвечает на вопрос «сколько данных мы потеряем», RTO — на вопрос «сколько денег мы потеряем на простое, пока эти данные возвращаем». Оба показателя важны, но при выборе схемы хранения бэкапов недооценивают именно RTO — потому что его сложнее посчитать заранее и он не виден в счёте за хранилище.

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

Из чего складывается настоящая цена восстановления

Вот формула, которая держит в поле зрения обе стороны уравнения:

Полная цена восстановления =
    Стоимость хранения бэкапа (за период)
  + RTO × Стоимость часа простоя для бизнеса

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

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

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

Холодный архив: дёшево хранить, дорого восстанавливать

Холодные хранилища (ленточные библиотеки, архивные тарифы объектных хранилищ, удалённые бэкап-серверы с медленным каналом) экономят деньги за счёт нескольких механизмов:

• Медленный или платный доступ на чтение. Многие архивные тарифы облачных хранилищ намеренно делают выгрузку данных дороже и медленнее хранения — это часть модели, по которой они дешёвые. У части сервисов запрос на восстановление файла из архивного класса вообще требует отдельного шага «разморозки» и ожидания, прежде чем файл станет доступен для скачивания.
• Более слабое железо на стороне хранилища. Дешёвый VPS под архив бэкапов обычно берут с минимумом CPU и с HDD вместо NVME — этого достаточно для последовательной записи раз в сутки, но узкое место при восстановлении, когда нужно быстро прочитать и распаковать большой объём.
• Удалённость и низкая пропускная способность канала. Если архив лежит в другом регионе или у провайдера с ограниченным исходящим трафиком, скачивание сотен гигабайт может занять часы просто из-за скорости канала — независимо от того, насколько быстрый там диск.
• Отсутствие подготовленной инфраструктуры под восстановление. Часто рядом с архивом бэкапов нет свободного сервера, куда можно сразу развернуть систему — сервер под восстановление ещё нужно арендовать, настроить и только потом накатывать данные. Это тоже часть RTO, которую забывают закладывать.

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

Как посчитать стоимость часа простоя для вашего бизнеса

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

Базовая оценка складывается из нескольких компонентов:

1. Прямая упущенная выручка. Средняя выручка за час работы, умноженная на долю операций, которые физически не могут произойти без сервиса (продажи в интернет-магазине, транзакции в платёжном сервисе, API-запросы у SaaS-клиентов).
2. Штрафы по SLA. Если у вас подписан договор с гарантией аптайма, за каждый час простоя сверх допустимого могут начисляться штрафы или компенсации клиентам — это фиксируемая, договорная часть цены простоя.
3. Стоимость труда во время инцидента. Час работы инженеров, которые в этот момент не разрабатывают продукт, а тушат пожар — часто в внеурочное время, с соответствующей наценкой.
4. Косвенные потери: отток и репутация. Труднее всего оценить точно, но именно они часто перевешивают прямую выручку — часть клиентов, столкнувшихся с недоступностью сервиса, больше не возвращается, а негативные отзывы снижают конверсию новых пользователей на месяцы вперёд.

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

Дальше считать просто: если восстановление с холодного архива занимает условно 6 часов, а с горячего дублирующего хранилища — условно 30 минут, разница в RTO — 5,5 часа. Умножьте эту разницу на посчитанную стоимость часа простоя — и вы получите реальную цену, которую вы платите за экономию на хранилище. Дальше сравнивайте эту цифру с разницей в ежемесячной стоимости хранения между вариантами хранилища. Это и есть решение, а не интуитивное «дешёвое хранилище — всегда выгоднее».

Как выбрать баланс: уровни хранения под ваш RTO

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

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

Практическая схема, которая обычно работает лучше, чем выбор одного уровня:

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

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

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

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