К основному содержимому

rclone: резервные копии VPS в облачные хранилища

Облако и DevOps · 19.04.2026 · 4 мин чтения
Иллюстрация к статье «rclone: резервные копии VPS в облачные хранилища»

rclone: облачные бэкапы для VPS

rclone — универсальный инструмент для работы с облачными хранилищами: поддерживает более 40 провайдеров, включая любой S3-совместимый сервис, Google Drive, Backblaze B2, Dropbox, OneDrive и другие.

Установка rclone

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

Настройка удалённого хранилища

# Интерактивная настройка
rclone config

# Выбрать: n (New remote)
# Имя: backblaze (или любое)
# Тип: b2 (Backblaze B2) / s3 (AWS/MinIO) / drive (Google Drive)

Пример: Backblaze B2

[backblaze]
type = b2
account = YOUR_ACCOUNT_ID
key = YOUR_APP_KEY

Пример: S3-совместимый (MinIO/Hetzner)

[hetzner-s3]
type = s3
provider = Other
access_key_id = YOUR_KEY
secret_access_key = YOUR_SECRET
endpoint = https://fsn1.your-objectstorage.com
region = eu-central

Шифрование бэкапов

# Создать зашифрованный remote
rclone config
# Тип: crypt
# Remote: backblaze:my-bucket/encrypted
# Пароль: задать надёжный пароль

[backblaze-crypt]
type = crypt
remote = backblaze:my-bucket/encrypted
filename_encryption = standard
directory_name_encryption = true
password = ENCRYPTED_PASSWORD

Команды синхронизации

# Копировать файлы (не удалять в облаке)
rclone copy /var/backups backblaze-crypt:vps-backups

# Синхронизировать (удалять лишнее в облаке)
rclone sync /var/backups backblaze-crypt:vps-backups

# Проверить содержимое
rclone ls backblaze-crypt:vps-backups

# Сухой прогон (без изменений)
rclone sync /var/backups backblaze:my-bucket --dry-run -v

Скрипт автобэкапа с cron

#!/bin/bash
# /usr/local/bin/vps-backup.sh

DATE=$(date +%Y-%m-%d)
BACKUP_DIR=/tmp/backup-$DATE
LOG=/var/log/rclone-backup.log

mkdir -p $BACKUP_DIR

# Дамп MySQL
mysqldump --all-databases -u root -p'PASSWORD' | gzip > $BACKUP_DIR/mysql-all.sql.gz

# Файлы сайтов
tar -czf $BACKUP_DIR/www.tar.gz /var/www/html

# Загрузка в облако
rclone copy $BACKUP_DIR backblaze-crypt:vps-backups/$DATE >> $LOG 2>&1

# Очистить локальную копию
rm -rf $BACKUP_DIR

# Удалить бэкапы старше 30 дней
rclone delete backblaze-crypt:vps-backups \
  --min-age 30d --rmdirs >> $LOG 2>&1

echo "[$DATE] Backup done" >> $LOG
# Crontab — запуск каждую ночь в 3:00
crontab -e
0 3 * * * /usr/local/bin/vps-backup.sh

Мониторинг и уведомления

# Отправить уведомление при ошибке
rclone copy /var/backups backblaze:bucket || \
  curl -s "https://api.telegram.org/bot$TOKEN/sendMessage" \
    -d "chat_id=$CHAT_ID&text=Backup+FAILED!"
Совет: Используйте флаг --transfers=8 --checkers=16 для параллельной загрузки нескольких файлов — значительно ускоряет бэкап при большом количестве мелких файлов.

Разбор реальных ошибок

Большинство сбоев rclone делятся на две категории: опечатка в имени remote и отказ доступа на стороне провайдера.

Remote не найден в конфиге

Failed to create file system for "backblze:my-bucket": didn't find section in config file

Классическая опечатка в имени remote при вызове команды — rclone не подсказывает похожие варианты, просто не находит секцию. Проверьте точное имя командой rclone listremotes и сверьте посимвольно, особенно если remote создавался давно.

AccessDenied при загрузке

Failed to copy: AccessDenied: Access Denied. status code: 403, request id: ABCD1234

Ключ доступа не имеет права на запись в конкретный бакет — либо в IAM/bucket policy разрешён только GetObject, либо ключ создан для другого бакета. Проверьте политику на стороне провайдера и права конкретно на PutObject и DeleteObject, если используете rclone sync с удалением лишнего.

rclone vs restic/Borg

Критерийrclonerestic / Borg
Модель работыFile-level sync и copyБлочная дедупликация со снапшотами
ШифрованиеЕсть, через crypt remoteЕсть, встроено по умолчанию
Экономия места при повторных бэкапахНет дедупликации между версиямиДа, хранит только изменённые блоки
Число поддерживаемых облаков40+Меньше, но через rclone backend можно расширить

Когда rclone не подходит

  • Нужны инкрементальные бэкапы с блочной дедупликацией — rclone работает на уровне файлов целиком, для дедупликации нужен restic или Borg.
  • Нужны point-in-time снапшоты с мгновенным откатом к конкретной версии файла — rclone не хранит историю версий сам по себе, только то, что физически лежит в бакете.
  • Требуется WORM-хранение с юридически защищённой неизменностью — это настройка Object Lock на самом бакете, rclone не может это гарантировать со своей стороны.
  • Нужна репликация базы данных в реальном времени, а не файловый бэкап — тут нужны pg_basebackup, бинарные логи MySQL или встроенная репликация СУБД.
  • Канал крайне нестабилен, а файлы огромные (сотни ГБ) — специализированные инструменты с чанкованием и докачкой на уровне блоков надёжнее, чем повторный полный аплоад файла.

Проверка результата

# Сверить контрольные суммы локально и в облаке без копирования
rclone check /var/backups backblaze-crypt:vps-backups

# Посмотреть реальный занятый объём в бакете
rclone size backblaze-crypt:vps-backups

# Тестовое восстановление одного файла — критически важная проверка
rclone copy backblaze-crypt:vps-backups/2026-09-30/mysql-all.sql.gz /tmp/restore-test/
gunzip -t /tmp/restore-test/mysql-all.sql.gz && echo "Архив цел"

Команда rclone check без флага --download сравнивает только размер и хеш, который отдаёт API провайдера — этого достаточно для большинства случаев, но раз в квартал стоит делать полное тестовое восстановление, как во втором примере, а не доверять только контрольным суммам. Если бэкапы идут с сервера в кластере Docker Swarm, точку монтирования volume для дампа стоит вынести на отдельный диск, чтобы бэкап не блокировал рабочий I/O.

Статья помогла?
← Назад в базу знаний Задать вопрос поддержке