WordPress Backup: Hello, not Goodbye!
CodeGuard is dedicated to providing the best website backup service in the world. In addition to sites built without a CMS, we want to offer WordPress backup, Joomla backup, Drupal backup, MODX backup, sites built with any CMS that can be accessed via FTP/SFTP and sites that use MySQL; our goal is that anyone with a website can use CodeGuard to back it up. As of today, in an effort to better serve our users, we are introducing our FTP/SFTP + MySQL backup as the preferred and superior solution for WordPress sites. While this blog post explains why we are moving away from our WordPress backup plugin, we are here to assure you that we are not moving away from WordPress. We feel this is the first of many steps that enable us to better serve all CMS platforms. So we’re not saying “Goodbye” to WordPress, we’re saying “Hello” to the WordPress community by introducing our FTP/SFTP + MySQL backup as the easiest, most reliable, and secure WordPress backup service on the market.
Why we built a WordPress backup plugin in the first place
The WordPress backup plugin was on our product roadmap before a single line of code was ever written for CodeGuard. Our plan was to first produce a solution that would back up site content via FTP and MySQL databases directly or over SSH. The next area of focus would be either WordPress backup or producing a plugins for Plesk & cPanel.
“Plugin” is a dangerously innocuous-sounding word. The reason is that in many scenarios, plugins are simple. Depending on what the plugin is doing, it could be a few lines of code. Or if the plugin requirements can leverage existing API architecture, then things can move fast and meet all of the customer’s needs. Our WordPress backup plugin was not to be simple by any stretch.
WordPress backup plugin goals: Ease-of-use, Reliability, and Security
At a high level our solution was a WordPress plugin that communicated with the CodeGuard service. However, that description does not convey the enormous amount of resources that were poured into both the plugin developement and CodeGuard architecture to make the reliable and secure transmission of customers’ data a reality. After evaluating the existing solutions and talking with users and experts in the WordPress community we agreed upon three goals for our plugin, that it would be (i) easy-to-use, (ii) reliable, and (iii) secure.
We wanted bloggers and site owners of all skill levels to be able to use our plugin, so it was built to be very easy to install and configure. The process for installation and configuration was as streamlined as the administrators of the WordPress Plugin Catalog would allow it to be. Our first iteration of the installation process only required an email address, but we were asked to change the plugin to refer interested users to our website to signup before using the plugin. In the end, our process only required four steps to go from discovering CodeGuard to having your WordPress site backed up.
In order to accommodate all WordPress users, the plugin was built to work within as many hosting environments as possible. We have been able to support customers using everything from inexpensive (or free!) shared hosts all the way up to dedicated servers. Working with different hosting providers presents some interesting challenges. This is especially true in the shared hosting space, where server resources are limited and these limitations are aggressively enforced. In order to support the wide variety of environments our solution could be used in, the backup process was built to dynamically scale the amount of server resources being consumed on a customers site. For example, if we detected a memory limitation as the backup content was being uploaded to our servers, the service would automatically reduce the size of the data being sent on each request until it fit comfortably within the allocated memory. Or, if the database was being actively used and the CPU usage on the site was high, the service would automatically export fewer and fewer rows from the database at one time. The service and infrastructure components that were built for the WordPress backup plugin allowed our backups to run in some of the most restrictive hosting environments we encountered.
The security of our customers’ backups are of the utmost importance at CodeGuard. Our service and WordPress backup plugin communicate over the HTTP protocol just like a web browser visiting a site. But, as everyone knows, HTTP is not an inherently secure protocol. HTTPS is secure, but the majority of websites do not have an SSL certificate, which is required for trusted HTTPS communication. As a result, we produced a secure transport mechanism that operated over HTTP. Every installation of the plugin generates a unique 2048-bit RSA key-pair which is used to secure communications to and from the CodeGuard service over plain HTTP. Beyond that, a secure handshake is performed at the beginning of the communication process to establish the identity of the CodeGuard service and prevent man-in-the-middle or request forgery attacks. With this security protocol, built on industry standards like RSA and SSL, we were confident telling our users that information transmitted from their site to our service was secure.
What we found after thousands of WordPress backup plugin installations
The WordPress ecosystem is a strong and thriving one. There are a variety of plugins, themes and services available for nearly everything you can think of. A side effect of this is that there is a huge amount of variation in WordPress sites. Every customer we encountered had a different configuration and set of installed plugins. The openness of the WordPress plugin architecture also means that there is a possibility of interference between plugins. We experienced numerous cases where attempts to communicate with our WordPress backup plugin failed because another plugin was intercepting or blocking those requests. In every case a customer contacted us with this issue, we were able to identify and work around the problem. However, the fact that an individual had to take their time to open a support ticket and in some cases help us troubleshoot the issue, was not the kind of experience we want for CodeGuard users.
The secure transport mechanism was created internally for our service and WordPress backup plugin communication, but it was built using common, industry standard technologies. Specifically, the core of the protocol was built to use OpenSSL which has been around for more than 15 years and is commonly used on web servers for HTTPS/SSL communication. However, there were a number of hosts where OpenSSL was not installed or it was not available to users. In some cases, we were able to work with the host directly to expose the necessary packages to users sites. Or, if the user had a dedicated or VPS server we could work with them to configure it properly. However, this still created a scenario that we could not detect until the WordPress backup plugin was installed. At best, the resolution for this unfortunately common problem required valuable time from our customer to resolve. At worst, it was not possible to fix because the hosting provider did not want to correct the issue.
What, if anything could we do differently?
The vast majority of those who use our WordPress backup plugin are unaware these problems exist because they have never encountered an issue. I’m confident that in time we could resolve the issues that users have experienced. For example, we could build special cases into our WordPress backup plugin to provide appropriate messaging and instructions if we detect a plugin installed on their site that we know has caused issues in the past. We could change our security protocol to something that does not depend on OpenSSL. Or, we could ask potential users to fill out survey to determine compatibility before they attempt install the plugin. Given the pace at which the WordPress core and plugins are updated, all of these solutions would require significant ongoing effort to maintain.
At CodeGuard, our mission is to provide reliable website and database backup services regardless of what platform your site is using. We believe the best way to achieve that goal is by dedicating our resources to enhance the product in ways that benefit all of our users by preventing new installations of the WordPress plugin and focusing on the platform agnostic FTP, SFTP, SSH and MySQL protocols.
Existing WordPress backup plugin users will be supported for the rest of 2013
Existing users of the CodeGuard WordPress plugin can rest assured that we do not intend to interrupt your automatic backups. Support will be available for the plugin through 2013. We will also be offering assistance for those that wish to migrate from the WordPress plugin to FTP/SFTP and MySQL backups. To begin this process, please contact email@example.com.