Hi!

"me too" - I also support the idea of having a "preparation" command to speed up
the actual restore process. In my opinion this is not only a server-based thing
(of course you can save a lot of time collocating all the active data and e.g.
moving it to a restore disk pool). Perhaps also the client should have a special
function for a "big" restore, e.g. get a list of files (already prepared by the
server) and all the files packed together in on big something that takes up as
much network bandwith as possible (BTW: what about your other systems on a
shared media network while you restore one box?!?). ADSM could reduce
communication overhead and the client could concentrate on writing all the stuff
as fast as possible on the disk.

Regards,
Michael








Sheelagh Treweek <sheelagh.treweek AT COMPUTING-SERVICES.OXFORD.AC DOT UK> on 
18.03.99
09:31:52

Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>








 To:      ADSM-L AT VM.MARIST DOT EDU

 cc:      (bcc: Michael Abel/resnova)



 Subject: Re: restore times










Kelly,

This is such a good idea and I have to say, very sadly, not a new one.

I can recall discussing this with Paul Bradshaw (who old timers on this
list will remember as lead architect of ADSM) at least 3 years ago.  The
sad fact is that this has probably been on the requirements database for
at least those 3 years but no signs that it will ever be implemented.

Paul's thoughts at the time were that this facility would be excellent
to prepare for a major restore and stage the data to disk or to tape as
appropriate.  Most clients could give at least a few hours warning that
a major restore is needed - while their stolen or broken box is
replaced.  Good use could be made of that time by getting the data in
fit shape to come back.  To me this would be more cost effective than
worrying about collocation and offer a professional restore capability.

Regards, Sheelagh
------------------------------------------------------------------------------
Sheelagh Treweek                         Email: sheelagh.treweek AT oucs.ox.ac 
DOT uk
Sheelagh Treweek                         Email: sheelagh.treweek AT oucs.ox.ac 
DOT uk
Oxford University Computing Services     Tel:   +44 (0)1865 273205
13 Banbury Road, Oxford, OX2 6NN, UK     Fax:   +44 (0)1865 273275
------------------------------------------------------------------------------
> From owner-adsm-l AT vm.marist DOT edu  Wed Mar 17 20:20:49 1999
> From owner-adsm-l AT vm.marist DOT edu  Wed Mar 17 20:20:49 1999
> Delivered-To: fixup-ADSM-L AT VM.MARIST DOT EDU@fixme
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Date: Wed, 17 Mar 1999 13:12:11 -0700
> From: "Kelly J. Lipp" <lipp AT STORSOL DOT COM>
> Subject: Re: restore times
> To: ADSM-L AT VM.MARIST DOT EDU
>
> Geez!
>
> Keep your fingers crossed hoping not to have to restore this guy.
>
> What about changing the node name?  This would force new filespaces and
> effectively a full backup.  Then wait 60 days (retonly) and delete the old
> filespaces.  Probably easier than and export/import.
>
> Let's kick around a better way to do reclamation that will help to ease
> this "feature".
>
> What about setting collocation on before a reclaim?  What about changing
> the algorithm for reclaim in the server code itself.  Perhaps the engineers
> can jump in here with ideas they've kicked around.
>
> How about a new ADSM command: Consolidate filespace.  This command would
> determine which tapes contain a filespace, mount those tapes and move the
> data to new tapes.  This could be done on a weekly/monthtly basis for
> problem filespaces.  Better yet, do it on a threshold.  If a filespace
> begins to span more than x tapes, then consolidate.  Once the data has been
> moved, it is expired on the original tapes and reclamation can do its
> thing.
>
> Simple matter of programming.  Should take a week or two, don't you think?
>
> Kelly J. Lipp
> Storage Solutions Specialists, Inc.
> www.storsol.com
> lipp AT storsol DOT com
> (719)531-5926
>