Backup-стратегии для Linux-сервера: правило 3-2-1 на практике

Коротко: правило 3-2-1 — это три копии данных, на двух разных носителях или системах, одна из них — за пределами площадки. На Linux-сервере это собирается за вечер: дамп базы плюс restic или borg, который каждую ночь отправляет зашифрованные инкрементальные снимки на отдельную машину и в объектное хранилище. Хотя бы одна копия должна быть недоступна для удаления с самого сервера, а восстановление нужно проверять по расписанию, а не «когда случится».

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

Ниже — рабочая схема для типичного сервера с веб-приложением и базой данных: от выбора RPO и RTO до готовых команд и systemd-юнитов. Примеры проверены на Debian 12 и Ubuntu 24.04, restic 0.17 и PostgreSQL 16.

Что такое правило 3-2-1 и откуда оно взялось?

Правило сформулировал фотограф Питер Крог в середине 2000-х для архивов цифровых снимков, а потом его подхватила вся индустрия хранения данных. Смысл в том, чтобы ни одно событие не могло уничтожить все копии сразу.

• 3 копии. Рабочие данные на сервере считаются первой копией. Нужны ещё минимум две резервные.
• 2 разных носителя или системы. Копия в соседнем каталоге на том же диске не считается: она умрёт вместе с диском. Вторая система — отдельный сервер бэкапов, NAS, объектное хранилище.
• 1 копия вне площадки. Другой дата-центр, другой провайдер, другой аккаунт. Это защита от пожара, отключения ДЦ, блокировки аккаунта у хостера и взлома, который затронул всю площадку.

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

Почему RAID и снапшоты — это не бэкап?

Самая частая ошибка на маленьких проектах — считать резервной копией то, что ей не является.

• RAID 1/5/10 защищает от отказа диска. rm -rf, кривая миграция, повреждение файловой системы и шифровальщик моментально записываются на все диски массива.
• Снапшоты LVM, ZFS, Btrfs хороши для быстрого отката после неудачного обновления, но лежат на том же пуле. Умер пул — умерли и снапшоты.
• Снапшоты диска у облачного провайдера ближе к бэкапу, но живут в том же аккаунте. Злоумышленник с доступом к панели или API-токеном удалит их вместе с сервером.
• Синхронизация (rsync без истории, облачные «папки») честно копирует и удаление файла, и его зашифрованную версию.

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

Как определить RPO и RTO для своего сервера?

Прежде чем выбирать инструменты, ответьте на два вопроса. От них зависят частота копирования и то, куда класть копии.

• RPO (Recovery Point Objective) — сколько данных можно потерять. Если бэкап раз в сутки в 03:00, а сервер умер в 23:00, теряется почти сутки заказов, комментариев и загрузок.
• RTO (Recovery Time Objective) — за сколько нужно вернуться в строй. Скачать 200 ГБ из холодного хранилища и развернуть их на новом сервере — это часы, а не минуты.

Цифры стоит записать в документ проекта и согласовать с владельцем бизнеса. «Как можно чаще» — не ответ: каждый шаг вниз по RPO стоит денег и сложности.

Что именно копировать на Linux-сервере?

Образ всего диска удобен, но тяжёл, а восстановить из него один файл неудобно. Для сервера приложений практичнее копировать данные и конфигурацию, а систему ставить заново из пакетов или Ansible.

1. Базы данных — дампом или штатным инструментом физического копирования, а не копированием файлов из /var/lib/postgresql на ходу.
2. Пользовательские файлы — /var/www/*/storage, uploads, media и т. п.
3. Конфигурация — /etc целиком (он небольшой), включая nginx, systemd-юниты, sudoers, сертификаты из /etc/letsencrypt.
4. Секреты приложения — .env и ключи, но только в зашифрованный репозиторий.
5. Задания cron — /var/spool/cron/crontabs, а также /root и /home, если там живут скрипты.
6. Список пакетов — dpkg --get-selections > /var/backups/pkg.list, чтобы быстро повторить окружение.

Исключайте то, что пересоздаётся само: кэши, node_modules, /var/cache, /tmp, логи старше пары недель. Это экономит место и время восстановления.

Какие бывают типы резервного копирования?

• Полное — каждый раз копируется всё. Просто восстанавливать, но долго и дорого по месту.
• Инкрементальное — только изменения с прошлой копии. Быстро и компактно; при классической схеме для восстановления нужна вся цепочка.
• Дифференциальное — изменения с последней полной. Компромисс между двумя предыдущими.
• Дедуплицированные снимки — подход restic, borg и kopia. Каждый снимок выглядит как полный и восстанавливается независимо, но физически хранятся только новые блоки. Именно поэтому для сервера сегодня почти всегда берут один из этих инструментов, а не самописный tar с ротацией.

restic или borg: чем делать бэкап?

Для нового сервера проще restic: один инструмент закрывает и локальную, и облачную копию. Если у вас уже есть сервер бэкапов с borg — оставайтесь на нём, принципы ниже те же.

Как собрать схему 3-2-1 на restic: пошагово

Схема: копия 1 — рабочие данные; копия 2 — restic-репозиторий на отдельном сервере бэкапов в той же сети (быстрое восстановление); копия 3 — restic-репозиторий в S3-совместимом хранилище у другого провайдера (вне площадки).

Шаг 1. Дамп базы перед копированием

install -d -m 700 /var/backups/db
sudo -u postgres pg_dump -Fc -d app -f /var/backups/db/app.dump
# MySQL / MariaDB:
mysqldump --single-transaction --routines --triggers app | zstd -q > /var/backups/db/app.sql.zst

Формат -Fc у pg_dump сжат и позволяет восстанавливать отдельные таблицы через pg_restore. Имя файла без даты специально: историю хранит restic, а локально нужен только последний дамп.

Шаг 2. Пароль и переменные

install -m 600 /dev/null /root/.restic-pass
openssl rand -base64 32 > /root/.restic-pass
cat > /root/.restic-env <<'EOF'
export RESTIC_PASSWORD_FILE=/root/.restic-pass
export AWS_ACCESS_KEY_ID=...
export AWS_SECRET_ACCESS_KEY=...
EOF
chmod 600 /root/.restic-env

Копию пароля сразу положите в менеджер паролей команды. Без него репозиторий не откроет никто, в том числе вы.

Шаг 3. Два репозитория

. /root/.restic-env
restic -r rest:https://backup.lan:8000/web01 init
restic -r s3:https://s3.example-provider.ru/web01-backup init

Шаг 4. Скрипт бэкапа

#!/bin/bash
# /usr/local/sbin/backup.sh
set -euo pipefail
. /root/.restic-env
sudo -u postgres pg_dump -Fc -d app -f /var/backups/db/app.dump
dpkg --get-selections > /var/backups/pkg.list
for REPO in rest:https://backup.lan:8000/web01 s3:https://s3.example-provider.ru/web01-backup; do
  restic -r "$REPO" backup /etc /var/www /var/backups /root \
    --exclude-caches --exclude '/var/www/*/node_modules' --tag nightly
done
curl -fsS -m 10 --retry 3 https://hc.example.ru/ping/web01-backup >/dev/null

Последняя строка — пинг в мониторинг вроде Healthchecks или Uptime Kuma. Если пинг не пришёл вовремя, вы узнаете, что бэкап не отработал, в тот же день, а не через полгода.

Шаг 5. Запуск по systemd-таймеру

# /etc/systemd/system/backup.service
[Unit]
Description=Nightly restic backup
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/backup.sh
Nice=10
IOSchedulingClass=idle

# /etc/systemd/system/backup.timer
[Unit]
Description=Run backup nightly

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

[Install]
WantedBy=timers.target

systemctl daemon-reload
systemctl enable --now backup.timer
systemctl list-timers backup.timer
journalctl -u backup.service -n 50

Persistent=true запустит пропущенный бэкап после перезагрузки, а IOSchedulingClass=idle не даст ему тормозить сайт. Почему таймер удобнее cron, мы разбирали в статье про systemd без боли.

Шаг 6. Ротация

restic -r "$REPO" forget --tag nightly \
  --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune

Запускайте ротацию отдельным таймером раз в неделю, а для append-only-репозитория — только с сервера бэкапов (об этом ниже).

Как защитить бэкапы от шифровальщика: 3-2-1-1-0

Современные шифровальщики и взломщики первым делом ищут бэкапы: если сервер умеет удалять свои копии, это умеет и тот, кто получил на нём root. Поэтому классическое правило расширили до 3-2-1-1-0: плюс одна неизменяемая или отключённая копия и ноль ошибок при проверке восстановления.

• rest-server в режиме append-only. Запуск rest-server --append-only --private-repos: клиент может добавлять снимки, но не удалять. Команду forget --prune выполняют на самом сервере бэкапов, куда у веб-сервера доступа нет.
• borg через ограниченный SSH-ключ. В authorized_keys сервера бэкапов: command="borg serve --append-only --restrict-to-path /srv/borg/web01",restrict ssh-ed25519 AAAA...
• S3 Object Lock. Объекты в бакете нельзя удалить или перезаписать до истечения срока хранения, даже владельцу ключа. Поддерживается у крупных облаков и у ряда российских S3-совместимых провайдеров — уточняйте в документации.
• Отдельные учётные данные. Ключ, которым сервер пишет в бакет, не должен уметь удалять бакет и менять политики. Root-доступ к серверу бэкапов — только у людей, не у других серверов.

Базовая гигиена самого сервера тоже часть защиты бэкапов: см. наш чеклист базовой защиты Linux-сервера.

Как проверять, что бэкап восстанавливается?

Бэкап, который ни разу не восстанавливали, — гипотеза. Ноль в 3-2-1-1-0 означает именно регулярную проверку.

1. Целостность репозитория раз в неделю: restic check --read-data-subset=5% — читает и сверяет случайные 5 % данных, за месяц проходит почти весь объём.
2. Выборочное восстановление файлов: restic restore latest --target /tmp/restore --include /etc/nginx и сравнение с рабочей копией через diff -r.
3. Восстановление базы раз в месяц на отдельном стенде: pg_restore -d app_check /tmp/restore/var/backups/db/app.dump, затем пара контрольных запросов — число заказов, дата последней записи.
4. Учебная авария раз в квартал: новый чистый сервер, только документация и пароль от репозитория. Засеките время — это и есть ваш фактический RTO.

Результаты проверок полезно выводить на тот же дашборд, что и метрики сервера — как его собрать, мы показывали в статье про Prometheus и Grafana. Для restic есть экспортёры, которые отдают возраст последнего снимка и размер репозитория.

Типичные ошибки при настройке бэкапов

• Копии лежат на том же сервере или в том же аккаунте провайдера.
• Файлы живой базы копируются rsync-ом — копия получается несогласованной и может не подняться.
• Пароль от репозитория есть только на сервере, который нужно восстанавливать.
• Нет мониторинга: скрипт молча падает с полгода, потому что кончилось место или сменился ключ доступа.
• Нет ротации: хранилище переполняется, и новые копии перестают записываться.
• Восстановление не описано: в момент аварии человек впервые читает документацию restic.

Если инфраструктура описана в Ansible или конвейере CI, добавьте в репозиторий и юниты бэкапа, и инструкцию по восстановлению — тогда новый сервер получит их автоматически. Как построить такой конвейер, мы разбирали в гиде по GitLab CI с нуля. Справочник команд — в официальной документации restic и документации BorgBackup.

Чеклист: бэкап Linux-сервера по правилу 3-2-1

1. Записаны RPO и RTO для базы, файлов и конфигурации.
2. База копируется дампом или штатным инструментом, а не файлами.
3. Есть копия на отдельной машине и копия у другого провайдера.
4. Репозитории зашифрованы, пароль хранится вне сервера.
5. Хотя бы одна копия append-only или immutable.
6. Бэкап запускается таймером и пингует мониторинг.
7. Настроена ротация снимков.
8. Еженедельный restic check, ежемесячное восстановление базы, ежеквартальная учебная авария.
9. Инструкция по восстановлению лежит рядом с кодом инфраструктуры.

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

RAID или снапшот — это уже резервная копия?

Нет. RAID защищает от отказа одного диска, но удаление файла, ошибочная миграция или шифровальщик мгновенно попадают на все диски массива. Снапшот LVM, ZFS или облачного диска живёт на той же системе хранения и в том же аккаунте. Это удобная первая ступень, но не замена копии на другой машине.

Что выбрать: restic или borg?

Оба инструмента делают дедуплицированные зашифрованные инкрементальные копии. Restic — один бинарник и прямая запись в S3, SFTP, rest-server и через rclone почти в любое облако. Borg обычно чуть быстрее и плотнее сжимает, но для удалённого хранения нужен borg на сервере по SSH. Для нового сервера проще начать с restic.

Как часто делать резервные копии сервера?

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

Можно ли копировать файлы базы данных через rsync?

На работающей базе нельзя: файлы меняются во время копирования, и копия получится несогласованной. Делайте логический дамп (pg_dump, mysqldump с --single-transaction), физическую копию штатным инструментом (pg_basebackup, mariabackup) или снапшот файловой системы с остановкой записи.

Что такое правило 3-2-1-1-0?

Это расширение классического 3-2-1: плюс одна копия, которую нельзя изменить или удалить (offline или immutable — append-only репозиторий, S3 Object Lock), и ноль ошибок при проверке восстановления. Расширение появилось из-за шифровальщиков, которые сначала ищут и уничтожают бэкапы.

Где хранить ключ шифрования бэкапа?

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

Сколько места займут резервные копии?

С дедупликацией меньше, чем кажется: после первой полной копии каждый следующий снимок добавляет только изменившиеся блоки. Для типичного веб-сервера с 20 ГБ данных и хранением 7 дневных, 4 недельных и 12 месячных снимков репозиторий обычно укладывается в 1,5–3 объёма исходных данных.

Вернуться в блог