How to back up your server — and actually be able to restore it

Everyone is fine without backups, right up until the day they aren't. A mistyped command, a failed disk, an update that breaks more than it fixes — and suddenly the thing you built is gone, along with the evenings you spent on it.

The frustrating part is how avoidable it is. Backups aren't hard. But there's a gap between "I have backups" and "I can get my stuff back," and most people only discover that gap at the worst possible moment. Let's close it.

A backup isn't a backup until you've restored from it

Here's the uncomfortable truth: a backup you've never tested is a guess. Plenty of people have a folder of backups that turn out to be empty, corrupted, or missing the one thing they needed. The backup ran; the restore was never tried.

So the goal isn't "make backups." It's "be able to restore." Keep that as the real target and everything else falls into place.

What actually needs backing up

You don't usually need a copy of the entire machine. What you can't recreate is your data:

• the contents of your databases (the posts, users, orders — the stuff that changes),
• your files (uploads, documents, anything you or your users put there),
• your configuration (the handful of settings that make it yours).

The operating system and the software can be reinstalled in minutes. Your data can't be reinstalled at all. Back up the irreplaceable part.

The one rule that matters: get it off the server

A backup sitting on the same server it's protecting will die with that server. If the disk fails or the machine is lost, your backup goes with it.

So the rule is simple: at least one copy lives somewhere else — your own computer, another server, an object store. It doesn't have to be fancy. It just has to not be on the same box. A backup you can download and keep is a backup that survives the server.

Automate it, and keep more than one

Two quick add-ons that turn a backup into a habit:

• Don't rely on remembering. A backup you have to run by hand is one you'll skip. Put it on a schedule.
• Keep history, not just the latest. If your only backup is from last night and last night's data was already corrupted, you've faithfully backed up the problem. A few older copies give you something to fall back to.

Then test the restore — really

This is the step everyone skips, and it's the only one that proves the rest worked. Once — just once — take a backup and actually restore it somewhere. Bring the data back, open it, confirm it's all there. After that, you're not hoping anymore; you know.

The shortcut

You can assemble all this by hand — tar, rsync, a cron job, somewhere off-site to put it. Or you can let Server Manager handle it: it makes a backup of your data that you download and keep — off the server — packaged so it knows how to restore itself. When you need it, restoring is a request, not a research project. The point is to make "be able to restore" the easy default instead of the thing you meant to get around to.

Insurance you hope to never use

Backups are the one part of running a server that feels like wasted effort — until the day it's the only thing that matters. That day comes for everyone eventually. Owning your server means owning that safety net too: your data, copied somewhere you control, ready to bring back. Set it up once, and the worst day becomes a bad hour.

If you're just getting started, our guide on what to do with a fresh server lists backups as one of the four things every new server needs. The help guides go deeper when you're ready.