• Skip to primary navigation
  • Skip to main content

Managed WordPress Security for Pennies a Day. Call (619) 479-6637

Managed WordPress Security with Heart

MENUMENU
  • Why HackGuard.com? Why Choose HackGuard.com?
  • HackGuard.com WordPress Managed Services Rates WordPress Managed Services Rates
  • HackGuard.com Articles HackGuard Articles Library
    • Hack Guard Customer Testimonials
    • Top 20 WordPress Plugins to Avoid
    • How to Improve Junk Email Filtering at Gmail
    • WordPress 6.0.3 Security Release – Updated?
    • Why Should I Maintain My Own WordPress Website’s Backups?
    • About that “Weekly jQuery Migrate Status Update” email
    • How to Change a WordPress User from Subscriber to Administrator Role
    • WordPress 4.9.3 – Going into the tunnel and never coming out…
    • How Do I Migrate WordPress to a Different Domain Name?
    • Community Blogging: A Short Guide
    • WordPress Troubleshooting and How to Fix WordPress Errors
    • Is My Web Host Secure? Maybe not…
    • How to remove the subdirectory name from your WordPress website address
    • How can I improve the performance of my WordPress website?
    • How can I improve the performance of my WordPress blog (Part 2)
    • Protecting WordPress Against Brute Force Attacks
    • How do I reset my WordPress password?
    • How To Clear Cron Jobs in WordPress
    • xmlrpc.php and Pingbacks and Denial of Service Attacks, Oh My!
    • Free Website Monitoring Services, well, mostly free...
    • How to choose a secure web hosting company for a WordPress website
    • WordPress 404 Page Setup - Do You Have Five Minutes?
    • Can mod_pagespeed Improve Page Load Speed (external link)?
    • Yoast WordPress SEO Settings and Recommendations
    • Is Your Mom Missing Her BUMM?

WordPress backup

Why Should I Maintain My Own WordPress Website’s Backups?

WordPress Backup Locally or to the Cloud

Why Should I Maintain My Own WordPress Website’s Backups?

Thank you for asking. My name is Jim Walker. I’ve been managing website hosting and security for thousands of our businesses here at TVC.Net since 1997.

Some years back, I launched our HackRepair.com service, a reactive website security service for WordPress. I quickly found that nearly all of our new customers either did not have a web designer to help with ongoing security and maintenance or simply never considered the ongoing security requirements of WordPress. So HackGuard.com, our proactive security service, was born.

Through our HackGuard.com service, I learned some truths about hosting companies and their backup systems, especially in how backups are limited at various hosting companies.

I would go so far as to say that of nearly all of the websites I’ve worked on over the past decade, only a small fraction provided reliable backup options. In fact, most of the well-known web hosting companies do not back up their client’s accounts (at all), even though their hosting plans clearly state that “backups are included.”

The truth is that many web hosts deactivate backups entirely once a certain number of files have been created within the hosting account. This is often referred to as “inodes.” And once the customer exceeds the host’s inode limits, backups are suspended. Many web hosts skirt the ethics of this “promise” by offering paid backup options—which they often promote within the client’s hosting control panel. Sadly, because most clients rarely log in to their control panel, they never see that backups have been suspended due to exceeding the hosts’ inode limit. For this reason, many businesses are left with the mistaken belief that their accounts are being regularly backed up when in actuality, they are not.

This was one of the reasons I developed our HackGuard.com service. So many clients whose websites had been hacked were missing someone with expertise in maintaining WordPress websites as well as a working backup system. So developing a reliable service that covered maintenance, backups, and website security was a no-brainer.

When I started my HackGuard.com service, I tried a variety of backup options. Of the dozens of WordPress plugins tried over the course of a few years, I found only two met my service requirements, UpdraftPlus and WP Time Capsule. At the time, my service requirements included: displayed minimal self-advertising and promotion, provided responsive customer service, supported a variety of cloud backup options, and provided a high level of reliability.

Updraft Plus and WP Time Capsule

Having managed websites for over twenty years, I can say without a doubt that the biggest lesson I’ve learned in my time managing websites is a simple one: backup redundancy and security go hand in hand.

It’s for this reason that I believe every website should have at least two backup solutions in place: one system saving daily, weekly, and monthly backups offsite, and at least one yearly backup saved either offsite or on the client’s personal computer.

I could get into discussing the pros and cons of my most used backup plugins, but the details are beside the point. You can learn more about the pros and cons of each with a quick Google search. In short, it doesn’t matter which backup system you have in place. Having multiple backup systems regularly backing your website up to an offsite “cloud” backup service is key #1.

Of the cloud services I’ve tried for website backups over the years, both Amazon S3 and Google Drive have been very reliable. The biggest downside of Amazon S3 is cost. Once backups on Amazon S3 reach a terabyte, service fees may begin to exceed $100 a month, especially if you are doing frequent recovery of files. Alternate lower-cost cloud service options, like Wasabi, are available as well, which according to their website, is 80% less costly than AWS. As of this writing, I haven’t tested Wasabi enough to give a review on their service.

Amazon S3, Google Drive, Wasabi

Now, having covered the importance of backups, I would be remiss if I didn’t mention how backups may affect the performance of your website. On an overloaded or poorly tuned web server, backups may impact how a website loads during the moving of data from the web server to the cloud service. On the other hand, having maintained the backups of hundreds of websites on dozens of different web hosting companies’ servers over the past several years, I’ve found that the more experienced web hosts with well-tuned web servers have zero issues with clients running multiple backup systems simultaneously.

Sadly, many well-known hosting companies throttle their shared servers by severely limiting CPU cycles, number of processes allowed, and/or, memory. If you’ve worked on a website and seen a 503 error page appear, then you’ve likely experienced this first hand.

503 error page
This may have the undesirable effect of backups taking exceedingly longer to complete, which may then perceptively slow web page loading, as well as increase the likelihood of backup failure.

This often-reported backup plugin “problem” is nearly always related to how well a given hosting service has tuned its web servers. I know I’m repeating myself here, but I would like to reiterate once again that an overly restrictive hosting service may limit the ability of your backups to fully complete in a timely manner, resulting in backups failing unexpectedly. If a hosting company recommends against using backup plugins like UpdraftPlus, there is a high likelihood that you are using one of “those” overly restrictive hosting companies. Is this a red flag when choosing a quality hosting service company for your business? I think so.

Which leads me to a discussion on the next uber-important aspect of backup management: backup recovery. Once you’ve established a working offsite backup systems, repeatedly and periodically testing the recovery process is key #2.

With UpdraftPlus, a files-based backup solution, recovery is as simple as deciding what you wish to recover—be it a plugin, theme, or the entire account—and then clicking the “Next” button a few times until the process is completed. With WP Time Capsule, an incremental backup solution, you have the benefit of choosing restore points, and within those restore points, the specific files or database dates to restore. Irrespective of how the backup plugins work, periodically testing and becoming comfortable with the recovery process is as important a step as establishing the backup options for your website in the first place.

That said, website hosting or backup failures are inevitable. That’s why it’s imperative to have multiple backup options saving off-server. The cost to archive your website to a cloud service is minuscule compared to the physical and emotional cost of having to rebuild a website from an Internet archive or multi-year-old backup. Been there, done that, and it’s no fun at all!

In the worst case, when the web host’s server literally crashes and the data is lost, your cloud backup service decision may spell the difference between the same day recovery of your website’s files and database and a total and irretrievable loss of your content. Backing up your website to a cloud service is just smart business.

And while most of this discussion has been about the value of establishing an offsite backup system, you may ask, “What about my web host’s backups?” Great question, and not meaning to be flippant here, but as that guy in that movie, Donnie Brasco, said, “Forget about it.” Sure, your hosting company may offer backups as part of their service, though I would argue that for the fifteen or so minutes it takes to set up a backup system for your website to “the cloud,” why take the chance? Whether your web host has a backup available when you really need it is also beside the point. Take control of your destiny. Just make a backup.

 


Disclaimer:
This post was written by Jim Walker for informational purposes only, was not solicited, nor paid for respectively.

 

Filed Under: Call (619) 479-6637 Tagged With: cloud backups, local backups, off-site backups, updraftplus, website backups, WordPress backup, wp time capsule

How Do I Migrate WordPress to a Different Domain Name?

How Do I Migrate WordPress to a Different Domain Name?

Changing the domain name on an existing WordPress installation or staging a WordPress website at a different location may seem daunting at first. But it’s really quite easy to do. And I’ll show you how.

Use case #1:

You’ve purchased a number of domain names for your website. And you wish to assign another of your domain names as the main domain people see in the web browser location bar when they visit your website.

Use case #2:

Your client has asked you to update their existing theme but would prefer you not edit their live website. Staging the website in a subdirectory within the current hosting account will allow you to work with the existing theme in a safe environment.

Use case #3:

You would like to move your website to another web host, but test your website at the new host before pointing the domain name to the new hosting account.

 

 

Numero 1The process for making a backup of a WordPress website in preparation for a move to another hosting account or for staging purposes is rather straightforward.

Start by making a backup of your existing website files and database.

Backing up files and databases within cPanel is as simple as clicking Backup, then clicking two links:

  • Download a Home Directory Backup
  • then Download a MySQL Database Backup

 

Once you have a solid backup of files and database:

  1. Set up a staging subdomain within your web hosting account like staging.at-your-domain.com, or use a different domain name entirely.
    1. If you are installing your WordPress site within a subdirectory on a cPanel server, click the Addon Domains button.
    2. If you are installing your WordPress site into the main directory on a cPanel server, click the Aliases button, and you’ll be all set in two clicks.
  2. Then install WordPress into the new account or directory.
  3. Rename the wp-config.php file for now.
    We are doing this so that when you recover your site files you do not inadvertently overwrite the newly set up wp-config.php file.
  4. Upload and extract your backup of files within to your staging directory.
  5. Delete the wp-config.php file you just copied over from the live site and rename the wp-config.php file renamed in (3) above back to wp-config.php
  6. The how to import a database part of the process can be a bit tricky the first time around.
    1. Since you already have a working wp-config.php in place and a working database in place, use your FTP or your web host’s file editor to view the contents of your wp-config.php in order to obtain the database name.
    2. Log into your PHPMyAdmin. Click on the database name at left. This will display a list of tables. Check all tables, choose the Drop option, then Go to drop all the tables.*
      *All you are doing here is removing the existing database tables in preparation for import.
    3. And finally, click the Import option at the top, Choose File, select that database you downloaded to your computer earlier, then click Go.
  7. If all goes well with the import you will have completed the initial staging setup process.

 

Numero 2If you are setting up a development site using a domain name different than the original, just add these two lines in gray to the top of your wp-config.php.file (below the line “<?php”), example:*

<?php

define('WP_HOME',"http://{$_SERVER['SERVER_NAME']}/");
define('WP_SITEURL',"http://{$_SERVER['SERVER_NAME']}/");

* The WordPress.org website covers editing wp-config.php fairly nicely, in case you are interested in reviewing the technical bits.

 

Then visit your migrated website.
99% of the time the two lines of text above are all you need to do!


WordPress Magic
“So what’s this magic going on behind the scenes” you may ask?

Ok, I’ll let the rabbit out of the hat. The guts of your WordPress settings are maintained in the wp_options table. All this magical bit of gray text in #2 above does is override your siteurl settings in your database.
Presto magico!

 

 

Below is an example of the above how to migrate your WordPress website to a different domain name.

The original website with website address:
pharm.tvsecure.net

Website migration demo 1

 

I copied the same website into a subdirectory of the same account for staging purposes, at:
/pharm-staging.tvsecure.net

and set the domain name pharm-staging.tvsecure.net to point to that subdirectory.

However, we had one obvious problem. Because the staging website was copied from pharm.tvsecure.net any attempt to visit pharm-staging.tvsecure.net resulted in an immediate redirect back to the original pharm.tvsecure.net domain.

Well, that’s annoying.
So, following step #2 above, I simply copy/pasted the two lines shown above into the top of my /pharm-staging.tvsecure.net/wp-config.php file, like this:

wp-config.php example 1

 

The result? When I go to pharm-staging.tvsecure.net the new website address pharm-staging.tvsecure.net I had staged earlier within the directory:
/pharm-staging.tvsecure.net appears nicely like this:

Website migration demo 2

 

Well, that about covers the basics of migrating a WordPress website to a different domain name by copy/pasting two lines of text.

If you have suggestions or additions to this WordPress staging or migration related article please be sure to email me anytime, jim at HackRepair.com

Enjoy!

Filed Under: Call (619) 479-6637 Tagged With: migrating WordPress, staging, WordPress backup, WordPress staging, wp-config.php

Proactive WordPress Security Management for Pennies a Day™

© Copyright 2022 HackGuard.com™, HackRepair.com™,
The Hack Repair Guy™, Hack Repair Guy™
Copyright and Trademark Statement | Privacy Policy

Call HackRepair.com for website security help, (619) 479-6637.
Content Approved By Jim Walker, The Hack Repair Guy