[H-GEN] CDs vs tapes [was: Assistance Required]

Jason Henry Parker jasonp at uq.net.au
Sat Mar 30 04:42:12 EST 2002


[ Humbug *General* list - semi-serious discussions about Humbug and  ]
[ Unix-related topics.  Please observe the list's charter.           ]
[ Worthwhile understanding: http://www.humbug.org.au/netiquette.html ]

Robert Brockway <robert at timetraveller.org> writes:

> On Wed, 27 Mar 2002, David Jericho wrote:

> Swapping 45 CDs (roughly equivalent to 30Gb) sounds like fun.

Oooh, yes.

Ick.

> As someone (Ray?) mentioned in another post, they're fine for
> backing up a certain amount of data (say financial records) but I
> prefer to look at the worst case - the need for a full restore[1]

This is just what I back up to CD, to cover for `oopses' by the
relevant staff or software.

> [1] Actually the worst case is that the office & all servers are gone and
> all you have is insurance money to buy new gear and some tapes to 
> restore data from. [2]
> 
> [2] Come to think of it, the worst case scenario is _not_ having insurance
> money to buy new servers, but that is a different topic.

Well, no, *worst* case is you have no backups, either.

> The longevity (or rather lack of longevity) of just about every storage
> medium we currently use is raising questions about how much of our media
> will survive 100 years,

One hundred years!?  Don't make me laugh.  The only way I'm aware of
to *guarantee* data will last 100 years is to write.  it.  down.  On
paper.  (Or *perhaps* you could stamp it into gold leaf.  Hmm.)

> [2] Some very old movie prints are already lost.

Indeed.  If you look into it, you'll find that Eastman (of
Kodak/Eastman) buried film in his backyard because he realised old
film would eventually rot away, and guess what, it did.  The stuff has
now been painstakingly restored, though yes, some of it was lost
forever, and IIRC there is a museum of sorts in Rochester.

> Many are being copied to more modern tape technology.  Perhaps the
> key to data survival is to carry the data with you by updating it to
> modern media every few decades.

Paul Gearon can fill in details here, I think, but NASA has a very big
problem---its media are expiring so quickly that even *if* they had
readers (apparently some of the relevant designers are now *dead*),
and even if they started transferring old data right now, they still
would not be done in time to avoid losing any data to obsolescence.

> > Then again, if your backup media goes wandering, I'd address the issue
> > of where it's kept, and why people have access to it.
> Indeed.  Physical security, off site backups.  The Humbug archives would
> include good discussions of these I suspect :)

Hmm, are the archives backed up?  I know Mark is pretty religious
about his email.

> > got some uber l33t0 DLT tape unit (in which case, you already know all
> > of this). Then it comes down to how long it actually takes you to get
> > at the data stored on the media.
> > 
> > A SAGE-AU magazine a few months back had a short article discussing
> > backup solutions and software, and time taken to actually rebuild the
> > machine back to the point where the data on the media is useful. In a 
> > previous life, I had a beta level system where I could whack in a
> > CD, rip the old partition information off the backup server and fdisk
> > the machine up, and then just start a command to zap that data across
> > the network to the newly created partitions. Took 5 minutes plus the
> > time to actually transfer the data to restore a machine in its
> > entirety. Of course it took a few minutes more and some hardware
> > shuffling if the backup server had imploded.

Hmm, keeping track of partition sizes is a nice idea (this is
something I'd prefer to have on paper, if it was important (and I'm
not so sure it is, unless you're running Oracle or something which
needs raw partition access, since your insurance should cover new (and
thus probably larger) disks.))

Backups that restore over a network are great, but can always be
bodgied by hand if required.  My arrangement for full disaster
recovery is a bootable business card, fdisk by hand after working out
new partition sizes (pff, this takes 30 minutes, maybe 5 if it's a
rush job) and then one can either:

 o Install the SCSI controller in the system to be restored and get
   the backups read from tape that way;

 o Or install enough of AMANDA that the backups can be retrieved over
   the network.

The nice thing about the former option is that AMANDA stores, on the
tape, human-readable instructions on how to restore the next `file'
(backup image, really) to the local machine.

Of course this has been written up as a document which has six-monthly
reviews to keep it up to date (in fact I just finished the first
review.  Scary how much things change after you actually have to
*gasp* restore your fileserver's root partition because the disk is
fucked).

> > Ease of restoration comes down partly to how well you've documented
> > your procedures, and what dependancies you have. If you were as the
> Definately.

I'm pretty confident a technical user could follow the instructions I
left.  I don't think I'd want a non-technical user to be responsible
for the restoration of data.

> > sys admin to be (God forbid) be hit by a bus on the way to work, could
> Truck number = 1

In this case, it might be best to get a consultant in until the
sysadmin can gather his supernatural powers and make himself a new
form to present to the world of mortals?

> Anyway I'm probably preaching to the converted but I have trouble seeing
> how people manage to turn something which is essentially a very simple
> procedure (at least in many cases) into something so obfiscated.  And then
> I am further amazed at how they never get around to documenting it :)

Well, I'm amazed that AMANDA doesn't get more use, since it's no more
complex than it needs to be, for the flexibility.

Documentation is key.

jason
-- 
||----|---|------------|--|-------|------|-----------|-#---|-|--|------||
|                                                      jasonp at uq.net.au |
| `Duck.  Duck.  Duck.  Duck.  Duck.  Duck.' -- Ann Burlingham          |
||--|--------|--------------|----|-------------|------|---------|-----|-|

--
* This is list (humbug) general handled by majordomo at lists.humbug.org.au .
* Postings to this list are only accepted from subscribed addresses of
* lists 'general' or 'general-post'.



More information about the General mailing list