While we are on the subject again...I would like to thank you all again for
your help with my similar question a few weeks back. Things have worked out
quite well for us. We now have decreased the number of tapes in the vault
from 900+ to under 100. Of course we have to add to this number about 100
tapes in a new primary pool created for weekly full backups, but the savings
is still tremendous.
I went with the suggestion of having two node names running on each of the
servers, and scheduling full weekly backups on the second node that point to
"weekly full" storage pools. Data is kept in this management class for 14
days, so we should have leveled off in our tape usage by now. The weekly
full storage pool is now the only one managed by DRM, and copied to offsite
tapes. Not only have the number of tapes offsite decreased, but our daily
administrative tasks of copying to dr tapes, and then reclaiming them have
decreased significantly, allowing us to better manage our "long term"
primary pools.
We were able to easily implement this for our "regular" nodes, as well as
our SQL Server and Exchange databases. Oracle databases that are being
backed up with SQL Backtrack are our last remaining problem. SQL Backtrack
does not allow the flexibiliy of pointing to a different profile (compares
to options file) for backups of a database. But I am sure we will resolve
this one soon.
Thanks again for your help!
> -----Original Message-----
> From: Phipps Tony [SMTP:Tony_Phipps AT LONDONELEC.CO DOT UK]
> Sent: Friday, August 13, 1999 9:37 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: move data command on primary tape pool
>
> Thanks for the tips. Tests have shown that the copypool does indeed remain
> unaffected by the
> move data on the primary pool.
>
> I presume the only way to free up space/tapes in the copypool and to
> reduce
> the number of
> physical copies of old data is to delete copypool volumes (discarding
> data)
> that have
> not been written to for over month (after moving the primary copies).
> Balancing the requirements of having two copies of data in the short term
> (for DR purposes)
> and one copy long term (for legal requirements) must be a common problem
> and
> perhaps
> a method of retaining copypool data whilst deleting on site copies should
> be
> one for the
> wishlist.
>
> cheers
> Tony
>
>
>
> > -----Original Message-----
> > From: Russell Street [mailto:russells AT AUCKLAND.AC DOT NZ]
> > Sent: 13 August 1999 01:40
> > To: ADSM-L AT VM.MARIST DOT EDU
> > Subject: Re: move data command on primary tape pool
> >
> >
> > > If data is moved from primary tape pool A to another
> > primary tape pool B
> > > using "move data <vol_number> stgpool=primary poolB",
> >
> > There will be no change to the files stored in copypoolA. The copy
> > will remain in copypoolA.
> >
> > > Does the copypoolA version of the moved data expire normally during
> > > an "expire inventory"?
> >
> > Yes.
> >
> >
> >
> > With copypools ADSM considers the files themselves, not which primary
> > pool they are stored in.
> >
> > When you run "backup stgpool poolA copypoolA", ADSM works its way
> > through all the files in poolA and sees if they are in copypoolA. If
> > the file is not, then it is copied over. There is no checking that
> > all the files in copypoolA are still in poolA.
> >
> > As a working example, I have a DISK based primary pool and a tape pool
> > set as the next storage pool for migration (i.e., a standard setup).
> > Scheduled commands back up both pools to the same copypool. The files
> > are only copied once.
> >
> >
> >
> > Creating small storage pools with the FILE device type is a great way
> > to check out what ADSM does with files and copypools. You can
> > simulate your production storage pools and create some managment
> > classes to store files into those pools then. Back up a few files and
> > use "query content" to see them move around in response to different
> > commands.
> >
> >
> > Russell
> >
> >
> > [Charset iso-8859-1 unsupported, filtering to ASCII...]
> > > We wish ensure that only one physical copy of tapes
> > required for long term
> > > storage exist.
> > > As most of the data concerned is Oracle DB backups using
> > EBU, ADSM archives
> > > are not applicable.
> > > We also (for data security) wish to have two tape copies of
> > the backup data
> > > for upto a month to minimise the impact of media failure.
> > >
> > > The scenario:
> > >
> > > primary poolA is backed up nightly to copypoolA
> > >
> > > primary poolB has no copypool
> > >
> > > Tapes not written to for over a month have the data moved
> > from primary poolA
> > > to primary poolB
> > >
> > > If data is moved from primary tape pool A to another
> > primary tape pool B
> > > using "move data <vol_number> stgpool=primary poolB",
> > > what happens to copypool versions of the data from previous
> > storage pool
> > > backups of primary poolA? Does the copypoolA
> > > version of the moved data expire normally during an "expire
> > inventory"?
> > > If not, how do I free up the redundant space from copypoolA?
> > > The admin guide says: "Files in a copy storage pool do not
> > move when primary
> > > files are moved" but surely a copypool is a reflection of
> > its primary pool?
> > > Let me know if you have had any experience with this sort of thing.
> > > cheers
> > > Tony Phipps
> >
|
