It's ugly and manual, but doable.

1) before running the backup that is to be copied for off-siting -- mark all
'filling' status tapes for your SAP backup as 'readonly'. This will force
the backup to start new tapes.

2) After the backup finishes -- update all other tapes in the storage pool
to an access of 'unavailable' or 'offsite'

3) Do the storage pool backup to your off-site pool. The only tapes that
should be available are from the backup you really want to copy.

4) Update all the other tapes back to readonly access

I did this twice.

Then I set up the second init<SID>.utl file -- I was running my on-line
(nightly) backups to a 'PRDSAP-DLT' pool and the off-line (Sunday) backups
to a 'PRDSAP-OFFLINE-DLT' pool, and just copying the latter. This allowed
full automation (two crontab entries, one for Sunday, one for the rest of
the week), with a daily copy process that only found data to copy one day
per week.

Just make sure the off-line redo logs go off daily, and the retention
matches the weekly database backup.

We now have an LTO-based library and I run copies of all SAP backups to go
off-site -- but I still have the two init<SID>.utl files. Now I run 5
sessions (five tape drives) on Sunday for the off-line, and 4 sessions (four
tape drives) for the on-line backup.

Tom Kauffman
NIBCO, Inc

> -----Original Message-----
> From: Tait, Joel [mailto:Joel.Tait AT CCRA-ADRC.GC DOT CA]
> Sent: Monday, March 25, 2002 9:23 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: TDP R/3 Versioning and Off-site Vaulting
>
>
> Is there any other way to take a single SAP backup offsite
> with the original
> onsite? This issue must have come up before.
>
> Thanks
>
> Joel E. Tait
>
> -----Original Message-----
> From: Seay, Paul [mailto:seay_pd AT NAPTHEON DOT COM]
> Sent: Sunday, March 24, 2002 10:49 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: TDP R/3 Versioning and Off-site Vaulting
>
>
> The only way that I can think of is to create 2 onsite
> primary pools and
> change the management classes before each backup to what you
> want it to be.
> Unfortunately, that means the init[SID].utl file has to be
> different for
> each primary pool and you will have to do some switching of
> the file right
> before each backup.  What I would do is create is an
> init[SID].utloff and an
> init[SID].utlon and copy it to the init[SID].utl right before
> the BRBACKUP.
>
> Remember, though that the restores do not care about this.
> TSM will just go
> get the data whereeever it is.  But, it will care about the archive
> management class used for BRARCHIVE.  I would not try to do
> this with it.
>
> I am not an expert in this area, but it is a way to
> accomplish what you are
> trying.  Ultimately, you have to get the backup you want to
> copy and send
> offsite to a different primary storage pool.  So that only it
> is copied and
> sent offsite.
>
> -----Original Message-----
> From: Tait, Joel [mailto:Joel.Tait AT CCRA-ADRC.GC DOT CA]
> Sent: Friday, March 22, 2002 2:48 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: TDP R/3 Versioning and Off-site Vaulting
>
>
> Hi
>
> Does anyone have any idea's of how to use copy pools to take
> only 1 SAP DB
> Backup version off-site every week?
> Reason: Primary Pool will hold 4 - 4TB versions of a SAP DB Backup.
>
> Thanks
>
> Joel E. Tait
>