Nearly 14 years ago today, some of the greatest advice in the history of online publishing was dispensed.
Twas May of 1999 when the chart-topping modern day philosopher Terius Gray (better known by his apt stage name ‘Juvenile’), applied his lyrical genius to the Internet, imploring website owners everywhere to “back that thang up.“
For those of you not up on the latest slang definitions, “thang,” of course, means “website.”
Despite his hyperbole, the truth is that you don’t need to be a “big, fine woman” or refer to Mr. Gray as “big daddy” to enjoy the benefits of one of the smartest decisions you’ll ever make with your website.
You just need to be a serious website owner with a sound disaster recovery strategy, the first step of which is always having backups you can count on (and control).
The best way to backup your website?
So what is the best way to back your thang up?
When it comes to WordPress, there are two common backup methods relied on by most site owners:
- A WordPress plugin.
- Server backups provided by a host or cPanel.
These methods work okay … for the most part. However, there are drawbacks.
First, plugins are PHP-based, which is an inefficient and unreliable way to get backups. These plugins, via PHP, attempt to communicate with the server in a way that most secure Linux servers won’t allow or make very difficult … because a hacker could do the same thing.
Because of this, backup plugins have to rely on fallback methods that often lead to a high failure rate. Furthermore, they generally use WordPress’ scheduler versus the Linux scheduler which can lead to reliability issues as well. This leads to a high failure rate.
Contrast that with how we generate our daily backups over at Synthesis, for example. We do everything at the Linux level and have maybe one failure every two years.
(Don’t worry if words like “PHP” and “Linux” are freaking you out, we’re getting to the good stuff …)
The second drawback to the plugin backup method is that the backups are stored inside of the wp-content folder. This means that if your site goes down (or experiences data corruption), your backups are going to be unavailable or corrupted as well.
As for host-provided backups, they are certainly a nice benefit. There is peace of mind in knowing that your host takes a daily backup of your site and stores a week’s worth of them.
Most managed WordPress hosts provide this, and it should be a prerequisite of any premium host you consider.
It should also be a prerequisite that your host stores these backups in a separate facility from its servers, otherwise there is a single point of failure that could down your site and take your backups with it.
But what if you hire a developer who screws something up that tanks your site, and you desperately need to access your backup files?
Or what if you get hacked and files all through your site get corrupted?
You likely have to submit a support ticket and wait for help. Every minute you’re waiting represent dollars that you’re losing, and even the most responsive support staff won’t always be able to respond to a restore request immediately.
There is a better way …
Both of these backups options — plugin and host-provided — are nice fail-safes, but they are far from optimal.
We realized this at Synthesis, which is why we developed our Personal Backups for S3 program.
This is a Linux-level process (not PHP) that backs up your entire site, and pushes it to your Amazon S3 account daily.
What does this mean for you?
It means that Synthesis customers who configure their own Personal Backups have the peace of mind of daily backups that are stored separately from their live site files. They can access these backups anytime they want to or, more importantly, need to.
And we don’t even make you call us “big daddy” to get access to Personal Backups for S3. It is free to all Synthesis customers, and it takes just five minutes to set up via the Software Monitor plugin in the WP dashboard.
4 disaster recovery best practices
Backing your website up is essential. And for the truly serious site owner, having immediate personal access to your backups is doubly essential.
But that’s only the first step in having a solid disaster recovery plan.
Let’s run down four essential disaster recovery best practices.
1. Back your thang up.
At this point, you understand that it would be downright foolish not to backup your site on a regular basis. Moreover, you need to find a reliable way for your backups to be in your control.
Furthermore, even if you do store backups in a reliable place (like Amazon S3), you should download a known working backup of the site to your own hard drive, so you possess the ultimate fail-safe.
2. Restore as a last resort.
A common error when it comes to disaster recovery is jumping first to what should be the last resort.
Assuming that, at a minimum, your host is keeping daily backups on hand for you, you’re rarely more than 24 hours removed from a clean version of your site. That’s great to have as a fallback. But make sure it’s considered just that: a fallback.
When you do a complete site restore, you lose anything generated since the backup was taken. This could be posts, edits, comments, etc. Why go to such extreme lengths when most issues can fixed simply by replacing one file?
3. Think “replace” rather than restore.
If you or your developer bungles your functions.php file and it whitescreens the site, you don’t need to restore your site. You just need to replace the bungled functions.php file with a known good one.
You can request this specific action of your host, but for immediate results you can access your personal backups, locate the functions.php file from a date you know that it was working, and then simply overwrite the live file with the backup file via FTP.
Voila! Your site is working again, and you lost nothing except a few minutes of self-inflicted downtime, which you minimized by having a good disaster recovery strategy.
4. Prevent disasters in the first place.
The best disaster recovery plan of all is — of course — to prevent disasters in the first place.
As Ben Franklin said, “An ounce of prevention is worth a pound of cure.”
There are several ways to do this:
First, have your login info for essential accounts perpetually at the ready. That means filling out this WP Site Owner’s Emergency Checklist.
Second, don’t edit WordPress files via the dashboard editor. In fact, a hosting company that has your best interests at heart will disable the dashboard editor by default.
Do edit using FTP and a text editor. If you are unfamiliar with FTP, or if it seems intimidating, this tutorial will be very useful. The major benefit of a text editor is that you can immediately Edit/Undo changes. This simple function can bring a downed site back in a snap.
Third, back up individual files before you edit them.
If you want to protect yourself against a functions.php disaster, copy the file onto your hard drive before editing. Then, if something goes awry, you can immediately upload the working copy right from your desktop in a matter of seconds to get your site back.
Do this with any file you are editing. It takes a matter of seconds to back up a file. Why wouldn’t you?
Over to you …
In closing, allow me to harken back once more to the wisdom of Mr. Terius “Juvenile” Grey, who asked a most appropriate rhetorical question of his listeners that I will now pose to you:
Girl, who is you playing with? Back that thang up!
Girl, boy, it doesn’t matter. This is far from a gender-specific issue.
Any site owner is playing needless, negligent games with his or her site’s future if the thang is not being backed up daily, and if there isn’t a solid disaster recovery plan in place.
So back your website up, and know exactly how you’ll use it when you need it. Doing so will save you energy, time, and (most importantly) cash money.