Правило 3-2-1 для бэкапов: как выполнить его дёшево

MAATRIX

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

Что означает правило 3-2-1 на практике

Формулировка правила простая: минимум 3 копии данных, на 2 разных типах носителей, 1 копия физически в другом месте. Но за этой мнемоникой стоит один инженерный принцип — копии должны погибать по разным, независимым причинам. Если оригинал и «резервная» копия лежат на одном диске одного сервера, они умрут вместе при отказе диска, взломе с правами root или простой ошибке rm -rf не в той папке. Это не бэкап, а второй файл рядом с первым — подробный разбор именно этой ошибки и её последствий есть в статье антипаттерн: бэкап лежит на том же сервере.

Отсюда и три требования правила:

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

Дальше — как закрыть каждый пункт, не покупая избыточную инфраструктуру.

Три копии без покупки трёх серверов

Самая частая ошибка при планировании бюджета — читать «3 копии» как «3 сервера». На практике для типового проекта (сайт, база данных, набор файлов) схема выглядит так:

1. Копия 1 — оригинал. Рабочие данные на продакшн-сервере: база, файлы приложения, конфигурация. Это не бэкап, это то, что вы защищаете.
2. Копия 2 — локальный бэкап на том же сервере, но на отдельном диске или разделе. Дешёвый дополнительный диск (или отдельный раздел на существующем NVMe/SSD) для копии, которая нужна не ради катастроф, а ради бытовых ситуаций: уронили таблицу неудачной миграцией, откатили неудачный деплой, случайно стёрли директорию с загрузками. Восстановление с локального диска занимает секунды-минуты, потому что не нужно качать гигабайты по сети. Именно на этом пункте чаще всего экономят зря в обратную сторону — то есть считают, что раз копия 2 «недостаточно надёжна» сама по себе, то её вообще не нужно делать. Нужно: она просто не закрывает весь пункт 1 в одиночку, а закрывает свою узкую, но частую задачу быстрого отката.
3. Копия 3 — удалённая копия вне сервера. Вот здесь и происходит основная экономия бюджета: вместо аренды второго полноценного сервера с CPU, RAM и панелью управления ради одной задачи хранения архивов, для копии 3 достаточно объектного хранилища, оплата в котором обычно привязана к занятому объёму, а не к вычислительным ресурсам, которые вам для хранения архива не нужны.

Практическая команда для копии 2 — обычный локальный архив с уходом на отдельный раздел:

#!/bin/bash
# /usr/local/bin/backup-local.sh — копия 2, отдельный диск/раздел
pg_dump -Fc mydb | gzip > /mnt/backup-disk/db_$(date +%F).sql.gz
tar czf /mnt/backup-disk/site_$(date +%F).tar.gz /var/www/site
find /mnt/backup-disk -mtime +7 -delete

/mnt/backup-disk — это смонтированный отдельный диск или раздел, не тот же раздел, где живут /var/www и данные СУБД: если это будет один и тот же раздел, при его заполнении под удар попадёт и продакшн, и архив одновременно.

Два типа носителей — что это значит сегодня

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

Практический эквивалент в 2026 году — логическое, а не физическое разделение типов хранения:

• Локальный блочный диск сервера (SSD/NVMe, смонтированный раздел) — первый тип: быстрый, но зависит от одного сервера, одного контроллера, одного провайдера.
• Объектное хранилище (S3-совместимое, доступ по HTTP API с ключами доступа) — второй тип: другая модель доступа, другой протокол, часто другой провайдер и другой физический дата-центр. У него другие сценарии отказа — например, скомпрометированный SSH-ключ на сервере не даёт автоматически доступа к бакету с отдельными учётными данными.

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

Одна копия в другом месте — дёшево через объектное хранилище

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

Отправка архива в объектное хранилище через rclone:

# однократная настройка удалённого хранилища
rclone config

# отправка свежего архива после его создания
rclone copy /mnt/backup-disk/db_2026-08-30.sql.gz remote-s3:my-backups-bucket/db/

Тот же результат через aws-cli, если хранилище отдаёт стандартный S3 API:

aws s3 cp /mnt/backup-disk/db_2026-08-30.sql.gz s3://my-backups-bucket/db/

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

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

Экономия на объёме: сжатие и инкрементальные бэкапы

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

Сжатие перед отправкой. Текстовые дампы баз данных и большинство файлов сайтов сжимаются в разы без потери данных:

pg_dump -Fc mydb > db_2026-08-30.sql.gz    # -Fc уже включает сжатие custom-формата
# либо явное сжатие поверх обычного дампа
pg_dump mydb | gzip -9 > db_2026-08-30.sql.gz
# для файлов сайта
tar cf - /var/www/site | zstd -19 -o site_2026-08-30.tar.zst

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

Инкрементальные бэкапы вместо полных копий каждый раз. Классический tar или pg_dump каждый день создаёт полный архив с нуля — это самый простой, но и самый затратный по объёму способ. Инструменты с поддержкой инкрементальности и дедупликации (restic, borgbackup, kopia) хранят только изменившиеся блоки данных между снапшотами, а не пересохраняют то, что не поменялось:

# инициализация репозитория restic в объектном хранилище
restic -r s3:https://s3.example-provider.com/my-backups-bucket init

# ежедневный инкрементальный снапшот — сохранятся только изменившиеся блоки
restic -r s3:https://s3.example-provider.com/my-backups-bucket backup /var/www /etc

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

Ротация: политика хранения версий, чтобы не платить за лишнее

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

Практичная схема ротации для небольшого проекта — не «все версии навсегда» и не «только последняя», а компромисс по глубине истории:

Для restic такая политика задаётся одной командой и запускается регулярно после создания нового снапшота:

restic -r s3:https://s3.example-provider.com/my-backups-bucket forget \
  --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

Флаг --prune не просто помечает старые снапшоты как удалённые, а физически освобождает место в репозитории — без него удалённые метаданные снапшотов остаются, а реальный занятый объём в хранилище не уменьшается. Для локальной копии 2 на отдельном диске подойдёт простая очистка по возрасту файлов, как в примере из раздела про три копии (find /mnt/backup-disk -mtime +7 -delete) — там глубина истории может быть короче, потому что это копия для быстрого отката, а не для долгосрочного архива.

Итог: пример недорогой полной схемы 3-2-1

Собранная воедино схема для небольшого проекта (сайт плюс база данных) выглядит так: оригинал на продакшн-сервере — копия 2 в виде сжатого ежедневного архива на отдельном разделе того же сервера с хранением последней недели — копия 3 в виде инкрементальных снапшотов restic, отправляемых в S3-совместимое объектное хранилище другого провайдера, с ротацией --keep-daily 7 --keep-weekly 4 --keep-monthly 6. Всё это запускается одним cron-заданием раз в сутки, а раз в квартал — тестовое восстановление из удалённой копии, чтобы схема была не просто «работающей по логам», а проверенной на практике. Ни один из трёх пунктов правила здесь не потребовал аренды второго полноценного сервера ради одних только бэкапов — только дисковое пространство и дисциплина в сжатии, инкрементальности и ротации.

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