It’s a good idea to periodically back up your WordPress site. That way, if something unexpected happens, you can recover. You should also back it up prior to major upgrades. Here’s how to backup a WordPress site, quickly and easily, at little to no cost.
When to backup your WordPress site
Ideally you want to backup your WordPress site as frequently as you work on it. If you write every day, back it up every day. If you write once a week, like I tend to do, back it up weekly. That way you don’t lose any of your work in progress. I lost about a month’s worth of content back in 2006 because I wasn’t backing up frequently enough. My database got corrupted, so I restored from my most recent backup, but it was a month old.
You’ll also want to back up your site before any major upgrades. My upgrade to WordPress 5.5 was, to put it mildly, a bit of a disaster. It worked, but it slowed the site down something fierce. Had I thought to make a backup beforehand, I could have reverted and then planned the migration a bit better to preserve my SEO. SEO is your lifeblood, and site speed is a critical factor in it.
I’ve also had two occasions where an upgrade to my Yoast plugin didn’t go well. They fixed the problems eventually, but unless everyone is having the problem, their support tends to blame you. Taking a backup before upgrading Yoast helps you to manage your risk. So, make a backup before you upgrade Yoast to a major new version. Then if it goes sideways, you can revert.
How to backup your WordPress site
There are probably an infinite number of ways to backup your WordPress site. I’ll give you the two that I think are easiest. Which of the two is easiest depends on how much access you have to your system, and your comfort level with Unix commands.
I want to give one caveat. If you use a caching plugin, make sure to read to the end of this post, because caching plugins can sometimes interfere with backups and restores.
The Unix way
If you have shell access to your system, you can back up your WordPress site with this sequence of commands:
tar cvzf filebackup.tgz /var/www
systemctl stop mysql
tar cvzf dbbackup.tgz /var/lib/mysql
systemctl start mysql
These are based on the most common locations for those files, but you’ll need to verify the specifics for your particular host.
Also be aware this method will cause some downtime. It should be brief, but downtime is downtime. For this reason, you may find a plugin preferable.
Using a plugin
If you don’t have shell access, or don’t know where your database and PHP files are located, or just want greater convenience, you can use a plugin instead. I use Duplicator. It gives me a single-file backup and an installation script so I can recover to a new server if I need to, even if WordPress isn’t on the machine.
Simply install Duplicator from the WordPress Plugins widget, then choose Duplicator from your sidebar in the WordPress UI. Navigate to Packages, click Create New, name your backup, click Next, check for warnings, then check the box labeled Yes, then click Build. The build process can take a while, depending on the size of your site and how fast your storage is. My site takes about two minutes. I have fast storage, but I have 20 years’ worth of content.
When it finishes, download the installer and the archive. The installer is archive-specific, so get both. The backup the installer script references is defined about 90 lines into the file. I like to combine the two into a single zip file after I download them, to keep them together. The file can be rather large. In my case, it’s over a gig. Twenty years’ worth of content takes up some space.
After you download the backup, navigate to Packages, check the box next to the backup you just created, then navigate to Bulk Actions, choose Delete from the dropdown, and click Apply. You don’t want to leave backups laying around on your website, because if that file ever gets into the wrong hands, it makes it very easy to steal all your content.
Restoring your backups
To restore a backup, you reverse the process from before. Here’s how.
The Unix way
From a Unix shell, run the following commands:
systemctl stop apache2
tar xvzf filebackup.tgz /var/www
systemctl stop mysql
tar xvzf dbbackup.tgz /var/lib/mysql
systemctl start mysql
systemctl start apache2
It’s pretty quick, if you’re comfortable with the commands and have appropriate access.
From the Duplicator plugin
To restore a backup with Duplicator, upload the installer.php and the matching archive file to your host. Then point your browser at your URL and append installer.php to the end. For example, I would use https://dfarq.homeip.net/installer.php. Adjust it for your site.
Then follow the script. The script will ask for a lot of details, including your database credentials. You can find the username and password for your database in your wp-config.php file. You can either restore to a new database or overwrite the existing database. Using a new database is safer, but can bloat up your database storage. If you don’t know how to go in and delete the old database afterward, choose the option to overwrite the existing one.
My backups take 2-3 minutes to restore. I have fast storage and a ton of content. Your results may vary.
The caveat with caching plugins
If you run a caching plugin, be sure to disable it and then re-enable it after restoring your backup. Otherwise, it’s very likely your front page will load but your individual posts will not.
The location of your caching plugin will vary. I use Simple Cache, which lives in the WordPress Settings menu.
This is a hassle, but cache really speeds up your site, which is good for SEO. I recommend using a caching plugin and putting up with the hassle.
If you have shell access it’s probably better to use mysqldump just the wordpress database itself than to archive /var/lib/mysql entirely, which includes all of your other databases. Something like mysqldump -u USER -p PASSWORD DATABASE | gzip > dbbackup.sql.gz is sufficient. To restore, gunzip < dbbackup.sql.gz | mysql -u USER -p PASSWORD DATABASE. Additionally you have to be careful restoring using either method – if you have added any database tables (perhaps new plugins in wordpress) since the backup, when you restore, the tables will be left intact using both restore methods, and if you then reinstall the plugin it's going to find partially configured table data there and maybe be confused. With the mysqldump method, instead of specifying the database directly you can use –add-drop-database –databases DATABASE, and then omit DATABASE in the restore command; this will make the dump include the database name, and an explicit drop / create database command, in the dump file.