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 проти restic/Borg
| Критерій | rclone | restic / 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.