IBM LTO 3581 L38 are not ready for TSM ?
Hello Advancer: My TSM Server upgrade to V5.3.5.1 on Windows 2003 Server, but cannot support IBM TotalStorage 3581 2U Autoloader Model L38 , In TSM Supported Devices Page cannot find any message for 3581-L38 (* http://www-306.ibm.com/software/sysmgmt/products/support/IBM_TSM_Supported_Devices_for_AIXHPSUNWIN.html )* i don't know what version can be upgrage and support L38 ? Thanks~
Re: IBM LTO 3581 L38 are not ready for TSM ?
IBM 3581 Ultrium Tape Autoloader mean that all 3581 Tape Autoloader supported from the base levels 5.2.0.00 You must use Atape driver from ftp://ftp.software.ibm.com/storage/devdrvr/Windows/Win2003/Latest You don't need upgrade server from current level. * Wu Tony [EMAIL PROTECTED] [Tue, 29 May 2007 18:41:02 +0800]: Hello Advancer: My TSM Server upgrade to V5.3.5.1 on Windows 2003 Server, but cannot support IBM TotalStorage 3581 2U Autoloader Model L38 , In TSM Supported Devices Page cannot find any message for 3581-L38 (* http://www-306.ibm.com/software/sysmgmt/products/support/IBM_TSM_Supported_Devices_for_AIXHPSUNWIN.html )* i don't know what version can be upgrage and support L38 ? Thanks~
TSM Incremental Database backups never expire
Greetings, I have just started doing incremental TSM database backups to a TSM Filesystem devclass. This has worked very well on some of our more active TSM servers, where the log would grow so fast that a single full TSM database backup performed daily was not sufficient. We don't always have enough tape drives or scratch tapes available to do extra full TSM database backups in the middle of the night just because the log is grown too big. So we set up a filesystem devclass, and pointed the TSM database backup trigger to do it's incremental backups to the filesystem. This has solved the problem with the log filling up. But now the filesytems are filling up! We have DBBACKUPEXPIREDAYS set to 5, so the full TSM dbbackups expire in 5 days, but apparently nothing comes along and deletes the old incremental DB files that get created by the incremental backups. I guess I just assumed they would expire when the full database backups expired. From the Admin Reference apparently they aren't expiring because they aren't in the VAULT status? If I issued 'set drmfileprocess yes', that could cause our move drmedia commands to include the file device class files, but that doesn't sound like a good idea, since the files can't actually be checked out. The manual isn't very clear on what happens in this case. Am I missing something in how to set this up? Best Regards, John D. Schneider Sr. System Administrator - Storage Sisters of Mercy Health System 3637 South Geyer Road St. Louis, MO. 63127 Email: [EMAIL PROTECTED] Office: 314-364-3150, Cell: 314-486-2359
Re: TSM Incremental Database backups never expire
The TSM DRM regimen must be rigorously followed for it to properly and fully work. Deviations make for problems. Refer to IBM Technote 1115957 and the Disaster Recovery Strategies with Tivoli Storage Manager redbook for the necessary steps and guidance. Consider also that your File approach to DB incrementals was set up as a tape utilization expedient; but be clear what role disk-locked database backups can play in the overall disaster recovery strategy, where the site is presumed lost, and thus disks with it. Richard Sims
Re: TSM client backup in a DiskXtender environment
You need to work with your storage admin to determine how you want to backup and how the retention policy will be on Centera or DX side, below are a few questions you need to have an answer: 1. Is the file being purged once it's migrated to Centera? 2. How frequent the purge rule was setup to run? 3. Is the files in Centera pool was configured to be never deleted? 4. Are there multiple Centera was configured to replicate each other? 5. How you want to recovery the system when the whole Windows server with DiskXtender need to be recovered? In our environment, since we have Centera configured to be replicated between both site, so we do not need to backup original files which has been migrated to Centera. In DiskXtender, you can configured whether you want to trigger the file retrieval from Centera when your bakcup program try to access the file, I have our DiskXtender configured to use Special application filtering, and edit the list to set DSM.EXE, DSMC.EXE, DSMCSVC.EXE, and DSMAGENT.EXE so when TSM need to backup the file, it will only backup the stub file. However, if TSM backup always occur before DiskXtender move the files to Centera, TSM will still backup the files which deemed to be moved to Centera, but those files can be configured with shorter retention since finally it will go to Centera. Also make sure your DX admin setup scheduled meta data export, so you can configured TSM to backup the meta data (along with DiskXtender registry), which is critical when you need to recover the whole environment. Regards, Fred Yang Sr. System Engineer Northshore LIJ Health System -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Schneider, John Sent: Friday, May 25, 2007 5:29 PM To: ADSM-L@VM.MARIST.EDU Subject: TSM client backup in a DiskXtender environment Greetings, We are making plans to implement EMC DiskXtender on a Windows Filesystem. We are unclear how the TSM client backs up a filesystem like this. In a DiskXtender environment, as files get to a certain age, say 90 days, they are sent to a DiskXtender backend store, which in our case will be an EMC Centera. The files are then replaced with a stub file that looks like the original name, but is a very small file. If an application tries to open a stub file for reading, then DiskXtender retrieves the file from its backend store, and returns it to the filesystem This way the filesytem can seem to contain TBs of data, but only be a couple hundred GBs in actual size. The functionality is similar to the TSM HSM software, I guess. So when TSM makes a pass through the filesystem the first time, it is backing up original files. Then eventually they get turned by DiskXtender into stub files. But I am told the stub file has the same date and name and size as the original file, so will TSM back up the stub, or will it skip over it because it doesn't look changed? Or, if it tries to back it up, won't DiskXtender recall the original file, and so TSM will back up the original? My storage guy is saying that TSM needs to back up the stubs, so that if some sort of corruption happens in the filesystem, we can restore all the stub files. He is telling me that if TSM was smart enough to undertand the Windows Extended Attibutes, it would know how to back up a stub file. Or does DiskXtender have a way to recreate the stub files? If anyone has this implemented, please describe how it works. Best Regards, John D. Schneider Sr. System Administrator - Storage Sisters of Mercy Health System 3637 South Geyer Road St. Louis, MO. 63127 Email: [EMAIL PROTECTED] Office: 314-364-3150, Cell: 314-486-2359 -Original Message- From: De la Fuente, Jason Sent: Friday, May 25, 2007 12:13 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; Schneider, John; [EMAIL PROTECTED]; '[EMAIL PROTECTED]' Subject: Centera Stub Files/DX/TSM Anyone, At EMC World this week, some DX folks were telling me that TSM does not recognize the extended file attributes that are associated with stub files. Consequently, a backup of a stubbed file would cause the entire file to be pulled back from the Centera. In a later session, another customer stated that IBM had addressed this issue and that TSM does now support extended file attributes. Can someone shed some light on this as it is relevant to our current direction of leveraging the Centera for the Enterprise Imaging and Medical Imaging (PACS) archive. Thanks! Jason de la Fuente MISD Enterprise Storage Lead 314-364-3148 [EMAIL PROTECTED] - The information contained in this electronic e-mail transmission and any attachments are intended only for the use of the individual or entity to whom or to which it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law.
Re: Audit library problem.
We've seen something like this. It was a tape library microcode bug, not a TSM problem. It's still unresolved, though it only bites us about once a year. Still in a finger-pointing dispute with Quantum over their library microcode. Looking at your time stamps, it appears that your library is giving back its stored inventory to TSM, and that it has become corrupted. So you've got to force the library to actually re-read all the barcodes, instead of regurgitating them from its own (corrupted) memory. A first step would be to power-cycle the library and also restart the TSM server. Roger Deschner University of Illinois at Chicago [EMAIL PROTECTED] === Copy protection: a headache only for the law-abiding. === --New York Times === On Mon, 28 May 2007, Erik Björndell wrote: Hi All! Have anyone experienced any problems like this one below? 05/28/07 14:08:02 ANR8457I AUDIT LIBRARY: Operation for library TLS-412180 started as process 15. (SESSION: 15, PROCESS: 15) 05/28/07 14:08:03 ANR8788W Unable to read the barcode of cartridge in slot-id 16 in library TLS-412180; loading in drive to read label. (SESSION: 15, PROCESS: 15) 05/28/07 14:08:03 ANR8300E I/O error on library TLS-412180 (OP=C0106C03, CC=207, KEY=05, ASC=21, ASCQ=01, SENSE=70.00.05.00.00.00.00.0A.00.00.00.00.21.01.00.C0.00- .02., Description=Device is not in a state capable of performing request). Refer to Appendix D in the 'Messages' manual for recommended action. (SESSION: 15, PROCESS: 15) 05/28/07 14:08:03 ANR8942E Could not move volume NOT KNOWN from slot-element 16 to slot-element 63000. (SESSION: 15, PROCESS: 15) 05/28/07 14:08:03 ANR8460E AUDIT LIBRARY process for library TLS-412180 failed. (SESSION: 15, PROCESS: 15) Erik Björndell SYSTEMS SPECIALIST Zetup by Semcon Mellanvägen 7, SE-461 38 Trollhättan, Sweden Mobile +46(0)736 84 04 06 E-mail [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] www.zetup.se http://www.zetup.se/
Re: Audit library problem.
Another thing we have seen with Qualstar libraries and later versions of TSM is a problem like this if you do not have the Drive Last parameter in the library set correctly. For instance, if you only have eight drives in your twelve drive library you need to ensure that drive last says 8 and not 12. Kelly J. Lipp VP Manufacturing CTO STORServer, Inc. 485-B Elkton Drive Colorado Springs, CO 80907 719-266-8777 [EMAIL PROTECTED] -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Roger Deschner Sent: Tuesday, May 29, 2007 12:20 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Audit library problem. We've seen something like this. It was a tape library microcode bug, not a TSM problem. It's still unresolved, though it only bites us about once a year. Still in a finger-pointing dispute with Quantum over their library microcode. Looking at your time stamps, it appears that your library is giving back its stored inventory to TSM, and that it has become corrupted. So you've got to force the library to actually re-read all the barcodes, instead of regurgitating them from its own (corrupted) memory. A first step would be to power-cycle the library and also restart the TSM server. Roger Deschner University of Illinois at Chicago [EMAIL PROTECTED] === Copy protection: a headache only for the law-abiding. === --New York Times === On Mon, 28 May 2007, Erik Björndell wrote: Hi All! Have anyone experienced any problems like this one below? 05/28/07 14:08:02 ANR8457I AUDIT LIBRARY: Operation for library TLS-412180 started as process 15. (SESSION: 15, PROCESS: 15) 05/28/07 14:08:03 ANR8788W Unable to read the barcode of cartridge in slot-id 16 in library TLS-412180; loading in drive to read label. (SESSION: 15, PROCESS: 15) 05/28/07 14:08:03 ANR8300E I/O error on library TLS-412180 (OP=C0106C03, CC=207, KEY=05, ASC=21, ASCQ=01, SENSE=70.00.05.00.00.00.00.0A.00.00.00.00.21.01.00.C0.00- .02., Description=Device is not in a state capable of performing request). Refer to Appendix D in the 'Messages' manual for recommended action. (SESSION: 15, PROCESS: 15) 05/28/07 14:08:03 ANR8942E Could not move volume NOT KNOWN from slot-element 16 to slot-element 63000. (SESSION: 15, PROCESS: 15) 05/28/07 14:08:03 ANR8460E AUDIT LIBRARY process for library TLS-412180 failed. (SESSION: 15, PROCESS: 15) Erik Björndell SYSTEMS SPECIALIST Zetup by Semcon Mellanvägen 7, SE-461 38 Trollhättan, Sweden Mobile +46(0)736 84 04 06 E-mail [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] www.zetup.se http://www.zetup.se/
Windows 2003 R2 File Restore statistics
Folks, Last week I weighed into a discussion about restore performance on Windows platforms and stated that it is only possible to restore something like 50-60K files per hour. Someone else in the list provided information that contradicted my assertion. This caused me to think and since I had the resources in the lab, I decided to run some new tests to see what I might see. Something has apparently changed. I will stick by my 18 month old results, but I have now observed much higher restore performance. Not sure what the story is. My original testing was done on Windows 2003 Server. The new testing I am doing is on Windows 2003 R2 and the latest service pack. I conjecture that something changed in the file create code or that the hardware I am running now is significantly faster than 18 months ago. I like the former but willing to consider the latter. My testing all those months ago was on the latest hardware at the time, including I/O subsystems and it didn't really matter what the storage was: locally attached SCSI or FC attached SAN storage. Results were very similar. Today's numbers look something like 200K files/per hour restoring from file device class pools on Compellent SAN over GigE to another FC attached storage array. Large read and write caches on both sides. Hardly any CPU utilized on the client and upwards of 80% network utilization. I believe my bottleneck is on the Compellent SAN but will investigate further by teaming my NICs and getting a bit more network involved. I intend to publish a new STORServer/TSM performance report in the next couple of weeks detailing what I've learned. Expect this to include LTO-4 performance as well as the backup/restore stuff already mentioned. Thought, though, that I should get what I had together out to all of you sooner rather later since I was very wrong in my original post. Thanks, Kelly J. Lipp VP Manufacturing CTO STORServer, Inc. 485-B Elkton Drive Colorado Springs, CO 80907 719-266-8777 [EMAIL PROTECTED]
Re: TSM Incremental Database backups never expire
Richard, I could't agree more. The incremental database backups going to disk will not help us in a disaster recovery scenario; we still get a full TSM database backup to tape every 24 hours for DR. The incremental database backup was proposed to us by an IBM Global Services consultant because the TSM log can't grow past 13GB, and some of our TSM servers have too much activity and their logs were filling up. We used to allow the TSM server to trigger full backups in that situation; but the problem was that occasionally there weren't enough tape drives available, and the log would fill up while waiting for one. Then I was up in the middle of the night recovering a TSM server by extending it's log temporarily. Not pleasant to do 2 or 3 times a week, and always risky. I would still like to ask that someone address my question about how do I expire the old incremental database files? If I turn on DRFILEPROCESS so move drmedia picks them up, will they go to VAULT status, then get deleted by expire inv? Best Regards, John D. Schneider Sr. System Administrator - Storage Sisters of Mercy Health System 3637 South Geyer Road St. Louis, MO. 63127 Email: [EMAIL PROTECTED] Office: 314-364-3150, Cell: 314-486-2359 -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Richard Sims Sent: Tuesday, May 29, 2007 10:44 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] TSM Incremental Database backups never expire The TSM DRM regimen must be rigorously followed for it to properly and fully work. Deviations make for problems. Refer to IBM Technote 1115957 and the Disaster Recovery Strategies with Tivoli Storage Manager redbook for the necessary steps and guidance. Consider also that your File approach to DB incrementals was set up as a tape utilization expedient; but be clear what role disk-locked database backups can play in the overall disaster recovery strategy, where the site is presumed lost, and thus disks with it. Richard Sims
ext2 extended file attributes?
One of my users pointed out that ext2 has an extended attribute to tell dump not to back it up. He was wondering if TSM honored that setting. I gave it a try (chattr +d test_file) and then did an incremental backup of the directory. TSM seemed to ignore the no_dump bit and backed up the file, and upon restore, didn't restore the ext2 attributes (they were all blank.) Is this expected? I can understand, perhaps, not honoring the no_dump (since it's not dump,) but I'm a little concerned extended file attributes for ext3 aren't backed up/restored. Is there a special flag or setting I need to define on the client for that behavior? A bug? This is on a 5.3.3 client on a RedHat AS4 system. Dave
Re: TSM Upgrade to V5.3.4.2
Um. It's not a patch in the sense that it has an APAR number, it's a patch in the sense that it isn't in a formal install package. Go to the FTP site and look in the TOOLS directory: ftp://ftp.software.ibm.com/storage/tivoli-storage-management/tools/ Select either WINDOWS or UNIX depending on where your TSM server runs. Download the files and read the README very CAREFULLY, there are several steps. After you copy the files, you shut down your server and enter a dsmserv runfile command to load the files, then bring your TSM server back up. It's in the instructions. I've installed the patch many times on both Windows and AIX, never had a problem. Happy TSM-ing! From: ADSM: Dist Stor Manager on behalf of Lamb, Charles P. Sent: Fri 5/25/2007 3:25 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: TSM Upgrade to V5.3.4.2 Our consultant recommended that we update to V5.4.3.2 for now and in the spring of '08, update to V5.4.x.x which will allow V5.4.x.x to mature more. We have loaded the TSM command line interface V5.4.0.4 on some PCs which has help our TSM operational personnel since they perform a lot of command line functions without having to use the ISC V6.0.1.1 media package software. I did not know there was an APAR to allow the old web GUI to work with V5.3/V5.4. What is the APAR number?? -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Prather, Wanda Sent: Friday, May 25, 2007 2:06 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] TSM Upgrade to V5.3.4.2 My biggest problem with the 5.3.4.2 ISC was the java-sometimes-pop-up window for the command line function; it didn't process output from scripts and command line the same way as the old admin GUI. I'm curious as to why you stopped with 5.3.4.2 instead of 5.4; the ISC 5.4 command-line window seems much better; queries and scripts come back pretty consistently the same as the old Admin GUI window. In the meantime, install the patch that lets you use the old web GUI with 5.3. (Doesn't work with IE7, but works fine with older IE and Firefox). Naturally it doesn't have any of the new function in it, but the old stuff works fine. And it works with 5.4. W From: ADSM: Dist Stor Manager on behalf of Lamb, Charles P. Sent: Wed 5/23/2007 4:07 PM To: ADSM-L@VM.MARIST.EDU Subject: TSM Upgrade to V5.3.4.2 We just upgraded from TSM V5.2.7.3 to V5.3.4.2. The TSM ISC software needs some work ( our e-mail will not work with the words I wanted to use). We installed the ISC version from the TSM V5.4 media pack which IBM sent me. Any word on updates to ISC software?? I am using command line to complete our daily TSM work since the ISC does not have the q ac function which the old java web software had (search on both txt and message). A lot of re-training for us since everything is moved around in the ISC software.
Re: ext2 extended file attributes?
I ran into a similar situation where the TSM client (v5.2.3 at the time) wouldn't backup/restore the ext3 extended acls on RHEL3. The problem turned out to be that the TSM client is looking for libacl.so but couldn't find it. It was available as libacl.so.1 (which symlinked to libacl.so.1.1.0). By adding a symlink for /lib/libacl.so pointing to libacl.so.1 I was able to backup and restore files w/extended acls. -Ken Mueller -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Dave Mussulman Sent: Tuesday, May 29, 2007 3:15 PM To: ADSM-L@VM.MARIST.EDU Subject: ext2 extended file attributes? One of my users pointed out that ext2 has an extended attribute to tell dump not to back it up. He was wondering if TSM honored that setting. I gave it a try (chattr +d test_file) and then did an incremental backup of the directory. TSM seemed to ignore the no_dump bit and backed up the file, and upon restore, didn't restore the ext2 attributes (they were all blank.) Is this expected? I can understand, perhaps, not honoring the no_dump (since it's not dump,) but I'm a little concerned extended file attributes for ext3 aren't backed up/restored. Is there a special flag or setting I need to define on the client for that behavior? A bug? This is on a 5.3.3 client on a RedHat AS4 system. Dave
tdpsql client 5.3 is it compatible on 32bit windows OS ?
Anyone I am in the process of installing tdpsql client on windows 32bit machine. The install was easy for 5.2.1.6 It is a completely different story when I try to install tdpsql client 5.3.3 on windows 32bit. Is it compatible on 32bit or does (tdpsql client 5.3) only run on 64bit windows ? You will never quess how many times I tried to reinstall. Gary
Re: tdpsql client 5.3 is it compatible on 32bit windows OS ?
Hi Gary, Data Protection for SQL 5.3.3 was only released for Windows x64-bit. You should not try to install it on Windows 32-bit. The latest version for Windows 32-bit is 5.2.1.6. Data Protection for SQL 5.3.3 for x64 bit is the same functional level as Data Protection for 5.2.1.6 but compiled and tested on Windows x64. I hope this helps. Thanks, Del ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU wrote on 05/29/2007 04:31:53 PM: Anyone I am in the process of installing tdpsql client on windows 32bit machine. The install was easy for 5.2.1.6 It is a completely different story when I try to install tdpsql client 5.3.3 on windows 32bit. Is it compatible on 32bit or does (tdpsql client 5.3) only run on 64bit windows ? You will never quess how many times I tried to reinstall. Gary
