Thanks, Alex.  I am going to start testing the "dual node" scenario on a
couple of the servers and see how it goes.  I like this idea much better
than the archive or export thing.

> -----Original Message-----
> From: Alex Mounayar [SMTP:Alex.Mounayar AT SMED DOT COM]
> Sent: Thursday, July 08, 1999 3:40 PM
> To:   ADSM-L AT VM.MARIST DOT EDU
> Subject:      Re: "Full" backup suggestions
>
> Debbie,
>
>      We also have a need for two different retention policies,  both short
> term(normal backup)
> and long term (disaster recovery and special data retention requirements).
> This is implemented by using
> a different nodename for the long term backups. We added an additional
> SERVERNAME stanza in our options
> file that specifies the different NODENAME,  then we start up another
> scheduler with the -SERVERNAME= option.
> The new NODENAME belongs to a management class with the desire retention
> policy.
>
> Alex Mounayar,
> Shared Medical Systems
>
> ------------------------------
>
> Date:    Tue, 6 Jul 1999 23:58:03 -0400
> From:    "Weeks, Debbie" <debbie AT ADMIN.USF DOT EDU>
> Subject: Re: "Full" backup suggestions
>
> Thanks for the comments, I think the consensus is that archive is the way
> to
> go.  I agree.  I can also easily redirect weekly database backups to a
> different storage pool than the "daily kept forever" backups, and send
> copies of it offsite.  I explained the risks to management, and, in light
> of
> the costs, they are willing to accept them, or so they say now.
>
> Our only other alternative would appear to be purchasing a lower cost
> media
> for offsite use.  Convincing them to invest in more hardware would be
> difficult at this point.
>
> Thanks again for all your input and suggestions.
>
> > -----Original Message-----
> > From: steveh AT WESLEY.COM DOT AU [SMTP:steveh AT WESLEY.COM DOT AU]
> > Sent: Tuesday, July 06, 1999 7:54 PM
> > To:   ADSM-L AT VM.MARIST DOT EDU
> > Subject:      Re: "Full" backup suggestions
> >
> > Seems to me that you could run archives to a separate pool, and have a
> > copypool
> > associated with that, but not have a copypool associated with your
> > mainstream
> > data i.e. there is no requirement to have any copypools at all so just
> > copy
> > offsite what is "required".
> >
> > Another possibility, if you have a lot of frequently changing data,
> might
> > be to
> > backup your storagepool only say once per week, immediately after
> > expiration has
> > run.
> >
> > I'm not really advocating either of these: there are obvious
> consequences
> > in the
> > case of a media failure for example, but if you have to keep the
> > powers-that-be
> > happy....(until the first time you get a tape error of course <G>)
> >
> >
> > HTH
> >
> > Steve.
> >
> > AIX/ADSM/Oracle Guy
> > The Wesley Hospital
> >
> > Bris