До основного вмісту

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 проти 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.

Чи була стаття корисною?
← Назад до бази знань Поставити питання підтримці