Backing Up Your Site
If you’re like me, you have fun doing stuff like ssh-ing into your site, performing a MySQL backup, zipping up the contents of your wp-contents directory, and downloading the results to your local drive space — which is covered by BackBlaze.
If that sounds enjoyable to you, I think you and I both know that you don’t need this section — or likely this post! You’re likely already backing up your WordPress site using custom scripts on some periodic basic. Or you’re using a backup plugin like one of ones I talk about below. You have my undying respect if you take the additional step of testing restorations of your backups. I know some professional IT departments that don’t that that necessary step!
On the other hand, if things like ssh-ing and performing MySQL backups aren’t activities that excite you, then you probably prefer spending your limited time doing stuff like, I don’t know, researching topics and writing blog posts. You know, doing stuff for your audience!
The honestly important stuff!
Well, I have good news. Backups are easy. Easier than I thought. Probably easy enough to make me change how I currently backup this site.
Here’s the short version:
Install a plugin called UpdraftPlus. I’ve checked several recent reviews of WordPress plugins, and they seem to agree that this is the best choice.
Here are some articles you can double-check to make sure UpdraftPlus is for you:
- Design Bombs: 8 Best Backup WordPress Plugins Compared – 2018: I really liked this post’s testing methodology.
- IsItWP: Best WordPress Backup Plugins (Compared)
- WP Buffs: The 6 Best Backup and Restore Plugins to Keep Your WordPress Site Safe
It’s easy to put off backing up your site. But I’ll tell you this for free: Something dreadful will happen to your site. It’s the nature of sites. If you’re prepared, your readers might never know anything happened.
But if you’re not prepared… Let me be very honest here: I don’t want to see a fellow ani-blogger go through that kind of anguish. Please, backup your site.
Backing Up Is Enough, Right?
But I’d say no.
I say “maybe” because I’m from an ancient time. A time before DeOps. A time before the empire….
Okay, this isn’t Star Wars, but Ben Kenobi had a point. A backup will help you recover from something terrible. But testing a change before you make it can prevent something terrible from happening in the first place. DevOps is all about streaming functionality directly into production and relying on automated testing. It’s great if you can invest in the team and tools to get it right.
See, if the school board had invested more in a testing system, they could have put the zombie in that system and poor Kyoko Hayashi might have survived for at least another episode! Capture from the HIDIVE stream.
But if you can’t afford a team, then your best bet is testing changes on a system other than your live site.
I’m sure that’s what Ben meant.
Testing Major Changes Before Going Live
Ever want to change themes, or make a major change to your existing theme, and stop in a moment of terror, your finger hovering over the “Publish” button, thinking, “Will this toast my site?”
If you have a good backup because you used something like UpdraftPlus, you can recover. Maybe that’s enough for you — seriously, maybe that’s the right way for you to spend your time! Maybe taking the time to test the kind of changes you make isn’t worth your while. But maybe it is! That’s a decision I trust you to make.
As a software developer in a previous life, I have an instinct to prevent something dreadful from happening in the first place. But — and I’m being honest here — if you’re not interested in either paying for a second server to act just as a test server, or if you’re not interested in building your own version of Linux under VMware Fusion or Virtualbox, then please stop reading here. Make sure you have a good backup solution, and focus your attention where you think you’ll get the best return on your investment.
But if you’d like to test stuff, here’s something I recently learned while researching this post.
First, you’ll need one of two things:
- A second domain from your internet hosting provider. For example, I might go to TigerTech and setup CrowsWorldOfAnimeTest.com, complete with MySQL, Apache, and PHP. It’ll be the same cost as my main site, which is to say, it’ll double my monthly costs. I could also build my own from scratch using Amazon Web Services, and I could easily shut it off when I’m not using it to drive down costs. But it’s a lot more work.
- If my personal (home) computer has at least 8Gb of RAM and enough free disk space (depending on how big your site is), you can build a virtual version of your site on your personal computer. That’d be about the same amount of work as using Amazon Web Services.
For option #2, I’ve successfully used VirtualBox, VMware Fusion, and even VMware vSphere at home. But I’m also a software developer, a computer security professional, and a recovering systems administrator, so I invest in things that most people think are eccentric. And I’m cool with that, because not only am I a computer professional, I’m comfortable in my eccentricity.
If you’re interested in #2 (or the AWS option for #1), I’ll assume you have the skills to install Linux and Apache, add MySQL, add PHP, and add WordPress on your own. In other words, I’ll assume you can get the server to the point where it’s running a vanilla installation of WordPress.
If you’re interested in #1, I’ll assume you can pay the internet service provider to get to the point where the site is running vanilla WordPress. In other words, you can purchase a site running WordPress.
The process I’m about to describe will do the following:
- Restore all of your posts, pages, and comments to your test site
- Copy the images associated with those posts and pages
It will not:
- Copy your plugins
- Duplicate your theme
This is a good thing, because the goal is to test major theme changes. If you restore everything, including plugins, you might increase your costs, because some plugins have a fee. Others, like JetPack, might get confused if you restore an exact copy to another site (though JetPack will try to detect that situation and protect you from it — but why chance it?).
Having additional copies of your site might not protect you from an acid attack like Kurumi’s copies did for her, but they can still make your life easier. Capture from the Funimation stream.
In other words, this approach focuses attention on testing how your posts and pages will look if you make changes to your themes. You could also use this approach to test plugin upgrades (e.g., upgrade your test site first), but in my experience, that’s not the best use of your time. And yes, I admit your mileage may vary!
The idea is to export your live site to a file called eXtensible Markup Language (XML) file, then import that file into your test system. The export will bring all of the text from your posts and pages. When you import it into your test site, you’ll have the option to bring the images, too.
To get started, log into your live site’s admin screen. Click on:
You’ll see some options. Select:
- All Content
Then click on:
- Download Export File
Make sure you make a note of where you download the file (i.e., the folder or directory), and what file name you gave it.
Now, log into your test server’s admin page. Click on:
You may have to install the WordPress Importer plugin first. Take care of that, then select:
- WordPress: Run Importer
Here’s where things might get tricky. Look on the screen for something like:
“Choose a file from your computer: (Maximum size: 20 MB)”
Unless you have a small site (or you just started out), the default of 20M won’t be enough. I changed mine to 200M, which means 200 megabytes.
The default installations for PHP don’t allow very big files to be uploaded. If you’re hosting your own site, check this file (assuming a recent version of Linux CentOS or RedHat:
Check how big your downloaded Export was (mine was about 25Mb). Now, find these two settings in php.ini:
post_max_size = 20M
upload_max_filesize = 20M
Your setting might not be 20M. That’s short for 20Mb. Set it to something big enough to process your file. In my case, I’d round up to 30Mb and set them to:
post_max_size = 30M
upload_max_filesize = 30M
systemctl restart httpd
systemctl restart apache2
Depending on your version of Linux.
If you can’t make those changes, you’ll probably have to work with your internet hosting provider to make them for you.
Once that’s done, log back into your test site’s admin page and select:
- WordPress: Run Importer
Pick the file you just exported from your live site. Click on the button “Upload File and Import.”
For your own sake, please do not just click through this screen! Read the paragraphs below to make sure it does what you need it to!
Now, these pieces are very important:
- Import author: You can either bring in the authors (like tcrow), create a new one, or assign all of the imported posts to a user you already setup on the test system. I generally keep my IDs the same (like tcrow), so I just import the author. That means for #1, I make no selection or change. Otherwise, if you already created a new user for yourself in the test system, you can use “assign posts to an existing user” to select the ID you created.
- Import Attachments: This is critical, and it’s something I missed the first dozen times I did this. Make sure you select the checkbox “Download and import file attachments.” This will download your screen captures and other images.
Those two things together will create your posts in a way that lets you test changes to themes.
Now, Test Your Changes!
Now that your test site has all of your posts, pages, and images, you can make changes to your themes to your heart’s content! Or you can update all of the plugins and make sure they still work! Or you could deactivate and/or delete plugins to see what impact it has on your site. If you’re like me, you’re always looking for the best way to present content. Sometimes, that means changing themes or making theme changes like front-page layouts. Without a test system, I don’t want to make changes that are too drastic for fear of destroying my site!
But with this approach, I can make all the changes I want to the test site and not impact the main site! If I make a change that looks ugly, no one but me will know! If I make a change that is fantastic, I can recreate it on the main site!
But that’s only if I know what changes I made! As you make changes, make sure you write down the settings you changed or the steps you took. That way, you can more easily make those changes with confidence to your main site.
The good thing about testing your changes to make sure they’re safe? You’ll have more time to do fun stuff! Capture from the Crunchyroll stream.
Backing up your site helps you recover from unexpected disasters. If something destroys your site (or severely damages it), you can put it back just the way it was. Using a test site and leveraging WordPress’ Export/Import capabilities can let you test changes before you make them to your live site — and eliminate either the need to undo changes or, in extreme circumstances, from restoring your site from backup.
Which means you more time to focus on your posts. Or go sing karaoke!
If you’d like to talk in more detail about the virtualization options, let me know in the comments! I’m guessing that if you’re interested in that approach, you’ve probably already pursued it. But if that guess is wrong, I’ll be happy to share my experience with setting you a test system on your home PC or even in Amazon Web Services. It’s less expensive than paying an internet service provider for a permanent test site, and it’s fun to learn.
I hope these ideas help you meet the expectations of your readers!