Skip to content

my WordPress backups strategy

As mentioned previously, I had a major backups fail with this blog. I’ve now implemented a backups strategy that meets my needs, so I thought I would put together a post documenting what I did.

Step one (1) is local backups of the WordPress database. There are any number of ways to do this, including some well-reviewed plugins like this one. Given that I have shell access to the machine running this blog and full control over things like cron, I figured I would use this as an exercise and write my own little shell script to do the work.

Step two (2) is what I ignored last time, and that’s getting both the database and the wordpress directory (wordpress itself, templates, uploads, etc.) off site. For that I’ve used rsnapshot, which I installed via apt-get on a machine that is NOT the blog host. I decided to put the hourly/daily/weekly/monthly crontab lines in my own personal crontab on the rsnapshot host. One of the reasons for this is that I might decide to make more extensive use of rsnapshot later, and I’d like to keep the WordPress backups separate. The one caveat with doing this is that it assumes access to an SSH key and the¬†SSH_AUTH_SOCK from my tmux session, so if my session dies, backups stop working. Given that I use this machine on a daily basis, that is not a major concern. Still, a better way to do this would be to create a dedicated, unprivileged backups user that would run rsnapshot from its crontab. Then on the blog host, I’d have a matching unprivileged user with access to the target directory for the database backups. I decided against doing that work because both of these machines are fairly restricted to begin with (nobody else has shell login, reasonable update schedule, etc.) and it seemed like overkill for blog backups.

{ 4 } Comments