Бэкапы в S3-хранилище: restic и rclone на практике

Бэкап в S3-хранилище — самый практичный способ выполнить главное правило резервного копирования: копия должна жить вне сервера. Снапшоты у хостера не спасут от удаления аккаунта, а архив в соседнем каталоге — от rm -rf или шифровальщика. В этой статье настроим связку restic + rclone на Ubuntu 24.04: restic будет делать зашифрованные дедуплицированные бэкапы в S3-совместимое хранилище, rclone — зеркалировать их во вторую локацию, а cron — запускать всё это по расписанию. Настройка restic занимает полчаса, а в конце вы получите схему, которая соответствует правилу 3-2-1 и восстанавливает сервер на любую дату.

Правило 3-2-1 и место S3 в нём

Классическая формула надёжного резервного копирования:

• 3 копии данных — рабочая плюс два бэкапа;
• 2 разных типа носителей или систем хранения;
• 1 копия обязательно вне площадки, где живут данные.

S3-совместимое объектное хранилище закрывает пункт «вне площадки» идеально: оно дешёвое (десятки рублей за гигабайт в год), доступно по HTTPS из любой точки и не зависит от вашего хостера. Протокол S3 сегодня поддерживают почти все: Yandex Object Storage, VK Cloud, Selectel, Backblaze B2, Cloudflare R2, MinIO на собственном сервере. Всё, что описано ниже, работает с любым из них — меняется только endpoint и ключи.

Наша целевая схема для VPS:

Про общую стратегию и выбор того, что вообще включать в бэкап, мы писали в статье о резервном копировании VPS по схеме 3-2-1 — здесь сосредоточимся на инструментах.

Установка restic и подготовка доступа к S3

Restic есть в репозиториях Ubuntu 24.04:

sudo apt update
sudo apt install -y restic
restic version

У провайдера объектного хранилища создайте бакет (например, my-backups) и сервисные ключи — access key и secret key. Restic читает настройки из переменных окружения. Сложим их в отдельный файл, чтобы не светить секреты в истории команд:

sudo nano /root/.restic-env

Содержимое (endpoint и регион подставьте своего провайдера):

export AWS_ACCESS_KEY_ID="ВАШ_ACCESS_KEY"
export AWS_SECRET_ACCESS_KEY="ВАШ_SECRET_KEY"
export RESTIC_REPOSITORY="s3:https://storage.yandexcloud.net/my-backups/vps1"
export RESTIC_PASSWORD="длинная-случайная-фраза-шифрования"

Ограничьте права и подключите файл в текущую сессию:

sudo chmod 600 /root/.restic-env
source /root/.restic-env

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

restic init: создаём репозиторий и первый бэкап

Инициализация выполняется один раз:

restic init
# created restic repository 3f1a2b... at s3:https://storage.yandexcloud.net/my-backups/vps1

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

# Свежий дамп базы перед бэкапом
mysqldump --single-transaction --routines -u root -p mydb > /var/backups/mydb.sql

restic backup /var/www /etc /var/backups \
  --exclude "/var/www/**/cache" \
  --exclude "*.log"

Restic шифрует данные ещё на сервере и режет их на блоки: в хранилище улетают только блоки, которых там ещё нет. Поэтому первый бэкап идёт долго (весь объём), а все последующие — минуты, даже при ежедневном запуске. Посмотреть накопленные снапшоты:

restic snapshots
# ID        Time                 Host    Paths
# 8f04c123  2026-07-17 03:00:01  vps1    /var/www, /etc, /var/backups

Полезно периодически проверять целостность репозитория:

restic check

restic restore: восстановление — то, ради чего всё затевалось

Бэкап, который ни разу не восстанавливали, — это лотерейный билет, а не бэкап. Проверьте восстановление сразу после настройки. Вся последняя копия целиком:

restic restore latest --target /tmp/restore-test

Только один каталог или файл — флаг --include:

restic restore latest --target /tmp/restore-test --include /var/www/example.com

Восстановление на конкретную дату — по ID снапшота из restic snapshots:

restic restore 8f04c123 --target /tmp/restore-2026-07-17

А для «достать один файл, не выкачивая всё» удобен встроенный просмотр:

restic ls latest /etc/nginx/
restic dump latest /etc/nginx/nginx.conf > nginx.conf.restored

После теста сравните пару файлов с оригиналами (diff -r) и удалите временный каталог. Такой тест стоит повторять раз в квартал. Кстати, проверенный бэкап — это ещё и готовый механизм переезда: восстановить репозиторий можно на совершенно новый сервер, что сильно упрощает миграцию на другой VPS.

Ротация: restic forget и prune

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

restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

Эта политика оставляет 7 дневных, 4 недельных и 6 месячных копий, а --prune физически удаляет из хранилища блоки, на которые больше не ссылается ни один снапшот. Благодаря дедупликации суммарный объём такого набора обычно лишь в 1,3–1,7 раза больше объёма самих данных.

rclone: вторая копия и произвольные хранилища

Restic закрыл вторую копию правила 3-2-1, rclone сделает третью. Rclone — это «швейцарский нож» для облачных хранилищ: копирует и синхронизирует данные между 70+ провайдерами. Установка и настройка:

sudo apt install -y rclone
rclone config

Мастер спросит тип хранилища (выбирайте s3), провайдера, ключи и endpoint — в итоге появится именованный remote, например backup2. Проверка и зеркалирование репозитория restic во второе хранилище:

rclone lsd backup2:
rclone sync s3-primary:my-backups/vps1 backup2:my-backups-mirror/vps1 \
  --transfers 8 --checksum

Здесь sync делает точную копию (удалённое в источнике удаляется и в зеркале), --transfers 8 ускоряет перенос параллельными потоками. Репозиторий restic зашифрован, поэтому зеркалировать его можно куда угодно — хоть в бесплатный лимит другого облака. Второй сценарий использования rclone — прямое копирование больших статичных файлов (видео, архивы), которые не нуждаются в версионировании: rclone copy /var/media backup2:media.

Бюджетный вариант третьей копии — маленький сервер в другой локации. Подойдёт NAT VPS от Cheap-Host в Германии: тариф NAT Plus за 349 ₽/мес даёт 50 ГБ NVMe — достаточно под зеркало бэкапов небольшого проекта, а заодно копия оказывается в другой стране. Синхронизировать на него можно тем же rclone по SFTP-remote.

Автоматизация через cron

Соберём всё в один скрипт /root/backup-s3.sh:

#!/bin/bash
set -euo pipefail
source /root/.restic-env

# 1. Дамп базы
mysqldump --single-transaction --routines -u root mydb > /var/backups/mydb.sql

# 2. Бэкап в S3
restic backup /var/www /etc /var/backups --exclude "*.log" --quiet

# 3. Ротация
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune --quiet

# 4. Зеркало во второе хранилище
rclone sync s3-primary:my-backups/vps1 backup2:my-backups-mirror/vps1 --quiet

Права и задача в cron:

chmod 700 /root/backup-s3.sh
crontab -e
# Каждый день в 03:15
15 3 * * * /root/backup-s3.sh >> /var/log/backup-s3.log 2>&1

Раз в неделю просматривайте /var/log/backup-s3.log — «тихо сломавшийся» бэкап хуже его отсутствия, потому что создаёт ложное чувство безопасности. Если только осваиваете планировщик, синтаксис расписаний разобран в статье про cron и задачи по расписанию. И не забудьте, что бэкапы — лишь один пункт защиты сервера: остальные собраны в чек-листе безопасности VPS из 15 пунктов.

FAQ

Чем restic лучше простого архива tar в S3?

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

Что будет, если забыть пароль RESTIC_PASSWORD?

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

Restic или rclone — что выбрать для бэкапов?

Это разные инструменты: restic — система резервного копирования с версиями, шифрованием и дедупликацией; rclone — синхронизатор файлов между хранилищами. Оптимально использовать оба: restic пишет бэкапы в S3, rclone зеркалирует репозиторий во второе хранилище.

Как часто запускать бэкап в S3?

Для типового сайта — раз в сутки ночью через cron. Благодаря дедупликации restic ежедневный запуск дешёв. Для активных баз данных дамп можно снимать чаще — каждые 4–6 часов, restic заберёт только изменённые блоки.

Сколько места в S3 займут бэкапы?

Первый снапшот равен объёму данных за вычетом сжатия, дальше добавляются только изменения. Сайт на 20 ГБ с политикой 7 дневных, 4 недельных и 6 месячных копий обычно занимает 25–35 ГБ. Точную цифру покажет restic stats.

Вывод

Связка restic + rclone + cron закрывает резервное копирование VPS полностью: зашифрованные версионируемые бэкапы в S3, автоматическая ротация, зеркало во второй локации — и всё это бесплатным open-source-инструментарием за один вечер настройки. Главное — сохранить пароль репозитория в надёжном месте и хотя бы раз в квартал прогонять тестовое восстановление.

Если вы ещё выбираете сервер, на котором всё это будет крутиться, — у Cheap-Host тариф Pro от 750 ₽/мес: 12 vCPU, 16 ГБ RAM, 128 ГБ NVMe, KVM и безлимитный трафик, так что ночные выгрузки в S3 не упрутся ни в диск, ни в канал. Сервер выдаётся за минуту — тарифы на cheap-host.onl.