Best practices: backup and restore

One of the oldest features of Seravo’s WordPress hosting and upkeep plans is the daily backup feature. We back up all of our customers’ WordPress sites daily and keep a copy of those backups on our servers for 30 days. On many occasions these backups have saved our customers from extensive damage and extra work.

In this article, we share the best practices for backing up and restoring your site.

Running a backup from the command-line

All of our backup processes happen on the server-side, not within the clients’ WordPress installations. What makes this feature special and extremely valuable to our customers when creating a backup or restoring from one, is that the backup is not dependent on whether WordPress or any other PHP code is working. This backup method also provides added security, because a possible information security breach on the WordPress site doesn’t automatically entail access to backups, limiting the extent of potential damage as the attacker will not be able to directly remove the backups.

The backups include the database and all the files. Regardless of the automation used, the backup can also be run manually by running over SSH connection on the command-line:

$ wp-backup

This command produces a fresh database output in the file /data/db/example.sql and after that copies all files (including the fresh database file) into the folder /data/backups.

Leaving files out from backups

The backup folder itself is of course left out of the backup. If the user wants to leave something else out of backups, the file or directory path can be added in the file /data/backups/exclude.filelist.

Browsing backed-up files

The backup system uses the rdiff-backup command-line program. The data from the latest backup can be found in the /data/backups/data directory. The data from older backups is stored under the directory /data/backups/data/rdiff-backup-data/.

All backups can be listed with the command:

$ rdiff-backup -l /data/backups/data/
Found 30 increments:
 increments.2016-01-26T04:16:46+02:00.dir Tue Jan 26 04:16:46 2016
 increments.2016-01-27T04:20:26+02:00.dir Wed Jan 27 04:20:26 2016
 increments.2016-01-28T04:14:48+02:00.dir Thu Jan 28 04:14:48 2016
 increments.2016-01-29T04:19:06+02:00.dir Fri Jan 29 04:19:06 2016
...
Current mirror: Mon Feb 22 18:53:55 2016

Alternatively you can run the command to see the total disk space of the backup and the file sizes of changes observed in each backup:

$ rdiff-backup --list-increment-sizes /data/backups/data

Time Size Cumulative size 
--------------------------------------
Mon Feb 15 04:02:02 2016 514 KB 237 MB (current mirror)
Sun Feb 14 04:15:02 2016 1.04 MB 238 MB
Sat Feb 13 04:12:45 2016 546 KB 239 MB
Fri Feb 12 04:15:01 2016 917 KB 240 MB 
Thu Feb 11 04:19:14 2016 552 KB 240 MB
Wed Feb 10 03:22:29 2016 691 KB 241 MB
Tue Feb 9 22:12:12 2016 1.10 MB 242 MB

An older backup can be browsed by running rdiff-backup -r 2016-01-26 /data/backups/data ~/restore-2016-01-26, for example.

After the command, the user’s home directory includes a folder named restore-2016-01-26 that includes a /data copy of the folder from that day. The contents of the folder can then be examined and all or some of the files restored.

Restoring a backup

If you ran the command above and the backup from the date in question can be found in folder ~/restore-2016-01-26, you can then restore the desired files with, for example, the cp command. To restore the folder /data/wordpress from the backups you should run:

rm -r /data/wordpress
cp -ra ~/restore-2016-01-26/data/wordpress /data/wordpress

The backup could be restored in the database in this example by running wp db import ~/restore-2016-02-26/db/example.sql.

Similarly, the program wp-backup runs the counterpart of the command above, i.e. the wp db export command. When restoring the backup of the database you should keep in mind that it overwrites the old database. For example, restoring the database in an online store is dangerous because information on orders made after the backup will be deleted .

The database dump /data/db/example.sql contains the whole database, including all table structures and all database rows. Each database row is on separate rows, so it is more handy to compare the database dumps by using the diff command, for example, or in a graphic format with the meld tool.

With the help of a backup, a site can be restored at Seravo, but also anywhere else. The file format of the backup is open and not dependent in any way on the service provider. If you want extra security for your site, it is advisable to copy the /data folder onto a separate computer regularly. The folder includes all files and the database from the time of the latest backup, so with it the WordPress site can be set up again on any server.

Did you lose track of the commands already? We provide expert help.

All of Seravo’s WordPress hosting & upkeep plans include customer support from WordPress experts who are more than happy to help you with backups as well! Take a look at our plans and sign up today to make your WordPress site faster and more secure with Seravo.

PS. When was the last time you backed up your computer or workstation?