Backups: WordPress Maintenance Series – Part 2

Backups are the Important First Step in the Maintenance Process

Preface:

WordPress websites consist of:

1. A standalone MySQL database is connected to the WordPress CMS within a configuration file on the server in the WordPress root installation. The database contains all digital content, user data, and individual tables generated by various plugins.  The main options table contains all the vital information about the site’s name, URL, theme, and plugins.  Separate tables within the database contain user details, post/page content, and other tables specific to unique functions and plugins.
2. All WordPress files, including WordPress Core, plus configuration files and the essential contents of the /wp-content/ folder (themes, plugins, uploads, and some other folders added by some plugins).

Why do we need backups?

There are many scenarios where a backup of the entire site or even just the database is pivotal in restoring a site quickly or moving it (migrating) to a new host.  Many site owners will have backups and never need a restoration. The alternative to having current backups is the risk of data and content loss and downtime. The site owner would incur the expense of a developer rebuilding/recreating a site and any lost business and brand visibility during downtime.

The primary consideration is what we “backup” to save if we need a possible restoration.  We need to determine whether we need a backup of:

• just the database;
• various WordPress components within the /wp-content/ folder: themes, plugins, media (uploads); or
• a full/complete copy of the site that includes all the above as well as WordPress core files.

There are many applications and options for what and how to secure various types of backups—whether via one or more of the following that we detail further below:

1. Host-supplied Backup options (outside of WordPress at the server level, e.g., via cPanel or Site Tools)
2. WordPress Backup Plugins
3. “Manual Backups” are described below.

1) Host-supplied Backups

The availability of Host backups varies according to the provider and hosting plan. We generally advise Sullivan Solutions clients about hosting plans and suggest they look for those that offer free backups for several days, an on-demand option, and an effective process to restore selectively. Years ago, it was necessary to contact the host support team and request they restore a server backup, but that took considerable time, and there was no confidence in the dated version of the site/files to be restored.  It was not uncommon for a site to be unavailable (down) for a considerable time.

For example, SiteGround hosting (not affiliated) provides daily backups for 30 consecutive days. From their “Site Tools,” it’s possible to access these backups by a desired date to selectively restore just the database, specific files, or the entire website.  A use case example includes a scenario where a reputable plugin is updated and subsequently triggers a “fatal error,” causing the site to crash — perhaps the new version has a coding error or conflict with another vital installed plugin.  If accessing the WordPress dashboard is impossible, as it would be with a crash, rolling that plugin back to its previous stable version from a recent backup should restore access to the admin and fix the problem.  We would then contact the plugin developers for support and provide them with incident data to help them release a patched version, hopefully within days.

2) WordPress Backups via Plugins

Plugin backups add an extra layer of security and redundancy when host backups are also in existence. We generally use a premium plugin called Solid Backups (aka Solid WP, formerly BackupBuddy), which enables the ability to run on-demand backups of:

• database
• theme
• plugins
• media, or
• complete backup

The backup files are stored in a folder in the /wp-content/uploads/ or any customized location by default. When backups are generated, they are output in a zipped file format. These zipped files can be downloaded to a local desktop. We can also send backup files to authorized destinations like Dropbox, OneDrive, an email, or a different hosting account. Solid WP also has its own external storage system called “Stash,” but it has limits to the size and quantity of backups we can store.

We might use a backup methodology to migrate a site from one host to another.  This plugin also includes Restoration options and excellent processes.

If the WordPress dashboard is accessible, one can also easily selectively restore an earlier version of the database, theme, or plugin. A tool called “importbuddy” can also be downloaded or sent to a remote destination to guide a site restoration into a new database with a new or temporary domain. Its many options make it robust.

Another powerful backup plugin is Updraft Plus. Its base version is free but limited. Premium add-ons provide more options for sending to remote destinations or using Multisite (WordPress Networks) installations. When we encounter compatibility issues with Solid WP due to the server environment, we often explore Updraft as the alternative.

3) Manual Backups

Manual Backups require technical savvy. They involve utilizing processes that are often a last resort when other matters fail for one reason or another. This is also an option if WordPress dashboard access is impossible despite all efforts and the host doesn’t offer backups or much support.

What’s needed?

• Hosting account cPanel or FTP credentials are needed to access unique files.
• The website database is accessed via phpMyAdmin and exported —usually as a zipped SQL file.
• Files can be accessed via FTP using a client like FileZilla or from the host cPanel or Site Tools; there is typically an application called File Manager.  File Manager provides the ability to create an archive (compressing into a gzip or zip folder) of either all files or just the /wp-content/

Let’s get a bit more granular.

The Database Backup

As a CMS, all the actual written content in pages, posts, and website configurations for the domain, users, and settings in the theme and plugins are within the MySQL database.

The database is not inside the actual set of WordPress files but, as described above, is in a separate database application called MySQL. Each database has a unique name and authorized users with password security, which we call a table prefix.  Most plugins have unique tables within the database for any settings or content.

Within phpMyAdmin, we can browse through the database tables (it requires expertise), realizing that even the simplest mistake can render the database unusable and potentially permanently damage the website. This is why having backup database copies is critical.

If the database is in a separate location, how does it work with a WordPress installation?

The WordPress CMS expects to have a MySQL database to operate successfully.  In each WordPress installation, the required wp-config.php file contains information about the following:

• name of the database server (it can vary by host)
• name of the database
• database user (this is separate from the WordPress admin users)
• database password
• database table prefix — by default, this is wp_, but we change it to something far more complex and difficult to guess as this is often a pathway for hackers or intrusions like malware injections

When we don’t have the option to restore a backup with a server restoration tool OR a restoration within the WordPress admin, we still have some options so long as we have the database files.

Option 1

Restore the database information into a brand new database using the Solid WP importbuddy.php script.

Option 2

Create a new and empty database, copy all the credentials involved to later update wp-config.php, and then unzip the database files on our local desktop to reveal all the individual .sql files. We can then upload those into the empty database and save them. We then connect all the new information in wp-config.php; hopefully, the site will work again. Of course, this is oversimplifying the process, but it does provide an overview.

Restoring Files

Often, the WordPress installation is okay.  Let’s assume it is.

Ideally, we will have downloaded a zipped archive of the site’s wp-content folder.

Typically, we would follow something like the following process:

1. Rename the existing wp-content folder to something like wp-content-old
2. Upload the wp-content.zip file using either FTP or the File Manager
3. Unarchive/Expand the zip folder, ensuring it is in the website domain root location as with the wp-content-old folder

The wp-content folder includes lots of other folders to include:

• themes
• plugins
• uploads
• and more specific folders that might be generated by plugins

So long as the database is connected and these files are back in their correct location, we can test to see if the site is now available.

There are many more options and use cases, but it’s a tedious process that requires in-depth knowledge of WordPress database and file structures.

But this is what we do!