Стратегия 3-2-1 звучит просто: три копии данных, два разных типа носителя, одна копия вне площадки. Сложность всегда в деталях — кто хранит пароль, что происходит при росте репозитория и когда вы последний раз реально восстанавливали файлы. Рассмотрим реализацию на restic: локальный репозиторий на внешнем диске, зеркало по SFTP на отдельную машину, политика хранения, автоматизация и проверка восстановления.

Подготовка: два репозитория и пароль

restic шифрует репозиторий целиком, поэтому без пароля копия физически нечитаема. Храните пароль отдельно от репозиториев, в файле с правами на чтение только владельцем.

sudo mkdir -p /srv/restic /etc/restic
printf '%s' 'очень-длинный-сложно-угадываемый-пароль' | sudo tee /etc/restic/password >/dev/null
sudo chmod 600 /etc/restic/password
export RESTIC_PASSWORD_FILE=/etc/restic/password

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

restic -r /srv/restic init
restic -r sftp:backup@nas.example:/restic init

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

Первый бэкап и структура репозитория

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

restic -r /srv/restic backup /etc /home /srv/www \
    --exclude-file=/etc/restic/exclude.txt --tag nightly
restic -r /srv/restic snapshots

Список исключений держите в /etc/restic/exclude.txt: кэши, каталоги .git, временные файлы и виртуальные машины. Без них первый бэкап растянется на часы, а раздутый репозиторий придётся долго чистить. После запуска snapshots покажет снимки с датами, хостами и размерами — это ваша точка входа при восстановлении.

Политика хранения: forget и prune

Репозиторий растёт бесконечно, пока вы не зададите политику. Команда forget оставляет снимки по правилам, а prune действительно освобождает место.

restic -r /srv/restic forget \
    --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --keep-yearly 1 --prune
restic -r /srv/restic forget --keep-daily 7 --dry-run

forget удаляет только записи о снимках, prune переписывает индексы и освобождает пакеты — запускайте его после серии forget, а не в цикле. Перед первым реальным применением политики всегда делайте dry-run и смотрите, какие снимки собираются исчезнуть.

Минимальный набор данных

Перед первым запуском составьте список осознанно, а не по принципу «захватить всё подряд». Для веб-сервера это обычно конфигурации из /etc, скрипты и данные приложения, дампы базы данных через pg_dump или mariadb-dump с сохранением в отдельный каталог, сертификаты Let’s Encrypt и пользовательские домашние директории. Дампы кладите в каталог, который попадает в бэкап, и проверяйте размер файла сразу после создания: пустой дамп — частый признак сломанного скрипта, который обнаруживается только при восстановлении. Образы виртуальных машин держите в отдельном репозитории с другой политикой хранения, иначе они быстро раздуют основной.

Автоматизация через systemd-таймер

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

EnvironmentFile=/etc/restic/env
ExecStart=/usr/bin/restic backup /etc /home /srv/www --tag nightly

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

Файл /etc/restic/env содержит RESTIC_REPOSITORY=/srv/restic, RESTIC_PASSWORD_FILE и RESTIC_CACHE_DIR=/var/cache/restic, причем каталог кэша обязателен: без него каждый прогон заново читает индексы по сети. После daemon-reload включайте таймер и проверяйте результат через journalctl -u restic-backup.

Код возврата каждого прогона остаётся в журнале, поэтому раз в неделю листайте journalctl -u restic-backup -p err или добавьте в скрипт вызов restic stats, чтобы заметить рост репозитория раньше, чем он забьёт диск. Для уведомлений достаточно обернуть ExecStart в небольшой скрипт: при ненулевом коде он отправляет письмо или вызывает вебхук. В отличие от cron здесь вы гарантированно получаете и уведомление, и структурированную запись в журнале.

Вторая копия: restic copy

Данные уже лежат в локальном репозитории, читать исходные файлы заново не нужно — достаточно скопировать снимки во второй репозиторий.

restic -r sftp:backup@nas:/restic init --from-repo /srv/restic --copy-chunker-params
restic -r sftp:backup@nas:/restic copy --from-repo /srv/restic --verbose

Флаг —copy-chunker-params при инициализации критически важен: он делает нарезку файлов в обоих репозиториях совместимой, иначе дедупликация между ними не заработает. Параметр —from-repo указывает источник, -r — назначение. Повторный запуск переносит только новые снимки, уже скопированные пропускаются. Помните: копирование шифрует и расшифровывает данные заново, поэтому на медленном канале лучше планировать его отдельным таймером.

Проверка: check и восстановление

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

restic -r /srv/restic check
restic -r /srv/restic check --read-data-subset=1/5
restic -r /srv/restic restore latest --target /tmp/restore-test

check без флагов сверяет индексы и деревья; —read-data-subset=1/5 читает пятую часть пакетов, и за пять запусков вы полностью прочитаете репозиторий. Планируйте такой прогон раз в месяц отдельным таймером. Восстановление в /tmp/restore-test раз в квартал обязательное упражнение: распакуйте контрольный конфиг, часть базы и пару фотографий, сверьте хэши. Именно в этот момент вы узнаете про неописанный в документации шаг восстановления.

Ключи и пароль

Пароль от репозитория не восстанавливается: без него данные нечитаемы физически. Храните копию пароля в менеджере паролей и в запечатанном конверте. Резервные ключи restic позволяют ротировать пароль без перезаписи репозитория.

  • менеджер паролей с доступом по второму фактору — основное место хранения;
  • запечатанный конверт у доверенного человека — офлайн-копия, доступная даже при компрометации аккаунтов;
  • второй ключ restic на другом устройстве — право ротировать пароль без переписывания репозитория;
  • короткая инструкция восстановления в том же конверте, чтобы справился не только вы.
restic -r /srv/restic key list
restic -r /srv/restic key add --new-password-file /etc/restic/password2
restic -r /srv/restic key remove 1a2b3c4d

Итог

Стратегия 3-2-1 на restic сводится к четырём операциям: локальный репозиторий на отдельном носителе, зеркало по SFTP с совместимыми параметрами нарезки, политика forget с prune и регулярный check с пробным восстановлением. Шифрование и дедупликация включены из коробки, а systemd-таймер с EnvironmentFile делает весь цикл незаметным. Настоящая защита появляется только когда вы один раз восстановили файлы по расписанию проверки, а не когда бэкап «вроде бы проходит».

Насколько публикация полезна?

Нажмите на звезду, чтобы оценить!

Средняя оценка 0 / 5. Количество оценок: 0

Оценок пока нет. Поставьте оценку первым.

Поделиться: Telegram ВКонтакте