Антипаттерн: все бэкапы у одного провайдера

MAATRIX

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

Как выглядит "бэкапы есть" в большинстве проектов

Типичная схема, которую можно увидеть в 9 проектах из 10, где хоть кто-то думал о резервном копировании:

• VPS с продакшеном арендован у провайдера А;
• в панели того же провайдера включены еженедельные снапшоты диска;
• вдобавок настроен cron, который каждую ночь архивирует базу и заливает её в объектное S3-совместимое хранилище — тоже у провайдера А, в том же личном кабинете;
• вход в панель — один логин, один пароль, одна привязанная карта.

С точки зрения чек-листа «бэкапы настроены» всё в порядке: копия есть, она регулярная, её можно скачать через API. С точки зрения независимости — копия ничем не отличается от исходных данных: она наследует все риски, которые несёт сам аккаунт у этого провайдера. Разница между этой схемой и бэкапом на том же сервере количественная, а не качественная: там точка отказа — один диск, здесь — один аккаунт, но логика одна и та же. Копия, которая физически или административно привязана к оригиналу, защищает только от подмножества сценариев — от случайного rm -rf или отказа конкретного диска. От всего, что затрагивает аккаунт целиком, она не защищает никак.

Четыре сценария, где один провайдер теряет всё сразу

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

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

Уход провайдера с рынка или банкротство. Небольшие и средние хостинг-провайдеры закрываются, продают бизнес или сворачивают конкретное направление регулярно — это часть нормального цикла рынка, а не что-то экстраординарное. Обычно это сопровождается уведомлением за 30-60 дней, но если письмо ушло на устаревший email или потерялось в спаме, время на миграцию сгорает незаметно. Если бэкапы лежали там же — мигрировать оказывается нечего.

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

Тот же аккаунт, но другой сервис — это не диверсификация

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

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

Что значит "независимая инфраструктура" на практике

Независимость — это не расплывчатое пожелание, а конкретный набор развязок:

• Другая компания. Второй провайдер юридически и организационно не связан с первым — не филиал, не тот же холдинг, не реселлер той же инфраструктуры.
• Отдельные учётные данные. Отдельный email для регистрации (не алиас того же ящика — если скомпрометирован основной ящик, через восстановление пароля можно добраться и до второго аккаунта), отдельный пароль, отдельная 2FA — в идеале на другом устройстве или в другом приложении-аутентификаторе.
• Отдельный способ оплаты. Если карта заблокирована банком или произошёл спор по платежу у провайдера А, это не должно автоматически задевать провайдера Б.
• Разная физическая/юридическая локация — по возможности. Не обязательный пункт для небольшого проекта, но снижает риск одновременного попадания под один и тот же региональный сбой или регуляторное решение.
• Ограниченные права доступа. Учётная запись, которая пишет бэкапы на второй сервис, не должна иметь прав на удаление старых копий без дополнительного подтверждения — иначе скомпрометированный ключ с прода сможет не только читать, но и стереть архив на втором провайдере.

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

Рабочая схема: как перенести копии за периметр провайдера

На практике это не требует держать вторую полноценную инфраструктуру — достаточно недорогого объектного хранилища у независимого провайдера и инструмента синхронизации. Рабочий минимум на базе restic (шифрование и дедупликация из коробки) и второго провайдера как получателя:

# Установка restic на сервере с продакшеном
apt install restic

# Инициализация репозитория на стороне ВТОРОГО провайдера
# (S3-совместимое хранилище, отдельный аккаунт, отдельный ключ доступа)
export RESTIC_REPOSITORY="s3:https://s3.provider-b.example/backups-prod"
export RESTIC_PASSWORD_FILE="/etc/restic/passphrase"   # ключ шифрования — хранить ОТДЕЛЬНО от сервера
export AWS_ACCESS_KEY_ID="ключ-с-правами-только-на-запись-в-этот-бакет"
export AWS_SECRET_ACCESS_KEY="..."

restic init

Ежедневный бэкап и ротация в cron:

#!/bin/bash
# /usr/local/bin/backup-offsite.sh
set -euo pipefail

pg_dump -Fc mydb > /tmp/mydb.dump

restic backup /tmp/mydb.dump /etc/myapp --tag prod-daily

# Хранить: 7 ежедневных, 4 недельных, 6 месячных копий
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

rm -f /tmp/mydb.dump

0 3 * * * /usr/local/bin/backup-offsite.sh >> /var/log/backup-offsite.log 2>&1

Три детали, которые здесь важны и часто упускаются:

1. Ключ доступа с правами только на запись (или append-only), без права на удаление и перезапись существующих объектов, если хранилище это поддерживает (object lock / versioning). Тогда даже полная компрометация сервера-источника не даёт удалить уже записанные бэкапы — только дописать новые.
2. Passphrase шифрования restic не хранится на том же сервере, что и бэкап-скрипт — иначе при компрометации прода атакующий получает и зашифрованный архив, и ключ к нему в одном месте, что обнуляет смысл шифрования. Подробнее о том, как эта ошибка выглядит на практике, разобрано в статье про бэкап без ключа шифрования.
3. Регулярная проверка восстановления — restic restore latest --target /tmp/restore-test раз в месяц на отдельной тестовой машине. Бэкап, который никогда не разворачивали, с точки зрения надёжности эквивалентен отсутствию бэкапа: неработающий формат архива, забытый пароль или тихо сломавшийся cron обнаруживаются обычно только в момент, когда восстановление уже нужно позарез.

Эта схема — частный случай более общего правила 3-2-1: три копии данных, на двух разных носителях, одна из которых — за пределами основной площадки. «За пределами площадки» в 2026 году для большинства проектов означает не столько другой город, сколько другой провайдер, другой аккаунт и другой набор учётных данных.

Сколько это стоит и когда полная диверсификация — избыточность

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

Для небольшого личного проекта или тестового стенда избыточно держать полноценную вторую инфраструктуру — здесь оправдан risk-based подход: если восстановление за день из снапшота того же провайдера приемлемо, не стоит тратить время на настройку второго аккаунта. Порог, после которого диверсификация становится обязательной, — момент, когда простой или потеря данных стоят дороже, чем несколько часов на настройку restic + аккаунт у второго провайдера с минимальным тарифом под объектное хранилище (обычно это единицы долларов в месяц для баз в пределах десятков гигабайт).

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