Where to send your backups
I use Proton Drive and a home server because I already have both. They're not the only options, and they're not the best options for everyone. What matters is redundancy — two targets, different failure modes, at least one automated so it happens even when you forget.
Fast restores over the LAN, no third-party dependency, no recurring cost beyond the hardware you already own. Downside: your basement is not a data center — power outage, hardware failure, or ISP downtime means the backup target is unreachable. rclone's SFTP backend uses your existing SSH key; no additional authentication setup needed.
End-to-end encrypted, off-site, automated. If you already pay for Proton, the storage is included. rclone's Proton Drive backend handles OAuth and two-factor authentication natively. Downside: restore speed is gated by your VPS bandwidth to Proton's servers. For a few hundred megabytes of database dumps and config files, it's fine. For pulling down a full site restore, it's slower than a local target.
A dedicated backup storage provider — you get an empty filesystem accessible over SSH. No APIs, no web dashboards, just SFTP or rsync. They offer a reduced rate for BorgBackup users. Good option if you want a hands-off remote target that behaves like a Linux filesystem without managing a second server yourself. Pricing starts around $12/month for 100 GB.
Cheap, predictable pricing — 1 TB for around €4/month. Accessible over SFTP, rsync, Samba, or WebDAV. rclone supports it as an SFTP or WebDAV remote. Good fit if you already use Hetzner for anything or want the cheapest-per-terabyte option that isn't a consumer cloud drive.
S3-compatible object storage — rclone's B2 backend is mature and well-documented. Pricing is usage-based: roughly $6/TB/month for storage plus download charges. Restores are more expensive than storage, but for backups you rarely pull from, the math works out. Good option if you already use B2 for anything else or want an S3-compatible target without AWS pricing.
If you already run a VPS with BuyVM, their block storage slabs are cheap attached storage — 256 GB for $1.25/month, 1 TB for $5/month. Accessible as a mounted volume, not a remote. You'd still need rclone or rsync to push backups to it, but it's an inexpensive second-location target if you have a second BuyVM instance or want storage attached to the same VPS for staging before an off-site push.
Prorated hourly billing, scaled to your compute instance — $2/month for a 1 GB Nanode, $3/month for 2–4 GB shared CPU plans, $5/month and up for larger instances. Four backup slots: one manual snapshot and three auto-rotating slots. No file-level restore — restores are a full instance overwrite, which means a single compromised site can't be surgically repaired from the backup without taking every other site on the server down with it. The backup process does not pause database writes, so there's no quiescence guarantee — your MariaDB backup may be crash-consistent but not transactionally clean. Vultr, DigitalOcean, and other providers offer similar snapshot-based services with the same trade-offs.
None of these are an endorsement. They're options with different trade-offs. The rule I follow: one target should be automatic (cron runs it whether I remember or not), and one target should be independent (a different provider, a different failure mode). Cloud services are convenient. They should not be your only backup. If you're relying entirely on a cloud storage provider to keep your data safe, you're one terms-of-service change, billing snafu, or service shutdown away from losing access. Push to the cloud, pull to local when you can, and sleep better.
Provider-native backups — Linode's Backup Service, DigitalOcean's Snapshots, Vultr's Automatic Backups — are the simplest option because they require zero configuration. Everything on the instance gets backed up, no rclone setup, no cron jobs, no remote to configure. The trade-off is granularity: you can't restore a single database without restoring the entire instance. If one WordPress site is compromised, you can't pull just that site's files from a snapshot — you overwrite everything. For disaster recovery — the entire VPS is gone and you need it back — they're the fastest path to a working server. For day-to-day file-level recovery — a corrupted plugin, an accidental DROP TABLE, a config edit you regret — rclone to a remote target gives you the granularity that provider snapshots don't. I use both. The Linode backup is the last-resort nuclear option. The rclone backups are what I actually reach for.
A note on what to back up
Not everything on your server needs to be backed up. The nginx binary, PHP-FPM packages, and system libraries can be reinstalled from the package manager. What can't be reinstalled:
- Database dumps —
mysqldumpper database, orwp db exportper WordPress site. If you run WordPress, the database is the site. Everything else is replaceable. - Site content —
/wp-content/uploads/for WordPress media./bl-content/for Bludit pages, users, and plugin workspace data. Exclude cache directories and anything transient. - Themes and plugins you've customized —
/wp-content/themes/if you've built a child theme or edited templates./bl-themes/and/bl-plugins/if you've written your own. A core theme from a repository can be reinstalled. The customizations you spent a weekend on can't. - Nginx configuration —
/etc/nginx/sites-enabled/,/etc/nginx/snippets/,/etc/nginx/nginx.conf. These represent hours of tuning. Back them up. - SSL certificates —
/etc/letsencrypt/or the renewal configuration. Certbot can reissue certs, but having the live directory backed up saves time during a restore. - cron jobs —
crontab -l > /backups/crontab.txt. You won't remember every job you scheduled at 3 AM six months ago.
The general rule: back up anything you customized. Core CMS files, default themes, and unmodified plugins can be reinstalled from their source. Your child theme's functions.php, your hand-tuned nginx snippets, your cron schedule — none of that exists anywhere else. If you touched it, back it up.
What you exclude is as important as what you include. Backing up /var/log/ or /tmp/ wastes bandwidth and storage. Backing up the full /var/www/ including stale staging sites, test directories, and abandoned projects fills your remote with junk. Be specific. Your backup script should enumerate what it collects, not blindly copy everything.
This guide documents a two-target backup strategy using rclone with Proton Drive and a home server over Tailscale SFTP. The approach is portable to any rclone-supported remote — the principles of redundancy, automated cron scheduling, and local-plus-cloud targeting apply regardless of which providers you choose.
Compatibility: rclone is available for Linux, macOS, Windows, and FreeBSD. The SFTP backend works with any SSH server. Proton Drive support requires rclone 1.63+. Backblaze B2, rsync.net, and Hetzner Storage Box are supported natively. The cron scheduling patterns and --transfers 1 tuning are VPS-agnostic.
2026-05-29: Initial publication — rclone backup strategy covering Proton Drive and home server SFTP remotes, cron layering with nightly job scheduling, age-based remote pruning, provider comparison for backup targets, and guidance on what to include and exclude from backups.