Taking a backup you can actually restore from

Taking a backup you can actually restore from

A backup you can genuinely fall back to is one that captures more than the website files, that leaves the server it came from, and that you have actually restored somewhere and checked before you needed it for real. Most migration failures are not caused by a missing backup; they are caused by a backup that turned out to be incomplete, or one that nobody ever tried to restore. This guide covers all three of those things in order.

Before you start

This picks up from a server you can already reach, either through SSH for a VPS or through cPanel for web hosting. If you have not got that far yet, get access sorted first.

A few things to have in place before you start:

• Enough free disk space to generate a backup. On cPanel, a full backup typically needs up to around 200% of the space your account already uses, for temporary files during generation and for the archive itself. If the account is nearly full, the backup can fail partway through.
• Somewhere to send the backup that is not the server you are backing up. A copy sitting in the same home directory, or on the same disk, is not a backup you can fall back to if that server has a problem.
• Root or WHM-level access if you are on a VPS, since a proper database dump and file archive both need it to preserve permissions correctly.
• Time to actually restore the backup somewhere and check it, not just generate it and assume it is good. This is the step migrations skip, and it is the one that turns a smooth migration into an outage.

Step 1: Write down everything that has to come with you

Before running a single command, list what "the server" actually consists of. Website files and the database are the obvious two, but a full migration backup needs to cover:

• Website files, including anything outside the main web root.
• Every database, not just the one the main site uses.
• Email, if mailboxes are hosted on the same account or server.
• Cron jobs, both the site owner's and root's. These are invisible from most panel screens most of the time, and a missed cron job is one of the most common sources of a migration bug that only shows up days later.
• Environment files and secrets: .env files, API keys and database passwords that live outside version control and will not show up in a Git checkout.
• SSL certificate files, if you are using a paid certificate: the certificate, the private key and the CA bundle.
• DNS zone data, if DNS is managed on the server you are moving away from.

Treat this as a checklist you tick off, not something you trust yourself to remember under time pressure on migration day.

Step 2: Dump every database with the right flags

A file copy of the database's data directory is not a safe way to back up a live database. Use mysqldump, and use it with flags that most quick guides leave out. This command is identical on AlmaLinux 9 and Ubuntu 24.04, since it works against the database server, not the distribution:

mysqldump -u root -p --all-databases --single-transaction --routines --events --triggers --default-character-set=utf8mb4 > full-backup.sql

Here is what each flag actually does, and why it matters:

• --all-databases dumps every database on the server, not just the one you remember to name.
• --single-transaction takes a consistent snapshot of InnoDB tables without locking them, so a live site keeps working while the dump runs. It does nothing for MyISAM tables, which do not support transactions; if the database has MyISAM tables mixed in, use --lock-tables instead for those, accepting that this does briefly lock the site.
• --routines --events --triggers capture stored procedures, scheduled events and triggers. By default mysqldump leaves all three out, and a database that relies on any of them will look like it restored correctly right up until something that depended on a trigger or a scheduled event quietly stops happening.
• --default-character-set=utf8mb4 avoids Unicode characters turning into errors or corrupted text on restore.

The account running this needs at least SELECT on the tables, SHOW VIEW on any views, and TRIGGER on any triggers being dumped; if you are using a restricted database user rather than root, permission errors partway through usually mean one of those is missing.

Once the dump finishes, do not assume a file with a sensible size is a good file. Open it and check it starts with the comment lines mysqldump always writes at the top, then count the INSERT statements against roughly what you expect. A dump that stops halfway through often still produces a file that looks plausible at a glance.

Step 3: Archive the files with permissions intact

A plain tar archive loses ownership detail, access control lists and extended attributes unless you tell it to keep them. Without those, restored files can end up owned by the wrong user, or with permissions that stop a service starting. This command is again the same on AlmaLinux 9 and Ubuntu 24.04:

tar -cpzf backup.tar.gz --acls --xattrs /var/www /etc /home

-p preserves permissions and ownership. --acls and --xattrs preserve access control lists and extended attributes. Leave either out and things that worked on the old server, particularly anything relying on ACLs for shared access, may simply stop working after a restore, with no obvious error to point at why.

If you are copying a live site straight across to a new server rather than working from an archive, rsync with the same intent looks like this:

rsync -e ssh -aAXHPv /var/www root@newserver:/var/www/

The -A and -X flags are the ACL and extended-attribute equivalents; people leave them off the same way they leave --acls off tar, for the same reason: everything appears to have copied fine until something specific breaks later.

Step 4: If your site is on cPanel hosting, use a Full Backup

On shared, reseller or WordPress hosting, cPanel's Backup feature has a Full Backup option that packages the home directory, databases and email together in one archive. When you generate it, you are asked for a destination: Home Directory, Remote FTP, Remote FTP (passive) or Secure Copy (SCP). Choosing Home Directory just leaves the archive on the same disk as the account it backed up, which is not a backup you can fall back to if that account or server has a problem. Choose FTP or SCP and give it a remote server, username and password so the archive actually leaves the server as part of generating it.

Two things worth knowing before you run one:

• Only run one full backup at a time. Starting a second while one is still generating can delay or abort the process.
• A full cPanel backup cannot be restored by you from inside cPanel. Partial restores of files, databases or email forwarders are available in the account, but a full account restore requires WHM-level access. On Hostworld's cPanel hosting, that means opening a support ticket and asking us to run the restore, rather than trying to do it from your own account and ending up with a partial, confusing state.

Once you have downloaded and verified the archive, move it off the server and consider deleting the copy in the account. Leaving it there does two bad things at once: it counts towards your disk usage, and if something happens to that account, your only backup goes with it.

Step 5: If you're on a VPS, take a Virtualizor backup too, but don't rely on it alone

Hostworld VPS customers manage backups through Virtualizor, reached from the client area. A Virtualizor backup plan sets a rotation, for example keeping the two most recent backups and deleting the rest as new ones are taken. That is fine as a rolling safety net, but it is not the same as an independent, verified restore point: if the rotation count is low and something goes wrong three backups ago, that restore point is already gone.

When you do need to restore in Virtualizor, you are asked for the server the backup is on, the directory it is in, and the date of the backup you want. From there you choose between two very different outcomes:

• Restore VPS restores the backup over the existing VPS, overwriting its current disk state.
• Restore to new VPS restores the backup onto a fresh VPS, leaving the original untouched.

Use "restore to new VPS" if you are testing whether a backup is good. Using the first option to "just check" a backup will overwrite the live server you are trying to protect, which is the opposite of what you are trying to do.

Step 6: Get the backup off the server, properly

The point of moving a backup off the server is independence from both the old server and the new one. If both machines have a problem at the same time, which happens during a migration more often than people expect, you need a copy that depends on neither. That can be a local machine, cloud storage, or a separate backup service, but it needs to be somewhere that a fault on either server cannot reach.

For a VPS, an SCP copy to a machine you control is a straightforward way to do this:

scp backup.tar.gz full-backup.sql user@yourlaptop:/backups/

Do this for every file you generated in steps 2 and 3, and for the cron exports and environment files noted in step 1. Get crontab -l for the site's user and sudo crontab -l for root, since both are easy to forget and neither shows up in a file or database backup.

Step 7: Test the restore before you rely on it

A backup that has never been restored is an assumption, not a recovery plan. Test it somewhere isolated, never against the live server: spin up a separate environment with no connection to production, restore into it, and check the result properly rather than glancing at whether files appeared.

A restore test worth trusting checks:

• that the backup can actually be located and accessed when you need it, not just that it exists somewhere
• that files are present and match what you expect
• that the database restores without errors and the data in it looks right
• that applications start and important workflows, like logging in or placing an order, actually work
• how long the whole restore took, since that number matters if you are doing this for real under time pressure

Version mismatches are a real trap here too. A dump taken from one database version can fail to restore cleanly on a different one if it used features that were later deprecated, so test the restore against something close to the version you will actually be moving to, not whatever happened to be available.

On a VPS, "restore to new VPS" in Virtualizor is the mechanism that lets you do this test without touching the live server. Restore behaviour is not identical across every platform, so it is worth confirming that a full restore does what you expect before you are relying on it for real, rather than assuming.

What next

With a backup taken, verified off the server and actually test-restored, you are in a position to move the files, database and configuration across without the migration itself being the risky part. If you have not chosen where you are moving to yet, our VPS guides cover choosing and setting up a VPS, and our London VPS range runs from our own data centre. If anything about the backup or restore process is not behaving as this guide describes, open a support ticket and we will look at it with you before you move anything live.