ADSM-L

Re: Useful 'move data' options

1998-07-17 09:15:46
Subject: Re: Useful 'move data' options
From: "Weeks, Debbie" <debbie AT ADMIN.USF DOT EDU>
Date: Fri, 17 Jul 1998 09:15:46 -0400
I agree!  This type of function might also enable me to only send the
active versions offsite, something we are truly interested in.

> -----Original Message-----
> From: Hilton Tina [SMTP:HiltonT AT TCE DOT COM]
> Sent: Friday, July 17, 1998 8:16 AM
> To:   ADSM-L AT VM.MARIST DOT EDU
> Subject:      Re: Useful 'move data' options
>
> I think another handy addition to either mov data or reclamation would
> be to move all the active files to a set of tapes, separate from the
> inactive files.  It that was done every so often it would reduce the
> number of tapes needed to restore a node.  I've had some people try to
> get me to schedule full backups to accomplish this, but I've been able
> to refuse so far.
>
> Anyone else agree?
>
> > -----Original Message-----
> > From: Bruce Elrick [SMTP:belrick AT HOME DOT COM]
> > Sent: Thursday, July 16, 1998 7:14 PM
> > To:   ADSM-L AT VM.MARIST DOT EDU
> > Subject:      Re: Useful 'move data' options
> >
> > I hope you didn't think I had any say over the matter!  Other than
> to
> > get people on ADSM-L to do "me too"'s to the point that maybe
> > development would consider it.
> >
> > An open request to Cyndie Behrens...could this be added to the
> > official
> > list of requested features?
> >
> > Could someone intimate with the internals of ADSM comment of the
> > feasability of my suggestion?
> >
> > Cheers...
> > Bruce
> >
> > Steffan Rhoads wrote:
> > >
> > > After some thinking and subsequently meeting a new customer with a
> > large ADSM
> > > installation (2 sites, 2 UNIX ADSM servers each with middlin DLT
> > libraries, @40
> > > servers/clients each site) and seeing the mess they have these
> > options would be
> > > LIFESAVERS!  Were going to have to create all new policy domains,
> > storage pools
> > > and schedules: you can imagine the processing time that's going to
> > be spent and
> > > how usefull these additional MOVE DATA options would be.
> > >
> > > How soon?
> > >
> > > Bruce Elrick wrote:
> > >
> > > > Would anyone find the following options to the 'move data'
> command
> > > > useful?
> > > >
> > > > type
> > > >    all - all data on volume, default
> > > >    backup - backup data
> > > >    archive - archive data
> > > >    spacemanaged - space managed data
> > > >    - allow pairs of the above three types
> > > >
> > > > node
> > > >    - specify a list of nodes whose data is to be moved
> > > >
> > > > filespace
> > > >    - specify a list of filespaces whose data is to be moved -
> may
> > > > require
> > > >    the node option specified
> > > >
> > > > Since migration from sequential storage pools to sequential
> > storage
> > > > pools
> > > > already moves collocation clusters, the implementation of the
> > latter two
> > > >
> > > > options should be trivial.  The implementation of the first
> option
> > might
> > > > be
> > > > more difficult but would be immensely valuable.  I've seen a
> > number of
> > > > situations where backup, archive, and space managed data are
> mixed
> > in
> > > > a storage pool (bad idea from a data integrity point of view)
> and
> > there
> > > > is
> > > > currently no way to separate the data.
> > > >
> > > > Anyone agree on this?
> > > >
> > > > Cheers...
> > > > Bruce
> > >
> > > --
> > > Steffan Rhoads
> > > Lead Technical Consultant
> > > Think Enterprise Solutions
> > > 10 Holland
> > > Irvine, California  92618-2504
> > > srhoads AT westernmicro DOT com