Why We Built BackHub

by Daniel Heitz | Last updated on January 20, 2014

We initially built BackHub because we saw the need for it in our day-to-day work. We needed backups of running projects and a way to archive our inactive repositories. Like other small teams, we also wanted to save money on our GitHub plan.

Recognizing the value of Backhub to other teams led us to launching our tool as a service.

Since we started using GitHub, it has become a linchpin in our project development process. GitHub is the place where we communicate everything from epics and stories to actual tasks, and from product specifications to the definition of done.

Considering that all our business value is in the cloud, placed in a proprietary system we can’t control, we greatly value a program that gives us additional safety to preserve our work. And although we could install GitHub Enterprise on our own servers, it’s not cost-effective for us.

This early version of BackHub provides:

  • Backups of all repositories, including all metadata
  • Archives of inactive projects, giving us space for new ones

Backup Repositories

There are many solutions for backups, but most of them can’t backup private repositories, and none of them are able to restore backups properly.

A backup repository solution should provide total peace of mind. It should have solid answers for questions such as: What if I don’t have local copies of the repository? What if our projects are deleted or destroyed by a rogue team member? What if team member passwords are leaked? What if GitHub is unavailable or accidentally loses our data? What if all our issues and milestones are changed or deleted?

Besides the code itself, there is also metadata around a repository. For us, this is almost as valuable, since we use metadata to write our stories and tasks (using milestones and issues). Milestones, issues and comments lack versioning, however, so anyone on the team or with access to our repository could delete valuable information. That`s why we needed a solution that not only backs up code, but all the metadata associated with it.

Backups of all the value, repository and metadata, give you peace of mind and keeps you independent.

Archive Repositories

Since we do client work, we are not only working on one big project. We also develop many small projects. After delivering a project, we go on to the next one.

Most of these projects either need very little maintenance or are handed over to an external company that maintains the product or website. In this case, although we transfer ownership of the repository, we still want to keep a local copy of the project for the records.

Metadata is not included in regular backups or local copies of a repository, yet it also contains valuable information:

  • Issues: what was done and by whom, which commit refers to which story or task
  • Milestones: what was delivered and when. And in our case, since we use milestones as SCRUM stories, which issue refers to which story
  • Wiki: all the information associated with a project, specifications, definition of done etc.

Once a project is inactive, it no longer needs to be kept at GitHub and we don’t want it to count against our private repository quota. If this were the case, we would need to invest in a larger plan every few months.

Thanks to BackHub, which backs up code and all metadata associated with it, we can delete such repositories on GitHub and only restore them when doing maintenance or further developing an inactive project.

Archiving inactive repositories both keeps our GitHub account clean and saves us money on our GitHub plan.

Update: Since this early version, Backhub Basic, we have implemented our service as an app called BackHub on GitHub Marketplace. This is a more robust and reliable service that offers important benefits, including integrated billing, daily snapshots for the month, cloning, and external storage. BackHub Basic is no longer offered.

Profile picture of <a class=Daniel Heitz">