Drobo Drive Failure: Lesson Learned? Again?

 

Well, my Drobo is up and running again.  All my data appears in tact.  Wonderful!  Now we go merrily along like nothing happened, right? Not quite.

Today, I have the backup bug.  The backup bug is a wonderful thing.  Simply put, I have the incredible urge to back everything up.  Make multiple copies of everything I don’t want to lose and securely distribute those copies out into the universe where, one day, I might call on them to resurrect themselves.  Yeah!

I also know  something about the backup bug: it will go away quickly.  Today my data are safe, and they’ll probably be safe tomorrow.  I can put it off for a couple days while I resolve other priorities.  Days will become weeks and weeks will become an unknown amount of time until my next hard drive failure.  It will come.

When that hard drive failure comes again, and it will, I’ll be kicking myself, fixing the problem and hopefully moving on with minimal data damage, but with a huge loss of time.  While I probably will have minimal loses, it’s still a waste.  With 2 TB hard drives getting down to as little as $100 these days, it’s cheaper to buy a bunch and consistently backup rather than lose a couple days fixing the problem.  It’s a hard lesson to learn.

What really kills off my backup bug is organization.  I have the space to properly backup, particularly today.  However, the question because what and how to backup.  I don’t want to backup everything, just those things that are not adequately backed up.  I have several categories for my data:

1. Active  - Active data are those things I’m actively modifying.  Writing projects, for example.  These require constant backup.

2. Inactive - Formerly active projects that are retired.  I may want them on my computer or server, but they only need multiple static copies.

3. Configuration - those files that are used to configure my computer - the OS, for example.  These, like Active projects, should be constantly backed up but not necessarily in the same place.

4. Replaceable - if the files are not really mine, like an application disk image, and can be reacquired generally shouldn’t be backed up, unless they are no longer available.

5. Temporary - judgement call - once it’s backed up, it might be around for a really long time.

In any case, none of my files are organized this well… I should probably get to it if I’m going to get anything before the backup bug goes away.

, styled with lin.css