Re: discovering 3590 serial numbers on NT
Richard Bates wrote: > > I have multiple AIX TSM servers using 3590 tape drives (in two 3494 > libraries) across a SAN. When I needed to know the serial numers of the > rmtX devices I just used "lscfg -vl rmtX". This enabled me to define the > appropriate drives to the correct TSM library. Simple. > > When I build a similar TSM environment on NT and the TSM device driver > discovers the 3590s across the SAN I get a list of mtx.x.x.x devices. How > do I find out which physical 3590 each mtx.x.x.x device corresponds to? I > can't find anything similar to "lscfg" for NT. > > At the moment I'm having to define one tape drive to a library. Mount a > tape in the drive (if possible) and then use mtlib to see which tape drive > has got that tape mounted. Repeat for each drive. ...and that's the way ya gotta do it, thanks to the lack of a decent toolset for identifying SCSI devices in NT. -- Mark Stapleton ([EMAIL PROTECTED])
Re: Please comfirm...
hi i had the same problem with certain of my media. after moving the data from the volumes, i checked out the faulty media, using the checkout command. if their is nothing physically wrong with the tapes, you can reuse them by checking them in again. however, instead of using the checkin command, you should use the label command. using the label command, actually reinitialise the tapes again __ Reply Separator _ Subject: Please comfirm... Author: znoriega ([EMAIL PROTECTED]) at MM Date:05/05/2001 7:46 AM I got these messages when mounting and accessing data from the volume (003172). This volume contains critical data and i don't want to lose it. Please confirm if i did the right thing. I move the data from that volume to another volume and Adsm automatically delete the volume and make as scratch tape. Do i need to remove physical (checkout) this volume from adsm and library? -- ANR8820W Repairing VCR data for Volume 003172 in drive DRIVE3 (MT0.0.0.6); mount may be delayed. ANR8831W Because of media errors for volume 003172, data should be removed as soon as possible. ANR8337I 3590 volume 003172 mounted in drive DRIVE3 (MT0.0.0.6). regards, Zosi Noriega ADNOC P.O. Box 898 AUH, AUE
Re: Please comfirm...
Zosi - See my notes on VCR Data problems in http://people.bu.edu/rbs/ADSM.QuickFacts The Move Data you did was fine, and you do not have to Checkout the volume. But you probably need to update your drive(s) to improved microcode to eliminate the cause of the problem. Richard Sims, BU
Please comfirm...
I got these messages when mounting and accessing data from the volume (003172). This volume contains critical data and i don't want to lose it. Please confirm if i did the right thing. I move the data from that volume to another volume and Adsm automatically delete the volume and make as scratch tape. Do i need to remove physical (checkout) this volume from adsm and library? -- ANR8820W Repairing VCR data for Volume 003172 in drive DRIVE3 (MT0.0.0.6); mount may be delayed. ANR8831W Because of media errors for volume 003172, data should be removed as soon as possible. ANR8337I 3590 volume 003172 mounted in drive DRIVE3 (MT0.0.0.6). regards, Zosi Noriega ADNOC P.O. Box 898 AUH, AUE
Re: Problem downloading latest Windows Client
We had numerous occasions like this; found out the way "around" it was to ftp-login to our firewall, then ftp to the site (using "quote site" command) --- seems some firewalls get snotty when using a browser for ftp. Alternatively, go home (or to offsite client) and download via DSL or T1 ... both answers work for me. -Original Message- From: Thomas Denier [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 03, 2001 12:03 PM To: [EMAIL PROTECTED] Subject:Re: Problem downloading latest Windows Client Quoting Jeff Connor <[EMAIL PROTECTED]>: > I've been trying to download the latest Windows client from the > service.boulder.ibm.com FTP server all day but can get the .EXE to > download > all the way. I can download the README's but the .EXE file download > stops > at 22,168KB and hangs there every time. Anyone else had this happen? I once saw behavior like this while trying to download client software to an Intel-architecture Linux system. The problem went away when I shut down Linux, powered off the system, and powered on the system. I have since seen other behavior suggesting that the network card on that system is a little flaky.
Re: Identify tape volumes
If you have the activity log, a cheap&dirty method would be to select from volumeusage, then reconcile with the tapes that were used during that period (ie, search=' mounted' on the act-log query)... alternatively, do a query vol & query content for each tape returned from the volumeusage table. (You could use the show cmd for volumeusage & other info, but that's another story; search the archives for the full list of show cmd arguments.) Consider the following SELECT query, to queue up the right tapes: select distinct node_name,volume_name,stgpool_name from volumeusage \ where node_name='ClientXYZ' and stgpool_name='3570POOL' -Original Message- From: Jolley, Bill Sent: Thursday, May 03, 2001 6:45 AM To: [EMAIL PROTECTED] Subject:Identify tape volumes I am looking for a select statement to identify tape volumes used during an oracle db backup for a specific date (04/20/01). Can anyone help me? Thanks William M. Jolley EDS 9014 Research Drive Charlotte, NC 28226 Tel:704-548-5524 pag:877-471-5029 email:[EMAIL PROTECTED]
Re: Slow restore for large NT client outcome.. appeal to Tivoli
I have two fundamental suggestions, I have not seen item 2 mentioned yet: 1. Use Microsoft folder-copy (be sure to run WinDiff - it's notorious for *not* copying all the files/directories) - and compare performance for copying large number of customer files; 2. Run the instrum_client_detail trace - this is a client-level trace option, very cool, documented in a number of old ATSC and Performance info papers from the old ADSM days... it still works, and provides a very clear view of where time is being spent during backup/restore. We are exactly in that position with a very large client; we just ordered 6-drive, 72-slot LTO and H80 to handle existing 1.6 TB of file served data occupancy across 5 NT servers, some 7 million files/dirs. We will also mitigate the failure-recovery scenario to a large extent with fibre-attached EMC storage, replacing old dual P-Pro with latest Compaq server gear. As part of our "little" fix-it project, we will be doing some benchmark measurements; I, for one, plan to use both of the above listed methods to confirm/reset our expectations... sure hope we can do better than 5-10 GB/Hr restore speed. (Maybe will try Win2K as well as NT - if there is a possibility of keeping the resulting member server.) BTW, we did get some numbers from Tivoli/IBM indicating NT is the slowest, but all 3 platforms (NT, Solaris, AIX) are slowest with large numbers of small files (AIX is, by far, the fastest in their benchmarks!). We considered switching to Samba-like solution (with AIX), just so we could use the IMAGE backup for fast restore; that is how ArcServe can beat TSM - also, that's (somewhat) how Replica beats TSM, and that's one advantage of TDP for Workgroups... too bad the owning children could not get along well-enough to move that solution forward (ie, sending TDPfW data across LAN to TSM server). At this point, we're betting on (a) EMC reliability & recoverability (RAID-S), (b) combination of EMC and newer Compaq gear for better performance, and (c) TSM-5.1 (1q02) delivery of image backup for Win2K! Regards, Don -Original Message- From: Kelly J. Lipp [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 20, 2000 2:38 PM To: [EMAIL PROTECTED] Subject:Re: Slow restore for large NT client outcome.. appeal to Tivoli Could someone with experience doing large restores with ArcServe or BackupExec provide some performance numbers? I've been in shops where the backups were taking a very long time. Longer than my TSM backup took. I never witnessed a restore but how can it be better. I want the facts. I'm tired of hearing about how much faster ArcServe and BackupExec are (in theory) compared to TSM in reality. I'm sick and tired of it and I won't take it anymore! This is what happens when you TSM 24 hours per day. Your brain. Your brain on TSM. Not a pretty picture. Kelly J. Lipp Storage Solutions Specialists, Inc. PO Box 51313 Colorado Springs CO 80949-1313 (719) 531-5926 Fax: (719) 260-5991 Email: [EMAIL PROTECTED] www.storsol.com www.storserver.com -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of Keith E. Pruitt Sent: Wednesday, September 20, 2000 12:03 PM To: [EMAIL PROTECTED] Subject: Re: Slow restore for large NT client outcome.. appeal to Tivo Jeff, we too have a problem with small files. At first I thought it was a Netware thing because the servers we have the greatest amount of files on reside on the Netware servers. But reading emails from several users I see that I may have a future problem on the NT side. We store Word and WordPerfect docs on two Netware 5 machines and each server holds about 1.8 Million files apiece. Needless to say these files are not that big. It took over 11 hours to back each of the servers up and they total around 30GB per server. We were forced to perform a Full backup because our director and other new admins don't understand and feel comfortable with the "incremental forever" logic. I would hate to see what a restore would look like. In contrast, we just backed up a directory on an NT server we are using for our Backoffice conversion and that dir totals 35GB. That took 2h20m. We also performed a large restore from one AIX machine to another one of about 25GB. Less than 2 hours to restore. We have tweaked our Netware and AIX ADSM server according to performance guides and other suggestions and still have issues with small files. We will be moving our documents from Netware to NT soon and our NT guys like to refer to ADSM as crap. They are used to Arcserve but our now raving about BackupExec. It is going to be extremely difficult to explain if our huge machine can't keep up with their backup server. I know that overall ADSM is a better and more stable product but what do you do when you have a mixture of servers with large databases(ADSM's favorite) and (the more common) servers with small files that Arcserve and others like? I'm hoping another ADSM/TSM user ha
Re: Slow restore for large NT client outcome.. appeal to Tivoli
Correction... the traceflag is instr_client_detail, then use tracemax=4000 (for wrap-around) and tracefile=xxx.out. Don France Technical Architect - Unix Engineering/P.A.C.E. San Jose, CA mailto:[EMAIL PROTECTED] PACE - http://www.pacepros.com Bus-Ph: (408) 257-3037 -Original Message- From: France, Don G (Pace) Sent: Friday, May 04, 2001 9:50 PM To: [EMAIL PROTECTED] Subject:RE: Slow restore for large NT client outcome.. appeal to Tivoli I have two fundamental suggestions, I have not seen item 2 mentioned yet: 1. Use Microsoft folder-copy (be sure to run WinDiff - it's notorious for *not* copying all the files/directories) - and compare performance for copying large number of customer files; 2. Run the instrum_client_detail trace - this is a client-level trace option, very cool, documented in a number of old ATSC and Performance info papers from the old ADSM days... it still works, and provides a very clear view of where time is being spent during backup/restore. We are exactly in that position with a very large client; we just ordered 6-drive, 72-slot LTO and H80 to handle existing 1.6 TB of file served data occupancy across 5 NT servers, some 7 million files/dirs. We will also mitigate the failure-recovery scenario to a large extent with fibre-attached EMC storage, replacing old dual P-Pro with latest Compaq server gear. As part of our "little" fix-it project, we will be doing some benchmark measurements; I, for one, plan to use both of the above listed methods to confirm/reset our expectations... sure hope we can do better than 5-10 GB/Hr restore speed. (Maybe will try Win2K as well as NT - if there is a possibility of keeping the resulting member server.) BTW, we did get some numbers from Tivoli/IBM indicating NT is the slowest, but all 3 platforms (NT, Solaris, AIX) are slowest with large numbers of small files (AIX is, by far, the fastest in their benchmarks!). We considered switching to Samba-like solution (with AIX), just so we could use the IMAGE backup for fast restore; that is how ArcServe can beat TSM - also, that's (somewhat) how Replica beats TSM, and that's one advantage of TDP for Workgroups... too bad the owning children could not get along well-enough to move that solution forward (ie, sending TDPfW data across LAN to TSM server). At this point, we're betting on (a) EMC reliability & recoverability (RAID-S), (b) combination of EMC and newer Compaq gear for better performance, and (c) TSM-5.1 (1q02) delivery of image backup for Win2K! Regards, Don -Original Message- From: Kelly J. Lipp [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 20, 2000 2:38 PM To: [EMAIL PROTECTED] Subject:Re: Slow restore for large NT client outcome.. appeal to Tivoli Could someone with experience doing large restores with ArcServe or BackupExec provide some performance numbers? I've been in shops where the backups were taking a very long time. Longer than my TSM backup took. I never witnessed a restore but how can it be better. I want the facts. I'm tired of hearing about how much faster ArcServe and BackupExec are (in theory) compared to TSM in reality. I'm sick and tired of it and I won't take it anymore! This is what happens when you TSM 24 hours per day. Your brain. Your brain on TSM. Not a pretty picture. Kelly J. Lipp Storage Solutions Specialists, Inc. PO Box 51313 Colorado Springs CO 80949-1313 (719) 531-5926 Fax: (719) 260-5991 Email: [EMAIL PROTECTED] www.storsol.com www.storserver.com -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of Keith E. Pruitt Sent: Wednesday, September 20, 2000 12:03 PM To: [EMAIL PROTECTED] Subject: Re: Slow restore for large NT client outcome.. appeal to Tivo Jeff, we too have a problem with small files. At first I thought it was a Netware thing because the servers we have the greatest amount of files on reside on the Netware servers. But reading emails from several users I see that I may have a future problem on the NT side. We store Word and WordPerfect docs on two Netware 5 machines and each server holds about 1.8 Million files apiece. Needless to say these files are not that big. It took over 11 hours to back each of the servers up and they total around 30GB per server. We were forced to perform a Full backup because our director and other new admins don't understand and feel comfortable with the "incremental forever" logic. I would hate to see what a restore would look like. In contrast, we just backed up a directory on an NT server we are using for our Backoffice conversion and that dir totals 35GB. That took 2h20m. We also performed a large restore from one AIX machine to another one of about 25GB. Less than 2 hours to restore. We have tweaked our Netware and AIX ADSM server according to performance guides and other suggestions and still have issues with small files. We will be moving our documents from Netware to NT soon and our NT
