Question about restoring a tsm db.
Yesterday my TSM server crashed and lost the db. Our TSM DB is approx. 1.5 TB on a windows system. I started a TSM DB RESTORE last night around midnight and it's still running this morning. Is there any way to know how long it will run or follow the progress other than the scrolling console? Ricky M. Plair Storage Engineer HealthPlan Services Office: 813 289 1000 Ext 2273 Mobile: 757 232 7258 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ CONFIDENTIALITY NOTICE: If you have received this email in error, please immediately notify the sender by e-mail at the address shown.This email transmission may contain confidential information.This information is intended only for the use of the individual(s) or entity to whom it is intended even if addressed incorrectly. Please delete it from your files if you are not the intended recipient. Thank you for your compliance.
Re: Backup Offsite
There is a 3rd -party product called Autovault that will manage the vaulting of a primary pool. (very well supported product, by the way) OTOH, best practice requires you still have a 2nd copy of the data. Vaulted tapes can get lost, get eaten by a drive, etc... W -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Grigori Solonovitch Sent: Tuesday, March 11, 2014 6:05 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Backup Offsite No way for real tapes. You can use Data Domain VTL replication for primary pools, by the way. Grigori Solonovitch, Senior Systems Architect, IT, Ahli United Bank Kuwait, www.ahliunited.com.kw -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Kiran Sent: 11 03 2014 12:29 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] Backup Offsite Hi All, Is there a way to make the backup tapes offsite without copy pool tapes in TSM My daily backup window is around 1TB. So making copypool with the exisitng tape library is not possible. Disclaimer: http://www.dqentertainment.com/e-mail_disclaimer.html Please consider the environment before printing this Email. CONFIDENTIALITY AND WAIVER: The information contained in this electronic mail message and any attachments hereto may be legally privileged and confidential. The information is intended only for the recipient(s) named in this message. If you are not the intended recipient you are notified that any use, disclosure, copying or distribution is prohibited. If you have received this in error please contact the sender and delete this message and any attachments from your computer system. We do not guarantee that this message or any attachment to it is secure or free from errors, computer viruses or other conditions that may damage or interfere with data, hardware or software.
Re: Recovering Linux TSM server from partial filesystem failure
Thanks for the suggestion. As SOP, we update all firmware, every few months, so this box is up-to-date. The Dell diagnostics finally finished, CLEAN. No issues found. I have some of the FODC logs when the first error occurred (was moving them to another filespace as fast as I could when the disk was filling up to 100% due to DB2 dumps). Don't know if there is enough info to show what happened. At this point it is going to be a wipe and rebuild. On Tue, Mar 11, 2014 at 4:15 PM, Skylar Thompson wrote: > Since you mentioned Dell, one thing to check would be PERC and hard drive > firmware levels. There have been a number of updates to both over the past > few years concerning silent data corruption under a variety of conditions. > > On Tue, Mar 11, 2014 at 03:07:24PM -0400, Zoltan Forray wrote: > > Thanks for finding that but, as you said, it doesn't help much. The disk > > filled to 100% due to DB2 taking dumps but that doesn't tell me what > caused > > the dumping in the first place. > > > > We are still running Dell full diagnostics (started yesterday afternoon > and > > was at 78% as of 2pm EDT). My OS guy is watching the pot boil and will > > report back once it finishes. Then it that is clean, he will wipe it and > > reinstall RH 6, since it doesn't look like what is left (/TSMDB, /TSMLOG, > > /TSMARCHLOG) will be of any value without the root filesystem. > > -- > -- Skylar Thompson (skyl...@u.washington.edu) > -- Genome Sciences Department, System Administrator > -- Foege Building S046, (206)-685-7354 > -- University of Washington School of Medicine > -- *Zoltan Forray* TSM Software & Hardware Administrator Virginia Commonwealth University UCC/Office of Technology Services zfor...@vcu.edu - 804-828-4807 Don't be a phishing victim - VCU and other reputable organizations will never use email to request that you reply with your password, social security number or confidential personal information. For more details visit http://infosecurity.vcu.edu/phishing.html
Re: Backup Offsite
TSMManager has a vaulting management option to select "Primary pools to vault". Go to http://www.tsmmanager.com. From my sig, I do not work for them (other than as a beta tester). Just a satisfied customer. On Wed, Mar 12, 2014 at 8:56 AM, Prather, Wanda wrote: > There is a 3rd -party product called Autovault that will manage the > vaulting of a primary pool. > (very well supported product, by the way) > > OTOH, best practice requires you still have a 2nd copy of the data. > Vaulted tapes can get lost, get eaten by a drive, etc... > > W > > -Original Message- > From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of > Grigori Solonovitch > Sent: Tuesday, March 11, 2014 6:05 AM > To: ADSM-L@VM.MARIST.EDU > Subject: Re: [ADSM-L] Backup Offsite > > No way for real tapes. You can use Data Domain VTL replication for primary > pools, by the way. > > Grigori Solonovitch, Senior Systems Architect, IT, Ahli United Bank > Kuwait, www.ahliunited.com.kw > > -Original Message- > From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of > Kiran > Sent: 11 03 2014 12:29 PM > To: ADSM-L@VM.MARIST.EDU > Subject: [ADSM-L] Backup Offsite > > Hi All, Is there a way to make the backup tapes offsite without copy pool > tapes in TSM > > > > My daily backup window is around 1TB. So making copypool with the exisitng > tape library is not possible. > > > > > > > > > > > > Disclaimer: http://www.dqentertainment.com/e-mail_disclaimer.html > > > > Please consider the environment before printing this Email. > > > > CONFIDENTIALITY AND WAIVER: The information contained in this electronic > mail message and any attachments hereto may be legally privileged and > confidential. The information is intended only for the recipient(s) named > in this message. If you are not the intended recipient you are notified > that any use, disclosure, copying or distribution is prohibited. If you > have received this in error please contact the sender and delete this > message and any attachments from your computer system. We do not guarantee > that this message or any attachment to it is secure or free from errors, > computer viruses or other conditions that may damage or interfere with > data, hardware or software. > -- *Zoltan Forray* TSM Software & Hardware Administrator Virginia Commonwealth University UCC/Office of Technology Services zfor...@vcu.edu - 804-828-4807 Don't be a phishing victim - VCU and other reputable organizations will never use email to request that you reply with your password, social security number or confidential personal information. For more details visit http://infosecurity.vcu.edu/phishing.html
Re: Tape Drive compatibility
George, Sounds like you found yourself in a bowl of spaghetti with just a spoon to eat your way out. Some general recommendations: 1. Check all of your tapes for different generations of media. There may be a mix of JA, JB and JC media. 2. Assuming that you have both onsite and offsite tape pools, you may want to create two virtual libraries using ALMS and designate one for onsite use and the other for offsite os some other easy to manage scheme to differentiate their use. 3. Thinking ahead to manage & growth, you will need to divide the media and assign a volser range to assign to each library. If you do have different generation of media(JA,JB,JC), then it is relatively simple to assign one generation to each virtual library but if all media is say, JB media, then you will need to specify volser ranges for each library and when you get a new set of media in the current sequence, you will need to assign new volser ranges for each virtual library - not difficult just another thing to manage. Cheers, Neil Strand From: George Huebschman To: ADSM-L@VM.MARIST.EDU, Date: 03/11/2014 01:56 PM Subject:[ADSM-L] Tape Drive compatibility Sent by:"ADSM: Dist Stor Manager" My question is: Is there a way to determine what tapes in a 3584 library have been written to by E05 or E06 3592 tape drives? Because: I have a library with two generations of drives. I discovered this morning that my DR Tape Library had no scratch tapes. I expected around 200. I found that I had 167 libvolumes that were marked "Private" with no last use. I checked and found that they were not in volhistory, so I updated them to scratch status. Then I wanted to know why. I found a drive offline, with an online path. I offlined the path until I could determine why the drive was offline. I queried the actlog for a plethora of error messages over the last day. I wondered if I would see a lot of attempts to use the path to the drive that was offline, but I didn't. I saw a number of "ANR8779E Unable to open drive" errors matched with "ANR8381E 3592 volume Volser01 could not be mounted in drive 3592_x", for a different drive, just one. TSM used that one drive and eventually tried all the scratch media and marked them private. I tried again forcing TSM to use different E05 drives with the same result. ( I think all my scratch media is now formatted for E06.) I WAS able to run a DB backup to an E06 tape drive by taking all of the E06 tape paths offline. When the newer tape drives were installed, it was believed that they would be compatible with the earlier drives. (before my time here) But, while they can read tapes written by E05, the E05 can not read or write to tapes written by an E06 drive. I could just turn off the two E06 tape drives, I will still have six E05 drives. But that leaves me with two problems that I see. - Tapes written to by E06 will be unusable. - Any tapes brought from Production (Export tapes, DB tapes, Data) would be unreadable, because Prod is only using E06 tape drives. (Because we had this same problem there.) (Of course, I can always put the E06 Path back online as needed.) George Huebschman (George H.) The contents of this email are the property of PNC. If it was not addressed to you, you have no legal right to read it. If you think you received it in error, please notify the sender. Do not forward or copy without permission of the sender. This message may contain an advertisement of a product or service and thus may constitute a commercial electronic mail message under US Law. The postal address for PNC is 249 Fifth Avenue, Pittsburgh, PA 15222. If you do not wish to receive any additional advertising or promotional messages from PNC at this e-mail address, click here to unsubscribe. https://pnc.p.delivery.net/m/u/pnc/uni/p.asp By unsubscribing to this message, you will be unsubscribed from all advertising or promotional messages from PNC. Removing your e-mail address from this mailing list will not affect your subscription to alerts, e-newsletters or account servicing e-mails.
Re: Tape Drive compatibility
Cheers back to you Neil! - They are all JA volumes. I have to wait for them to fail to ID them. - There are copypools so a second virtual library is a good option. - I was able to determine that all of the scratch made private were formatted for E06 drives. I took the E06 drives/paths offline and the tapes were all umountable. The volser label could not be read. I was able to make them usable by labeling them back in using only E05 drives. Since then I found 1,432 "ANR8447E .No drives are currently available in library" in the actlog. Normally that would make my mouth dry, but I know that I DO have paths to drives available. I expect that the errors are symptoms of TSM trying to mount E06 media with no E06 drives, so it is a reassuring symptom. I can look up the media involved and either do a restore volume or move data. I would need to use an E06 drive for the move data and possibly (pretty likely) for the restore volume operations. - My favored solution would be to upgrade the drives to all the same type, but I am not writing the check and neither is our customer. I like the idea of utilizing the two E06 drives for another reason beyond just using full capacity. We are correcting an issue with replication of SVC volumes over Global Mirror. It is billed as asynchronous, but ...it isn't. When daily changes were a quarter of what they are now it caused detectable but trivial slowness in Prod applications. Now it is a serious problem. The cure requires restructuring replication...and reshipping ALL of the production data. It's going to take ten days more or less. That is ten days without a recovery pointwell, without one that meets the SLA Management demands on the one hand that service interruptions and delays to the customer end, but they are unwilling to accept such a serious gap in DR capability So, the problem gets worse. (To me) Export media seems to be a way to mitigate that recovery gap. Daily exports are not elegant, they are a poor plug in the gap, but the alternative is no plug in the gap. Export media don't need to be in the destination TSM DB, which makes it unnecessary to restore a Prod db _backup to the DR TSM server. The idea is not popular though. The catch is that Prod is using E06. However, it has unused E05 drives. Partitioning the libraries looks ever better. Thanks Neil and Norman George Huebschman (George H.) The contents of this email are the property of PNC. If it was not addressed to you, you have no legal right to read it. If you think you received it in error, please notify the sender. Do not forward or copy without permission of the sender. This message may contain an advertisement of a product or service and thus may constitute a commercial electronic mail message under US Law. The postal address for PNC is 249 Fifth Avenue, Pittsburgh, PA 15222. If you do not wish to receive any additional advertising or promotional messages from PNC at this e-mail address, click here to unsubscribe. https://pnc.p.delivery.net/m/u/pnc/uni/p.asp By unsubscribing to this message, you will be unsubscribed from all advertising or promotional messages from PNC. Removing your e-mail address from this mailing list will not affect your subscription to alerts, e-newsletters or account servicing e-mails.
Re: Tape Drive compatibility
Hi George, I've had mixed drives in a library from before. What I've had to do set the devc format to the lesser drive format. I know this does not utilize the features of the new drives. But administratively when you no choice, it is much easier than splitting the library. http://publib.boulder.ibm.com/infocenter/tsminfo/v6/index.jsp?topic=%2Fcom.ibm.itsm.srv.doc%2Ft_devclass_define_ulw.html Best of Luck, -Nick On Wed, Mar 12, 2014 at 2:46 PM, George Huebschman wrote: > Cheers back to you Neil! > > - They are all JA volumes. I have to wait for them to fail to ID them. > - There are copypools so a second virtual library is a good option. > - I was able to determine that all of the scratch made private were > formatted for E06 drives. I took the E06 drives/paths offline and the > tapes were all umountable. The volser label could not be read. > I was able to make them usable by labeling them back in using only > E05 drives. > Since then I found 1,432 "ANR8447E .No drives are currently available in > library" in the actlog. Normally that would make my mouth dry, but I know > that I DO have paths to drives available. I expect that the errors are > symptoms of TSM trying to mount E06 media with no E06 drives, so it is a > reassuring symptom. I can look up the media involved and either do a > restore volume or move data. I would need to use an E06 drive for the > move data and possibly (pretty likely) for the restore volume operations. > > - My favored solution would be to upgrade the drives to all the same type, > but I am not writing the check and neither is our customer. > > I like the idea of utilizing the two E06 drives for another reason beyond > just using full capacity. > We are correcting an issue with replication of SVC volumes over > Global Mirror. It is billed as asynchronous, but ...it isn't. > When daily changes were a quarter of what they are now it caused > detectable but trivial slowness in Prod applications. Now it is a serious > problem. > The cure requires restructuring replication...and reshipping ALL of the > production data. It's going to take ten days more or less. > That is ten days without a recovery pointwell, without one that meets > the SLA > Management demands on the one hand that service interruptions and delays > to the customer end, but they are unwilling to accept such a serious gap > in DR capability So, the problem gets worse. > (To me) Export media seems to be a way to mitigate that recovery gap. > Daily exports are not elegant, they are a poor plug in the gap, but the > alternative is no plug in the gap. Export media don't need to be in the > destination TSM DB, which makes it unnecessary to restore a Prod db > _backup to the DR TSM server. The idea is not popular though. > > The catch is that Prod is using E06. However, it has unused E05 drives. > Partitioning the libraries looks ever better. > > Thanks Neil and Norman > George Huebschman (George H.) > > > > The contents of this email are the property of PNC. If it was not addressed > to you, you have no legal right to read it. If you think you received it in > error, please notify the sender. Do not forward or copy without permission of > the sender. This message may contain an advertisement of a product or service > and thus may constitute a commercial electronic mail message under US Law. > The postal address for PNC is 249 Fifth Avenue, Pittsburgh, PA 15222. If you > do not wish to receive any additional advertising or promotional messages > from PNC at this e-mail address, click here to unsubscribe. > https://pnc.p.delivery.net/m/u/pnc/uni/p.asp > By unsubscribing to this message, you will be unsubscribed from all > advertising or promotional messages from PNC. Removing your e-mail address > from this mailing list will not affect your subscription to alerts, > e-newsletters or account servicing e-mails.
Delete Volhist
If I wanting to keep two weeks of database backups I'm a little confused on how to run the delete volhist command. Usually I would run the following command: delete volhist type=dbb todate=today-14 With running only type=dbb I'm noticing a lot of volumes that no longer exist in the volhist file, so I wanted to ask this forum if I would run into any issues running the following command instead: delete volhist type=all todate=today-14 Regards, Eric
Re: Delete Volhist
Hello. We include parms: force and devc DELETE VOLHISTORY type=dbb todate=today-7 force=yes devc=xxxclass -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Maness, Eric Sent: Wednesday, March 12, 2014 5:06 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] Delete Volhist If I wanting to keep two weeks of database backups I'm a little confused on how to run the delete volhist command. Usually I would run the following command: delete volhist type=dbb todate=today-14 With running only type=dbb I'm noticing a lot of volumes that no longer exist in the volhist file, so I wanted to ask this forum if I would run into any issues running the following command instead: delete volhist type=all todate=today-14 Regards, Eric
Re: Delete Volhist
Also... on source server do: RECONCILE VOLUMES xxxCLASS (where xxxCLASS is the device classthis will tell you if any volumes are invalid) Output Example: Volume TSMNBG.DSS.372056474 not valid, source server missing corresponding entry for target server. RECONCILE VOLUMES xxxCLASS fix=yes (to mark the invalid files for deletion) -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Maness, Eric Sent: Wednesday, March 12, 2014 5:06 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] Delete Volhist If I wanting to keep two weeks of database backups I'm a little confused on how to run the delete volhist command. Usually I would run the following command: delete volhist type=dbb todate=today-14 With running only type=dbb I'm noticing a lot of volumes that no longer exist in the volhist file, so I wanted to ask this forum if I would run into any issues running the following command instead: delete volhist type=all todate=today-14 Regards, Eric
Re: Tape Drive compatibility
Nick, the catch here is that I already have media in Generation 3 format.. After setting the Gen 3 drives to write in Gen 2 density, they are also restricted to reading at Gen2. I would still have to remediate the Gen3 media. Hi George, I've had mixed drives in a library from before. What I've had to do set the devc format to the lesser drive format. I know this does not utilize the features of the new drives. But administratively when you no choice, it is much easier than splitting the library. http://publib.boulder.ibm.com/infocenter/tsminfo/v6/index.jsp?topic=%2Fcom.ibm.itsm.srv.doc%2Ft_devclass_define_ulw.html Best of Luck, -Nick George Huebschman (George H.) (301) 699-4013 (301) 875-1227 (Cell) The contents of this email are the property of PNC. If it was not addressed to you, you have no legal right to read it. If you think you received it in error, please notify the sender. Do not forward or copy without permission of the sender. This message may contain an advertisement of a product or service and thus may constitute a commercial electronic mail message under US Law. The postal address for PNC is 249 Fifth Avenue, Pittsburgh, PA 15222. If you do not wish to receive any additional advertising or promotional messages from PNC at this e-mail address, click here to unsubscribe. https://pnc.p.delivery.net/m/u/pnc/uni/p.asp By unsubscribing to this message, you will be unsubscribed from all advertising or promotional messages from PNC. Removing your e-mail address from this mailing list will not affect your subscription to alerts, e-newsletters or account servicing e-mails.
Re: Delete Volhist
Op 12 mrt. 2014, om 22:05 heeft Maness, Eric het volgende geschreven: > If I wanting to keep two weeks of database backups I'm a little confused on > how to run the delete volhist command. Usually I would run the following > command: > > delete volhist type=dbb todate=today-14 > > With running only type=dbb I'm noticing a lot of volumes that no longer exist > in the volhist file, so I wanted to ask this forum if I would run into any > issues running the following command instead: > > delete volhist type=all todate=today-14 > yes, that's safe to do. It will not delete volhist for volumes either assigned to a pool, or used by a library sharing client (if applicable). Do not, under any circumstances, ever include force=yes in a scripted del volhist, force=yes is an option that should only be used if you have verified 10 times that this is indeed what you want. No matter what anyone else does, force=yes is rarely needed and should not be used routinely. I usually do something like del volhist t=ddb todate=-5 del volhist t=all todate=-30 but I rarely use the longer retention of the 'other' volhist info. But do clean it up once in a while... > Regards, > Eric -- Met vriendelijke groeten/Kind Regards, Remco Post r.p...@plcs.nl +31 6 248 21 622