Миф: облако само делает бэкапы

MAATRIX

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

Путаница: избыточность инфраструктуры vs резервное копирование

Избыточность (redundancy, репликация) — это инженерное решение самого провайдера. Ваш диск на самом деле не один физический диск, а логический том, данные которого синхронно или почти синхронно пишутся на несколько физических носителей, часто в разных стойках или зонах доступности. Цель — пережить отказ железа: сгорел контроллер, вышел из строя SSD, накрылась целая стойка — сервис продолжает работать, потому что есть актуальная копия рядом.

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

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

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

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

Shared responsibility model: за что отвечает провайдер, а за что вы

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

SLA (соглашение об уровне обслуживания) в облаке почти всегда описывает *доступность сервиса* — то есть процент времени, когда платформа отвечает и работает, — а не *сохранность конкретных данных, которые вы туда положили*. Обещание 99,9% времени работы ничего не говорит о том, что будет с вашей базой, если вы или ваш скрипт по ошибке выполнит DROP TABLE или rm -rf не на той директории.

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

Реальный случай: как «облако само бэкапит» уничтожило данные

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

Дальше — миграция или скрипт очистки, который должен был удалить тестовые записи, а по ошибке (неверное условие WHERE, не тот --dry-run, спутанное окружение prod/staging) удаляет продовую таблицу целиком. Операция выполняется мгновенно, репликация синхронизирует изменение на все копии за секунды — с точки зрения инфраструктуры всё работает штатно: диски целы, узел отвечает, реплики согласованы. Просто согласованы они теперь на пустой таблице.

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

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

Что провайдер обычно предлагает отдельно как платную услугу бэкапа

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

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

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

Как проверить, есть ли у вас реальный бэкап прямо сейчас

Прежде чем полагаться на «облако само разберётся», стоит потратить пять минут и честно ответить на несколько вопросов о каждом важном хранилище данных — диске, базе, бакете:

1. Есть ли отдельно включённая функция бэкапа/снапшотов, а не просто «диск реплицирован»? Проверьте в панели управления провайдера конкретно раздел Backups/Snapshots, а не раздел про надёжность инфраструктуры.
2. Хранятся ли копии отдельно от рабочего тома — на другом физическом ресурсе, а лучше в другом регионе? Если бэкап лежит на том же диске или в том же бакете, что и оригинал, он погибнет вместе с оригиналом при том же инциденте (удаление, шифровальщик, отказ региона).
3. Какая глубина истории — сколько точек восстановления хранится и с каким шагом? «Есть бэкап» и «есть бэкап месячной давности с шагом раз в неделю» — разные гарантии.
4. Бэкапится ли именно содержимое, а не только конфигурация ВМ? Образ сервера, снятый до того, как в базу что-то записали, не спасёт данные, появившиеся позже.
5. Кто-нибудь пробовал восстановиться из этого бэкапа целиком, в отдельное окружение, и сверял результат? Непроверенный бэкап — это гипотеза о бэкапе, а не бэкап.

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

Практическая схема резервного копирования, которая переживёт удаление

Рабочая схема для VPS или облачного ресурса строится на правиле 3-2-1: минимум три копии данных, на двух разных типах носителей, одна из которых физически или логически изолирована от рабочей среды. На практике для сервера это можно собрать из готовых инструментов без экзотики.

Для файлов и директорий на VPS — restic в связке с внешним S3-совместимым хранилищем (не тем же провайдером, что и рабочий диск):

# инициализация репозитория бэкапов на внешнем S3
export AWS_ACCESS_KEY_ID=xxx
export AWS_SECRET_ACCESS_KEY=xxx
restic -r s3:https://s3.example-provider.com/my-backup-bucket init

# резервная копия директории с данными
restic -r s3:https://s3.example-provider.com/my-backup-bucket \
  backup /var/lib/myapp/data --tag daily

# политика хранения: последние 7 дневных, 4 недельных, 6 месячных
restic -r s3:https://s3.example-provider.com/my-backup-bucket \
  forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

Для базы данных — логический дамп до архивации, а не просто копирование файлов диска на живой базе:

# PostgreSQL: консистентный дамп без блокировки на чтение
pg_dump -Fc mydb > /tmp/mydb-$(date +%F).dump

# MySQL/MariaDB: дамп с единой транзакцией для InnoDB
mysqldump --single-transaction --routines mydb > /tmp/mydb-$(date +%F).sql

# дальше — этот дамп тоже уезжает через restic во внешнее хранилище
restic -r s3:https://s3.example-provider.com/my-backup-bucket \
  backup /tmp/mydb-$(date +%F).dump

Автоматизация через systemd timer надёжнее голого cron тем, что логирует запуск в journalctl и не теряется молча при перезагрузке:

# /etc/systemd/system/backup-restic.service
[Unit]
Description=Restic backup job

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup-restic.sh

# /etc/systemd/system/backup-restic.timer
[Unit]
Description=Daily restic backup

[Timer]
OnCalendar=*-*-* 03:00:00
Persistent=true

[Install]
WantedBy=timers.target

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

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

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