Disaster Recovery is something most people only think about right after a natural disaster. Business continuity (Latin for “Will you go out of business if your office floods?”) is usually an afterthought. The truth is that most of us are too busy to spend a lot of energy on the hypotheticals of disaster recovery and business continuity planning. While we often think of our workplaces as impervious, the truth is that computers are fragile and buildings are damaged frequently. Flooding, fire, theft, and tornadoes are all common enough that every development team should have a contingency plan. But as we enter the traditional peak of hurricane season in the Atlantic, let’s take a quick look at the the recoverability of Subversion and Git repositories in case of catastrophe.

Hurricane Sandy Aftermath in New York City: Is your server safe?
Image used under Creative Commons License from David Shankbone .

If you’re a Git user, you probably already know that Git is a distributed version control system (DVCS) that is designed without a single point of failure. Every clone of a Git repository contains all the information it needs to become the “master” at any time. So if your main Git server is destroyed in an catastrophic event, you can recover completely using any developer’s clone of the repository. Its peer-to-peer nature is one of the major differences between Git and Subversion. I wrote recently about some factors influencing how to choose between Git and Subversion.

Subversion is a centralized version control system, so all clients don’t carry the entire history of the repository. That means that the master repository needs to be protected to ensure that you don’t lose any code in case the master is destroyed. One easy way is to use ProjectLocker Subversion. In addition to our redundant primary storage, repositories are backed up to redundant storage over 2,000 miles away from the primary servers. So using ProjectLocker gets you a high degree of disaster prevention.

But you may be surprised to learn that Subversion has built-in features that can let you easily build in provisions for business continuity in the case of a technical disaster. With Subversion replication, you can configure a Subversion repository to replicate to a mirror repository. The mirror will automatically receive the entire history of the repository and all the information needed to reconstruct the repository. So if your company has multiple offices, you can easily mirror your primary Subversion repositories to a backup server in a different location.

You can even use ProjectLocker as a business continuity mirror for an in-house Subversion repository. If you have an in-house Subversion server, you can improve your disaster recovery planning by configuring your repository to replicate to ProjectLocker. Your mirrored repository will automatically benefit from all of the data protection, backup, and security we apply to primary repositories. And you’ll have a quick way to recover in case there’s a disaster incapacitates your office server. Reach out to us if you’d like to set up ProjectLocker as a mirror of your in-house Subversion repository.

What else do you do for disaster planning for your development environment?