Author Archives: admin

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!


March Feature Medley Series – Part 4: WordPress — The Beginning

Twitter Facebook

It’s been a very exciting week for the CodeGuard team. We’ve officially announced three new features at this point, and on top of that we’re in the middle of sponsoring the WordCamp ATL conference!

It’s time to announce the final feature this week for our March Feature Medley Series. We’ve saved this one for last because of the WordCamp conference, and that’s because it’s the addition of WordPress specific data-display in the CodeGuard dashboard!
CodeGuard WordPress Dashboard


If we detect that your website or database is running on WordPress, we can now show you specific information about your content such as how many current posts you have, users, themes, plugins, and more.
CodeGuard WordPress Information


Right now we have BIG plans in the works for WordPress websites. We’re not going to reveal everything that we have in the development-pipeline here today, but as a teaser we’re happy to say that we are moving towards a dashboard that can show you specific information based on the CMS you are using.
So, what does this new feature mean for you? Like our File Browser feature, this feature will be very useful to our customers who are trying to figure out what backup they need for a restore. Let’s say you want to restore your website back to a date it was a few months ago. You’re not really sure if you need a backup from February, January, or December… but what you do remember is the theme you had at the time, or what plugins you had installed at the time of the backup you need. This information gives our uses a quick and easy way to see what state their website was at, at any point in time.

What else do we plan to do with this feature? As a backup, monitoring, and restore service we hope to integrate WordPress specific information into all three of these core features very soon. This will make CodeGuard a more useable tool for people who use WordPress, design for WordPress websites, and develop WordPress websites. Basically, in the next few months you can expect many more exciting things to be released from CodeGuard!

Overall, we hope you’ve enjoyed our March Feature Medley Series. We started the week off by releasing our File Browser feature, and then announced our new Website Backup Success and Database Backup Success Graphs for the dashboard. Yesterday we proudly announced our heavily anticipated Test Restore feature, and today we are happy to close the week out with exciting news about our WordPress specific information display in the dashboard. Our team has been hard at work trying to make sure we started 2014 off with a bang. Do you think we succeeded? Feel free to leave us a comment and let us know!

Thank you for following our March Feature Medley Series!


CodeGuard at WordCampATL: T-shirts, MacBook Air Giveaway, Discounts, and Jobs!!

Twitter Facebook

Producing the most reliable website backup service on the market has not been easy. CodeGuard backs up over 100,000 websites and databases at 99.99% levels, for customers around the world. Our 1-click restores and ChangeAlerts have helped countless webmasters solve problems.

CodeGuard was designed to work with any CMS, and the backbone of our infrastructure is rock solid, with over 200 servers automatically spinning up and down each day to manage the backups. We even have external oversight systems that make sure our backups are not corrupt, missing files, or unusable, and track each step of our backup process to ensure backups complete on a daily basis. 

CodeGuard and WordPress

And having reached industry-leading performance levels, we are excited to focus on WordPress! As one of four platinum sponsors of the WordCampATL, held this Friday and Saturday, we are ready to hear from you, the WordPress community, with your thoughts and suggestions. We are looking for the best WordPress developers and designers to join our team to help bring our industry-leading reliability to the WordPress community.


5 ways we are showing our WordPress love

In addition to our Platinum Sponsorship, which helps to keep the ticket prices down, to show our dedication to the WordPress community, we will be:

1. Giving away a MacBook Air to one lucky attendee
2. Giving away 220 of our prized CodeGuard t-shirts, with 4 different designs to choose from
3. Offering a 67% discount for our Ninja plan – bringing the price to $20/year for WordCampATL attendees.
4. Holding a VIP Event at our office in the Brickworks (1000 Marietta St NW) on April 15th
5. Hiring 2-5 WordPress Developers and Designers to join our team!


Win a MacBook Air: Submission form here

To enter yourself for the MacBook Air drawing, complete this form: The drawing will be completely random, with a single number selected that corresponds with the submission number of the entry. You must be present to win, and the drawing will be held after the last speaker on Saturday.

Work with us! Freelance, part-time, and full-time opportunities

If you are interested in learning more about freelance, part-time, and full-time opportunities at CodeGuard, please complete this form. We will contact you with additional information about a VIP Event to be held in April: The event will be an informal gathering at our office in West Midtown, with appetizers and drinks, that allows for us to get to know you better, and vice versa.

Get a free t-shirt in exchange for a Tweet

To receive your t-shirt, you will need to tweet about CodeGuard. And to make things easy on you, here are a few tweets that you can copy & paste:

“Thanks @CodeGuard for the t-shirt. Website Backup FTW #WCATL”

“@CodeGuard is giving a MacBook Air away – stop by their table to enter! #WCATL”

“67% discount for the Ninja Plan? Yes, please. cgwcatl #WCATL”

“Just got my @CodeGuard shield shirt! Thank you! #WebsiteBackup #WCATL”

“Just got my @CodeGuard robot shirt! Thanks! #WebsiteBackup #WCATL”

“My @CodeGuard time machine t-shirt rocks. Stop by and get yours #WebsiteBackup #WCATL”

“Website backup is a no brainer. I’m gonna check out @CodeGuard! #WCATL”

“Restores that work? I’m all ears @CodeGuard #WCATL”

“@CodeGuard has freelance, part-time, and full-time WordPress dev & designer openings #WebsiteBackup #WCATL”

“Client-proof website backup? I didn’t know it existed! Thanks @CodeGuard #WebsiteBackup #WCATL”

“Backup without timeouts and reliance upon PHP? I’m listening @CodeGuard #WebsiteBackup #WCATL”

“But I thought all backups just worked : ) #RealReliability @CodeGuard #WebsiteBackup #WCATL”

“@CodeGuard showing the #WordPress love! Thanks for the t-shirt and I hope I win the MacBook Air #WebsiteBackup #WCATL”

“@CodeGuard seems serious about WordPress! Can’t wait to see what they produce! #WebsiteBackup #WCATL”

“@CodeGuard thanks for the t-shirt & Ninja discount! Code: cgwcatl #WebsiteBackup #WCATL”

March Feature Medley Series – Part 3: Automated Test Restore

Twitter Facebook

We hope that you’ve been enjoying our Feature Medley Series so far, because today we’re thrilled to announce the addition of CodeGuard Test Restore to the dashboard! This feature has been in the works for a long time. There were many technical challenges and hurdles that we had to overcome along the way. We knew it was a feature our customers craved though, so we rolled up our sleeves and got to work!

CodeGuard Test Restore


CodeGuard’s automated Test Restore allows you to test CodeGuard’s restore process/capability with your website without impacting any of your actual data. If a test restore passes you can rest assured knowing that should you need an actual restore one day, CodeGuard has you covered. If the test restore fails, we give you quick remediation tips for how to test our restore functionality manually, or contact us for further information. We highly recommend our customers try this functionality out for the peace of mind, and so that they can be 100% certain our system will work with their website when a disaster occurs.

CodeGuard Automatic Test Restore

How does CodeGuard Test Restore work?

Here are the steps that we take to make sure our restore process can work on your website:

* Connect to your website over SFTP
* Check the Write status of your website’s directories
* Check the Write status of the server your website is on
* Transfer data from CodeGuard to your website.

Those four items may not sound like a lot of work, but in reality there is a lot going on behind the scenes to make this magic happen! When we connect to your server we upload a ‘test’ .html file to your website’s root directory and then give you a link to go view the page live on your server. This file is then deleted in an hour, or when your next scheduled backup occurs.

CodeGuard Test Restore Success


Again, this process may seem simple, but there is a lot that could go wrong during all of this. Here are some of the failure cases we test for during the test restore process:

* Server connection errors
* Unable to connect to website over HTTP
* Unable to connect to website over FTP or SFTP
* Incorrect website login credentials
* Write permissions to the root directory path
* Server timeout errors
* Test restore file already existing
* Test restore file being too large
* Various other exceptions

We’ve had this feature live for all of our HostGator partner customers for about a month now, but today we have officially turned it on for every customer in CodeGuard. With the addition of the Website Backup Success and Database Backup Success graphs to the dashboard, and now with the addition of the Automated Test Restore feature, we hope to continue building trust with our customers, and continue building up their faith in the CodeGuard system.

Aren’t you curious about how your websites will perform should you need a restore? Login to the dashboard today to try this new feature by clicking on a website’s name and then by visiting the ‘Restore’ tab. As always, feel free to leave a comment or tweet us your thoughts!