It's not about source code backup. It's about a developer not losing half a day when an SSD dies. With RAID1, at least in theory, when one dies you should be able to replace it and keep going.

Thats what time machine with a relatively slow external firewire HDD is for. It would only lag by an hour at most.

Are you serious? The goal of RAID is to eliminate downtime; a drive fails and you pop in a new one. All without ever having to reboot or even stop working.

With Time Machine, you still have to manually rebuild your system after your drive fails. This is not what Time Machine is for; it's for, "oops, I shouldn't have deleted that file". (Which, incidentally, RAID is not for.)

RAID + SSD = no TRIM (cept for recent Intel drives). That's a problem. It's easier (and much cheaper) to just have a bootable backup that's updated nightly.

Even a RAID1 failure requires you to have a replacement (ie, trip to Fry's). A bootable backup, however slow, is just there.

Pretty sure this is not the case for Linux. LVM supports discard, so md probably does as well.

Also, you don't immediately need a replacement drive: RAID1 boots fine with only one device. Assuming your company policy is to have RAID1'd SSDs for all developers, you're probably going to have extras on the shelf anyway.

Time machine is for accidental data loss. RAID is for disk failures.

Exactly.

A nightly differential bootable system image backup a la SuperDuper, Macrium Reflect, Acronis or the like + cheap external 3TB drive = zero downtime... if the SSD fails, boot from external, and schlep it while the SSD is repaired/replaced.

Time Machine is bonus for lost/overwritten local files. Source Control guards the jewels (you don't fear committing untested code to local branch, do you?)

Going half a day without committing code is missing the point of version control.

I think a lot of people would disagree with that statement. If you are committing that frequently then there are probably instances where you are checking in half written code that does not even compile. If you are using DVCS chances are your commits are still only stored on your local machine and just as susceptible to loss. If you are using something centralized or pushing your changes you are potentially going to disrupt the rest of the team unless you are working on a private branch. In that case, it seems as if version control is being used as a backup system where a substantial number of revisions cannot even be built. I think that is poor use of version control. It becomes difficult (at least for me) to analyze past changes (maybe months after the fact) when some of the versions are half-baked ideas that I committed for safety before going out to lunch.

I think there are two requirements here: 1) redundancy of work in progress and 2) change control management. I want my work in progress to be relatively safe from failures, I want it to be automatic and I want to be able to choose which changes are worthy of their own revision number in version control. Personally, when committing work in progress I want my revisions to represent a logical stopping point and not necessarily dictated by how much time has elapsed since the last commit.

i think the parent meant that the developer would not be able to get any more work done during that day because their machine is without a hard drive, not that the code on the hard drive would be lost.

The better solution here is to have a couple of "gold disks" of a default developer machine; with all the required programs etc.

That way if you go down you can just swap the drive out and be on your way again.

This is what we do (and we have a lot of hard drive churn due to heavy use) and it works well.

I think I would rather have the RAID so I don't have to take as much time. Setting up the personal info stuff on a machine takes time too.

For Linux / Windows folks, SuperMicro has a nice tower that has 4 hot swap hard drive bays that I really like.

Things like Chrome and Dropbox have made this less of a chore.

Speaking only for myself... I have a gold disk plus a little script that syncs scripts and configs to backups. And I use Chrome logged into my Google account.

I do see your point, but a lot of it can be mitigated.

Between BitBucket and Dropbox, it takes me no time at all (well, a little time to sync Dropbox, but I'm busy in those times).

This recently happened with our main content server. I had been bugging my boss for almost 3 years to do backups of the system data as well as the content data, but his logic was that since the system was RAIDed, even if we had a loss of data, the RAID would allow us to swap in new drives.

Well, our air-conditioner went out for 3 days in the middle of a Japanese summer, and the RAID controller itself shorted out, taking the drives with it. My boss still doesn't understand how we lost our data, because "RAID was supposed to protect our data."