Off-Site Backups with rclone to Object and Cloud Storage

The off-site copy of your 3-2-1 is the one that protects against the worst cases, and rclone is the tool that makes it painless on a small budget. rclone speaks the protocol of dozens of object and mainstream cloud stores, turning any of them into a backup target for a few rupees of storage per month. A nightly sync to an encrypted remote is the difference between a backup plan and a backup plan that survives a fire or a compromise at your primary site. Netbay runs production in Lucknow DC01; the copying target should be geographically removed from it.

Configure a remote once

rclone stores connection definitions called remotes. Interactive setup is the documented path, and for a single VPS it is a quick walkthrough:

rclone config
rclone lsd OBJECTSTORE:netbay-backup
rclone lsjson OBJECTSTORE:netbay-backup | head -5

You end with a remote name, a bucket or folder outside the primary datacenter, and credentials stored in the rclone config file. Keep that file out of git or mask its secrets before it ever reaches a repository.

Encrypt with a crypt remote

A storage provider without encryption at your side sees only ciphertext when you wrap the plain remote in a crypt overlay. Configure the crypt remote once and use its name everywhere; the passphrase and salt it encodes must be stored separately from the server, because losing them loses the archives.

A minimal fragment of rclone.conf shows the shape:

[OBJECTSTORE]
type = s3
provider = Other
endpoint = https://storage.example.net
access_key_id = YOUR_ACCESS_KEY
secret_access_key = YOUR_SECRET_KEY

[secretbackup]
type = crypt
remote = OBJECTSTORE:netbay-backup
password = CONFIDENTIAL_ENCODED
salt = CONFIDENTIAL_ENCODED

rclone generates and encodes the crypt credentials during config; copy them into your password manager rather than a chat.

Sync, not copy, and check

rclone copy uploads everything every time; rclone sync makes the destination mirror the source, deleting files that vanished locally. That forces you to settle the retention policy before enabling it. For append-only archives, copy is right; where you prune locally with find, sync keeps the remote honest with the same policy.

rclone sync /var/backups secretbackup:vps01/daily   --transfers 4 --bwlimit 10M   --log-file=/var/log/rclone.log --log-level INFO
rclone check /var/backups secretbackup:vps01/daily --download

The check with --download pulls hashes back instead of trusting the listing, which is the closest cheap thing to a remote restore test a cron job can run.

Schedule it, cap the bandwidth

# /etc/cron.d/rclone-sync
20 4 * * * root /usr/local/bin/rclone_backup.sh

#!/usr/bin/env bash
# /usr/local/bin/rclone_backup.sh
set -euo pipefail
rclone sync /var/backups secretbackup:vps01/daily   --transfers 4 --bwlimit 10M   --log-file=/var/log/rclone.log --log-level INFO
rclone check /var/backups secretbackup:vps01/daily   --log-file=/var/log/rclone-check.log
rclone lsf secretbackup:vps01/daily | tail -3

The bwlimit cap keeps a large first sync from starving your site during the day, and the final lsf confirms files actually landed at the far end.

Takeaway

rclone turns object and cloud storage into a disciplined off-site tier, with encryption at the edge and checks you can schedule. Configure the remote once, wrap it in a crypt overlay, sync nightly under a bandwidth cap, and let check verify the hashes. The bucket is cheap; the discipline is the trick. Netbay deploys the VPS that runs this pipeline in under 60 seconds at netbayhosts.in.