[time-nuts] While we're discussing backups...

[brooke at pacific.net]

Hi:

I haven't been reading my email for a few months while I'm out of the
country but happened on this one while doing something else.

This is a subject where I have years of practical experience. Key Point:
In my experience the only backup that you can trust is one where you use
it immediately!

For example a friend was using a RAID system for a number of years then
one day got a message saying there was a disk problem.  He spent $4000 to
have a recovery service reclaim the hard drive.

To accomplish the backup what's needed is to make a clone of the hard
drive, remove the current hard drive as the backup and continue to work
from the new hard drive.  A side benefit of this is that the new hard
drive will have a larger capacity and cost less than the prior drive.

This was easy to do on WIN98 but starting with WIN XP SP2 you can NOT have
two bootable operating systems on the disk drives so cloning (Norton
Ghost) requires a boot into DOS.  This is probably a Microsoft anti copy
"feature".

Brooke Clarke




> Robert Vassar said:
>> There have certainly been some amusing replies.  My only point was
>> that if it you are storing stuff on "spinning rust", you can't call
>> it a backup if it's still spinning.  Power it off and de-cable it.
>> How much further you go after that to protect it depends on your risk
>> requirements.  I did like the zip-loc bag idea.
>
> I've been trying to stay out of this, but I have some expertise digital
> asset preservation, as it has been a recent research area of mine.
>
> (Someone referred LOCKSS -- that's good work and a nice place to start;
> one
> of its creators is a colleague of mine.)
>
> A couple points are worth making:
>
> Diversity of all kinds is good.  This would include geography, operating
> system, media, administrative control, 'players' (i.e. someway to
> interpret
> the bits) et al.
>
> Extra copies are good (and, yes, you can use coding to avoid 100% overhead
> for every copy), but you rapidly lose the benefit of the extra copies if
> you
> do not actively repair them quickly (enough) after they fail.
>
> And here's the rub: a significant fraction of storage failures are latent
> --
> they go undetected until you attempt to retrieve and 'perform' the asset.
>
> So to make sure your copies are good, you must audit them regularly.
> Given
> trust between administrative domains, this can be as simple as comparing
> cryptographic hashes of the bits.   (There are also schemes that work
> without assuming trust.)
>
> I don't have the ref handy at the moment, but we have a model and math
> that
> quantifies the issue around latent errors.
>
> But don't audit too often, if the auditing mechanism causes wear.   How
> often is often enough is left an exercise for the reader.
>
> These are of course general principles.  You still need to look at your
> threat model and the value of your data and make reasonable engineering
> choices.
>
> -ch
>
>
>
>
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>