How do you actually back up a VPS?
You back up a VPS two ways at once, and beginners usually only find out about one of them. The first is a snapshot, a full point-in-time copy of your entire server that your hosting provider takes and stores for you, usually a click or two in the control panel. The second is a file backup, where you copy specific folders, configs, and database dumps somewhere outside the server itself, using something like rsync or tar.
You want both, not one or the other. Snapshots save you when something goes badly wrong at the operating system level, a bad update, a botched migration, a server that will not boot. File backups save you when you just need last week's version of one folder, or when you want your data stored somewhere that has nothing to do with your hosting provider at all. Neither is complete on its own, and I learned that the slightly annoying way on my own server.
Snapshots vs file backups: what is actually different?
A snapshot captures everything: the operating system, installed software, configuration, and data, frozen at one moment. Restoring one puts the whole server back exactly as it was, which is wonderful when things are badly broken and useless when you only wanted one file back. Snapshots also live with your hosting provider, so if something happens to your account or that provider specifically, your snapshots go with it.
A file backup is narrower by design. You choose what matters, typically your website files, any databases, and configuration for the specific apps you run, and copy just that. It is smaller, faster to move around, and can be stored anywhere: your own laptop, cloud storage, a different server entirely. The tradeoff is that a file backup does not include your operating system setup, so restoring from one assumes you still have a working server to restore onto.
What should you actually back up?
Start with anything that would be painful or slow to recreate from scratch. That almost always means your databases, since a database holds live data that changes daily and cannot be regenerated from a git repository. It also means uploaded files, like images or documents users have added, and any configuration files you have hand-tuned, like your Docker compose files or web server configs.
What you generally do not need to back up separately is anything that lives in version control already, like your site's source code, or anything you could reinstall in minutes, like a fresh package install. On my own server, the things I actually care about losing are n8n's workflow data and a couple of small databases, not the base Ubuntu install underneath them.
What does a simple rsync and tar approach look like?
You do not need specialized backup software to get real protection. A basic pattern many small VPS owners use is a shell script that dumps any databases to a file, then uses tar to bundle the important folders into one compressed archive, then uses rsync to copy that archive off the server, either to your own machine or to separate storage. Run that script on a schedule with cron, and you have automated backups without a dedicated tool.
This approach is not fancy, but fancy is not the goal. The goal is a copy of your important data that exists somewhere other than the server it came from, updated often enough that losing the newest changes would not hurt much. If you already run n8n on a VPS, this is also a task you can eventually hand to a scheduled workflow once you trust the manual version.
How often should you back up?
Match the frequency to how much change happens and how much you would mind losing. A mostly-static site that rarely changes is fine with weekly backups and a snapshot before any risky work. A database taking daily form submissions or orders deserves nightly backups of at least that data, even if the rest of the server is backed up less often. There is no universal right answer here, only the honest question of what you could stand to lose.
Why is an untested backup basically worthless?
Because a backup is not really a file, it is a promise, and you do not know if a promise is good until you have tested it. I have seen plenty of people discover their backup script had been silently failing for months, only when they actually needed to restore something. A backup process that runs without errors is not proof it works. Proof is a successful restore.
This is the step almost everyone skips, and it is the one that matters most. A backup you have never restored from is a guess dressed up as a safety net.
How do you test a restore without wrecking your live site?
Spin up a second, cheap VPS temporarily, or use a separate directory on your existing server, and actually run the restore process there. Unpack your tar archive, load your database dump, and confirm the site or app actually comes up and looks right. This takes maybe half an hour and it is the difference between a backup strategy and a backup ritual you perform without knowing if it works.
Do this once right after you set backups up, so you catch any mistakes in the process while the stakes are low. Repeat it after any major change to what you are backing up, like adding a new database or app.
What is a sane backup routine for a beginner?
If you only take one thing from this post, make it this: turn on your host's automatic snapshots, set a schedule you will not have to think about again, and add one simple rsync and tar script for the specific files and databases you would truly hate to lose. That combination covers both the whole-server disaster and the smaller, more common mistake of accidentally deleting or overwriting something important.
Keep at least one backup copy off your hosting provider entirely, even if it is just a folder on your own computer that syncs down once a week. And put a recurring reminder on your calendar, not a fancy one, just a note every few months to actually restore something and confirm it still works. That habit alone puts you ahead of most people running their own server, including plenty of people who have been doing it for years.
Next step: once backups are in place and tested, it is worth locking down the rest of your server too. Our automation hub has more guides for running a small VPS safely and reliably.
