Can anyone recommend a good backup "system" for a developer?

Question

I'm known around the office as "the backup guy". As a developer, I often jump back and forth between projects, and as a result I don't always remember exactly what changes were present in each when I return to them. I usually have to compare my local changes versus those in our source control system, and then I'll eventually remember it all. Thing is, I don't always have the luxury of doing this. Sometimes I have to build something for a client quickly, and so I make a backup of the working directory, and that way I can get the latest files from source control, and build the DLL quickly - all while knowing that the other (in-progress) changes are safe.

The problem is that I've now accumulated a bunch of backup folders in each project directory, which makes it harder to find the specific change I was looking for. while my practices have evolved to the point that I always take the time to give each backup folder an informative name, I'm starting to think I'd be better off writing my own tool.

For example: If I select a few folders in windows explorer, I'd like to have my own context menu item that triggers my own backup application. This application would prompt me for a backup name, and description. It would then move the selected folders to a specific, centralized backup directory - where it would also generate a 'readme.txt' file, outlining the backup details. Also, the backups would also be organized by date/time. I feel this would refine my backup procedure, and facilitate future lookups.

But yet, I can't help but wonder if such tools already exist. Surely, someone must be as obsessive as me when it comes to backups.

Do you know of any tools that could help me improve my backups?

I'm aware of this post, but isn't exactly aligned with what I want. I'd prefer to keep the backups on the same machine - I'll handle moving them over to other machines myself.

Update

To clarify: If I'm working on Task A, and suddenly I need build something for a client (Task B), I have to backup what I have so far for Task A, and get the latest from source control into the working directory. I then start and finish Task B, and then restore Task A. This is an ideal, neat scenario. But sometimes, I only get back to Task A a week down the line, or further - because I get hit with Task C, Task D, etc - all of which affect the same project. Now, if these changes are scheduled to be checked in, then I would probably benefit from checking them in as I progress (but to be honest, we usually wait until it is complete before we check it in, at this company - that means less checkins of unfinished code). So I'm not sure if each of my backups should equal a branch - because I'm sometimes excessive with my backups.

Answer 1

I think what you want is a distributed version control system, such as git.

Answer 2

First, your existing source control system can probably already support this, in the form of branches. Instead of just copying the working directory, commit it as a separate branch, where you can keep that client's version of the application.

However, as skiphoppy said, a distributed source control system would be much better suited for this. I quite like Bazaar, but git is very popular too (although I don't know how good its Windows support is, since it is primarily a *nix tool developed for the Linux kernel)

Answer 3

Subversion using TortoiseSVN will provide you with this functionality. The concepts are different (revisions, not "backup names") . The readme.txt that you make mention of is summarized in the Subversion log. Any comment that you provide can be used to guide others looking at the revision. Check out the Wikipedia page on Subversion as well as the homepage to download it and TortoiseSVN.

Answer 4

CloneZilla, backs up your entire hard drive partition, its free and reliable. I use it in place of Acronis Echo Server, and it restores my entire system in 8 minutes.

Answer 5

As skiphoppy says, a DSVN can really help. Git offers the ability to shelve the stuff you're working on now so that your working copy is clean yet you can pull your current working set off the shelf when you're done. That seems like what you really want.

If you're using Perforce, there's a couple of tar-based utilities that do this, too, but I haven't yet used them.

Answer 6

How about changing the way you work, sounds like one day things will go tits up if you carry on as is. Fair enough on the need to build a dll mid way through a change and having to back up your work in progress, but once release is done then re-integrate your changes with the release version immediately. I'd never allow myself to have multiple back ups of the same app, but hey, that's just me.

Answer 7

I think it's a pretty reasonable practice to check in every night. Sometimes I check in 3 or 4 times a day, sometimes 20 (every time my code is working, actually).

If your code is always checked in, you should easily be able to just sync to a different branch without backing anything up.

If you can't check in your changes by the end of the day, a very reasonable answer is to discard them. You are most likely in some hole that you will have trouble digging yourself out of, and the next day you will replicate the work in an hour and do it MUCH BETTER than you did the first time. Also, if you go that long with broken code, how do you test?

Finally, if your code REALLY can't be checked into the build every day (it actually does happen in some situations, regardless of what I said in the previous paragraph), branch.

No more backups.