Сколько стоит потерять пять минут данных против суток

MAATRIX

Когда речь заходит про резервное копирование, почти все разговоры крутятся вокруг того, сколько эти бэкапы хранятся и куда их складывать. Но у аварии есть ещё один параметр, который стоит денег отдельно от места на диске — сколько данных вы готовы потерять безвозвратно, если сбой случится за секунду до следующего бэкапа. Это и есть RPO, Recovery Point Objective: не «сколько мы храним», а «сколько мы можем позволить себе потерять». Разница между RPO в пять минут и RPO в сутки — конкретный компромисс между стоимостью инфраструктуры резервного копирования и ценой того, что вы теряете при сбое. Разберём, из чего складывается каждая сторона этого компромисса и как выбрать RPO, который вашему бизнесу реально по карману.

Что такое RPO и почему это не то же самое, что RTO

RPO и RTO путают постоянно, хотя они отвечают на разные вопросы:

• RTO (Recovery Time Objective) — сколько времени пройдёт, прежде чем система снова заработает после сбоя. Это вопрос про простой.
• RPO (Recovery Point Objective) — на какой момент времени назад откатятся данные, когда систему поднимут. Это вопрос про потерю.

Логика простая: если последний успешный бэкап был сделан в 14:00, а сбой произошёл в 14:04, вы теряете все изменения за эти четыре минуты — они физически не попали ни в один снапшот. При суточном расписании и сбое за минуту до следующего бэкапа теряются почти сутки: все заказы, платежи, правки в базе, которые накопились с последнего дампа.

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

RTO и RPO почти всегда обсуждаются в паре, но платите вы за них по-разному: RTO покупается инфраструктурой восстановления (готовый резервный сервер, автоматическое переключение), а RPO — частотой и надёжностью самого резервного копирования. Можно иметь мгновенный RTO (горячий резерв поднимается за секунды) и при этом плохой RPO (бэкапы раз в сутки) — система поднимется быстро, но с данными, устаревшими на день. Экономику самого RTO и разных режимов резерва мы разбирали в статье про холодный, тёплый и горячий резерв — здесь фокус только на второй половине уравнения.

Пять минут: что покупает частое резервное копирование

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

Нагрузка на систему. Каждый цикл бэкапа — это чтение данных с диска, а для баз данных зачастую ещё и блокировки или снапшоты на уровне СУБД. При частоте в пять минут вы переходите либо на инкрементальное копирование (снимается только дельта с прошлого снапшота), либо на непрерывную репликацию (данные пишутся сразу в двух местах) — полный дамп базы каждые пять минут для заметного объёма данных превращается из резервного копирования в постоянную фоновую нагрузку, конкурирующую с продакшеном за диск и сеть. Без ionice и правильного планирования частый бэкап реально мешает работе основного сайта через борьбу за ввод-вывод — проблема вполне частая на бюджетных VPS.

Объём хранимых версий. Точки восстановления каждые пять минут даже за один день — это 288 версий, за неделю уже больше двух тысяч, если не сворачивать старые версии в более редкую сетку — почасовую, потом суточную. Логика ротации усложняется, и хранилище растёт быстрее, чем при редком бэкапе с той же глубиной истории. Здесь напрямую работает вопрос сколько хранить бэкапы и какая ротация — при частом RPO ротацию продумывать обязательно, иначе диск с бэкапами исчерпается быстрее, чем кажется на старте.

Сложность инфраструктуры репликации. RPO в пять минут для транзакционных систем обычно реализуется не через cron-скрипт с дампом, а через механизмы репликации на уровне СУБД — WAL-архивирование в PostgreSQL, binlog-репликацию в MySQL, или через pg_basebackup в связке с непрерывной архивацией WAL. Это качественно другой инженерный контур: нужен второй узел (хотя бы реплика для чтения WAL), мониторинг лага репликации и процедура point-in-time recovery, которая восстанавливает базу на конкретную секунду, а не просто разворачивает последний дамп.

Пример конфигурации непрерывной архивации WAL в PostgreSQL, которая на практике даёт RPO в единицы минут (зависит от частоты archive_timeout и объёма трафика записи):

# postgresql.conf
archive_mode = on
archive_command = 'rclone copyto %p remote:pg-wal-archive/%f'
archive_timeout = 300  # форсировать выгрузку WAL-сегмента не реже раза в 5 минут
wal_level = replica

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

Стоимость инфраструктуры. Частый RPO почти всегда требует более мощного сервера (запас по I/O и CPU под фоновую нагрузку репликации), хранилища с более высокой пропускной способностью и, как правило, отдельного узла под саму репликацию или архив WAL. Точные цифры зависят от объёма данных и провайдера, но направление однозначное: чем короче интервал RPO, тем больше постоянных, а не разовых расходов.

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

RPO в сутки — самый простой и дешёвый вариант с точки зрения инфраструктуры, и именно поэтому он остаётся дефолтом для огромного числа проектов.

Что вы экономите. Ночной cron-job с полным дампом базы и архивом файлов — это минимальная инженерная сложность: один скрипт, одно расписание, минимум точек отказа. Нагрузка на систему сосредоточена в узком окне (обычно ночью, на минимуме трафика), поэтому даже на скромном VPS полный дамп не мешает продакшену. Хранилище нужно на несколько десятков ежедневных версий, а не на тысячи — ротация тривиальная: например, хранить последние 7 суточных копий и по одной на конец недели за последний месяц.

Простой пример суточного бэкапа с ротацией по restic, который на практике закрывает RPO в сутки для большинства некритичных систем:

#!/bin/bash
# /opt/scripts/backup-daily.sh — запускается по cron в 03:00
export RESTIC_REPOSITORY="s3:https://storage.example.com/backups"
export RESTIC_PASSWORD_FILE="/etc/restic/password"

pg_dump -U app_user app_db | gzip > /var/backups/db-$(date +%F).sql.gz
restic backup /var/backups /etc/app-config
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

Чем вы рискуете. Цена этой простоты — в худшем случае вы теряете почти сутки данных. Если сбой происходит в 23:50, а последний бэкап был снят в 03:00 этого же дня, потеряно почти 21 час работы. Для интернет-магазина это заказы, оформленные за день, которые придётся восстанавливать вручную (если вообще получится) — по логам почты, по выпискам платёжной системы, по памяти клиентов. Для CRM — потерянные контакты и сделки, которые менеджеры создавали весь день. Для блога или статического контента это вообще не проблема, потому что правки легко внести повторно за пару минут.

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

Как посчитать реальную стоимость каждой стратегии

Сравнение «пять минут дороже, сутки дешевле» верно только на уровне направления, но для реального решения нужна более конкретная модель. У задачи есть две стороны расходов, и обе нужно сопоставить.

Сторона первая — стоимость инфраструктуры RPO. Сюда входит:

• дополнительный сервер или мощность под репликацию/частые снапшоты (если частый RPO требует отдельного узла);
• объём хранилища под возросшее число версий и глубину истории;
• трафик на выгрузку данных, если бэкапы уходят за пределы основного сервера — а они должны уходить: копия, лежащая рядом с оригиналом на том же диске, не переживёт аварию самого сервера и не является полноценным бэкапом;
• инженерное время на настройку и поддержку более сложного контура (WAL-архивация, мониторинг лага репликации, процедуры point-in-time recovery — всё это требует внимания сверх разового скрипта).

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

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

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

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

Методика выбора RPO под реальную ценность данных

Главная ошибка в выборе RPO — установить одно значение на весь проект «для простоты». В реальной системе почти всегда есть несколько категорий данных с разной ценностью, и уравнивать их RPO по верхней планке — переплата, а по нижней — риск.

Практическая методика — пройтись по системе и явно раскидать компоненты по трём условным категориям:

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

Данные, где потеря нескольких часов неприятна, но переживаема. Контент, редактируемый в течение дня — статьи, карточки товаров, настройки, переписка во внутреннем чате. RPO в несколько часов (снапшот каждые 4–6 часов вместо раз в сутки) — разумный компромисс: заметно снижает потери по сравнению с суточным циклом, но не требует полноценной непрерывной репликации.

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

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

Практические паттерны: разные RPO для разных систем

На практике удобно ориентироваться на несколько типовых профилей, которые закрывают большинство реальных ситуаций.

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

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

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