rclone: Backing Up Your VPS to Cloud Storage

rclone: cloud backups for your VPS

rclone is a universal tool for working with cloud storage: it supports more than 40 providers, including any S3-compatible service, Google Drive, Backblaze B2, Dropbox, OneDrive, and others.

Installing rclone

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

Setting up a remote

# Interactive setup
rclone config

# Choose: n (New remote)
# Name: backblaze (or any name)
# Type: b2 (Backblaze B2) / s3 (AWS/MinIO) / drive (Google Drive)

Example: Backblaze B2

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

Example: S3-compatible (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

Encrypting backups

# Create an encrypted remote
rclone config
# Type: crypt
# Remote: backblaze:my-bucket/encrypted
# Password: set a strong password

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

Sync commands

# Copy files (do not delete in the cloud)
rclone copy /var/backups backblaze-crypt:vps-backups

# Sync (delete extra files in the cloud)
rclone sync /var/backups backblaze-crypt:vps-backups

# Check contents
rclone ls backblaze-crypt:vps-backups

# Dry run (no changes)
rclone sync /var/backups backblaze:my-bucket --dry-run -v

Automated backup script with 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 dump
mysqldump --all-databases -u root -p'PASSWORD' | gzip > $BACKUP_DIR/mysql-all.sql.gz

# Website files
tar -czf $BACKUP_DIR/www.tar.gz /var/www/html

# Upload to the cloud
rclone copy $BACKUP_DIR backblaze-crypt:vps-backups/$DATE >> $LOG 2>&1

# Remove the local copy
rm -rf $BACKUP_DIR

# Delete backups older than 30 days
rclone delete backblaze-crypt:vps-backups \
  --min-age 30d --rmdirs >> $LOG 2>&1

echo "[$DATE] Backup done" >> $LOG

# Crontab — run every night at 3:00
crontab -e
0 3 * * * /usr/local/bin/vps-backup.sh

Monitoring and notifications

# Send a notification on failure
rclone copy /var/backups backblaze:bucket || \
  curl -s "https://api.telegram.org/bot$TOKEN/sendMessage" \
    -d "chat_id=$CHAT_ID&text=Backup+FAILED!"

Real Errors Explained

Most rclone failures fall into two categories: a typo in the remote name, and access denied on the provider's side.

Remote Not Found in the Config

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

A classic typo in the remote name when invoking the command — rclone does not suggest similar names, it simply cannot find the section. Check the exact name with rclone listremotes and compare it character by character, especially if the remote was created a long time ago.

AccessDenied on Upload

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

The access key does not have write permission for that specific bucket — either the IAM/bucket policy only allows GetObject, or the key was created for a different bucket. Check the policy on the provider's side and permissions specifically for PutObject and DeleteObject if you use rclone sync with deletion of extra files.

rclone vs. restic/Borg

When rclone Is Not a Good Fit

• You need incremental backups with block-level deduplication — rclone works at the level of whole files; for deduplication you need restic or Borg.
• You need point-in-time snapshots with instant rollback to a specific file version — rclone does not keep version history on its own, only what physically sits in the bucket.
• You need WORM storage with legally enforced immutability — that is an Object Lock setting on the bucket itself; rclone cannot guarantee that on its own.
• You need real-time database replication rather than a file backup — that calls for pg_basebackup, MySQL binary logs, or the database engine's built-in replication.
• The connection is extremely unstable and the files are huge (hundreds of GB) — specialized tools with block-level chunking and resume are more reliable than re-uploading the whole file.

Verifying the Result

# Compare checksums locally and in the cloud without copying anything
rclone check /var/backups backblaze-crypt:vps-backups

# See the actual space used in the bucket
rclone size backblaze-crypt:vps-backups

# A test restore of a single file — a critically important check
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 "Archive is intact"

The rclone check command without the --download flag only compares size and the hash returned by the provider's API — that is enough for most cases, but once a quarter you should do a full test restore like the second example instead of trusting checksums alone. If backups run from a server inside a Docker Swarm cluster, move the volume mount point for the dump to a separate disk so the backup does not block production I/O.