Автоматические бэкапы: что настроить до первого запуска

За полчаса можно настроить ежедневное резервное копирование файлов Linux-сервера с помощью Restic 0.17.x и systemd. Но срок первого полного бэкапа зависит от объёма данных и скорости диска или сети. Главное — до запуска определить, что копировать и куда, а после настройки проверить не только создание снимка, но и восстановление файлов.

Что подготовить до настройки

Инструкция рассчитана на сервер под Linux, где работает systemd, и локальный диск для копий, уже подключённый и смонтированный в /mnt/backup. Restic должен быть установлен, а команда /usr/local/bin/restic version — показывать версию 0.17.x. Путь к исполняемому файлу может отличаться: подставьте свой, если Restic установлен в другом месте.

До начала проверьте три вещи:

• Место назначения. Убедитесь, что диск действительно смонтирован в /mnt/backup, а не просто существует папка на системном диске. Иначе копии могут заполнить раздел с операционной системой.
• Состав данных. Ниже в качестве примера копируются /etc и /var/www. Добавьте каталоги своего приложения. Базы данных нельзя считать защищёнными только потому, что копируется папка с файлами: для них нужен отдельный согласованный способ экспорта.
• Отдельное место для второй копии. Локальный диск помогает при поломке сервера, но не спасает, если потерян или повреждён сам диск с резервными данными. Для важных данных запланируйте ещё одну копию вне сервера — например, в другом хранилище.

Снимок — сохранённое состояние выбранных файлов на момент резервного копирования. Restic хранит снимки в репозитории; после удаления или поломки исходных файлов из него можно восстановить данные. Пароль репозитория нужен для доступа к копиям: если потерять его, восстановление может оказаться невозможным.

Создайте репозиторий и защитите пароль

Сначала создайте файл с паролем. Команды ниже выполняйте от имени root; они создадут случайную строку и закроют доступ к каталогу и файлу от других пользователей.

install -d -m 700 /root/.config/restic
umask 077
openssl rand -base64 32 > /root/.config/restic/password

Скопируйте пароль в надёжное место вне сервера, доступное только тем, кто отвечает за восстановление. Не кладите его в резервируемый каталог и не отправляйте в общий чат. Без пароля снимки бесполезны.

Создайте репозиторий на смонтированном диске:

export RESTIC_REPOSITORY=/mnt/backup/restic
export RESTIC_PASSWORD_FILE=/root/.config/restic/password
/usr/local/bin/restic init

Проверка: Restic сообщит, что репозиторий создан. Если команда не находит файл пароля или каталог, проверьте пути и права доступа. Если диск не смонтирован, остановитесь и сначала исправьте подключение.

Настройте скрипт и расписание

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

install -d -m 755 /etc/restic
cat > /etc/restic/excludes.txt <<'EOF'
/tmp
/var/cache
EOF
cat > /usr/local/sbin/backup-restic <<'EOF'
#!/bin/sh
set -eu

mountpoint -q /mnt/backup || {
    echo "Диск резервных копий не смонтирован в /mnt/backup" >&2
    exit 1
}

export RESTIC_REPOSITORY=/mnt/backup/restic
export RESTIC_PASSWORD_FILE=/root/.config/restic/password

/usr/local/bin/restic backup --tag automatic --exclude-file=/etc/restic/excludes.txt /etc /var/www
/usr/local/bin/restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
EOF
chmod 700 /usr/local/sbin/backup-restic

Список исключений — пример, а не универсальная рекомендация. Убедитесь, что в нём нет нужных вам данных. Перед запуском вручную выполните /usr/local/sbin/backup-restic. Первый запуск может занять заметное время. Проверка: Restic завершится без ошибки и покажет созданный снимок. Если скрипт сообщает, что диск не смонтирован, не убирайте проверку — разберитесь с точкой монтирования.

Теперь создайте службу systemd:

cat > /etc/systemd/system/restic-backup.service <<'EOF'
[Unit]
Description=Резервное копирование с Restic
RequiresMountsFor=/mnt/backup

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/backup-restic
EOF

cat > /etc/systemd/system/restic-backup.timer <<'EOF'
[Unit]
Description=Ежедневное резервное копирование с Restic

[Timer]
OnCalendar=*-*-* 02:30:00
RandomizedDelaySec=30m
Persistent=true

[Install]
WantedBy=timers.target
EOF

systemctl daemon-reload
systemctl enable --now restic-backup.timer
systemctl start restic-backup.service

Таймер запускает бэкап раз в день около 02:30, со случайной задержкой до 30 минут. Если сервер был выключен в назначенное время, параметр Persistent=true позволяет выполнить пропущенный запуск после включения. Проверка: команда systemctl status restic-backup.service показывает успешное завершение, а systemctl list-timers restic-backup.timer — следующий запуск.

Проверьте, что данные можно вернуть

Успешное завершение службы ещё не доказывает, что вы восстановите нужный файл. Посмотрите список снимков и восстановите тестовую копию в отдельную папку, не поверх рабочих данных:

export RESTIC_REPOSITORY=/mnt/backup/restic
export RESTIC_PASSWORD_FILE=/root/.config/restic/password
/usr/local/bin/restic snapshots
/usr/local/bin/restic restore latest --target /tmp/restic-restore-check

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

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

Где такая схема не сработает

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

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

Если служба завершилась с ошибкой, посмотрите журнал командой journalctl -u restic-backup.service. Частые причины: диск не смонтирован; неправильный путь к Restic или файлу пароля; кончилось место; один из исходных каталогов отсутствует. Исправьте причину и запустите службу вручную повторно. Не считайте задачу решённой, пока не появился новый снимок и не прошла проверка восстановления.

Что делать дальше

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