WordPress Web Site Disaster Recovery On The Cheap

Are you hosting a business-critical WordPress website on a shared hosting provider?

If so, you probably have experienced a website outage – something that has caused material impact to your cash flow.

And if you haven’t, it is only a matter of time before you do.

Why is this?

Because all hosting providers have outages. That includes the big ones and the small ones.

What sort of outages can happen? Human error, bad updates, expired credit cards, physical hardware problems, disasters like storms and hurricanes, and lastly: Internet fiber cuts.

Nobody is immune from human mistakes, and nobody is immune from Internet fiber cuts.

Even the big players like Microsoft Azure and Amazon can’t guarantee a backhoe won’t rip out essential fiber circuits – which cripples their data center Internet connectivity – and can mean an outage for your website.

Does this even matter for your website?

That depends.

What is the revenue that you derive from your website on a daily basis? (Whether that be leads, physical sales, affiliate commissions, etc.)

Once you are making $100 or more per day from your website – it makes no sense to suffer an outage.

Do you make big money the week of black friday through online sales? It only makes sense to have a backup option. Black Friday (and Cyber Monday) is an opportunity for sales measured in HOURS. Your website cannot be down for even 5 minutes without jeopardizing revenue.

Hopefully, I’ve convinced you this is important.

Now, let’s talk about what we can do about this.

Considerations for Rapid Website Recovery

Should you upgrade your website hosting to the next level plan?

No – that won’t help. As we explained above, all hosting providers have outages. Even the Triple Platinum Premium Elite Turbo plan. VPS hosting, dedicated physical servers, and all those other more expensive options are no solution – they can fall victim to all those same outages.

And whatever SLA they are offering you will not compensate you for the lost revenue.

What you really want to do is take a page from the hardware redundancy handbook.

You might have heard of RAID arrays. Originally, it was an acronym standing for Redundant Array of Inexpensive Disks (RAID).

It’s a way to take cheap, commodity hard drives and combine them to achieve otherwise unheard of uptime and reliability.

We need something similar:

a Redunant Array of Inexpensive Hosts (RAIH).

You want redundant, inexpensive hosting providers – that you can redirect website traffic to in minutes.

In minutes. Not hours, and not days.

I’m going to explain how to do that here.

The Strategy for Inexpensive WordPress Disaster Recovery

This strategy is very simple.

We’ll use two cheap shared hosting providers to ensure our website is nearly always up.

This is easier said than done – especially if you lack a big budget for technical operations.

So, I’m going to explain to you all the key concepts, and how to perform them.

There are three key elements to this strategy.

You must have, in advance of any possible outage, the following:

  • Reasonably recent, full backups of your WordPress website. These should be available outside of your hosting account. This means a full backup of the database, the file uploads (wp-content/uploads) and a full backup of the WordPress files- including themes, customizations, plugins, etc.

    What does reasonably recent mean? How often are there major updates on your website? Is a week or two week old version of your website better than NO website? Probably yes.

  • Two or more “dissimilar” cheap shared hosting providers. What does dissimilar mean? It means not alike, different. You don’t want two east coast hosting providers, for example. One big winter storm could take down both. You want east coast and west coast. A2 Hosting’s Arizona data center and IONOS (1&1) Pennsylvania data center or Siteground‘s Chicago data center, Blue Host‘s Utah data center are some possible combinations. And – these two services need to be Linux based and provide secure shell access “SSH access” – for reasons we’ll describe fully soon.

  • Cloudflare as a point of indirection. Cloudflare’s main reason for existence is to provide cached content to your users quicker (a so-called Content Delivery Network or CDN) – and to do that they take over your DNS entries. And a bonus side effect for us – this will allow you to rapidly and easily re-route traffic from one hosting provider to another – possibly in minutes. Cloudflare also brings a lot of other benefits – and it’s FREE. FREE as in $0.

  • Let’s dive into specifics. First step, we must have reasonably recent backups.

    You Do Have Backups, Right?

    Do you have full, recent backups of this money making, business critical WordPress site?

    If not, you should.

    And I mean backups that are within easy reach – not the automatic backups from the hosting provider.

    If it’s critical, you need your own backups, on your own disks or hardware.

    Not backups that exist only on your hosting provider’s cPanel.

    Why?

    Because if the hosting provider is down how will you access their backups?

    You won’t.

    So, use this process to create your own backups on a recurring basis. Make it easy and relatively painless, so it gets done as it needs to.

    There are 3rd parties that provide backup services for WordPress (via Plugins, etc.). These might not be a bad solution – but I don’t know – because I don’t use them.

    Instead, I use the tried and true solutions that Linux system administrators have relied on for years, and years.

    Why? Because they are cheap, they are reliable, they offer high performance (for both backup AND restore) and I have complete and total control.

    This ensures that I can get to my critical data without having to go through any middle men.
    cPanel access is useful for many things, but not for easy and fast backup and restore.

    And as such, this is our first requirement for our cheap web hosting provider: they must offer Linux based shared hosting (as opposed to Windows – which is too expensive anyways), and they must allow “SSH Access”.

    Secure Shell, or SSH, basically means Linux command line access. And with that you can run powerful and free tools with ease.

    How To Backup Your WordPress Database

    To have a full backup of your WordPress site, you need the complete set of files (PHP files, configuration files, user uploads, themes, etc.) and a backup of the database.

    Let’s tackle the database first.

    I’ll assume you are using MySQL as the database.

    As it turns out, if you have SSH access to your server you can easily run the attractively named “mysqldump” command to get a complete, full fidelity backup of your MySQL database at any time.

    This backup file will have every table, every view, and every row and column of data.

    What’s even better, you can use this single (but large) file to make a complete new copy of your database on another MySQL Server. On any MySQL server – like that from a secondary hosting provider!

    To be clear, you need to “SSH” into the web server to run these commands.

    Here’s the mysqldump command:

    mysqldump -hlocalhost -udatabase_user -puser_password database_name > database-backup.sql
    

    The above command will backup a database named “database_name”, using a user “database_user” (with password “user_password”) and output it to a file named database-backup.sql.

    We’re going to use a better version of that simple command in a bash script – which is an easy way to run a bunch of commands in sequence.

    We need to create a script file named databasebackup.sh.

    To create the script file, run these commands.

    touch databasebackup.sh 
    chmod +x databasebackup.sh
    

    You can then use “vi” or “nano” to add the contents of the file.

    The Nano text editor will be simplest for a beginner.

    Run nano using “nano databasebackup.sh”.

    Type the following lines, and replace the values as instructed below, then use Ctrl+O to update the file.

    #!/bin/bash
    now=`date +%Y%m%d-%s`
    echo "Date is $now"
    #
    filename="dbbackup-website-$now.sql"
    echo "Dumping $filename..."
    #Replace "localhost" with the database server name
    #Replace "user" with the database user name
    #Replace "password" with the database user password
    #Replace "database_name" with the actual name of your WordPress database
    mysqldump -hlocalhost -uuser -ppassword database_name > $filename
    tail -1 $filename
    

    What does this script do?

    it will dynamically create a unique file name for our database backup – it will incorporate a date/time stamp in the name.

    It will then create that uniquely named backup file.

    We’ll also output the final line of backup output – so we can be sure the job ran correctly.

    To run the file:

    ./databasebackup.sh
    

    The resulting backup file may be large, but it contains everything you need to recreate your database and the data within.

    You could also backup multiple databases using the script. This is helpful for those of us with mighty web empires – it’s very easy to run a dozen websites or more on one hosting account.

    So, we’ve now effectively turned our database into a file (that backup file), and we can treat it just like all the other files that make up WordPress.

    By the way, if you needed to restore your database backup – you can easily do that with PhpMyAdmin (which every hosting provider gives you) and by simply using the “Import” function.

    Or, you can use the mysql command line – which is less prone to errors and timeouts if your database is large.

    And that’s also how this is better than relying on your host’s automatic backups. It’s a file YOU can copy, and access anytime you need it.

    So, let’s talk about that next.

    How To Backup Your WordPress Files

    Your WordPress installation consists of many types of files – PHP files, configuration files like .htaccess, HTML files, and much more.

    It also includes all those photos and pictures you (or your users) have uploaded to the website.

    Therefore, you should have a complete backup copy of all of these, at all times. They are an integral part of your website. It’s also very important that the complete nested directory structure of all these files be maintained as well.

    Remember that in the previous section we created a backup file for your database.

    So let’s just handle these files in the easiest way possible.

    We’re going to use a super-powerful linux command called named “rsync”.

    We’ll use this to create fast and efficient copies of the files (and directory structure) that makes up your website.

    Greatest program ever? rsync

    For anyone that has ever had to deal with copying or moving many files around; they know it can be a challenge.

    Copying files can be slow, it can timeout, you may have to restart, you may forget what was already copied. You can copy things to the wrong location. You may have to copy nested folders 8 levels deep. You may be re-copying things already copied, and so on. It’s a pain.

    rsync makes all that go away.

    It will quickly and efficiently synchronize two sets of files, on two different machines.

    In this case, we’re going to sync down (1 way sync) a complete copy of the file structure from your web host to your local machine (Mac or Linux – with Mac specifically being demonstrated here).

    You will then have a complete copy of the files on your local machine.

    Why rsync?

    It’s smart – it only copies files that have changed. If it dies mid-stream (which is rare – more likely you’ll lose your Internet connection) – you can restart it and you aren’t doing “re-work”.

    It’s fast – it compresses files automatically on the fly to get the best performance.

    It’s recursive – you can point it to a root directory and with the right command flags it will perfectly replicate a file structure and files. It will handle directories nested dozens or hundreds of levels deep.

    It’s secure, because the files are copied over an encrypted tunnel.

    Did I mention it’s fast? That’s really one of its strong points.

    Rsync easily uses SSH to copy files between two machines. And that’s another reason we needed that SSH access on our hosting provider.

    You could use FTP / SFTP to move files as well – but dealing with directory structures is a lot of work. For copying files and retaining a folder structure, rsync is just plain better.

    Here’s an example of an rsync command:

    (Explain rsync here – Coming soon!)

    And guess what – once you have the files local, it’s just as easy to push them elsewhere – using all those great rsync features – fast, efficient, recursive, etc.

    So now that we have a backup (a complete set of files, including database backup) from our web host, we could easily use rsync (in the opposite direction) to push those files to a new or different host.

    There is one more aspect of this we need to discuss.

    A backup job that isn’t run is worthless.

    Running a backup has to be easy, or you won’t do it.

    It can be automated – but it can’t be too automated.

    What I mean by that is we don’t want our backup job silently failing, and leaving us exposed with no backups.

    For me personally, I run the backup job myself – when I need to. But it’s quick and easy to do – so it’s not a pain. And I always know that I have good backups.

    Is this too much drudgery for you? It’s not for me – because there is serious money involved with my websites. It’s worth my time.

    So, let’s talk about how you can make running backups quick and easy (and secure.)

    SSH Key Authentication – Passwordless, but Secure

    When you run rsync with a remote machine as the source or target, you’ll have to login, or authenticate.

    This is the process of proving who you are – so you can be allowed to login.

    The most common form of authentication is the user and password combination we all know and love.

    But SSH and linux offer a better solution – key authentication.[1]

    This uses cryptographically generated values to uniquely and securely identify a user.

    And, it’s very secure.

    But best of all for our purposes, we can use this to turn running backups into a very easy job – because you won’t have to enter a clunky password.

    We’ll make it so easy you’ll be able to run backups before you make any big changes to your site – before you upgrade WordPress, before you upgrade plugins, before that big storm approaches, etc.

    Enough about the benefits – let’s do this.

    SSH key authentication uses cryptographic keys that are asymmetric. There is a public key and a private key – which together are a key pair.

    Long story short, the public key needs to be on the web server, and the private key needs to be securely stored in the .ssh subdirectory of your home directory.

    Follow these detailed steps to setup SSH:

    Now, if you did all that correctly, you’ll be able to run your rsync commands without having to enter passwords.

    Let’s string this all together into a single bash script.

    BASH Scripting – Make It Repeatable

    Who can remember all these complicated commands? Certainly not me, That’s why I take anything I do on a regular basis and turn it into a bash script.

    A bash script lets you string together multiple linux commands into one easy to use file that you can run from the command line.

    For example, here’s my websitebackup.sh bash file.

    This creates a complete, full fidelity backup of multiple websites that I host. It gives me everything I need to restore to another provider.

    (File example here – coming soon!)

    You can see from the comments that it does several things.

    First, we SSH into the remote server, and run that script we created to backup the database files. After that has run, we’ve got the .sql backup files sitting on remote disk – one file per website database.

    Then, we use that amazing rsync command to copy down all files changed since last time – and that includes those newly created database backup files.

    Remember, rsync is fast, and intelligent. It copies what it needs to – and skips what is already there.

    Lastly, we remote back into the server and remove the backup SQL files – because it’s not secure to leave un-necessary database backups laying around.

    Once we run the command, we have a full backup locally.

    Do You Have a Backup of Your Backups?

    Having a backup of your backups is also a best practice.

    I use Apple’s Time Machine backups to regularly backup the MacOS hard drive – and that includes my website backups.

    That gives me an easy way to have days, weeks, or months worth of archival backups.

    But perhaps more importantly, it’s another copy of my critical data that I control and have access to.

    Just in case my laptop gets lost, stolen, or the SSD fails.

    Some would consider this part overkill – and maybe it is. Because truth be told, there’s also copies of the data on the hosting providers.

    But it is best practice.

    Again, you have to decide – how important is this to you or your business?

    Dissimilar Shared Hosting Providers

    Now that we have our own backups of our business critical, valuable data, let’s talk about the dissimilar shared hosting providers.

    We already mentioned that you want Linux hosting.

    Why?

    Linux is the best hosting platform for WordPress.

    It’s cheaper than Windows hosting, it’s great for WordPress, and it has powerful tools – like ssh and rsync.

    And for most purposes shared hosting (as opposed to dedicated servers or what is commonly called a “VPS”) is good enough, and cost efficient.

    Shared hosting means your website is one of dozens, hundreds, or thousands on the same server.

    That’s why shared hosting is the cheapest option. It’s shared across many customers.

    Dedicated servers and Virtual Private Server (VPS) hosting give you your own server – for your exclusive use. This can offer great performance, privacy, and very precise control. It makes total sense for some uses. But it is also more expensive – significantly so.

    And frankly, if your web site is a WordPress based affiliate sales web site, a small business marketing or lead generation web site, or small time e-commerce storefront – dedicated hosting is probably overkill.

    So, shared hosting is the way to go for the average WordPress site. It’s cheap and pretty good.

    And again, remember that those fancy, expensive dedicated hosts or VPS systems can still have outages. Just like the little guys. So, why spend the extra money when it really won’t make a difference?

    Let’s now talk about why you want dissimilar hosting providers.

    I said “dissimilar” means not alike, or different.

    You want 2 shared hosting providers with different data centers, in different parts of the country.

    Examples: Texas and Chicago, Virginia and Arizona, etc.

    You’ll find that some of these potential outages can impact an entire geographical region.

    You don’t want two hosting accounts with the same provider, in the same data center – that’s not enough diversity to address the risk.

    I’d setup two providers with different contract expirations too, just to be on the safe side.

    But, on the other hand, you don’t want two hosts that are so wildly different it is a pain to manage.

    I’d look for two hosting providers that use cPanel or similar access. That way all the administrative concepts will be the same, or close enough that it won’t be a pain to manage.

    And lastly, they must both use Apache and MySQL – this way your database backup file and any web server related configuration files (.htaccess, etc.) should be compatible across the two.

    Don’t intermingle Apache with NGINX (another kind of web server) or MySQL with PostgreSQL. It’s not going to work.

    It’s OK to use an Apache compatible server like LiteSpeed though.

    The only caveat to this plan is that there *might* still be small, but important, differences in the .htaccess files used on each provider.

    You’ll have to sort that out in advance, and keep a relevant copy of the htaccess file for each – so you can switch easily.

    For example, my A2 hosting .htaccess file has some LiteSpeed server specific configuration – so I have a working copy of that file named htaccess.a2.

    My Ionos account uses the htaccess.ionos file – which doesn’t have the litespeed specific config.

    To switch from one to the other, you simply use the “cp” command to copy the desired file to “.htaccess”.

    NOTE: If you use Wordfence security’s plugin you will also have to handle the .user.ini and wordfence-waf.php file in a similar fashion – as these both contain hard-coded paths to important Wordfence related files.

    NOTE: If you have problems uploading media attachments, you may have to go to “Settings”, “Media”, and set the file uploads location to wp-content/uploads.

    Lastly, look for providers that have a free SSL option. For small websites, it is more important that you use HTTPS and have an SSL certificate – but nobody particularly cares whether it is free SSL certificate or one of those fancy $80/year SSL certificates. So why waste the money?

    Once you have your two providers chosen – you really, really should set up the 2nd hosting provider in advance. It needs to be ready to go at a moment’s notice.

    The only caveat to this, is that you will likely have to temporarily route traffic to the new host provider for the various “AutoSSL” and free SSL registrations to work properly. So, this does take a little bit of planning. You can do this during a lull in your website activity – like Sunday mornings.

    But, it’s worth the effort.

    After all, the whole point is to be able to rapidly get your website up and running again

    Don’t fumble around with adding a hosting account, logging in, copying files, installing SSL certificates, etc. for 8 hours while you are losing sales. Get it going in advance.

    So, you’ll need to setup both hosts, in advance. But if there are two copies of your website running, how does the Internet know which one to use?

    When a user pulls up your website, which one will they be seeing?

    It’s DNS records, of course, but let’s make it easy to change.

    We’ll talk about using Cloudflare CDN to do that next.

    Cloudflare Content Delivery Network (CDN)

    Cloudflare’s CDN service is amazing – it helps keep load off your server, gives your users better performance (quicker page loads), and helps make your website more resilient in the face of attacks.

    And they also offer a very useful FREE plan. That’s right – FREE ($0).

    Cloudflare’s CDN is a reverse proxy system. They have a network of servers world wide, and from these locations they can serve cached content (pages, text, images, videos) much more quickly to your users. Cloudflare’s servers sit “in front” of your web server.

    There are several reasons for this, but the important point is that when you use Cloudflare CDN with your website, it’s actually Cloudflare that decides what “origin server” the website content is coming from.

    And this gives us an easy way to change incoming traffic from flowing to one hosting provider or the other.

    In minutes.

    As you might expect, this is done via DNS records. And because Cloudflare is a reverse proxy system, you actually set up their DNS name servers for your domain.

    (Example of how to setup Cloudflare, and DNS record change – Coming soon!).

    Technically, you can re-point your traffic using any DNS system. But I like using Cloudflare because it’s free, they are a huge (and awesome) company, and it means my DNS entries aren’t tied to any one of those smaller providers.

    And by the way, even if you take no other advice in this article – use Cloudflare anyway. It really does make a big performance difference and is dead simple to setup. For FREE.

    Let’s Put It All Together

    Now let’s put it all together into an example.

    Let’s say we are actively using Hosting Provider A to serve our website.

    All is going well. The site is up – and you are making money.

    We’ve got recent backups, because we know having backups that are relatively recent is important.

    And then, something happens.

    Provider A performs a server OS update – and it’s not good. It doesn’t take the website down, but it makes it so slow that you are losing 90% or more of your traffic.

    You call support. They have you reboot your Wifi router, and all the other ridiculous things first level support does.

    They escalate to the next level of support – but still no resolution. And hours later, you are still waiting.

    But at the end of all that, let’s say it’s not a simple problem, and they can’t give you an ETA to resolve. And you may be down for hours, or days.

    That’s when we put our plans into action.

    Here’s what you would do.

    You’d take the latest backup copy of the MySQL database and restore it to Provider B. This ensures the latest posts, pages, comments, and more are in place.

    You’d then run the rsync command in “reverse” to copy the latest backup files from the backup copy to Provider B. This will ensure all the latest file uploads, images, etc are in place.

    This also ensures that the Provider B website has any new plugins, theme changes, etc. that you have implemented since.

    But it’s also important to note that because of the magic of rsync this will be a differential copy – meaning it’s only going to copy what is new or changed. And it’s going to be as fast and efficient as possible.

    Then, you’d set your local hosts file to point to the IP of the Provider B web server. This lets you do a quick sanity check to ensure the website looks and works as it should. Once you are sure of that, move on.

    You’d then login to your Cloudflare CDN control panel, and point the A DNS records for that domain to the Provider B web server.

    Within minutes, most, if not all, users nationwide will be pointed to the Provider B web site. (You’ll see warnings about DNS changes taking up to 48 hours – but in my practical experience – every user that matters will have the new records in minutes.)

    Provider A can then take their sweet time to resolve their issue.

    And your website will be up and running (thanks to provider B).

    And, if at some point you want to point back to Provider A, you’d do a similar process to ensure the latest database and file uploads are in use.

    It’s that easy.

    And this process is so easy, you could do this at the slightest hint of trouble, for maximum uptime.

    Rehearsals – Practice Makes Perfect

    To take this concept further, I’d recommend a disaster recovery test or rehearsal before critical events.

    That means, prepare for Black Friday, Retail Season, or Christmas or other heavy sales period by putting your process into practice.

    This will prove that both hosts still work, and that they have a reasonably up to date copy of all files.

    You’ll still have to sync things up if disaster does happen, but it will be much quicker (remember, it’s a differential copy.)

    And, you’ll rest well knowing it will probably work.

    WordPress Web Site Disaster Recovery On The Cheap – In Summary

    So, there you go.

    A simple and cheap way to keep your critical business web site running during an outage.

    I put this in place for myself after a 3 day outage by my web hosting provider. That outage could have cost me a lot in lost sales. (Far in excess of what having a backup hosting provider costs.)

    Which one was it?

    I won’t say.

    Because it doesn’t matter.

    They ALL have outages.

    So take some responsibility for your business and make sure you have options when it inevitably happens.

    Postscript on Cloudflare Outage July 2nd, 2019

    Now, you might say – doesn’t Cloudflare have outages too?

    Yes they do. In fact they had one about a week after I originally wrote this article.

    Guess what – it was a bad update. And they fixed it in about 30 minutes time. Compare that to the hosting provider bad update I suffered – that took nearly 4 days to resolve.

    If I’m going to have a single point of failure, I want it to be the most robust provider possible – and a world class large company like Cloudflare is who I trust to be that single point of failure.

    References

    1 How To Configure SSH Key-Based Authentication on a Linux Server

About the author

Tim

I'm an all around computer junkie, interested in many aspects of programming, operating systems, and enterprise IT technologies. I love Mac OS X, Linux, and Windows and more!

Be the first to comment

Leave a comment

Your email address will not be published.


*


close

Need a robust off the grid power solution?

Off the grid, portable power solution for your devices - big and small

Check out the Goal Zero Yeti line of power solutions - powerful Li-Ion batteries that you can charge from Solar Panels or via wall charger.  These are the ultimate in portable electric power!