GoDaddy Backup and 1&1 Website Backup Made Simple

Twitter Facebook

We know that our customers’ time is extremely valuable, and we want to do whatever we can to minimize the amount of time spent configuring and managing backups. To that end, we’ve designed our system to be robust and reliable, so that after websites and databases are added to CodeGuard customers can trust that their backup will be taken care of every day.

GoDaddy Backup Made Easy

For some time we’ve been working on extending those same concepts to our initial setup process. To date, we’ve asked customers to provide us with all of the connection details for their website. For many, gathering their FTP/SFTP server hostname, FTP/SFTP username, FTP/SFTP password, MySQL database hostname, username and password is quite a chore. We’re excited to launch our new website addition process that allows customers of several large hosting providers take advantage of our new automatic account configuration. All you need to do is provide your hosting account credentials and select which websites and databases you would like to be backed up. The entire four step process is as follows:

Step 1: Select your host

The first step when adding a new website to CodeGuard is selecting a host. Currently, we support automated website addition for GoDaddy backup and 1&1 backup. If your websites are not hosted on either of these providers, the “Other” option takes you to the advanced website connect process.


Step 2: Provide your hosting credentials

Next, the customer is prompted to enter credentials for his or her respective hosting provider. These credentials are 100% secure and are only used one time.


Step 3: Select a Hosting Account

Then, the customer is asked to select a hosting account, which has various websites associated with it.


Step 4: Select a website

Finally, the customer is prompted to select a website to add to CodeGuard.



Throughout this entire process, CodeGuard makes secure requests to our new application Viper. This application drives a headless web browser using Watir and PhantomJS to log into the customer’s account and retrieve the necessary information. When a customer selects a website to be backed up, Viper creates a background job which automates all of the required steps to enable website backup. Within a short time, the customer receives an email that his or her website is being successfully backed up with CodeGuard.

Working with a hosting provider in this way can be complex, so Viper has several monitoring tools which allow for a seamless customer experience and quick failure notification. If anything goes wrong during any of the website addition steps, Viper promptly notifies our team, so we can address the issue and inform the customer that the issue has been resolved. We also run automated tests several times per day to ensure that any changes to a hosting provider’s website are immediately noticed and Viper gets updated.

Looking towards the future, our main goal is to ensure that every CodeGuard customer can take advantage of these new tools. For example, Viper currently detects WordPress sites and adds both the website and database to CodeGuard without requiring any extra information. However, this feature is only available for GoDaddy backup customers. In order to improve every CodeGuard customer’s experience, we are working on extending Viper’s functionality to as many hosting providers as possible.

-Tripp Roberts

The Easiest Way to Upgrade Your Site to HTTPS

Twitter Facebook

Google just changed their ranking algorithm to give a boost to sites that use https instead of http. Even if you have a content site or a personal website, it makes sense to take all reasonable measures to secure it from hacking, especially when Google could give your site more traffic.

The easiest way to get https is to use a paid CloudFlare account and turn on Flex HTTPS. This avoids the need to buy and install a security certificate, saving money overall. CloudFlare also helps protect your site from malicious bots, hackers, and denial of service attacks.

To configure CloudFlare for HTTPS, login, click the gear icon next to your site, and choose “CloudFlare settings”. Then set the SSL switch to Flexible SSL.  This encrypts communications between CloudFlare and users. CloudFlare still communicates with your web server via http, eliminating the need to make changes there. Most man-in-the-middle attacks happen close to where the user connects, such as an un-encrypted WiFi network vulnerable to Firesheep, or a hotel network that splices ads into web pages, not between major Internet services such as CloudFlare and your hosting provider.

Flexible SSL

After making the switch its necessary to test the site to make sure you get good lock symbols on all pages. If you have embedded assets using non-secure http protocol, you need to update those to https. Search the code for the string src=”http: to find them.

Green Lock Means Secure

To redirect http to https when using CloudFlare, add the following magic code to your .htaccess file, if you have a Linux/Unix server.

RewriteCond %{HTTP:CF-Visitor} '"scheme":"http"'
RewriteRule ^(.*)$$1 [L]

Remember to update your robots.txt file and your sitemap.xml file to use your new https urls. Lastly, update Google Webmaster Tools and Google Analytics to reflect your new website URL.

Keep CodeGuard in your Pocket

Twitter Facebook

CodeGuard's got you covered from your pocket.

If you haven’t already discovered the CodeGuard iOS app, we thought that it was time to give it a formal introduction. The app allows you to monitor your backups from your iPhone or iPod touch, allowing you to take CodeGuard with you and giving you a greater peace of mind.  It also allows you to find out when things change right away, without having to check your email or log in on a computer. Want to know some more specifics? Let’s take a look at some features.

When first logging into the CodeGuard App, you will see a list of the websites that you have backed up on CodeGuard. Tapping any of those websites will take you to a screen showing the most recent backups for your site. You can even scroll all the way back to your oldest backups, with more loaded the further you scroll. If there were any changes on your site for that backup, you can tap on that backup to see more details. On the details screen, you will be shown the total number of files added, changed, and deleted for that backup, as well as a list of the names of the changed files.

Easily navigate to the site and backup you are looking for.

Easily navigate to the site and backup you are looking for.

You might want to view your backups by date instead of by site, especially if you have a large number of sites backed up. (Here’s looking at you, Samurai and Shogun customers!) Just take a quick detour to the Settings tab, tap on “Layout Settings”, and switch from the default “Display Backups by Site” to “Display Backups by Date”. Now, back on the main “Track Backups” tab of the app, you will see a list of dates to choose from. Selecting one of these dates will display a list of all your websites and a short summary of that day’s backup for each site. If you want to look into any of these backups, you can still access the same detailed view by tapping on any of the changes that occurred for that backup.

See a breadth-first view of all the backups from a single date.

See a breadth-first view of all the backups from a single date.

Previously, only our CodeGuard direct customers have been able to use our iOS app. Because logging in required a username and password associated with a CodeGuard account, none of our customers who access CodeGuard through their hosting provider could use the app. If you’re one of those customers, we have exciting news for you. In the app’s latest release, we have built in a QR code scanner that you can use to log in to your account.  Just scan the code generated in your dashboard (look under “Settings”, then click on “Mobile”) and you’ll be ready to go.

Access your unique code to log in from the “Mobile” page found on the Settings drop-down menu.

Access your unique code to log in from the “Mobile” page found on the Settings drop-down menu.

Just tap “Log in with QR code” and the log in scanner will appear.

Just tap “Log in with QR code” and the log in scanner will appear.

Even when you aren’t actively using the CodeGuard app, We’ll let you know what’s going on with your site. Whenever a website is activated on your account or a significant change is  detected in a backup we’ll send you a notification letting you know what’s up. Whenever a website is activated on your account or a backup is taken, we’ll send you a notification so you know CodeGuard is still working. (Note: Push notifications for the CodeGuard app must be enabled in your iPhone’s Settings to receive notifications.)

That’s a basic summary of the essential features of the CodeGuard iOS App. But that’s not all; we have more updates planned for the app in the future. In the meantime, it’s already available on the App Store so you can try it out for yourself today.


Announcing New Backup Retention Settings

Twitter Facebook

One of the things that makes CodeGuard a leader in the website backup space is our incremental and differential storage engine. This technology allows us to backup and restore websites quickly while using as little storage space as possible. For all of its advantages, this system does have one drawback. Due to the way that each backup incrementally builds on the one before it, removing old backups is a challenging task. Customers have requested the ability to remove old backups from their account and, to date, the solution has been a manual one. However, we hope to make this process much easier with our new Backup Retention functionality. The new Backup Retention option gives customers the ability to keep only the backups that they need and get rid of the rest, or they can keep every single backup for as long as they want.

Backup Retention allows customers to reduce their storage footprint by automatically removing old backups from our system. CodeGuard customers can now visit their Settings Page to adjust their Backup Retention period. You can choose to keep either 90 days of backups or all backups. If you select 90 days, we will periodically remove old backups so that only backups from the last 90 days show up. If you would like to keep more than 90 days of backups, just select “Keep all backups”. More options are on the way.

Keep all backups or only the most recent.

Keep all backups or only the most recent.

What’s so hard about removing old backups, anyway?

Although the process of removing old backups may seem like an easy task, creating the new Backup Retention feature took a lot of time and effort. The reason it was so difficult to implement has to do with the way that our incremental backup process works. Traditional backup processes copy all data from the source to the destination each time a backup is performed. CodeGuard uses an incremental backup process that only copies the changed data from the source to the destination for each backup. Both traditional and incremental solutions make a full backup initially. The difference is that traditional backup processes continue to take full backups, whereas incremental processes only store the changes on subsequent backups. This means that incremental backups take up much less space, but it also means that removing old backups is difficult. Since each new backup is based on the previous backup, removing an old one will affect all backups that occur after it.

Each backup builds on the previous day.

Each backup builds on the previous day.

Getting technical

CodeGuard’s incremental backup solution is based on a version control tool called Git. Git can be used to track changes made to a group of files, called a “repository”. It is an incredibly powerful tool originally built for developers to help them track code changes. It’s not just for keeping track of code, though. Git can also be used as a great backup utility for storing any kind of file. In fact, the popular backup program bup is based on Git. There is, however, a minor downside to using Git for backups: Developers frown upon rewriting the file history that Git keeps track of, and so the creators of Git did not make removing old backups, or “commits” easy. In addition, each new commit is closely tied with all of the other commits in the repository, which means that it is very difficult to untangle one backup from it’s neighboring commits.

Rewriting history

To solve this problem, we created a new tool, that we call git-tail, to handle the complex logic needed to combine incremental backups and remove files that are no longer needed. It uses the “git filter-branch”, “git update-ref”, and “git-gc” commands, among others, to rewrite the Git commit history, remove old files and commits, and compress what’s left so that it takes up as little space as possible. Here’s a snippet of the code from our open-source git-tail repository hosted on GitHub:

git-tail shrinks a repo by removing commit history.

git-tail shrinks a repo by removing commit history.

This ruby code replaces the head of the commits we want to get rid of with a new commit object. It then rewrites the commit history, removes the old commit, and removes any references to the old commit.

One at a time, please

What happens if a CodeGuard customer tries to restore a backup while their backups are being removed? This is a problem we had to address while creating the Backup Retention functionality. If the restore is allowed to take place at the same time that removal is occurring, the files may not be restored correctly. Resource contention and synchronization are common problems for developers. To handle this issue CodeGuard has locking mechanisms in place that allow only one process to use a resource at a time. In the above scenario, the code that handles backup removal will ask for a lock before it begins. This lock prevents any other processes from accessing a customer’s backup while the removal task is running. Then, once the job is done, it releases the lock, and the restore process can begin accessing the customer’s backups.

Now that you understand how it works, it’s time to try it out! With our new Backup Retention feature, it’s now easier than ever to manage the storage size of your CodeGuard account!

Coming Soon to CodeGuard: Restore Progress Tracker

Twitter Facebook

The feature: Restore Progress Tracker

Over the last few weeks the CodeGuard team has been working hard on a new feature we are excited to release soon: The Restore Progress Tracker. Coming soon to the dashboard, whenever you request a restore you will be able to see live, real-time progress on the status of the restore, along with an estimated time for completion, and what step in the process it is currently in.

Screen Shot 2014-07-11 at 1.32.22 PM

We’ve had a very similar feature in our dashboard for a long time now: The Backup Progress Tracker. When a customer adds a website or database to CodeGuard for the first time we show you real-time updates on the status of your first backup. It’s been a long time coming, but we’ve finally been able to extend this functionality to our restore process as well. Right now our real-time updates for restores will only be available for our Automatic “One-Click” Restores, our Individual File Restores, and our Database Restores. This excludes our Download Zip feature for the time being.

If you’re curious to learn about the development challenges our team went through to make the magic happen, keep on reading!

The challenges:

This project wasn’t so much a design challenge, because we had already developed our Backup Progress Tracker feature (most of the UI was recycled), but more so a development challenge because the processes are completely different. The main problem to solve was, “How do we show real-time restore progress in our dashboard? How do we get this information about our restores?” For me, the project got divided into three main parts:

  • How do I solve this problem for Automatic “One-Click” Restores?
  • How do I solve this problem for Individual File Restores?
  • How do I solve this problem for Database Restores?

When it came to the steps these restore types went through there were a few similarities, but there were also a lot of differences. At the start of the project these differences were a “black box” for me though, and so I set out to meet with two of our back-end gurus, Jonathan and Michael, to get a feel for how these processes work. After an hour of lively white-boarding we were able to document exactly what is going on behind the scenes with each restore. The main steps of the restore process are as follows:

  1. A CodeGuard server is started to begin the restore
  2. A connection to your server is opened to perform the restore
  3. A pre-restore backup is taken just before the restore begins (Not for Individual File Restores)
  4. A comparison is made between your current website and the backup you have chosen to restore to (Automatic “One-Click” Restores only)
  5. We modify the running website: add files, remove files, override existing files (Not for Database Restores)
  6. We push the selected backup to your database (Database Restores only)
  7. We finalize the details with logging and get ready to email you
  8. The restore is complete!

You can see with the comments I made in parenthesis that it was a somewhat tricky task to organize all those steps! This brings me to the next major challenge I encountered, which was how to develop these views to show the proper steps based on restore type without unnecessarily duplicating tons of code. I didn’t want to have to create a separate view in the application for Database Restores, a separate view for Automatic Restores, and a separate view for Individual File Restores. To me that seemed a little wasteful, and I knew there had to be a smarter way to write the code.

Screen Shot 2014-07-11 at 1.36.26 PM

While I worked on a sane way to do this, another challenge arose, which was how do we decide when to show this view (partial) in the dashboard? When a restore is ongoing in the dashboard, it has a Status and a Type. The restore Type correlates to what type of restore it is (naturally), so Automatic Restore, Individual File Restore, or Database Restore. The Status of the restore determines what point in the process it is at (Not Requested, Requested, Backing Up, Comparing, Transferring, Finalizing, Delivered). We obviously didn’t want to show this view in the dashboard if no restore is in progress, but if a restore just completed (and is “Not Requested”), we wanted to be able to keep this view in the dashboard for a period of time to give the customer a chance to view it and see what happened.

To overcome the challenges of what to show and when to show it, I relied heavily on the Type and Status attributes of the restore to drive this view. By utilizing these attributes I was able to code the Restore Progress Tracker in one main view! Granted, it is a very large view, but with one main location for this logic I was probably able to avoid duplicating hundreds of lines of code. Don’t get me wrong, the “genius” of this work was definitely not accomplished by myself alone! I continued to interact heavily with Michael and Jonathan on the team to figure out the best and most efficient way to tackle this project throughout it. In the end, I think we were able to solve these challenges as they came in a great way.

Screen Shot 2014-07-11 at 1.39.35 PM

While I worked on the views, Michael was able to figure out a way to intelligently calculate the estimated time of completion for the restore. This involved analyzing how long previous backups and restores took to complete for that website/database and then by using that data to drive our estimates. Jonathan was also able to help me in a big way when it came to the “real-time” component of the feature, and figuring out a way to refresh this content every few seconds for real-time progress. Overall, I had a lot of fun watching us come together during this project to conquer our coding challenges!


With our development challenges out of the way, our next challenge is to deliver to you, our customer, the restore experience you want and deserve. Our main goal with this feature is to make restores a little less scary, a little less of an “unknown”, and as a result a lot less stressful for you and your business.

I don’t want to tease too much, but I would like to note that the Restore Progress Tracker is just one part of a much larger set of enhancements we have coming soon to our restore experience! Hopefully this current enhancement will hold you off until our next major improvement is released (stay tuned!).

To conclude, we certainly don’t want anything bad to happen to your websites or databases, but if disaster does strike and you need to restore your content, rest assured that CodeGuard will let you know what is happening every step of the way. You can expect to see the Restore Progress Tracker in the dashboard within the next week, and if you do encounter it, please let us know what you think!