Backing up Databases Just Got Easier

For websites using a content management system (CMS), backing up the database is crucial. In fact, database content such as posts, comments, and users is often more important to website owners than the file content (e.g. themes and plugins). That’s why CodeGuard now automatically detects and adds databases for websites built with WordPress, Drupal, and Joomla.


Read More “Backing up Databases Just Got Easier”

Introducing Microsoft SQL Server support in CodeGuard


As some of our customers may have already noticed, we at CodeGuard have been hard at work adding a new product line – Microsoft SQL Server Database backups. Today, we wanted to share some of the technical aspects around the creation of this new

Until recently, we have only provided MySQL database backups. Like many other cloud-based companies, much of the work we do is performed on the Linux operating system. While that works well for many of the systems we back up, including SFTP, FTP, MySQL, and WordPress, currently, it is better to backup Microsoft SQL Server using a Windows-based solution. Fortunately, these servers, like other parts of our infrastructure, run in Amazon’s Elastic Compute Cloud, where we can create and remove new Windows Servers in only a few minutes. With some custom code written to execute the backups on this group of servers, we are able to provide the same type of daily backups to our Microsoft SQL Server clients that we do to clients running MySQL.

There are multiple ways to backup Microsoft SQL Server, including creating a backup through the SQL Server administrative interface, using a tool such as MyLittleBackup, or creating a backup of the Windows Drive where the Microsoft SQL Server database stores its information. Most of these methods will store the database as a binary blob in a proprietary format. This format makes using the type of differential backup that CodeGuard offers impossible. This, in turn, means that preserving Daily and Point-in-time backups requires more and more space. Storage would quickly fill up or become prohibitively expensive.

One commonly used tool, Microsoft SQL Server Management Studio (Microsoft SSMS), does offer the ability to export the data in an essential format called TSQL. In a small menu a few levels deep, if one ticks the proper set of check boxes, one can generate what is called a “script” for the database. The process is error-prone, but this script can then be used to load the same data to restore to a specific point in time for that database. However, because we need to perform this backup for our customers every day, we felt that there must be a better way than jumping through these hoops.

Our solution uses the same underlying Microsoft APIs that SSMS uses, but we wrap them in a service to make them more robust and more responsive to some of the diverse methods developers and hosting providers use when deploying Microsoft SQL Server. Using our process, we generate a TSQL script, just like SSMS, and save it to our differential and incremental storage system. If we do this daily, each additional backup only requires us to store the changes that occurred on that day (usually much smaller than the rest of the database).

Some readers may be wondering more about the specifics of the method that we are using to import these Microsoft SQL Server files into our backup storage system. There were a number of options available, but the path we ultimately chose was to build a standalone tool which would appear to the existing CodeGuard backup system to operate in the same way as the MySQL-specific “mysqldump” tool, which we already use to back up some MySQL databases. In this way, we could reuse much of the backup process that already existed in our core system, applying tried and tested code to the problem at hand.

However, no mysqldump-like tool that we found operates on Linux and connects to Microsoft SQL Server in the same way. To make the two appear the same, we wrote a small program to run on our Linux servers in Go, one of the programming languages we use regularly here at CodeGuard. Like mysqldump, the tool we wrote can be called in a predictable way from the Linux command line, and results in a TSQL file very similar in appearance the database files created by mysqldump. However, the mechanism used to generate the file is quite different. In this case, we leverage Amazon Simple Queue Service (SQS) and Amazon Auto-Scaling Groups to start and manage Windows Server EC2 instances. When the Linux Go tool is run, it sends a message to the MSSQL SQS queue we have created. There, an EC2 instance running Windows Server will be waiting to take the job that we have dispatched over SQS and generate the TSQL file. Based on the number of jobs submitted, the Auto-Scaling Group will run more or fewer Windows Servers, to get the best of both throughput and cost savings. When a job is complete on the Windows side, the information is uploaded to Amazon S3, and a message is sent back to the Go tool. We use S3 as an intermediary because the size of the file is much greater than the permitted size of an SQS message. At the end of this part of the process, the Go tool receives the returned message, downloads the backup from S3, and feeds it to the backup system just as mysqldump would.

Similar to our MySQL option, we allow our customers (in fact, we encourage them!) to request zip files containing the TSQL scripts. These can be downloaded conveniently from our system as a compressed file. An owner can then load them locally into tools like SSMS whenever needed for data recovery, migration, auditing or testing purposes. The process to add these databases is usually straightforward and is described in our Support Center.

For those of you out there running Microsoft SQL Servers, please give it a try! Feel free to let us know how your experience went by emailing: We appreciate the feedback!

What’s Your Phone Number?

Many companies voice a commitment to customer service but not all follow through.  Everyone has had the experience of working through a phone tree of choices  … option 1, menu 2 -option 4, menu 3-option 1…. only to have the call dropped or get re-cycled back to the beginning.  Or maybe you do get through to a customer service agent but then get passed around like a hand grenade without its pin.   Sound familiar?

Good customer service is in the details.  For example, a company should ask: what information is really needed from a customer before handling their call?  I think many companies make data collection more important than the actual service.  But sometimes that little extra bit of information represents a detail that really highlights the right kind of commitment.

One such detail at CodeGuard involves asking for phone numbers.  Many of our competitors never ask for a phone number when a customer signs up.  We do.   And around this little detail we recently have undertaken a company-wide initiative to standardize our phone data and employ it in the most useful way possible.    

Why do we want your phone number?  First, we reach out to all our direct signups with a welcome call.  We want our direct customers to know they can contact us at any step along the way to get assistance with problems or simply get questions answered.  Further when we see a persistent problem with a customer’s backup we have an easy and personal way to reach out and facilitate a solution.

Our efforts to standardize phone numbers began with the need to put them in a format to ease the creation of a daily call list.  We wanted a simple easy-to-read format.  More importantly, since we reach out to customers around the world, we need to be able to identify the country codes and use those to determine the best time to place a call.  For some reason a “welcome” call that wakes a customer at 3am is not always welcomed by the recipient!  The same is true when returning a customer’s call.

So first we needed a standard way to list the phone numbers that we had.  But this in turn made us realize that we needed a better way to solicit good input.  We realized we needed a way to ensure that customers provided their country codes and added phone numbers that fit the country format.

To add this standardization without building the functionality from scratch, we turned to a jQuery plugin that looked simple to work with and could give us the functionality we wanted.  The plugin provides a dropdown with country code identified by a country’s flag, providing both color and an easy identifier for users.  Additionally, the plugin identifies invalid entries (wrong formats, incomplete numbers and incorrect characters [e.g., letters versus numbers]).  By enforcing better input we ensure a greater chance of successfully reaching out to our customers.  Finally, the plugin provides standard ways of handling phone numbers with extensions.

Country Code Dropdown

Using jQuery we are implementing the plugin across our web application.  Not only do we want to capture good phone numbers on sign up but we want to encourage updating and/or correcting entries when a customer updates their accounts.  Over time, this should improve our database and allow us to upgrade our customer service.

Any developer knows that even small changes can ripple through an application requiring changes to prevent other code from breaking or rendering other code obsolete.  This has proved to be true here as well.  While we want to encourage customers to update or correct their phone numbers, our newly added code chokes if a previously entered phone number is not valid.  We therefore have had to go back through our code and tweak the places where validation is not to be utilized so users will not be pestered for a phone number at the wrong times.

Asking for a customer’s phone number is not a big feature but it does have big implications for our commitment to quality customer service.  We think it is worth the time to get it right.


Easy Upgrade From The Free Plan

When we launched our free plan recently, we weren’t sure whether customers would routinely want to upgrade from the free offering to a paid subscription. Of course, we hoped that would be the case but, in the absence of concrete data, we always try to keep new functionality as simple as possible. Our MVP was a plain signup form to create the account and page with a message asking customers to delete their account and sign up again for a paid plan if they took an action that initiated an upgrade.

We knew going in that this would not be an ideal experience for customers that wanted to upgrade and over the course of a few weeks, we heard from a handful exactly how dissatisfied they were with the process. With a few strong data points, we were able to make the decision to prioritize this work and deliver a new, easy upgrade process for those customers that want to benefit from our paid features. The entire process has just three steps.

1. Create a CodeGuard account with the free offering.


2. Select the upgrade option from the dashboard to see the available plans (image below intentionally large).

Screen Shot 2016-04-25 at 3.40.29 PM

3. Pick the plan that best suits your needs.


4. Enter billing information to initiate the new subscription.


This process of releasing and testing a small feature with “obvious” follow-on work, rather than doing all of the work up-front may seem counterintuitive to some. However, we have learned that our assumptions about how a new product or feature will be used do not always perfectly match what our customers need. So, rather than building something that we think is ideal, we release the smallest possible feature, make incremental changes, listen to or observe customers and iterate to build something that customers actually value.

Realtime Syncing with AWS Lambda

In one of our recent blog posts, we talked about the improvements we have made to integrate our WordPress plugin with our main CodeGuard dashboard. One of the issues we faced when working on this integration was making sure WordPress plugin data are synced with the dashboard quickly so users see changes in close to real time.

We’ve talked about how the CodeGuard WordPress plugin works in the past, but just to give you a short refresher: The plugin first scans the WordPress root directory for files. It splits this content between several small zip files that are then transmitted and safely stored in an Amazon S3 storage account managed by CodeGuard. Combined, these zip files make up a single backup. We also upload log files that can be used to determine which steps in the backup succeeded and which steps failed, as well as an integrity check that we use to verify all of the zip files are present in S3. In order to make details about the backup accessible in our main CodeGuard dashboard, we needed a way to analyze the information stored in S3 and record statistics in our Rails app database that we could then display to users.

Read More “Realtime Syncing with AWS Lambda”

Behind The Scenes: CodeGuard WordPress Plugin Architecture


We’ve talked before about some of the architecture we use to back up hundreds of thousands of websites and databases using FTP, SFTP, SSH and MySQL, but many of our customers have opted for the simplicity of our new WordPress plugin. In keeping with our other behind the scenes posts, we wanted to share a bit more about the technical aspects of the solution for those that are curious.

Read More “Behind The Scenes: CodeGuard WordPress Plugin Architecture”