Re: Question on Restoration from DBSNAPSHOT
Mark, Actually it's not confusing. Logically since there have been no transactions between the two full DBB, resetting the recovery log should not logically cause any problems. Of course if TSM is marking each DBB and recovery log set with some sort of serial number, and will only play with matching serial numbers I can understand the "mechanical" reason why it won't work. Of course I can have my cake and eat it too by: 1) Doing a full DBB to disk 2) Sending that DBB to tape during my daily Sysback system backup Thanks, H. Milton Johnson Voice: (210) 677-6728 -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Mark D. Rodriguez Sent: Tuesday, February 17, 2004 1:05 PM To: [EMAIL PROTECTED] Subject: Re: Question on Restoration from DBSNAPSHOT Milton, The short answer is no. You can only use the most recent full/incremental series to restore to the most current state, i.e. using the ROLLFORWARD log. The reason is that once you do a DBB (either full or incremental) the log is reset. Therefore any older version, in your case the first DBB full, can only be used for a PIT restore. Hang in there, I know it gets confusing at times but it really does make sense in a crazy sort of way! -- Regards, Mark D. Rodriguez President MDR Consulting, Inc. === MDR Consulting The very best in Technical Training and Consulting. IBM Advanced Business Partner SAIR Linux and GNU Authorized Center for Education IBM Certified Advanced Technical Expert, CATE AIX Support and Performance Tuning, RS6000 SP, TSM/ADSM and Linux Red Hat Certified Engineer, RHCE ======== === Johnson, Milton [IT] wrote: >Mark / Mike, > >Nice to here from you Mark. I am aware that DBSNAPSHOT can only be >used for PIT restoration, at least after refreshing myself, and that >only the BACKUP DB FULL/INCR resets the recovery log. What I'm now >asking is can I make two DBB (full), one immediately after the other, >and then use either one to do a restore to the point of failure using the recovery log? > >Thanks, >H. Milton Johnson >Voice: (210) 677-6728 > >
Re: Question on Restoration from DBSNAPSHOT
Mark / Mike, Nice to here from you Mark. I am aware that DBSNAPSHOT can only be used for PIT restoration, at least after refreshing myself, and that only the BACKUP DB FULL/INCR resets the recovery log. What I'm now asking is can I make two DBB (full), one immediately after the other, and then use either one to do a restore to the point of failure using the recovery log? Thanks, H. Milton Johnson Voice: (210) 677-6728 -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Mark D. Rodriguez Sent: Tuesday, February 17, 2004 10:23 AM To: [EMAIL PROTECTED] Subject: Re: Question on Restoration from DBSNAPSHOT Hi Milton, It's been a long time since we talked. You know you could have just called me and I would have helped you out. But anyway here is what I recommend: DBSNAPSHOT - should be used for your DR backups of the DB. They should be to a tape and taken offsite with your DR tapes. DBSNAPSHOT is effectively a full backup of the DB, but it does not involve the LOG in any way. Therefore, it can only be used for a PIT (point in time) restore. Also, please note that a DBSNAPSHOT does not reset the LOG like a DBB (full or incremental) does if the LOG is set to ROLLFORWARD. This makes it perfect for a DR type restore since in a disaster you would expect that the LOG would be lost. Please note if you are using DRM then you should update your scheduled Prepare command to include "Prepare Source=DBSnapshot" so that it manages the correct tapes for you. I sure do wish that the ITSM developers would make this the default! DBB(full and incremental) - should be kept onsite for rapid DB recovery including restore to the most recent time using a ROLLFORWARD log. I prefer to do these DBB to a device of type FILE. This allows for much faster backups and restores. Furthermore, I can schedule a full once a week and incrementals the rest of the week with no penalty on the restore time for multiple volumes since they are all coming from disk. This methodology offers a few more not so obvious advantages, you could easily schedule multiple DBB incrementals a day thus reducing the size requirement of you LOG. Also, if you use DEFine DBBackuptrigger you can set your triggered backups to go to the same device of type FILE which means in a triggered event your DBB will take place much faster and a rapidly growing DB would be less likely to trigger the DB spacetrigger. Remember when defining your DBBackuptrigger to make sure you specify NUMINCremental to 32 allowing for as many incrementals as possible between fulls, again there is no penalty here for multiple volumes since it is going to a device of type FILE. BTW, based on your note you were doing DBSNAPSHOT's daily which takes as much space as a DBB full does. If you switch to the method described above, you will use far less space on disk since you will be doing mostly incremental backups of the DB. If you are anyone else has any questions about this please feel free to contact me either by this list or send me email directly. -- Regards, Mark D. Rodriguez President MDR Consulting, Inc. === MDR Consulting The very best in Technical Training and Consulting. IBM Advanced Business Partner SAIR Linux and GNU Authorized Center for Education IBM Certified Advanced Technical Expert, CATE AIX Support and Performance Tuning, RS6000 SP, TSM/ADSM and Linux Red Hat Certified Engineer, RHCE ============ === Johnson, Milton [IT] wrote: >All, > > TSM: Storage Management Server for AIX-RS/6000 - Version 4, >Release 2, Level 1.7 > OS: AIX 4.3.3 ML 9 >Log Mode: RollForward > (Upgrade project planned in near future, but that's another >story) > >Everyday I do a full backup of the database to 3590E tape, immediately >followed by a DBSNAPSHOT to a file on disk. The 3590E tape promptly >goes offsite. My question is if I experience a loss of the database >can I then restore from the DBSNAPSHOT and recover to the point of >failure using the RECOVERY LOG? I would like to avoid the time delay >of returning the 3590E tape, containing the database backup, from the vault. > >Anyone done this? > >Thanks, >H. Milton Johnson >UNIX Systems Administrator - USCC San Antonio, TX >Email: [EMAIL PROTECTED] > >
Re: Question on Restoration from DBSNAPSHOT
Mike, I'm somewhat surprised that so far yours has been the only reply. I have reviewed the 4.2 Administrators Reference and it clearly states on page 873 that a snapshot can not be used to restore a db to it's most current state, so I guess that answer's my original question but begs another. If I make a full backup to tape/disk and immediately follow it with another full backup to disk/tape, can I do a db restore to it's most current state using either one of the full db backups as a starting point and the recovery log? Richard, Do you have any thoughts/knowledge on this? Thanks, H. Milton Johnson Email: [EMAIL PROTECTED] -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Mike Wiggan Sent: Friday, February 13, 2004 10:38 PM To: [EMAIL PROTECTED] Subject: Re: Question on Restoration from DBSNAPSHOT Milton, We recently introduced disaster recovery, and I pondered this for a while. The outcome is that we store the DBSNAPSHOT off site, as one can recover to a point in time. In our case VIA a SAN to another robot. We keep the full backup + any incremental within the local robot to avoid time delay. Prior to introducing DR, I remember one evening when we had to recover the database and it took two hours before we got the tape into the robot. One soon learns. Kind Regards Mike Wiggan, TCS/14 IT Infrastructure Integration Specialist Petroleum Devlopment Oman LLC ([EMAIL PROTECTED]) -Original Message- From: Johnson, Milton [IT] [mailto:[EMAIL PROTECTED] Sent: Thursday, February 12, 2004 20:06 To: [EMAIL PROTECTED] Subject: Question on Restoration from DBSNAPSHOT All, TSM: Storage Management Server for AIX-RS/6000 - Version 4, Release 2, Level 1.7 OS: AIX 4.3.3 ML 9 Log Mode: RollForward (Upgrade project planned in near future, but that's another story) Everyday I do a full backup of the database to 3590E tape, immediately followed by a DBSNAPSHOT to a file on disk. The 3590E tape promptly goes offsite. My question is if I experience a loss of the database can I then restore from the DBSNAPSHOT and recover to the point of failure using the RECOVERY LOG? I would like to avoid the time delay of returning the 3590E tape, containing the database backup, from the vault. Anyone done this? Thanks, H. Milton Johnson UNIX Systems Administrator - USCC San Antonio, TX Email: [EMAIL PROTECTED]
Question on Restoration from DBSNAPSHOT
All, TSM: Storage Management Server for AIX-RS/6000 - Version 4, Release 2, Level 1.7 OS: AIX 4.3.3 ML 9 Log Mode: RollForward (Upgrade project planned in near future, but that's another story) Everyday I do a full backup of the database to 3590E tape, immediately followed by a DBSNAPSHOT to a file on disk. The 3590E tape promptly goes offsite. My question is if I experience a loss of the database can I then restore from the DBSNAPSHOT and recover to the point of failure using the RECOVERY LOG? I would like to avoid the time delay of returning the 3590E tape, containing the database backup, from the vault. Anyone done this? Thanks, H. Milton Johnson UNIX Systems Administrator - USCC San Antonio, TX Email: [EMAIL PROTECTED]
Re: Restoring files from a savevg
You have stacked files onto one tape. To restore the XXXvg use: # mt -f /dev/rmt0.1 fsf 1; restorevgfiles -f /dev/rmt0.1 To restore the YYYvg use: # mt -f /dev/rmt0.1 fsf 2; restorevgfiles -f /dev/rmt0.1 Milton Johnson Voice: 210-677-6728 Email: [EMAIL PROTECTED] -Original Message- From: Calvin Chang [mailto:[EMAIL PROTECTED] Sent: Monday, December 08, 2003 1:53 PM To: [EMAIL PROTECTED] Subject: Restoring files from a savevg Hello everyone, I'm having trouble trying to restore a file from my VG. Here is the scenario: Basically every night I backup my mksysb, XXX Volume group, and YYY Volume group all to one tape using this command #mksysb -ie /dev/rmt0.1 #savevg -i -f /dev/rmt0.1 XXXvg #savevg -i -f /dev/rmt0.1 YYYvg How do I access data that I need to restore from the XXXvg?? I tried using the #restorevgfiles -f /dev/rmt0 command and it returns saying that the file is not in an archive format. Any help would be deeply appreciated. Thanks
Re: TSM on AIX now, platform change coming?
Personally I would never consider a WinDoze solution. WinDoze does not have a rich scripting environment like UNIX does. Using scripting I have been able to: * Increase the performance of my TSM server * Improve reclamation efficiency * Created a menu driven program to aid the day-to-day maintenance * Monitor TSM for problems with notification via web pages, email and pager * Store useful information in the TSM DB such as: - Number of cleaning cartridges in library - Number of cleaning cycles remaining on those cartridges - Number of times each tape drive was cleaned in the last 24 hours (excessive cleaning could point to a problem) * etc, etc A WinDoze environment is just too limiting an environment. You have TSM on AIX experience, so I would not change without a very compelling reason. Also TSM on AIX means that one vendor supports the hardware, OS and application. Any problem arising from that combination is IBM's problem. I try to avoid situations where multiple vendors can point fingers at each other. Milton Johnson -Original Message- From: Nancy Reeves [mailto:[EMAIL PROTECTED] Sent: Friday, December 05, 2003 8:52 AM To: [EMAIL PROTECTED] Subject: Re: TSM on AIX now, platform change coming? I was reminded that another of our options is using Windows (Win2K3). How does that compare with using AIX & Sun for TSM servers? Nancy Reeves Technical Support, Wichita State University [EMAIL PROTECTED] 316-978-3860 > -Original Message- > We are now running TSM 4.2 on an AIX box. Not only is the TSM level > unsupported, so is the AIX level. And the box is running on empty, > plus we > are really tight on storage, both disk and tape. > Any thoughts on comparing AIX vs. Sun for a TSM server?
Re: Tivoli Field Guides
Thanks, unfortunately the Reclamation Tips guide link is broken. Milton Johnson -Original Message- From: Richard Sims [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 18, 2003 7:51 AM To: [EMAIL PROTECTED] Subject: Tivoli Field Guides A lesser-known information source for registered IBM customers is found in the Tivoli Field Guides - yet another area in the amazing information store created and maintained by IBM. Here you can find explorations of various topics such as HSM, Windows cluster service database backup and restoral, a treatise on the full-incremental backup philosophy, patches, and other topics. There are some rough edges, such as the broken link for the Reclamation Tips guide, but nevertheless a helpful information source. Go to: http://www.ibm.com/software/sysmgmt/products/support/Field_Guides.html and wend your way through its subdivisions. Richard Sims, BU
Re: Move nodedata - what is moved first
Marc, Part of our routine to send tapes offsite includes "BACKUP STGPOOL DISKDIRPOOL COPYPOOL" which send the DIRMC storage pool offsite. Part of the restoration procedure includes "RESTORE STGPOOL DISKDIRPOOL" Milton Johnson Voice: 210-677-6728 Email: [EMAIL PROTECTED] -Original Message- From: Marc Levitan [mailto:[EMAIL PROTECTED] Sent: Friday, October 24, 2003 8:13 AM To: [EMAIL PROTECTED] Subject: Re: Move nodedata - what is moved first What would happen if there was a site disaster and the data was only on the disk which is no longer available to perform restores? I guess what I am asking is, without sending DIRMC off-site, can you recover from a site disaster? |-+---> | | Deon George | | | <[EMAIL PROTECTED]| | | .COM> | | | Sent by: "ADSM: | | | Dist Stor | | | Manager"| | | <[EMAIL PROTECTED]| | | T.EDU> | | | | | | | | | 10/23/2003 08:07| | | PM | | | Please respond | | | to "ADSM: Dist | | | Stor Manager" | | | | |-+---> >--- | | | |To: [EMAIL PROTECTED] | |cc: | |Subject: Re: Move nodedata - what is moved first | >--- | Peter, > servers . Currently, our main file server has data on over 200 3590 > tapes therefore a directory restore can potentially have hours added > to the process directly related to tape mounts. Is the directory information you referring about related to Windows systems? You should use the DIRMC client option to store all your directory information in a DISK based storage pool (DISK or FILE), so that it remains on faster quicker access media for restore purposes. (Dont let that stuff go to tape for the reasons you have outlined below.) The DIRMC client option is not really required for Unix based systems, as the database has enough space to store that information. ...deon --- Have you looked at the A/NZ Tivoli User Group website? http://www.tuganz.org Deon George, IBM Tivoli Software Engineer, IBM Australia Office: +61 3 9626 6058, Fax: +61 3 9626 6622, Mobile: +61 412 366 816, IVPN +70 66058 mailto:[EMAIL PROTECTED], http://www.ibm.com/tivoli
Re: SQL to determine what offsite volumes are needed for move dat a
Bill, I also have only 2 tape drives and was running in to the problem of tapes going off sight and never coming back. I solved it by creating a reclamation script that does the following (pseudo code): for stgpool in TAPEPOOL COPYPOOL do while [count(stgpool tapes > 51% reclaimable) -gt 0] do find percent_reclaimable of most reclaimable tape in stgpool update stg stgpool recl=percent_reclaimable while reclaimation in process do sleep 5 minutes done update stg stgpool recl=100 done done With this approach I have brought the count of COPYPOOL tape >51% reclaimable down from ~130 to ~6. I was pleasantly surprised by the impact this approach had. Thanks, Milton Johnson Voice: 210-677-6728 Email: [EMAIL PROTECTED] -Original Message- From: Bill Kelly [mailto:[EMAIL PROTECTED] Sent: Thursday, October 16, 2003 9:54 AM To: [EMAIL PROTECTED] Subject: SQL to determine what offsite volumes are needed for move data Hi, We're running TSM server 5.1.6.2 on z/OS. One of the (many) resources we're short on is tape drives. Consequently, I'm always looking to streamline processes that use these drives. Here's the problem I'm currently looking at: Our tape copy pools are kept offsite. Reclamation for these pools is handled by leaving the TSM reclamation threshhold at 100% so that he never does reclaims on his own. On a regular basis, we run a job that queries the server for copy pool tapes with a reclamation threshhold greater than 'n' percent. This list of tapes is used by the operators to go and fetch the tapes to be brought onsite. They then run a job that updates those tapes to access=readwrite, and issues a 'move data' command for each tape. Now the problem. Some of these 'move data' processes treat the volume that is being emptied as 'offsite', even though the volume has been loaded into the library and its access updated to readwrite. I'm pretty sure the reason for this is that the volumes in question have files at the beginning and/or end that span to other copy pool volumes which are themselves still offsite. If the volume being emptied is treated as 'onsite', then the move data runs pretty quickly - the copy pool volume is mounted for input, the data is copied, and the volume goes pending. However, if the volume being emptied is treated as 'offsite', TSM will perform the move data by mounting for input *all* of the primary pool tapes that have data on this copy pool tape. Since our primary tape pools are collocated, while our copy pools are not, this results in dozens of tape mounts for primary pool volumes to use as input. The move data process can take hours in this case, tying up tape drives much longer than necessary. For the moment, I'll ignore the question of whether TSM should be smart enough to mount only the one or two primary pool volumes that contain the spanned files, and use the single copy pool volume that's being emptied for all the other data. The way I've been handling this is rather cumbersome. These are the steps I take: - after the move data's have started, issue a 'q proc' command - cancel all of the move data's that are treating their input volume as 'offsite' - issue an 'audit v' command for each of the copy pool volumes being treated as 'offsite' - each audit volume process fails with the following message: ANR2456E AUDIT VOLUME: Unable to access associated volume NN - access mode is set to "offsite". - this tells me which additional copy pool volume needs to be brought onsite in order to make a move data process treat the original volume to be emptied as an onsite volume - go get the additional offsite volumes needed, load them into the library, update their access to readwrite, and issue move data commands for the original volumes being treated as offsite by TSM Then, of course, the entire process has to be repeated because the 'audit volume' command will only tell me *one* offsite volume that might be needed; if a volume has files that span from both the beginning and end of the tape, I won't know that until the 2nd round of 'move data' commands is issued. As you can see, this is a laborious, difficult-to-automate process. Things would be greatly simplified if we could tell right up front which copy pool volumes were going to be treated as offsite, and which additional copy pool volumes would be needed to be brought onsite in order to make the move data's all run as 'onsite'. Having this information up front would allow me to build a list of *all* tapes needing to be brought onsite, requiring only one trip to the offsite location, saving all the hassle of canceling/auditing/etc. I *know* that the information about which offsite volumes are needed must be easy/quick to retrieve, because the 'audit volume' commands fail instantly with the message telling me what offsite volume is needed. So, here's my question (finally!): can anyone provide SQL that could be used to tell me, given a copy pool v
