Re: TDP R/3 Versioning and Off-site Vaulting
Instead of playing with the utl file, why not modify the TSM storage pools? Send the backup to a primary pool with no volumes assigned to it, then modify the nextpool parameter as needed. All week it points to your normal onsite tape pool, but for the weekly backup you want offsite, it points to another pool. This other pool is backed up to your offsite pool. Two admin schedules is all it takes for the swapping, and another one for the backup storagepool. Pools: Storage Device EstimatedPctPct High Low Next Stora- Pool NameClass NameCapacity Util Migr Mig Mig ge Pool (MB) Pct Pct --- -- -- - - --- --- SAPDBTAPEIBM3590 154,439.8 19.9 20.0 100 70 SAPDBDISKDISK 0.00.00.090 70 SAPDBTAPE SAPDBTAPE2 IBM3590 65,400.04.74.7505 OFFSAPDBTAPE IBM3590 21,578,596 32.4 (The numbers above are way off - just copied from a server I have to get the format correct) Schedules: (Assume SAP database backup starts at 02:00 on Saturday, runs for 4 hours) 01:58 Saturdays "upd stg sapdbdisk nextpool=sapdbtape2" 06:30 Saturdays "upd stg sapdbdisk nexpool=sapdbtape" 06:30 Saturdays "backup stg sapdbtape2 offsapdbtape" I would modify the "normal" condition as close to the backup starting as possible - if TSM is offline at 1:58, it's unlikely to be back up by 02:00. And, of course, give enough time after the backup for the backup to run long. Nick Cassimatis [EMAIL PROTECTED] There's more than one way to skin a cat, but you'll go through a lot of cats to figure them all out.
Re: TDP R/3 Versioning and Off-site Vaulting
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.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.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:[EMAIL PROTECTED]] > Sent: Monday, March 25, 2002 9:23 AM > To: [EMAIL PROTECTED] > 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:[EMAIL PROTECTED]] > Sent: Sunday, March 24, 2002 10:49 AM > To: [EMAIL PROTECTED] > 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:[EMAIL PROTECTED]] > Sent: Friday, March 22, 2002 2:48 PM > To: [EMAIL PROTECTED] > 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 >
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:[EMAIL PROTECTED]] Sent: Sunday, March 24, 2002 10:49 AM To: [EMAIL PROTECTED] 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:[EMAIL PROTECTED]] Sent: Friday, March 22, 2002 2:48 PM To: [EMAIL PROTECTED] 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
Re: TDP R/3 Versioning and Off-site Vaulting
Set up two management classes, one for normal use and one for the copy to go off site. Use two different copy groups to point to the two different management classes. And then set up two different init.utl files (I'd use initPRD.utl and initPRD.off.utl, for my PRD instance, but that's just me :-). When you run brbackup for the off-site copy, include '-r /initPRD.off.utl' on the command line. My off-line script uses this to invoke brbackup: # export BR_TRACE parm added for debugging faild shutdown 2-1-2002 trk /usr/bin/su - ora$LOWSID -c "export BR_TRACE=15; brbackup -c -m all -r /oracle/$SID/backint/initPRD.utl.sun -t offline_force" And my online backups use this: /usr/bin/su - ora$LOWSID -c brbackup -c -m all -r /oracle/$SID/backint/initPRD.utl -t online The script is run from the root crontab and SID is passed as a parameter. Tom Kauffman NIBCO, Inc > -Original Message- > From: Tait, Joel [mailto:[EMAIL PROTECTED]] > Sent: Friday, March 22, 2002 2:48 PM > To: [EMAIL PROTECTED] > 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 > >
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:[EMAIL PROTECTED]] Sent: Friday, March 22, 2002 2:48 PM To: [EMAIL PROTECTED] 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
Re: TDP R/3 Versioning and Off-site Vaulting
Since TSM is pretty rigorous about copying everything in a primary pool to the copypool, only way I can see is to split your primary pool in pools A and B. Send backups 1-3 to pool A, backup 4 to pool B. Do backup stgp on pool B, and send resulting tapes offsite. You'll need to fiddle with management classes to get backup 4 to go to pool B. _ William Mansfield Senior Consultant Solution Technology, Inc "Tait, Joel" <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> 03/22/2002 01:48 PM Please respond to "ADSM: Dist Stor Manager" To: [EMAIL PROTECTED] cc: 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 Joel Tait (E-mail).vcf Description: Binary data
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 Joel Tait (E-mail).vcf Description: Binary data
