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.
Ease-of-use
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.
Reliability
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.
Security
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 support@codeguard.com.
-Jonathan
Thanks for explaining the situation. I understand the situation well because I previously used a WordPress backup plugin on my customers’ sites. Results were varied because of the different hosting environments. That’s primarily why I switched to CodeGuard – I found that the direct connection via FTP was more reliable.
The only part where that falls down is that many web hosts don’t allow remote MySQL connections. The WordPress plugin solved the problem, but since it’s now being retired here’s a workaround I’ve come up with: Use a plugin like WP-DBManager to create automatic daily database dumps. The dumps are stored in the wp-content which will then be backed up by CodeGuard via FTP.
To the CodeGuard team: I look forward to you improving your service now that you are no longer maintaining the WordPress plugin. Here are some places to start:
* Improve the directory filtering for a site. Right now I can only filter directories when adding a new site – I can’t edit a site’s settings to change the filtered directories.
* Please improve the UI for the My Sites page. It gets terribly cluttered after 20+ sites.
* Do improve your malware monitoring. It would be great if you could scan the contents of PHP / Python / Ruby / etc files for malicious code and alert site owners when you find it.
* Please don’t ruin my workaround above by automatically filtering database dumps. Thanks!
David,
Based on our prior discussion, I think your use cases and needs are representative of many of our Professional or Enterprise users, so we very much appreciate your insight.
We are conscious of the remote access limitations imposed by hosting providers like GoDaddy and we intend to provide a solution. There are several ways to overcome this challenge which will resolve the issue for users of Joomla!, Drupal and MODX, as well as WordPress. We are in the process of identifying which solution will work best for our customers.
Thank you again for taking the time to provide this feedback. There are two points that I wanted to answer specifically:
We are actively working on improving the file and folder filtering now. The current process has the potential to be inconvenient for some users, so we’re working to address those concerns.
Of course not! It’s your storage space, you can use it however you’d like.
- Jonathan
Hi guys, thanks for your huge efforts!
The few times I’ve emailed you with suggestions, your team has been extremely receptive to feedback and very polite. Your software is top notch and your strong growth is evidence of that.
However, I strongly believe you will look back on this decision, maybe in a week, or maybe in a few years, as one of the worst strategic decisions you ever made. I know you are a young company and your time is limited, even your financing is limited. But dealing with the WordPress issues by abandoning a plugin is a terrible reaction in my opinion, so I’ve listed specific points below.
1. Caring about “all” CMS platforms is misdirected. Joomla, Drupal, and pretty much every other CMS besides WordPress is losing market share every day. WordPress is the only CMS gaining traction around the world every single week. Your customer base is already largely made up of WordPress users, so by trying to please “everyone” you may lose your growing reputation. Why not boldly declare a WordPress and/or FTP only policy? Which brings me to…
2. Within the massive WordPress world, the entire philosophy has been moving toward “backend management only” for the past few years. After setting up a WordPress site, ideally, developers should rarely have any reason to require FTP connections. By forcing the WordPress community to step backward into the realm of FTP, you are swimming against the current in many ways. Not only will you likely be passed by in place of other similar plugins like VaultPress, but you will lose thousands of customers who are not super tech savvy. Plus, developers who manage dozens or hundreds of sites can quickly recommend and install your plugin, but shifting their work over to FTP and manual configuration will create a nightmare for client management. Which brings me to…
3. Punishing the entire WordPress community for the small amount of fools who believe GoDaddy is actually a viable web hosting option is like “cutting off the nose to spite the face.” Security, MySQL, and SSL are not issues, as you even said, for 90% or more of your current WordPress customers. It sounds like this decision is coming in part because of your team’s frustration with wasting time helping obnoxious customers who are clueless enough to use GoDaddy web hosting. Which brings me to…
4. Do NOT waste time helping customers who are not PAYING customers. Many online SaaS companies offer a free version of their product to expand their customer base and get their name out there. This is fantastic. Companies like CloudFlare will millions of dollars in investment can afford to waste a load of money on letting their support staff help freebie customers, in the name of research. But in the case of CodeGuard, spending too much time on these types of customers is obviously frustrating your staff and wasting a lot of your time and money. Either charge for support, or don’t accept support tickets from free customers if this is truly such a huge problem. Which brings me to…
5. Your pricing structure is very fair, but it chould probably change to convince more developers to sign up for a paid plan. For example, jumping from the personal 1 site plan to a 25 site plan is a pretty big jump for small companies with 5-15 clients, etc. If you could offer perhaps a $25 plan, or even $50 plan in between, it may convince more to sign up. As it is now, developers can and do simply set up each client with a new free account. The biggest problem of all is that your professional $99 plan forces developers, many who are small business owners in a tough economy, to throw down over $1,000 up front for an entire year of CodeGuard service. Yikes! Which brings me to…
Conclusion: Please, please, please… don’t abandon the WordPress plugin. Instead, throw more of your weight behind it, and make it MUCH better. Allow webmasters to automatically restore backups via the WordPress backend, without manually downloading files from CodeGuard. Allow webmasters to “pause” backups during restore actions, and let webmasters backup only certain MySQL tables if needed. Also, include more information on the stats panel to include custom post types, etc. Regarding payment options, you REALLY need to allow developers to pay on a monthly basis, such as a PayPal subscription or PayPal invoice system. Again, CodeGuard is not a super corporate service, meaning that many of your customers will always be small and medium businesses esp. outside of North America who need to pay in smaller amounts each month using PayPal.
Anyway, I love you guys, much more than alternative solutions, and your company is still fresh and energetic. Please don’t lose your great attitude and great WordPress plugin. The silent majority of your customers, 99% probably, are as happy as clams with the plugin and probably will never even realize that you are not supporting it any longer. PLEASE RECONSIDER, THANKS! =)
P.S. Adding an extremely detailed FAQ section that is HIGHLY visible may greatly reduce support tickets!
Cheers! =)
I’ve read all of this and find myself completely agreeing with Jake. I run a large website with about 1TB of traffic per month, and CodeGuard has made me sleep a lot better, knowing it’s all getting backed up on a daily basis
. The WordPress plugin made all the difference, let me repeat that. The WordPress plugin made all the difference.
If anything, I would double down on the plugin, and neglect all the other CMS’s. Gretzky said “I skate to where the puck is going to be, not where it has been”. WordPress is fast growing platform that has changed the web for good, while other CMS’s are shrinking, and for a good reason: they suck at offering a user friendly interface which 99% of mere mortals need (most developers and designers fit into this category). CodeGuard is at a unique position to market “backups for the rest of us”, yet it’s choosing exactly the opposite.
Also, the difference in pricing is a very good point. The first thing I notice whenever I see that CG pricing table is how far the Personal and the Professional plans are priced from each other. In fact, it would be better marketing-psychology-wise to price the first $49, just so that the $99 plan doesn’t look ridiculously expensive. That said, I hope you’ll introduce a semi-professional plan for $24 per month. If you introduce a plan like this, you will be very happy with it’s popularity one year from now. Price aggressively, go for volume (this is especially true for web companies in the early stage).
Finally, yes, you must have a monthly package. In this day and age, a yearly plan is seen as spammy, perhaps even evil.
PS
Love the blogpost and explanation of decisions made here.
Thank you for this post. I was unsure whether FTP was better or the Plugin.
I am using CodeGuard along with BackWPUp. Is that a wise choice, or should I rely on CodeGuard alone? Does the Plugin-based backup affect my site’s performance?
I am very sorry to see this WordPress CodeGuard Backup plugin no longer being supported after 2013. I use it for quite a few of my clients’ websites who use webhosters that do not allow external database connections. So the only way to backup the database is to use a locally installed plugin like this one.
I got onto this page as I was looking for a similar solution for Joomla! sites with webhosters that have the same security restriction. And now I found out that the WordPress plugin will be discontinued!
This of course means that you won’t create a Joomla! 1.5/2.5/3.2 alternative either. This will make it impossible for customers with hosters that restrict external MySQL access to fully backup their CMS. This is a huge setback for me and my clients. This means we will need to work with an extra extension to backup the database while CodeGuard can only deal with the files.
I seriously hope you will reconsider this. We do not need less or no plugins like this, we need more of them!
This makes complete sense to me. With the FTP/SFTP backup available I never really understood the need for a WP plugin as well. Most hosts nowadays will give you SSH access so remote MySQL backups shouldn’t really be an issue. I would say the only downside is that its slightly more difficult to setup than just a plugin, but I think you have to have at least a basic technical understanding to really be able to use a Codeguard backup file to restore your site anyway.