Neutering a test server
Recently, for migration/testing purposes, I did a full conversion of a 5.5 server to 6.2 on my test TSM server. I would like to continue using this server to test additional upgrades without having to wipe and rebuild. Unfortunately, since it is a copy of a real server, whenever I fire it up, it keeps trying to reach out and touch other TSM servers that it has definitions to (library manager, etc), thus producing constant error messages due to invalid passwords, etc. I am concerned if I play with it to do like things mass-deletes, etc, it will try to do things like purge/release tapes, etc. Besides adding to DSMSERV.OPT: DISABLESCHEDS YES NOMIGRRECL What else can I do to neuter it to avoid possible problems? In this same vein, is there a simple way to remove the current instance and install/configure another one? 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
TSM V6.2 DB Directories
Is doing a TSM DB backup/restore the only way to remove a TSM DB directory in V6.2? David
Re: Neutering a test server
If you really want to isolate it, change the IP address to one in an unused/isolated subnet/vlan and don't give it a route statement. Make sure DHCP is not enabled on any of your other NICs. -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Zoltan Forray/AC/VCU Sent: Monday, May 14, 2012 8:46 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] Neutering a test server Recently, for migration/testing purposes, I did a full conversion of a 5.5 server to 6.2 on my test TSM server. I would like to continue using this server to test additional upgrades without having to wipe and rebuild. Unfortunately, since it is a copy of a real server, whenever I fire it up, it keeps trying to reach out and touch other TSM servers that it has definitions to (library manager, etc), thus producing constant error messages due to invalid passwords, etc. I am concerned if I play with it to do like things mass-deletes, etc, it will try to do things like purge/release tapes, etc. Besides adding to DSMSERV.OPT: DISABLESCHEDS YES NOMIGRRECL What else can I do to neuter it to avoid possible problems? In this same vein, is there a simple way to remove the current instance and install/configure another one? 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 This electronic transmission and any documents accompanying this electronic transmission contain confidential information belonging to the sender. This information may be legally privileged. The information is intended only for the use of the individual or entity named above. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or the taking of any action in reliance on or regarding the contents of this electronically transmitted information is strictly prohibited.
Re: Neutering a test server
What I do on our test server is put dummy entries in the /etc/hosts file for my other tsm servers. The search order is set to check hosts file entries first, then dns. For example, real server:tsm1 192.168.1.1 on server - in /etc/hosts: tsm2 99.99.99.99 Of course, this is assuming you have names in the tsm server definitions. Rick From: Zoltan Forray/AC/VCU zfor...@vcu.edu To: ADSM-L@VM.MARIST.EDU Date: 05/14/2012 09:54 AM Subject:Neutering a test server Sent by:ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU Recently, for migration/testing purposes, I did a full conversion of a 5.5 server to 6.2 on my test TSM server. I would like to continue using this server to test additional upgrades without having to wipe and rebuild. Unfortunately, since it is a copy of a real server, whenever I fire it up, it keeps trying to reach out and touch other TSM servers that it has definitions to (library manager, etc), thus producing constant error messages due to invalid passwords, etc. I am concerned if I play with it to do like things mass-deletes, etc, it will try to do things like purge/release tapes, etc. Besides adding to DSMSERV.OPT: DISABLESCHEDS YES NOMIGRRECL What else can I do to neuter it to avoid possible problems? In this same vein, is there a simple way to remove the current instance and install/configure another one? 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 - The information contained in this message is intended only for the personal and confidential use of the recipient(s) named above. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately, and delete the original message.
Re: Neutering a test server
On 05/14/2012 09:45 AM, Zoltan Forray/AC/VCU wrote: What else can I do to neuter it to avoid possible problems? I would say: + delete the paths from this server to the tape drives + delete the paths from this server to the library + Remove this server from the FC zone that can access the library and drives. That ought to keep you from overwriting tapes. If you get errors about failed communications attempts, I'd consider that not a huge deal. In this same vein, is there a simple way to remove the current instance and install/configure another one? My firm opinion on this is that you _want_ to wipe and rebuild when you reinstall. You ought to have your configuration control well enough in place that this doesn't occupy a lot of human time. And if it's not quite there, each burn-and-restart iteration is another opportunity to improve the automation. - Allen S. Rout
Re: Best practices for Oracle and DB2 Moves
We are doing a 5.5 to 6.2 migration now by exporting all our nodes to new servers. Some of our oracle nodes are very large, but exporting works fine, it just takes a while. We had one node that took over a week to complete. Here's an outline of our process: TSM-A is the 5.5 server. TSM-B is the 6.2 server. NODE1 is currently backing up to TSM-A using the TDP client. 0. Instruct DBAs to halt clean ups of old data (TDPOsycn or whatever scripts they run). 1. Export NODE1 from TSM-A to TSM-B. a. If there are mulitple file spaces export a few at a time to make it more manageable and to not fill BACKUPPOOL on TSM-B if possible. 2. NODE1 continues to backup to TSM-A. 3. Catchup export. You're now missing a day to a week of data, so after the initial export is done, do another export specifying the date using fromdate set to the date of the start of the orginal export and merge=yes. If there's a lot of data it could take a day to catch up. 4. Stop backups on NODE1. 5. Do a final catchup export using fromdate set to date of catchup export. Don't forget merge=yes. 6. Switch NODE1 over to TSM-B. 7. Make sure backups are working and all backup data is on the new server. 8. Delete NODE1 from TSM-A when you're comfortable. On 5/13/2012 23:42, Xav Paice wrote: - Original Message - From: Steve Harrisst...@stevenharris.info Hi All Like a lot of us, I'm contemplating a TSM 5.5 to 6.3 move for one of my customers. Most clients are not a problem, point the client at the new server, take the first backup, and then after an appropriate length of time either delete the data on the old server or export/import whatever is left. This works fine for the BA client, Domino, MSSQL, SAP, however it does not work for DB2 and Oracle. Since DB2 and Oracle keep track of their own named backups, and delete these when they have expired from the DBMS point of view, and they can only access one TSM node at a time, there will be orphaned backups left on the old server that will never expire, and as their entries are no longer in the DBMS's catalog they will never be deleted if they are imported to the new server. This particular customer likes to keep a periodic backup for a long time so it is a real issue. I just did Butterfly training, and that product solves the problem for oracle by restore/re-backup and fiddle the rman catalog. What are the rest of you doing to address this issue? Regards Steve. Steven Harris TSM Admin, Canberra Australia You could 'export node' - however if you want to do that across the LAN it does rely on the new server having a new name so you can do server-server comms, and a password reset. Or you can rename the old server, and reset the passwords on all the nodes you've not yet moved. Or just export/import via media. There is a time issue where you don't want the rman catalog resync'd or it will re-do a full backup depends on the time taken to export/import if that is an issue or not. I still fail to see why it takes so long to insert the database when doing an upgrade.
TSM 6.2 6.3 upgrade problem
Folks, I'm trying to upgrade a TSM 6.2 server to 6.3 on AIX 6.1. The process completes, but gives an error that DB2 failed to install. When I check the db2_inst.log as directed, I'm getting the message: DBI1149E To execute this program, you must be the owner of the installation copy. Explanation: The current DB2 copy was not installed by the user who is running the program. User response: Log in as the user who installed the current copy of DB2 and rerun the command. Thing is, I'm doing this while logged in as root, which is how the 6.2 software was installed as well. I'm not finding any additional errors as of yet, and Google doesn't have much to help me.** Launching TSM in console mode just confirms that DB2 didn't upgrade, as it fails reporting that DB2 version 9.7.0.4 is required, while 9.7.0.2 is installed. The messages themselves are pretty clear; I just can't tell what needs to be changed in order for it to work. Thanks!
Mega-Exchange backup
I have a customer with a 1.2 TB Exchange 2007 DB, expected to grow to 3 TB in the next 4 months. Fulls are already a problem (14 hours). Is there any Exchange-related reason I can't do the fulls for a couple of storage groups on Monday, the next 2 on Tuesday, next 2 on Weds. etc and spread them out? Thanks ..
TSM admin/operator duties
Hi, Is there a standard SLA to draw a line between the duties of OS admins/operators and TSM admin/operators? Many TSM admin duties like TSM server maintenance, tape libraries, DRM, ... are evident. But some tasks like verifying backups could be the point of dispute. Maybe it is dependent upon the complexity of the environment: how many systems to backup, different flavors of operating systems and applications, ... I would be grateful for any input. Regards, Mehdi
Re: TSM admin/operator duties
Hi Mehdi My take on this is that we as TSM admins provide an infrastructure that clients use to back up, just as if they had a local tape drive attached to their box. It is up to us to keep that infrastructure running and ensure that things post-backup, such as BACKUP STG and offsiting of tapes happen. Its up to the client administrators - Wintel admins, Unix admins, DBAs - whoever - to confirm that their backups have completed correctly. Now of course we can help. If the backup is run by a TSM schedule we can notify them that something has gone wrong. If they get stuck with a client problem we can help to resolve it, but the responsibility for checking it worked is theirs. If management try to put responsibility on you, insist that every backup is scheduled by TSM and that you have admin rights on every box to correct problems (or something like the TSMManager agent to allow you to do what you need). It is unfair to be held responsible for things you have no control over. My own opinion. Steve Steven Harris TSM Admin, Canberra Australia On 14.05.2012 22:52, Mehdi Salehi wrote: Hi, Is there a standard SLA to draw a line between the duties of OS admins/operators and TSM admin/operators? Many TSM admin duties like TSM server maintenance, tape libraries, DRM, ... are evident. But some tasks like verifying backups could be the point of dispute. Maybe it is dependent upon the complexity of the environment: how many systems to backup, different flavors of operating systems and applications, ... I would be grateful for any input. Regards, Mehdi
Re: Best practices for Oracle and DB2 Moves
On 14.05.2012 00:42, Xav Paice wrote: - Original Message - From: Steve Harris st...@stevenharris.info Hi All Like a lot of us, I'm contemplating a TSM 5.5 to 6.3 move for one of my customers. Most clients are not a problem, point the client at the new server, take the first backup, and then after an appropriate length of time either delete the data on the old server or export/import whatever is left. This works fine for the BA client, Domino, MSSQL, SAP, however it does not work for DB2 and Oracle. Since DB2 and Oracle keep track of their own named backups, and delete these when they have expired from the DBMS point of view, and they can only access one TSM node at a time, there will be orphaned backups left on the old server that will never expire, and as their entries are no longer in the DBMS's catalog they will never be deleted if they are imported to the new server. This particular customer likes to keep a periodic backup for a long time so it is a real issue. I just did Butterfly training, and that product solves the problem for oracle by restore/re-backup and fiddle the rman catalog. What are the rest of you doing to address this issue? Regards Steve. Steven Harris TSM Admin, Canberra Australia You could 'export node' - however if you want to do that across the LAN it does rely on the new server having a new name so you can do server-server comms, and a password reset. Or you can rename the old server, and reset the passwords on all the nodes you've not yet moved. Or just export/import via media. There is a time issue where you don't want the rman catalog resync'd or it will re-do a full backup depends on the time taken to export/import if that is an issue or not. I still fail to see why it takes so long to insert the database when doing an upgrade. Xav, maybe I have the wrong end of the stick, but bear with me. Suppose I have an oracle node on OLDSERVER that runs a 12 month retention backup on the first of every month At the moment it has daily backups going back 35 days and 12 months work of monthlies. So, I move the node over to NEWSERVER, and start taking backups there. On 1 June, it takes a new monthly to NEWSERVER. That is as expected. It also attempts to delete the 1 June 2011 backup which is now due to expire. The delete will fail as that backup exists on OLDSERVER not on NEWSERVER. RMAN catalog gets cleaned up and there is now no knowledge of the 1 June 2011 backup in RMAN. Move ahead three months. I run an export/import with merge from OLDSERVER to NEWSERVER. The 1/6/2011, 1/7/2011 and 1/8/2011 backups all get copied across because they have never been deleted, as do the 35 days worth of daily backups that were valid when the node was cut across. There are no RMAN entries for these now, so they will never be deleted. Looks to me that my only option is to run TDPOSYNC. The same applies to DB2, although I should be able to delete what I no longer want using adb2util. Am I confused somewhere? Regards Steve.
