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
>