How/Where to back up local checkout of a DVCS between pushes to the server?

Question

Do you (and your team) back up your local checkouts of your DVCS (Git, Mercurial) repository between pushes? How do you do so? If your hard drive were to fail after writing a bunch of code that was not yet stable (therefore not yet pushed), how would you get it back?

Answer 1

I'm paranoid.

Besides our central repository (set up with git init --shared --bare), I have another mirror repository set up on a network drive:

cd /network/drive
git init --bare
cd /local/repo
git remote add backup --mirror /network/drive
git push backup

I just occasionally push to backup, and since it is a mirrored repository, it's essentially just a full clone of my local repository.

Answer 2

Hello,

Funny that you ask this question because I just had a meeting last week where i heard some people were using commit/push of non-runnable even non-compilable code on the authoritative repository just to save it! (Note: it's different from what Mark says). It appeared so wrong to me and so getting in the way of Continuous Integration that we decided to install an rsync-based backup server so that the developers would realize how complementary version control and backup tools are!

I haven't yet installed the server, but if you have a spare Unix machine with an ssh server running on it, a simple crontab could do the job, e.g. using ssh and rsync (if you have an NFS-mounted partition, it would even be simpler):

$ crontab -l
# m h  dom mon dow   command
0,15,30,45 * * * * if `ping -c 1 machine.domaine.com
> /dev/null 2> /dev/null` ; then export SSH_AGENT_PID=
"`pgrep -l ssh-agent | cut -d' ' -f1`" ; export SSH_AUTH_SOCK=
"`/usr/bin/find /tmp -path '*ssh-*' -type s -user name -group
gname -name '*agent*' 2> /dev/null`" ; /usr/bin/rsync -avz -e ssh
--quiet /home/name/src [email protected]:/home/name/backup/src ; fi

(I assume that you can log in the machine using ssh, that you have an ssh-agent running and have used ssh-add).

This way, every 15 minutes, on-going work is saved, and as rsync is quite fast figuring out what has changed, it shouldn't make your workstation too slow.. In case your disk crashes, simply log into machine.domain.com, use your backup-ed credentials :-) and continue to work...

Hope it'll help.

Cheers,
Christophe.

= Security is mostly a superstition. It does not exist in nature. -- Helen Keller =

Answer 3

Yes, you should use a normal backup system in between your commits.

In fact, version control has nothing to do with backups. By this I mean that you should put a backup system in place for all employees, whether they are developers, secretaries, managers, or something else. The desktops should be backed up regardless of whether or not they are using a version control system.

I see a version control system as a crucial tool used to structure software development and to enable many people to work together. It is an essential tool when you need to maintain several parallel releases, or when you need to investigate a bug. You may be able to use a backup system to figure out when a bug was first introduced, but you cannot use a backup system to maintain several parallel branches. So a version control system gives you more than a backup system, and a backup system complements a version control system by taking care of all those uncommitted files.

Now, you will of course want to make backups of the repositories themselves. With distributed version control this is super easy -- you just push from your local repository to another repository on a remote backup server. This way the VCS will take care of locking and ensure that you have a consistent state on the backup server.