Бэкап и восстановление rclone

MAATRIX

Если бэкапы лежат на том же диске, что и рабочие данные, это не бэкапы, а иллюзия защиты — сгорит диск или отвалится сервер, и восстанавливать будет нечего. rclone решает эту задачу без лишней инфраструктуры: одна консольная утилита синхронизирует и копирует файлы в десятки облачных хранилищ (S3, Google Drive, Backblaze B2, Яндекс.Диск и другие), умеет шифровать данные на лету и работает по cron без графического интерфейса. Разберём, как настроить рабочую схему бэкапа с нуля и, что важнее, как из неё восстановиться, когда это действительно понадобится.

Установка и первая настройка

На большинстве дистрибутивов rclone ставится одной командой из официального скрипта — он сам определяет архитектуру и версию:

curl https://rclone.org/install.sh | sudo bash

Либо через пакетный менеджер, если хотите держаться репозитория дистрибутива (версия может быть старее):

# Debian/Ubuntu
sudo apt install rclone

# AlmaLinux/RHEL
sudo dnf install epel-release -y
sudo dnf install rclone -y

Проверьте версию — для продакшна лучше 1.65 и новее, там стабильнее работает шифрование и параллельная загрузка:

rclone version

Дальше нужен конфиг — интерактивный мастер rclone config задаёт вопросы по каждому хранилищу. Если сервер без GUI и без возможности открыть браузер для OAuth (актуально для Google Drive), настройте remote на локальной машине и перенесите файл rclone.conf на сервер:

# путь к конфигу по умолчанию
rclone config file
# обычно ~/.config/rclone/rclone.conf

Настройка remote для S3, Backblaze B2 и Google Drive

S3-совместимые хранилища (Backblaze B2 через S3 API, Selectel, Amazon S3) настраиваются практически одинаково. Можно пройти мастер rclone config, а можно сразу прописать секцию руками в ~/.config/rclone/rclone.conf:

[s3backup]
type = s3
provider = AWS
access_key_id = ВАШ_ACCESS_KEY
secret_access_key = ВАШ_SECRET_KEY
region = eu-central-1
endpoint =
acl = private

Для Backblaze B2 через нативный протокол (не S3-совместимый режим) конфиг короче:

[b2backup]
type = b2
account = ВАШ_ACCOUNT_ID
key = ВАШ_APPLICATION_KEY
hard_delete = true

hard_delete = true важен: без него удалённые файлы в B2 просто прячутся и продолжают тарифицироваться как хранимые — со временем счёт растёт незаметно.

Для Google Drive настройка требует OAuth-авторизации в браузере — сделайте её один раз на компьютере с GUI командой rclone config, выберите тип drive, пройдите авторизацию, а затем скопируйте готовую секцию [gdrive] из локального rclone.conf на сервер. Учтите лимиты обычного аккаунта Google Drive — не рассчитывайте на него как на основное хранилище для тяжёлых бэкапов, лучше как на вторичную копию.

Проверка, что remote видит хранилище:

rclone lsd s3backup:
rclone about s3backup:

Первая синхронизация и разница между sync и copy

У rclone два принципиально разных режима заливки, и путать их нельзя.

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

rclone copy /var/backups s3backup:my-bucket/backups --progress

sync приводит приёмник к точному состоянию источника — если файл удалён локально, он удаляется и в облаке. Это то, что вам нужно для актуального зеркала, но ошибка в пути источника может стереть всё хранилище:

rclone sync /var/backups s3backup:my-bucket/backups --progress

Первый запуск sync всегда делайте с флагом --dry-run — он покажет, что будет сделано, без реальных изменений:

rclone sync /var/backups s3backup:my-bucket/backups --dry-run -v

Полезные флаги для продакшна:

rclone sync /var/backups s3backup:my-bucket/backups \
  --transfers 8 \
  --checkers 16 \
  --bwlimit 10M \
  --log-file /var/log/rclone-backup.log \
  --log-level INFO

• --transfers — сколько файлов передавать параллельно (не путать с потоками на один файл).
• --bwlimit — ограничение полосы, чтобы бэкап не забивал канал в рабочее время.
• --checkers — сколько параллельных проверок хэшей/размеров, влияет на скорость сравнения при больших объёмах.

Шифрование данных перед загрузкой в облако

Если бэкап содержит чувствительные данные (дампы БД с персональными данными, ключи, конфиги), заливать его в чужое облако в открытом виде — риск. rclone поддерживает remote типа crypt, который шифрует имена файлов и содержимое перед отправкой в базовый remote.

Настройка crypt-обёртки поверх уже созданного s3backup:

rclone config
# n) New remote
# name: cryptbackup
# type: crypt
# remote: s3backup:my-bucket/encrypted
# filename_encryption: standard
# password: (сгенерируется мастером или введите свой)
# password2: (соль, тоже сохраните отдельно)

Ключевой момент — пароль и соль (password/password2) хранятся только у вас, rclone их не передаёт в облако. Потеряли пароль — потеряли доступ к данным навсегда, даже если бакет цел. Сохраните их в отдельном менеджере паролей, а не только в rclone.conf на том же сервере, который бэкапите.

Дальше работаете с cryptbackup: как с обычным remote — шифрование прозрачно:

rclone copy /var/backups cryptbackup: --progress
rclone ls cryptbackup:

В облаке при этом будут лежать файлы с бессмысленными именами и зашифрованным содержимым — просмотр бакета через веб-консоль провайдера ничего не покажет.

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

Ручные бэкапы забываются. Простой вариант — cron-задача с обёрткой в bash-скрипт, чтобы логировать результат и не терять контроль над флагами:

#!/bin/bash
# /usr/local/bin/backup-rclone.sh
set -euo pipefail

SRC="/var/backups"
DST="cryptbackup:"
LOG="/var/log/rclone-backup.log"

echo "=== $(date '+%F %T') backup start ===" >> "$LOG"
rclone sync "$SRC" "$DST" \
  --transfers 8 \
  --checkers 16 \
  --log-file "$LOG" \
  --log-level INFO

if [ $? -eq 0 ]; then
  echo "$(date '+%F %T') backup OK" >> "$LOG"
else
  echo "$(date '+%F %T') backup FAILED" >> "$LOG"
  # опционально: уведомление в telegram/email
fi

chmod +x /usr/local/bin/backup-rclone.sh
crontab -e

Строка в crontab — бэкап каждую ночь в 3:15:

15 3 * * * /usr/local/bin/backup-rclone.sh

Если предпочитаете systemd timer вместо cron (удобнее для просмотра статуса и логов через journalctl), понадобятся два юнита:

# /etc/systemd/system/rclone-backup.service
[Unit]
Description=rclone backup to cloud storage

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup-rclone.sh

# /etc/systemd/system/rclone-backup.timer
[Unit]
Description=Daily rclone backup

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

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now rclone-backup.timer
systemctl list-timers | grep rclone

Persistent=true важен: если сервер был выключен в момент запуска таймера, задача выполнится сразу после старта — не пропустите бэкап из-за перезагрузки.

Схему бэкапа стоит комбинировать с ротацией задач через cron, если на сервере уже есть другие плановые job — так проще отслеживать конфликты по нагрузке на диск и сеть.

Восстановление данных из облака

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

rclone copy cryptbackup: /var/backups-restore --progress

Восстановление конкретного файла или поддиректории:

rclone copy cryptbackup:mysql-dumps/2026-08-30.sql.gz /tmp/restore/ --progress

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

rclone ls cryptbackup:
rclone size cryptbackup:
rclone tree cryptbackup: --max-depth 2

Если нужно синхронизировать состояние обратно на сервер один в один (полное аварийное восстановление, а не выборочное), используйте sync в обратную сторону — но обязательно с --dry-run перед реальным запуском, потому что sync удалит на сервере то, чего нет в бэкапе:

rclone sync cryptbackup: /var/backups --dry-run -v
rclone sync cryptbackup: /var/backups --log-file /var/log/rclone-restore.log

Для проверки целостности после восстановления сравните контрольные суммы источника и приёмника:

rclone check cryptbackup: /var/backups

Команда покажет расхождения, если они есть — это единственный надёжный способ убедиться, что бэкап не побился при передаче.

Версионирование и защита от порчи бэкапа

Слабое место sync — если файл на сервере был испорчен (например, ransomware или ошибка приложения) до момента бэкапа, испорченная версия перезапишет рабочую копию в облаке. Защититься помогает пара приёмов.

Во-первых, версионирование на стороне хранилища — большинство S3-совместимых провайдеров и Backblaze B2 поддерживают object versioning, включается на уровне бакета через консоль провайдера или CLI, не через rclone. Включив его, вы получаете возможность откатиться к предыдущей версии объекта даже после sync.

Во-вторых, флаг --backup-dir у rclone — при синхронизации перезаписываемые и удаляемые файлы не пропадают, а перемещаются в отдельную директорию с меткой времени:

rclone sync /var/backups cryptbackup: \
  --backup-dir cryptbackup:archive/$(date +%F) \
  --log-file /var/log/rclone-backup.log

Так у вас всегда остаётся снимок предыдущего состояния, а не только «последний актуальный» бэкап, который может оказаться уже испорченным. Комбинация версионирования на стороне провайдера и --backup-dir закрывает большинство сценариев порчи данных — но регулярно (раз в месяц-два) стоит вручную проверять, что восстановление из старой версии действительно работает, а не только что процесс бэкапа не падает с ошибкой.

Для сравнения с альтернативными инструментами бэкапа — если нужна дедупликация и инкрементальные снапшоты внутри одного хранилища, посмотрите restic или BorgBackup: rclone проще и универсальнее по числу поддерживаемых облаков, но не делает дедупликацию блоков сам по себе — экономия места на этом уровне ложится на возможности самого хранилища (версионирование, lifecycle-политики).

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