ADSM-L

Re: Pre-fetching a restore?

2006-01-12 15:13:11
Subject: Re: Pre-fetching a restore?
From: Richard Sims <rbs AT BU DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 12 Jan 2006 15:11:36 -0500
On Jan 12, 2006, at 2:16 PM, Fred Johanson wrote:

Richard,

I have found that professors with research on toasted
harddrives are very willing to wait an extra day or two to
have me stage their backups from non-collocated tape (a false
economy if there ever was one) to disk.  Then tehy think that
TSM is such a nobrainer as their drive is resotred in one
easy stream.

Hi, Fred -

I'm glad that it worked out for you, in that scenario, but...

I'm naturally suspicious of the relative economics of moving a whole
lot of node data around on the server before initiating a restoral
which will likely call for only a fraction of it, being as the
operation is expensive in terms of time, drive occupation, and media
space. I'm also not crazy about the idea of manually subverting the
methodologies of an enterprise product such as TSM, rather than
methodically architect the site's implementation of it to best
expedite restorals by taking advantage of, rather than fighting, the
methods of the product. The messing-around approach also calls for
intervention by a TSM server specialist, rather than allowing
restorals to proceed per standardized site procedures to be invoked
by relatively ordinary site folk.

For both day-to-day operations and disaster recovery, I prefer that
my configuration be such that people at the site can efficiently
perform restorals without my intervention, both because it's an
unhealthy dependence and because the site needs me to be doing things
more commensurate with what they are paying me. (Stop laughing.)
Taking advantage of TSM features and recent technology (massive
capacity tapes, to reduce mounts, for one) allows restorals to
proceed more efficiently. I guess it all boils down to how much a
site is willing to pay for efficient data recovery - which lends to
the adage that one should configure for recovery, not backup.

    Richard Sims

<Prev in Thread] Current Thread [Next in Thread>