3. Grab the MySQL Databases

Unfortunately, because of the limitations of shared hosting environments, the filesystem you just pulled in will not contain the MySQL database that is an integral component of many dynamic web services including WordPress. There are two ways around this.

One is to set up a cron job on the hosting server in order to run a database backup tool that then drops the output somewhere where you can access it with the rsync job. The best tool for this is mysqldump [3], which is the main utility for taking backups of MySQL databases. mysqldump can be used for both the backup and restoration of MySQL. You might wish to configure something like this, for instance:

mysqldump -u myuser -p'password' database.msql /home/backup/sql/mydatabase.sql

Alternatively, some CMSs come with a built-in or add-on tool for backing up the database. For instance, WordPress users can install the WP Database Backup plugin to periodically generate and then save a copy of the MySQL database in a table you can access with rsync. You'll have to manually enable local backups as the plugin, by default, expects that you'll be backing up directly to a remote on the cloud. To prevent the accumulation of large amounts of storage that will count against your storage limit, I also limited the amount of MySQL backups that can be stored to two.

4. Script and Automate

Now that you have tested out the two rsync pulls required, it's time to put your commands into a Bash script and set it up in cron to run automatically. The beauty of rsync is that, unlike full backups, it only moves in the changes to the filesystem between runs. That means less unnecessary data transfer – which is especially important if you're mirroring that backup from your local to an off-site location such as a public cloud.

I built two directories within a backup folder that I created to host the backups on my NAS (which, in turn, mirrors the copies up to another cloud). I called these /files/ and /db/ and put the filesystem and MySQL backups into these subfolders respectively. You can set up the job to run however often you want.

To build a master backup script you can either run a script that calls the other scripts, or you can just call all the commands from one script. For this demonstration, I have chosen the latter approach (Listing 1).

#!/bin/bash
rsync -arvz -e 'ssh -p 12345' yourhost@123.456.789.71:/home/youruser/public_html /backups/hosting/website1/files
rsync -arvz -e 'ssh -p 12345' yourhost@123.456.789.71:/home/youruser/backups/mysql/ /backups/hosting/website1/mysql
Exit

If you are backing up several websites, you can add the sites sequentially. You can increase the verbosity by adding up to three vs. If you need to troubleshoot the script from a monitored terminal, then I recommend choosing this approach.

Conclusion

After you have the basic backup pull working, then you may wish to create weekly and monthly snapshots as well as daily ones. To achieve this, you can create /weekly and /monthly folders and then run rsync jobs between the daily and monthly snapshots to those (doing this locally saves time). Just make sure that the cron jobs are set to run at the appropriate interval.

As a final note: this backup still will not capture everything in cPanel, although it might be useful to roll back changes to, say, a WordPress theme. If you want to do the former, then cPanel has a native backup tool that creates full backups of the hosting environment. It's a good idea to do both (and evaluate what MSPs and third-party tools can achieve).

You can use the technique described in this article to create local backup copies of your shared hosting environment onto a Linux host using only rsync, a few cron jobs, and, if preferred, a WordPress plugin.