Order a server

Check that your backup can be restored

A backup you've never restored is a hope, not a plan. Run a restore drill on a copy, check the files, database and app really work, time it, then clean up.

updated · 4 min read

To find out whether a backup works, restore it somewhere that isn't your live server and check that the result runs, not just that the restore finished. Do it now, while nothing is broken, and again every few months or after a big change.

A drill answers three questions: does the backup contain everything you need, can you get it back, and how long does that take? This page shows how, for Rack4's off-site backups and for backups you run yourself.

Pick what you're testing

Write down the one thing you'd most hate to lose, and test that first. Usually it's one of:

  • The whole server (with off-site backups): restore into a new server.
  • A database: restore a dump into a scratch database.
  • Files (uploads, a website, config): restore into a scratch folder.

Never test by restoring over the live server or the live database. "Restore to the same server" in the panel replaces the server's disk; that's for real recoveries, not drills.

Off-site backups: restore into a new server

  1. On the server's Backups tab, choose new server… next to a recent backup. Pick a plan whose disk is at least as big as the backup's, and pay; it's billed like any server, so delete it when the drill is over.

  2. When it's built, it boots as a copy of the original, with the original's files and settings and its own new IP address.

  3. Straight away, stop anything that acts on the outside world. The copy has the original's cron jobs, timers, queue workers and app settings, so it may send emails, process payments, call webhooks or post to chat as if it were the live server. Log in and stop them:

    bash
    systemctl list-timers
crontab -l
systemctl stop cron   # crond on AlmaLinux, Rocky Linux and Fedora

    and systemctl stop any worker or app service you know sends things. Don't point DNS at the copy.

  4. Check it, as in Check the result below, and time how long the whole restore took.

  5. Delete the test server when you're done, so it stops costing money and can't send anything later.

On 31 October 2026 we did exactly this with one of our own servers: a 23.4 GB backup restored into a new server in about 25 minutes. A bigger disk takes longer; your own drill is the number to trust.

Your own backups: restore into a scratch place

Restore onto the same server, but somewhere new: never over the files or database in use.

Files. Restore into a scratch folder, then compare it with the live copy. For a tar archive:

bash
mkdir /root/restore-test
tar -xzf /root/site-backup.tar.gz -C /root/restore-test
diff -rq /var/www/site /root/restore-test/var/www/site

No output from diff means the restored files match the live ones exactly. A line per file means they differ: expected for files that changed since the backup, worrying for ones that didn't. With Borg or restic, use their own restore command with a target folder (borg extract from inside the folder, restic restore latest --target /root/restore-test), then compare the same way.

A database. Load the dump into a new, empty database with a different name, then compare it with the live one. For MariaDB or MySQL, from a dump of one database (made with mariadb-dump --single-transaction shop):

bash
mariadb -e "CREATE DATABASE restore_test"
mariadb restore_test < /var/backups/db/shop.sql
mariadb -N -e "SELECT COUNT(*) FROM restore_test.orders; SELECT COUNT(*) FROM shop.orders"

The counts should match, give or take what was written since the dump. A dump made with --databases or --all-databases contains CREATE DATABASE and USE lines and would load into the original database instead, so restore those on a test server, not the live one. For PostgreSQL: sudo -u postgres createdb restore_test and pg_restore -d restore_test shop.dump.

When you're done, remove the scratch copies: DROP DATABASE restore_test; and rm -rf /root/restore-test.

Check the result

"The restore finished" isn't the test. Check that you'd be back in business:

  • Files: the newest ones you expect are there, with the right owners (ls -l).
  • Database: row counts match, and the newest rows are as recent as the backup should be.
  • The app: on a restored server, open it through a hosts-file override (see Move to a larger Rack4 server), log in, and load a page that reads from the database.
  • Secrets: the restore includes, or you can find, what the app needs to start: .env files, API keys, TLS certificates, the encryption key for your backups.

Write it down

Keep a short note next to your backup setup:

  • the date, which backup you restored, and where to;
  • how long it took, start to working app;
  • anything missing or awkward, and what you changed because of it.

That note is what you'll want on the day you need it for real. For one-click apps, also check the app's own upgrade notes before restoring an old backup into a newer version: Update a one-click app covers that.

We tested the file and database steps on this page on Rack4 servers running Debian 13 (MariaDB 11.8) on 6 November 2026. The off-site restore timing is from our test of 31 October 2026, described on Off-site backups.

Ready when you are

Order a server