Recently at work we were about to be handed the task of making sure that all of the client sites were backed up. For a while, some other people we handling that task, but it was being handed to the developers since we are the ones that actually maintain the websites. There are about 30 sites we are managing so that is a lot to backup.
Before we could really tackle the task of handling the backups we had to make a lot of considerations. The first was understanding exactly what we needed to backup. Next we had to find the best method for doing the backups themselves because it does take a lot of time. We also needed to know what sort of controls and monitoring we needed to have over these jobs.
Why is this thing so slow?
The internet at the office isn’t the greatest. It is an old T1 connection that isn’t the fastest but it gets the job done. Originally the jobs were being performed by using FTP and downloading all the files. That is obviously a problem for several reasons. Doing that many FTP downloads takes a lot of time on our bandwidth, secondly unless you automate the backup, it will take time to go to each site and download the files. There is also the issue of what happens if the power goes out, or the internet goes down that night. It wouldn’t be unheard of to have that many connections happening for a length of time taking down the network temporarily, even for a few seconds.
The Options We Looked At
There were several options we were considering when we talked about this process. First we considered writing a script for each site to do the backups and using a cron to run them. While that is probably the best idea especially from a power user standpoint, I’m the only one there with the level of backend server administration experience. My concern was that others wouldn’t be able to fix an issue if I wasn’t around (bus plan thinking). Next we discussed doing the backups internally via FTP or a backup program, but as I mentioned before there were far too many issues facing that type of backup. Not only that, keeping backup copies locally really doesn’t help you in the event of a fire unless they are backed up to a medium and stored in a fire safe.
The final option we looked at was using a plugin since the sites we build are on the WordPress platform. Using a plugin would make it easy for anyone to configure as well as troubleshoot. We looked into several but finally decided on using WPBackup Pro. While it isn’t the cheapest plugin, it certainly has a lot of worthwhile features.
What We Liked About WPBackup Pro
One of the things we really liked about the plugin was that it allows you to backup to cloud storage providers like Dropbox and Google Drive. We use Google for emails and thus we have storage with them as well. What makes it so perfect is that it centralizes the backups in a place where we have control over access, and we know that it is relatively secure, plus far more redundant than any local server we have. Scheduling the backups is really easy to do as well, you can literally run a Job Wizard and backkup in minutes. The Google Drive setup does take a little of figuring out just because the API requires a few extra steps to connect, but once you do it one time, each new time goes faster and faster.
The setup we followed uses these principals:
- Files should be kept for 90 days. This gives us three months of files. In the event of an unknown malware infection it gives us enough of a time window to hopefully restore from a version before the infection.
- Databases should be backed up nightly. This helps in situations where data becomes corrupted. Since the database gets updated a lot, it makes sense to back it up a lot.
- Site files should be backed up weekly. They don’t change very often so there isn’t a point in doing it frequently.
- All plugins, and upper level directories should be backed up. Sometimes there are directories above the WordPress install that we use, so we should back those up.
- Alerts should be sent whether the job succeeds or not. This is something I learned in IT. If you are only getting alerts if the job fails, you have no way to know if the job is stuck unless you look. While that might be easy in a centralized backup application, you don’t have that with 30 client websites. This allows us to count the emails really quickly and see if we have our 30 successes from the previous day.
- TarGZ should be used as much as possible to limit filesize.
- Backups should be staggered to limit server load. Each job is given a 5 minute window (unless it needs longer) so that there are never two jobs overlapping.
All in all after setting this up it seems to be working really well. There were a few hiccups along the way where a job or two didn’t run, but after resetting the job it seemed to go away. This was definitely a great investment because of the amount of time it saves as well as how easy it is for anyone to go in a do a backup. I’m glad that we didn’t go the FTP commando, or scripted way. If you manage a lot of sites I highly recommend checking the WPBackup Pro plugin out.