# Backing up your VPS Source: https://vpsdime.com/knowledgebase/getting-started/backing-up-your-vps Last reviewed: 2026-07-02 Summary: Honest backup advice for a VPS, why backups (not RAID) are what save you, the 3-2-1 rule, dumping databases properly, tools that work well (restic, borg, rclone, rsync), off-site destinations, testing restores, and how our Nightly Backups add-on fits in as an extra layer, not a replacement. ## What this is How to actually keep your data safe on a VPS. Your data is your responsibility with any self-managed host, and the good news is that a genuinely solid backup setup takes an evening to build and then runs itself. First, a distinction that bites people: **redundancy is not backup.** Our nodes run RAID10 and redundant everything, which protects against a dead disk, but it faithfully replicates your mistakes too. Most real-world data loss is a deleted file, a botched upgrade, a bad migration, ransomware, or a compromise, and against all of those, only a backup helps. ## What to back up Split your VPS mentally into two piles: - **Irreplaceable:** your databases, uploaded files, application data, configs you've sweated over, TLS keys and certs. This is what backups are for. - **Rebuildable:** the OS and installed packages. You can reinstall those in minutes, so most people don't image the whole OS themselves, they keep a note (or script) of how the server was set up, plus the data. If you can answer "how would I get from a fresh [reinstall](https://vpsdime.com/knowledgebase/client-area/services/reinstall-os) back to a working server?", you know exactly what belongs in the backup. ## The 3-2-1 rule The classic standard, and it maps neatly onto a VPS: - **3 copies** of your data (the live one counts as one), - on **2 different systems**, - with **1 off-site**, away from the VPS and ideally away from any single provider. A copy that lives only on the VPS itself is not a backup: whatever takes out the server (compromise, deletion, a mistake with `rm`) takes the "backup" with it. ## Databases need dumps, not file copies Copying a running database's files produces backups that may not restore. Dump instead, on a schedule: - MySQL/MariaDB: `mysqldump --single-transaction dbname > backup.sql` - PostgreSQL: `pg_dump dbname > backup.sql` Run it nightly from cron to a folder like `/var/backups/`, then let your backup tool ship that folder off-site. Bonus: a nightly dump inside the VPS also makes our [Nightly Backups](https://vpsdime.com/knowledgebase/client-area/nightly-backups/nightly-backups-overview) image cleanly restorable, since the dump is a consistent copy sitting in the image. ## Tools that work well Any of these, automated with cron or better, a [systemd timer](https://vpsdime.com/knowledgebase/technical-questions/systemd-timers) (logged runs, catch-up after downtime, no overlaps), is a real setup: - **restic** (our default recommendation): encrypted, deduplicated, incremental, works with any S3-compatible storage or SFTP, and retention is one flag (`restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune`). One tool does the whole job. - **BorgBackup:** the same virtues, best when your destination is another Linux box you control. - **rclone:** syncs directories to almost any cloud storage; great for shipping a backups folder off-site. - **rsync** to another server: simple and battle-tested, though it's a mirror rather than versioned history unless you add snapshots. - Even a **tar + cron** job shipped off-site beats nothing, start simple rather than not at all. ## Where to send them (off-site) - **Object storage** is the sweet spot for price and durability: Backblaze B2, Cloudflare R2, Wasabi, or any S3-compatible bucket. Pennies per month for typical site data. - **Another server you control**, with a different provider or at home (a NAS), also works well. - The principle: at least one copy should survive the total loss of this VPS **and** be independent of any single company, including us. ## Test your restores An untested backup is a hope, not a backup. Twice a year, actually restore something: pull a file back from restic, load a database dump into a scratch database, and confirm it's all there. And make failure noisy, check that your backup job alerts you when it stops working (a cron email, or a dead-man's-switch ping service), because backup jobs love to die silently the month before you need them. ## Where our Nightly Backups add-on fits [Nightly Backups](https://vpsdime.com/knowledgebase/client-area/nightly-backups/nightly-backups-overview) images your **whole VPS** once a night with 3-night retention, with self-service full restore, per-file recovery, and disk-image download. It's $5/month on Linux and Windows VPS ([enable it here](https://vpsdime.com/knowledgebase/client-area/nightly-backups/enable-nightly-backups)) and included free on Premium VPS. Use it **in addition to** your own backups, not instead of them. The two cover different failures: - **Nightly Backups** is the fastest way back from "I broke the server last night", a whole-server rollback or a quick file recovery, no setup required. - **Your own off-site backups** give you long retention, history beyond three nights, and a copy that exists outside our platform entirely. Together that's a genuinely robust setup. Either alone has a gap. ## A solid starter recipe 1. Enable **Nightly Backups** on the VPS. 2. Add a nightly **database dump** to `/var/backups/` via cron. 3. Run **restic** daily to an off-site bucket (site files + `/var/backups/` + configs), with `--keep-daily 7 --keep-weekly 4 --keep-monthly 6`. 4. Put a **restore test** in your calendar twice a year. (Steps 2 and 3 are a script and a schedule, exactly the kind of thing an [AI chatbot](https://vpsdime.com/knowledgebase/support-coverage/software-and-server-management) drafts correctly from your paths and bucket details, you review the retention flags and paste it in.) An evening of setup, and every failure mode short of "the internet ends" is covered. ## Still need help? You can [open a support ticket](https://vpsdime.com/open-ticket/). So we can help on the first reply, it's worth mentioning: - the VPS hostname or IP, - what data you're trying to protect, and what you've set up so far. ## Related questions - "How should I back up my VPS?" - "Do you back up my VPS for me?" - "How do I back up my database properly?" - "What backup tool should I use on a VPS?" - "Where should I store my backups?" - "Is the Nightly Backups add-on enough on its own?" - "How do I know my backups actually work?"