Как настроить резервное копирование сервера по правилу 3-2-1

Это руководство показывает, как построить систему резервного копирования сервера, которая переживает реальные аварии: умерший диск, шифровальщик, удалённую базу данных, инцидент в дата-центре. Оно написано для тех, кто администрирует Linux VPS или выделенный сервер с типичным веб-стеком, и всё описанное ниже использует стандартные инструменты: rsync, cron, mysqldump, pg_dump. Цель не просто иметь копии, а уметь восстановиться из них в стрессовой ситуации.

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

Храните 3 копии данных на 2 разных системах, причём 1 копия находится в другой локации. Живые данные на сервере считаются первой копией. Вторая копия в соседнем каталоге на том же диске не является резервной: она умирает вместе с диском. Копия на отдельной машине защищает вас от отказа железа. Внешняя копия защищает от всего, что накрывает локацию целиком: пожара, затопления, взломанного аккаунта, шифровальщика, который шифрует всё, до чего сервер может дотянуться.

Практический минимум для одного сервера: живые данные, ночная копия на резервном хосте и зашифрованная копия в другой физической локации или у другого провайдера. Этого уже достаточно для 3-2-1 без какого-либо коммерческого софта.

Что копировать: данные, конфигурации и дампы, не обязательно весь диск

Полные образы диска для стандартного Linux-сервера редко оправданы. Операционная система переустанавливается за минуты, поэтому копируйте то, что действительно уникально:

• Данные приложений: /var/www, /home, каталоги загрузок.
• Конфигурация: /etc, включая веб-сервер, PHP, почту, задания cron, TLS-сертификаты и ключи.
• Дампы баз данных, созданные самой базой (следующий раздел).
• Собственные скрипты в /usr/local/bin или /opt и список пакетов.

Сохраните список пакетов, чтобы быстро воспроизвести то же окружение:

dpkg --get-selections > /var/backups/packages.txt

Частая ошибка: копировать /var/lib/mysql файл за файлом, пока база работает. Такая копия неконсистентна и после восстановления часто вообще не запускается. Базы данных копируют инструментами дампа, а не через cp.

rsync во вторую локацию по расписанию cron

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

#!/bin/sh
set -eu
DEST="backup@backup1.example.net:/backups/web01"

rsync -az --delete /etc/ "$DEST/etc/"
rsync -az --delete /var/www/ "$DEST/www/"
rsync -az /var/backups/db/ "$DEST/db/"

Флаг -a сохраняет права, владельцев и метки времени, -z сжимает при передаче, а --delete делает целевой каталог точным зеркалом. Учитывайте, что означает --delete: если файлы на сервере удалены или зашифрованы, следующий запуск отзеркалит и этот ущерб. Именно поэтому целевая сторона должна хранить собственную историю (см. раздел о сроках хранения ниже), а не одно единственное зеркало.

Запланируйте запуск через cron, после задания с дампом базы:

20 2 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1

Периодически проверяйте лог, а лучше настройте оповещение о ненулевом коде выхода. Задание резервного копирования, которое молча падает уже 3 месяца, частая находка при разборе инцидента.

Дампы баз данных: mysqldump и pg_dump

Для MySQL или MariaDB с таблицами InnoDB:

mysqldump --single-transaction --quick --routines --triggers \
  --all-databases | gzip > /var/backups/db/mysql-$(date +%F).sql.gz

--single-transaction создаёт консистентный дамп без блокировки таблиц, поэтому приложение продолжает работать, пока идёт дамп.

Для PostgreSQL можно снять всё сразу:

sudo -u postgres pg_dumpall --clean | gzip > /var/backups/db/pgsql-$(date +%F).sql.gz

или одну базу в формате custom, который позволяет выборочно восстанавливать отдельные таблицы:

sudo -u postgres pg_dump -Fc shopdb > /var/backups/db/shopdb-$(date +%F).dump

Запускайте дампы за 15-30 минут до задания rsync, чтобы каждая внешняя копия содержала свежий дамп.

Сроки хранения и шифрование внешних копий

Одной вчерашней копии недостаточно. Повреждение данных часто замечают через дни или недели, и тогда нужна копия из времени до повреждения. Разумное значение по умолчанию: хранить 7 дневных, 4 недельные и 6 месячных копий. На резервном хосте старые дампы удаляйте через find:

find /backups/web01/db -name "*.sql.gz" -mtime +14 -delete

Всё, что покидает железо под вашим контролем, должно быть зашифровано. Проще всего использовать age:

age -r age1examplepublickey0000000000 -o mysql-2026-07-21.sql.gz.age mysql-2026-07-21.sql.gz

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

Проверяйте восстановление раз в квартал, а снапшоты считайте бонусом

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

gunzip -t mysql-2026-07-21.sql.gz
gunzip -c mysql-2026-07-21.sql.gz | mysql

Снапшоты провайдера удобны для отката перед рискованным обновлением, но они не стратегия резервного копирования. Снапшот живёт на той же инфраструктуре, в той же локации и под тем же аккаунтом, что и сам сервер. Если аккаунт взломан, хранилище отказало или в дата-центре произошёл серьёзный инцидент, снапшот исчезает вместе с исходными данными. Снапшоты не выполняют ни условие "2 разные системы", ни условие "1 копия вне локации" из правила 3-2-1. Используйте их как дополнительный уровень удобства поверх настоящих резервных копий, но никогда вместо них.

Внешнюю копию организовать недорого. Небольшой VPS в другом дата-центре, чем ваш основной сервер, отлично подходит как цель для rsync с парой сотен гигабайт места. А если вы предпочитаете собственное резервное железо, разместите свою машину через колокейшен сервера в нашем дата-центре Tier 3+ в Риге и получите вторую локацию на независимой инфраструктуре. Какую бы цель вы ни выбрали, правила те же: 3 копии, 2 системы, 1 вне локации и учение по восстановлению каждый квартал.