Хранение бэкапов вне площадки: цена спокойствия за терабайт

MAATRIX

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

Почему один дата-центр — это одна точка отказа

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

Проблема в другом классе инцидентов — тех, что бьют не по одному диску или одной VM, а по всей площадке целиком:

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

В любом из этих сценариев оригинал и бэкап, если они физически рядом, гибнут вместе. Мы уже разбирали этот антипаттерн отдельно в статье про бэкап на том же сервере — там подробнее про механику отказа. Здесь важно другое: вероятность такого события низкая (в масштабах одного сервера — за годы работы у большинства это вообще не случается), но цена ошибки — не "потеряли час данных", а "потеряли всё и одновременно". Именно от этого сценария и защищает offsite-хранение: физически отдельная площадка, куда катастрофа основного ДЦ не дотягивается.

Что на самом деле означает "вне площадки"

Термин "offsite" на практике трактуют слишком вольно, и это стоит прояснить, прежде чем считать цену. Реальная защита от катастрофического сценария требует физического разнесения, а не просто "второй копии где-то ещё":

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

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

Для читателей, работающих с локациями в России, США и Великобритании, это означает конкретный практический выбор: если прод стоит в одной юрисдикции, offsite-копию разумно держать в другой — не только ради физического разнесения, но и ради независимости от локальных рисков конкретного региона (перебои у оператора связи, региональные ограничения, локальные форс-мажоры).

Из чего складывается цена терабайта offsite-хранения

Когда данные покидают периметр основной площадки, в стоимость терабайта добавляется несколько статей, которых нет у локального бэкапа:

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

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

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

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

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

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

Сколько переплаты даёт offsite по сравнению с локальным бэкапом

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

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

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

Как посчитать, оправдана ли переплата именно у вас

Простое сравнение "дороже или дешевле" здесь не работает — нужно сравнивать не среднюю стоимость, а стоимость наихудшего сценария. Вот рабочая последовательность:

1. Оцените, что происходит при полной потере данных без offsite-копии. Не "сколько стоит день простоя", а "что будет, если оригинал и локальный бэкап погибнут одновременно и восстанавливать нечего". Для многих проектов это не просто финансовые потери, а конец бизнеса или необратимая потеря доверия клиентов.
2. Отделите данные, которым это действительно нужно, от тех, что легко пересоздать. Не всё в вашей инфраструктуре требует offsite-защиты. Кэши, легко перегенерируемые артефакты сборки, временные файлы — можно потерять и пересоздать за часы. А вот база с данными клиентов, финансовые записи, уникальный контент — это ровно то, что должно иметь копию за пределами площадки.
3. Посчитайте дельту стоимости между текущей схемой (только локальный бэкап) и схемой с offsite-плечом именно для этого выделенного объёма данных — не для всей инфраструктуры целиком. Часто оказывается, что offsite нужен не для терабайтов логов, а для сотен гигабайт действительно критичных данных, и переплата за них куда скромнее, чем кажется на первый взгляд.
4. Сравните дельту с ценой худшего сценария. Если годовая переплата за offsite — это условно стоимость нескольких часов работы вашей команды, а цена полной потери данных — это репутация, клиенты и, возможно, само существование проекта, сравнение обычно решается не в пользу экономии.

Здесь стоит прямо сказать: с точки зрения простой математики ожидаемых потерь (вероятность события × ущерб) offsite-хранение часто выглядит невыгодным — вероятность катастрофы одной площадки действительно мала, и "средняя" ожидаемая потеря за счёт этого получается небольшой. Но полная потеря данных — это не "средний" исход, а разовое необратимое событие, которое голая математика ожидания склонна недооценивать. Offsite-хранение в этом смысле — не инвестиция с положительной ожидаемой доходностью, а страховка: вы платите регулярно небольшую сумму именно для того, чтобы исключить редкий, но разрушительный исход, а не для того, чтобы "выиграть" в среднем.

Практическая схема: 3-2-1 с offsite-плечом на VPS

Один из самых простых и предсказуемых по цене вариантов — держать локальный бэкап как обычно, а затем регулярно отправлять зашифрованный архив на отдельный VPS в другом регионе. Ниже — рабочая схема на связке restic и SFTP, без привязки к конкретному провайдеру.

На удалённом сервере (в другом дата-центре) достаточно пользователя с SSH-доступом и места под архивы:

# на удалённой площадке — создаём пользователя под приём бэкапов
sudo useradd -m -s /usr/sbin/nologin backup-offsite
sudo mkdir -p /home/backup-offsite/repo
sudo chown backup-offsite:backup-offsite /home/backup-offsite/repo

На стороне прод-сервера инициализируем репозиторий restic поверх SFTP и настраиваем ключ шифрования отдельно от ключей доступа к самому серверу:

# генерируем и сохраняем пароль репозитория ОТДЕЛЬНО от сервера
export RESTIC_PASSWORD="$(openssl rand -base64 32)"
echo "$RESTIC_PASSWORD" > /root/.restic-offsite-key   # храните копию вне сервера

restic -r sftp:backup-offsite@remote-host:/home/backup-offsite/repo init

Регулярный запуск бэкапа на offsite-площадку с ротацией версий:

#!/bin/bash
export RESTIC_PASSWORD="$(cat /root/.restic-offsite-key)"
REPO="sftp:backup-offsite@remote-host:/home/backup-offsite/repo"

restic -r "$REPO" backup /var/lib/postgresql/backups /var/www/uploads
restic -r "$REPO" forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

Ключевые нюансы, которые легко упустить на этапе настройки:

• Ключ шифрования не должен лежать только на проде. Если сгорит прод-сервер вместе с ключом, зашифрованный архив на удалённой площадке станет бесполезным набором байт. Копию ключа держите отдельно — в менеджере паролей, у второго администратора, в третьем месте.
• Ограничьте пользователя на удалённой стороне. SFTP-доступ для приёма бэкапов не должен давать shell-доступ к серверу — иначе компрометация прод-сервера автоматически даёт злоумышленнику доступ и к резервной площадке.
• Проверяйте восстановление, а не только запись. Успешный restic backup без ошибок не гарантирует, что restic restore через полгода отработает так же гладко. Периодическая тестовая распаковка архива с удалённой площадки — обязательная часть схемы, а не опция для энтузиастов.
• Мониторьте именно факт доставки на offsite-плечо, а не только факт локального бэкапа. Локальный бэкап может отрабатывать штатно неделями, пока внешний rsync или restic-задание молча падает по сетевой ошибке, и вы узнаете об этом только когда понадобится восстановление.

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

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