WordPressing the Cloud – Part 1 of 3
WordPress the Google Cloud using the Bitnami LAMP Stack
I am writing this into 3 parts, due to the length of this post. I planned on taking a couple of hours a day for 2 weeks to do some “WordPressing” in the Google Cloud and was finally able to. This is part one of three – Backups, Disaster Recovery, and Upgrading WordPress.
(I am providing links to the documentation from Bitnami, their community forums, and Google. These will show the procedure to follow. In some instances I am providing the procedure myself, where I found the answer in several different sources.)
Why should you host your WordPress site in the Cloud?
The cloud platform offered by Google is the perfect home for hosting your WordPress site. The flexibility to scale up resources on the fly and back down is a major reason to use the cloud. But disaster recovery and upgrading are the icings on the cake.
I still remember the phone calls from hosting clients when I was the support manager for a national hosting company. An article on their WordPress site had gone viral, or a so-called “well-planned” promotion was driving huge traffic to the site. But the hosting plan they were on could just not handle the traffic.
Putting your WordPress site in Google Compute, you can scale up the resources as needed on the fly, and when things settle down, reduce the resources. You pay for what you need. This way when you implement your well-planned promotion, you really don’t have to worry about “forgetting” to plan for the increased usage of resources, nor the embarrassment of a white error screen.
How do I do backups, restorations, and upgrades with WordPress in the Cloud?
As a developer, I try to stress the importance of backups to my clients. Do not rely on the courtesy backups done by your hosting provider. Do your own. I tested the backup/recovery options offered by Google Cloud on my server for the first part of my 2-week adventure.
First, I wrote a script to back up the files and database of any sites not yet live. These are the testing grounds for projects or sites I am currently building. I use the method of developing on my localhost, send changes to GitLab, pull the files to the testing site server, and then deploy on the clients’ server.
If something goes wrong, I have the DB/file backup from the testing server, the code in GitLab and a copy on my localhost. I feel safe and snuggly.
As for my live sites, such as this one, I run a script that takes a snapshot of the hard drive once a week or I manually take one before and after major upgrades or updates to WordPress.
WordPress is a great CMS, but if you have worked with it for a while, you should be aware of some of the frustrations that can come from upgrading the core files or plugins. The cloud makes it easy.
I created a snapshot of the current server, spun off a new server from the snapshot, installed the upgrades, and if anything breaks, I fix it. This process took about 30 minutes tops. The hardest part was to decide whether to use the new server (just point the DNS to that new server) or apply the upgrades to the old server. I decided to do the former.
In the same amount time that it took me to restore just the WordPress site on my previous dedicated server, now with my server in the cloud, I can just recreate the whole server that has the backup of WordPress in it.
The key factor here is to take backups. Automatic snapshots are the way to go. But being old school (that means being caught without a backup before) I still use a WordPress plugin to just back up the site files and database once a week. I store those in the free storage bucket that comes with my Google account.
I actually spent 4 hours over a 2 day period doing backups, snapshots, upgrading core files and plugins. Testing different scenarios. Why, I want to be prepared, just in case, for my sanity and that of my clients. (Really it is just the boy scout in me.) As for upgrading WordPress and/or plugins, it is done from the WordPress admin panel, the normal way.
In the next part of this series, I will discuss building a new server, configuring the new server, and moving the sites from the other cloud server and my VPS at another hosting company, but with a major twist in the structural layout.