Some strange tape related issues?
Hi all I'm sorry for all the questions that follow, but the level of help I get from this board is outstanding. I've been trying to move my TSM Server 5.1.6.2 install from one sun server to another and today had the second attempt, but I came across some odd things that made me too paranoid to go ahead (again), when I have a fully working server to fall back on. Question 1 (I have only discovered this after attempting to move to the new server and then moving back) On the 22nd of March I labelled 10 brand new 3590s, I can see this in the vol hist. The first 7 of those 10 have already been used (filling) and there are three remaining that so far have not been touched. Now, I noticed a strange thing when I issued the q libv command is that those last three volumes are listed as DbBackup. 3494A 000867 Private DbBackup 3494A 000868 Private DbBackup 3494A 000869 Private DbBackup Now, if I do a q vol stg=tapepool status=empty I do see those three volumes, and other as I would expect. Volume Name Storage Device Estimated Pct Volume Pool Name Class Name Capacity Util Status (MB) --- -- - - 000662 TAPEPOOL 3590CLASS1 0.0 0.0 Empty 000686 TAPEPOOL 3590CLASS1 0.0 0.0 Empty 000704 TAPEPOOL 3590CLASS1 0.0 0.0 Empty 000705 TAPEPOOL 3590CLASS1 0.0 0.0 Empty 000861 TAPEPOOL 3590CLASS1 0.0 0.0 Empty 000867 TAPEPOOL 3590CLASS1 0.0 0.0 Empty 000868 TAPEPOOL 3590CLASS1 0.0 0.0 Empty 000869 TAPEPOOL 3590CLASS1 0.0 0.0 Empty 000893 TAPEPOOL 3590CLASS1 0.0 0.0 Empty I can see in the activity log that all ten volumes were labelled correctly and I have done nothing to change them, so any ideas what I'm seeing here and why? Question 2 - part 1 After restoring the TSM database to the new server and starting it, I got a load of the following messages :- 04/08/06 12:41:30 ANR8455E Volume 000155 could not be located during audit of library 3494A. Volume has been removed from the library inventory. Now, most of these were scratch volumes, but seeing as the Library had been paused and set to auto again (at which point it does an audit), and seeing as now I have reverted to the old server connected to the same library and TSM can see all the tape volumes fine, why could the new server not. I got as far as this part of the test time and then TSM still new all about the scratch tapes. So what might be different this time? Question 2 - part 2 Following on from above, the new server also complained that it could not see two tapes from the tapepool. But the tapes are present and again, back on the old server I can see/audit them fine. What's going on? Do I just need to delete the lib/drive/path definitions, recreate and then checkin the lib volumes, or should I be wary of that if something in the tape inventory is a bit off? Question 3 Following on from above, I get very paranoid that I'm going to do something to knacker the actual library inventory, over write tapes that do not want to be overwritten etc, and I want to safe guard this to make sure it doesn't happen. I have upped the reuse delay from 2 to 5 days for the tapepool and I'm assuming that nothing I do on TSM with regards to removing recreating drives/lib/paths, checkin libv/audit etc will directly effect that, but is there anything I should be wary of doing here? I don't want to do ANYTHING that would make it impossible to go back to the old server within the first few days (hence the 5 day reuse delay). Question 4 For this question I need to tell you the sequence of events. 1) Allow backups to finish 2) Create offsite volumes 3) Migrate all data from the backup pool (caching is off) 4) Backup the DB 5) Move the drm to offsite location = vault 6) Prepare the drmplan and move off site also 7) Halt TSM Server 8) Shut down physical server 9) Connect new server to the library and drives used above 10) Boot and check drives etc are seen 11) Restore the DB to the new server 12) Start TSM Now, as well as all the scratch tapes it can't see and the two from the tapepool, it also says that it can no longer see the
Re: Some strange tape related issues?
Farren - The kind of inconsistencies you're seeing are the kind I would expect if your new TSM server db is stale or otherwise inconsistent with the state of your production server. This particularly shows up where you have multiple TSM servers in any manner sharing the same library. There should have been a good db restoral as you went to the new server today. One quick way to check that is to do: SELECT DATE_TIME AS "DATE TIME ",TYPE,BACKUP_SERIES,VOLUME_NAME - FROM VOLHISTORY WHERE TYPE='BACKUPFULL' OR TYPE='BACKUPINCR' and check the date-time values for currency. Richard Sims
Re: Some strange tape related issues?
Hi Richard I see the following which to me looks as I would expect and vol 000188 was indeed the volume I used this morning. I did not see any errors during backup or restore. The only thing is that the database volumes on the new server had mirrored copies already in place. These were stale when I started the server but then syncd ok. Could this have caused a problem? date time TYPE BACKUP_SERIES VOLUME_NAME --- -- - -- 2006-04-03 10:14:19.00- BACKUPFULL 1912 000193 2006-04-04 09:40:02.00- BACKUPFULL 1913 000370 2006-04-05 09:32:03.00- BACKUPFULL 1914 000413 2006-04-06 09:59:45.00- BACKUPFULL 1915 000441 2006-04-07 09:36:42.00- BACKUPFULL 1916 000488 2006-04-08 10:05:48.00- BACKUPFULL 1917 000188 Thanks Farren |-+---| | Richard Sims <[EMAIL PROTECTED]> | | | Sent by: "ADSM: Dist Stor | | | Manager" | To| | |[EMAIL PROTECTED]| | |U | | 08/04/2006 16:40 | cc| | | | | Please respond to |Subject| | "ADSM: Dist Stor|Re: [ADSM-L] Some | | Manager"|strange tape | | |related issues?| | | | | | | | | | | | | | | | | | | |-+---| Farren - The kind of inconsistencies you're seeing are the kind I would expect if your new TSM server db is stale or otherwise inconsistent with the state of your production server. This particularly shows up where you have multiple TSM servers in any manner sharing the same library. There should have been a good db restoral as you went to the new server today. One quick way to check that is to do: SELECT DATE_TIME AS "DATE TIME ",TYPE,BACKUP_SERIES,VOLUME_NAME - FROM VOLHISTORY WHERE TYPE='BACKUPFULL' OR TYPE='BACKUPINCR' and check the date-time values for currency. Richard Sims ## The information contained in this e-mail and any subsequent correspondence is private and confidential and intended solely for the named recipient(s). If you are not a named recipient, you must not copy, distribute, or disseminate the information, open any attachment, or take any action in reliance on it. If you have received the e-mail in error, please notify the sender and delete the e-mail. Any views or opinions expressed in this e-mail are those of the individual sender, unless otherwise stated. Although this e-mail has been scanned for viruses you should rely on your own virus check, as the sender accepts no liability for any damage arising out of any bug or virus infection. ##
Re: Some strange tape related issues?
On Apr 8, 2006, at 1:20 PM, Farren Minns wrote: Hi Richard I see the following which to me looks as I would expect and vol 000188 was indeed the volume I used this morning. I did not see any errors during backup or restore. The only thing is that the database volumes on the new server had mirrored copies already in place. These were stale when I started the server but then syncd ok. Could this have caused a problem? Farren - Unused mirrors should not be an issue, in that the unmirrored copy of the database should be fully viable unto itself. The Vary On which performed synchronization just copies the primary image data. You mentioned in your first posting today that the library was in Pause mode for some reason when the new instance of the TSM server was started. The library needs to be viable when TSM goes to use it at any time; and at start-up time, TSM is trying to do a lot of communication with it, for volumes consistency checking. Putting the 3494 back into Auto mode does not result in an audit, but rather a library-specific Inventory check (depending upon library settings), where the accessor runs around scanning storage cell and drive contents. Manually performing a TSM Audit Library may correct TSM's knowledge of its volumes in the library. I would use mtlib commands to get a list of the library tapes with Category Codes reported, to assure that all volumes seem reasonable and appropriate for use with the Library category code numbers as end up in the new TSM server. Presumably, your atldd driver is in good shape on the new server (?) and the 3494's Library Manager has been updated to allow access by the new server system? (I expect so, but want to assure that basics are not overlooked.) The only other thing I could think of is that there may be some architectural inconsistency which makes a db restoral type of server transfer dubious or invalid, possibly one system being 32-bit and the other 64-bit, for example. I would pore over the Activity Log in the new server looking for other problem indications. Richard Sims
Re: Some strange tape related issues?
Maybe I can chip in something useful on question #4 (then again, maybe not...) It looks to me as if the DB backup you took in step 4 was what you used to restore the DB to the new server in step 11? If so, then I think that the fact that you did the 'move drm' in step 5, *after* the DB backup was made will be lost when that backup is restored. So I would expect the "new" server to think that whatever tapes were involved in the drm move offsite were still in the library...that's what its database says. Or do I misunderstand what's wrong in question 4? Regards, Bill Bill Kelly Auburn University OIT 334-844-9917 >>> Farren Minns <[EMAIL PROTECTED]> 04/08/06 9:05 AM >>> Question 4 For this question I need to tell you the sequence of events. 1) Allow backups to finish 2) Create offsite volumes 3) Migrate all data from the backup pool (caching is off) 4) Backup the DB 5) Move the drm to offsite location = vault 6) Prepare the drmplan and move off site also 7) Halt TSM Server 8) Shut down physical server 9) Connect new server to the library and drives used above 10) Boot and check drives etc are seen 11) Restore the DB to the new server 12) Start TSM Now, as well as all the scratch tapes it can't see and the two from the tapepool, it also says that it can no longer see the off site tapes that I created earlier this morning, even though they were moved off site and the status of those volumes changed to vault. TSM knew they had been removed from the library so why is it trying to see them 'in' the library now? The command I use to move the volumes is as follows :- move drm * wherestate=mountable tostate=vault remove=bulk Again, I'm sorry for the lengthy prose, but i thought it best to be as verbose as possible. All the best Farren Minns John Wiley & Sons Ltd