The most common VPS disaster is not a hack or a hardware failure \u2014 it is a one-line command run in the wrong directory, or a provider\u2019s storage array dying on a Saturday. On a budget server there is no SAN, no replication, and often no included backup product, which means the safety net is entirely up to you. The good news: a solid backup strategy for a small VPS costs nothing in software and a few dollars a month in storage. This guide covers rsync and Borg, how to get copies offsite, and \u2014 the step everyone skips \u2014 how to prove the backups actually restore.<\/p>\n\n\n\n
Backup strategy starts with inventory, not tools. List what the server holds: application code (recoverable from git, probably not urgent), configuration files (small, critical, often forgotten), databases (the thing you actually cannot rebuild), and user uploads or state (medium size, hard to recreate). Assign each a recovery-time target \u2014 how fast you need it back \u2014 and a retention period. A sensible default for a small VPS: database dumps daily, configs daily, uploads daily, code weekly, with 14\u201330 days of history. Everything else is detail.<\/p>\n\n\n\n
rsync is the workhorse: it copies only the changed parts of files, works over SSH, and is installed on virtually every Linux box. A daily rsync of your data directory to a second location \u2014 another VPS, a cheap storage box, or a home NAS \u2014 gives you a current copy within minutes. The two things to get right: use BorgBackup fixes rsync\u2019s main gap. It stores deduplicated, compressed, optionally encrypted snapshots, so 30 days of daily backups of a 10 GB server typically consume a small fraction of 300 GB \u2014 only the changed chunks are stored each day. That makes realistic history affordable even on cheap storage. The workflow is simple: A backup on the same server is not a backup \u2014 it dies with the server. The offsite copy needs to be in a different failure domain: another provider\u2019s storage, an object-storage bucket (Backblaze B2, Wasabi, or a budget S3-compatible provider all work), or a machine you control elsewhere. For a small VPS the economics are trivial: a 20 GB repository with deduplication typically costs well under $1\u20132\/month on object storage, and rsync-over-SSH to a second cheap VPS costs whatever that VPS costs. Whatever you choose, automate it \u2014 a manual \u201cbackup day\u201d stops happening after the second month. Two rules: the offsite copy must be encrypted (Borg gives this free), and the restore path must not depend on the dead server.<\/p>\n\n\n\n A backup that has never been restored is a theory. Test quarterly, and test the hard path: restore to a fresh VPS, not over the top of the broken one. Spin up the cheapest instance your provider offers (or a local VM), restore the Borg archive or rsync copy, point the database at the restored dump, and confirm the application boots. Time it \u2014 if the full restore takes six hours, you now know your real recovery time, and you can decide whether that is acceptable. Automate the test where possible: a cron job that restores the latest database dump into a throwaway instance and runs a health check catches corrupted archives while they are still cheap to fix.<\/p>\n\n\n\n That is about two hours of setup, a few dollars a month, and the difference between a bad weekend and a lost server. For more on choosing a provider that makes offsite copies cheap, see the budget VPS comparison<\/a> \u2014 and the features guide<\/a> covers which plans include storage options worth using.<\/p>\n\n\n\n--delete<\/code> carefully (it mirrors deletions, so a ransomware-style wipe propagates to the backup), and never back up a live database by copying files \u2014 dump it first with mysqldump<\/code> or pg_dump<\/code> so the backup is a consistent snapshot. rsync\u2019s weakness is history: it keeps one state unless you script rotating snapshots (for example, --link-dest<\/code> for incremental hardlink copies), so a corrupted file silently overwrites yesterday\u2019s good copy.<\/p>\n\n\n\nBorg: Deduplicated, Encrypted, History-Preserving<\/h2>\n\n\n\n
borg init<\/code> once, then a cron job running borg create<\/code> daily with a --stats<\/code> flag and a prune policy (borg prune --keep-daily 14 --keep-weekly 8<\/code>). Because Borg encrypts by default, the offsite copy is safe even if the storage provider is not.<\/p>\n\n\n\nOffsite Storage: The Second Copy Is the Point<\/h2>\n\n\n\n
Tool<\/th> Best for<\/th> History<\/th> Encryption<\/th> Effort<\/th><\/tr><\/thead> rsync + SSH<\/td> Simple current-state copies, syncing to a second box<\/td> One state (unless you script snapshots)<\/td> Via SSH<\/td> Minutes to set up<\/td><\/tr> BorgBackup<\/td> Deduplicated, encrypted, long history on cheap storage<\/td> Unlimited snapshots, prunable<\/td> Built-in<\/td> About an hour to set up<\/td><\/tr> Database dump + object storage<\/td> Databases and small critical files<\/td> As many as you schedule<\/td> Add GPG or rely on the bucket<\/td> Minutes per service<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n Restore Testing: The Step That Separates Backups from Wishful Thinking<\/h2>\n\n\n\n
A Minimal Working Setup for a Small VPS<\/h2>\n\n\n\n
pg_dump<\/code>\/mysqldump<\/code>) into a \/backups\/db<\/code> directory.<\/li>borg create<\/code> an encrypted archive of \/etc<\/code>, \/var\/www<\/code>, and \/backups\/db<\/code>; prune to 14 daily + 8 weekly.<\/li>rclone<\/code> or rsync.<\/li>