Re: Disk/Volume/mountpoint access for TSM 6.3 on Windows
It's late in the day, but my 2c here is to add that it's not always necessary in Windows to use separate drive letters for LUNs - it's possible to 'mount' a volume under a directory rather than eating letters. This would appear to be a much more scalable approach - however, the difficulty as we discovered is that under some operations (e.g. format/restore the db) drive space is calculated based on the letter, even though there is space available in the actual db directory - meaning incorrect calculations. Just a warning - mounting volumes under a single letter and sub directories _should_ work fine but doesn't. I'm not sure about IBM support on that either. Lots of drive letters is the only way to go. > On 12/09/2012 11:30 AM, Prather, Wanda wrote: > > Hi Steve, > > > > DB2 on Windows, like on AIX, does his %full calculations based on > > the amount of space on the drives where the DB and logs are > > located, just like it would do the %full calculations based on the > > amount of space in an AIX filesystem.
Re: Best practices for Oracle and DB2 Moves
- Original Message - > From: "Steve Harris" > > 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.
Re: Server DB restore from offsite TSM server SNAPSHOT
On Tue, 2012-02-21 at 09:44 -0500, Zoltan Forray/AC/VCU wrote: > I am trying to experiment with doing a V5 to V6 conversion by first > restoring the V5 server to a test server. > > We have very little experience doing DB restores and none involving an > offsite TSM server. My first attempts failed. I think I know how to fix > it but the docs on how to perform a DB restore are a little contradictory > to what I want to do. > > SERVER-A performs DB SNAPSHOT backups to SERVER-B via server-to-server > definitions. > > Installed a same-level TSM server onto a test machine. > Did "dsmserv format" to prepare DB space to the equivalent of SERVER-A. > Replaced the test server volhist, devconfig and dsmserv.opt files from > copies of SERVER-A like-files. > > Tried to do a "dsmserv restore db volumenames=name.I.got.from.volhist > devclass=SERVER-B" > > Since I tried this over a month ago, I don't recall the error but I think > it has to do with the server-to-server definition being out of sync since > this is not the original SERVER-A. > > My guess is to bring up the test server and manually do a "UPDATE SERVER > SERVER-B FORCESYNCE=YES" > > However, when I go through the book scenarios on restoring a server DB, it > says: > > "Attention: Do not start the server until after you restore the database > (the next step). Starting the server before the restore would destroy any > existing volume history files." > > So, how do I do this? Do I bring up the test server first and correct the > sync before replacing the volhist file? > > Am I wrong in how I am trying to do this? Is there a better/different > way to do this? > > Looking for any suggestions/hints. A simple suggestion maybe, to try a different track and reduce the risk of breaking server to server communications on your production machines Since you're restoring to a test server rather than recovering the prod one, how about you make a new, temporary, device class of type FILE and store that somewhere both the prod and test servers can access (NFS?). Then make a dbsnapshot backup to the new device class, backup volhist, and recover the test machine from the temporary device class. It's probably stating the obvious but you probably don't want to have your test machine break the server to server comms with the production machine.
Re: Help! Select statement syntax for legal reasons
You could, if you really want a SQL query, run the following SQL on a regular basis and dump the output to a file, which will give you a listing on the day of the tapes for that criteria: SELECT VOLUME_NAME from contents where object_id in (SELECT object_id FROM backups WHERE node_name LIKE 'LNBRTZM3%5YR' AND ll_name LIKE 'training%.nsf') If that wildcard is supposed to be just one character replace % with _ , but I took * in your question to mean 'one or more of any character'. Pedantic, but please ignore my own spelling and typos. However, the query will probably take an age to run and you'll need to keep a close eye on the server in case of log pinning etc. I'd advise against it if possible. Note that, as previously noted, a query like this will only give you a current snapshot - you seem to be asking which tapes the data was on between some dates in the past - I don't know how to do that. You could tell the auditors to advise you what data to collect for them to query you on at a later date...maybe you need to pull a complete TSM database backup out of the cycle and pop it on a shelf on a regular basis to keep them happy. DISCLAIMER - I've not tested that query, it might have errors I've not spotted. - "Joni M Moyer" wrote: > > I guess that's what I'm looking for today. A report that will show me > where that particular file is on what particular tape for LNMBRZM355YR > for the mail1 filesystem for the training.nsf database for the time > frame of 7/08 - 1/09. It's just proof for them of where it resides as > of today. I just don't know what the syntax of the SQL statement > should be to get that information? > > Any thoughts/ideas? > > Thanks! > > -Original Message- > From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf > Of George Huebschman > Sent: Thursday, February 09, 2012 2:02 PM > To: ADSM-L@VM.MARIST.EDU > Subject: Re: Help! Select statement syntax for legal reasons > > I agree with Thom, the data gets spread everywhere and moved often by > reclamation. You can only tell them where it was when you ran the > report. > > On Thu, Feb 9, 2012 at 1:35 PM, Thomas Denier < > thomas.den...@jeffersonhospital.org> wrote: > > > -Joni Moyer wrote: - > > > > >I have a situation where someone wants to know what tapes > particular > > >people's backup data is on for our TDP for Mail backups for the > time > > >period from 7/08 - 1/09. The TSM client names are LNBRTZM3*5YR > and > > >the mail filesystem location is: mailx and the .nsf file names we > are > > >looking for are the training*.nsf and we need to know what tapes > the > > >data is on. > > > > > > > > >LNBRTZM335YR, mail1\training.nsf > > > > > >LNBRTZM355YR, mail2\training2.nsf > > > > > >Does anyone know what the syntax of this select statement would be > to > > >find this information? Any help is greatly appreciated as I was > told > > >I need this information by EOD and I'm not quite sure how to > gather > > >this from the TSM server side. My TSM server is on AIX and is at > > >5.5.5.0. > > > > TSM files on tape are more or less routinely moved to other volumes > > by reclamation processing. As far as I can tell, there are three > > possible ways of dealing with this possibility: suppress > reclamation > > of the volumes involved, send updates to the lawyers when and if > > files are move to other volumes, or respond in bad faith by > implying > > that today's information will remain valid indefinitely. > > > > Thomas Denier >
Re: TSM 6.3 node replication
- "Wanda Prather" wrote: > > I think the answer to your question is technically "no". > > The recommended way to move the metatdata is to set up DB2 HADR to > replicate the DB, which accomplishes what you want. > (If your DB isn't too big for your bandwidth, you can also backup the > DB to disk and ship the DB backup via FTP, but that's another story.) > > There is an STE presentation that includes the DB2 HADR setup: > http://www-01.ibm.com/support/docview.wss?uid=swg27021382 > > > -Original Message- > From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf > Of Xav Paice > Sent: Tuesday, February 07, 2012 11:40 PM > To: ADSM-L@VM.MARIST.EDU > Subject: [ADSM-L] TSM 6.3 node replication > > Hi, > > I'm keen to make use of the new features in TSM 6.3, one of which is > node replication. However, the client I'm working with has limited > bandwidth between datacenters and there is no way that 4TB of change a > day is going to be copied across the link even if it is deduplicated. > Is there a way to replicate just the metadata and not the actual data, > whilst shipping copy pool tapes by courier? My original, pre-release, > understanding was that this was possible but the documentation is > leaving me less clear. > > I was thinking along the lines of configuring nodes for replication, > but disabling replication for the filespaces - but does that copy the > entries for data contained on the copy pool volumes even if it doesn't > copy the objects? Thanks Wanda - that presentation was just what I needed. I guess I could also do db backups to virtual volumes located on a deduplicated storage pool lots to test out and play with.
TSM 6.3 node replication
Hi, I'm keen to make use of the new features in TSM 6.3, one of which is node replication. However, the client I'm working with has limited bandwidth between datacenters and there is no way that 4TB of change a day is going to be copied across the link even if it is deduplicated. Is there a way to replicate just the metadata and not the actual data, whilst shipping copy pool tapes by courier? My original, pre-release, understanding was that this was possible but the documentation is leaving me less clear. I was thinking along the lines of configuring nodes for replication, but disabling replication for the filespaces - but does that copy the entries for data contained on the copy pool volumes even if it doesn't copy the objects?
Re: Offsite copypool question
- "Paul_Dudley" wrote: > On the SQL servers I have included the SQL database folder in the > Exclude-Include configuration of the normal TSM backup setup. (these > databases are backed up using TDP for SQL) As well as that, SQL is > running all the time so the normal TSM backup client would never be > able to get a lock on these database files. I already have a backup of > these SQL databases in the SQLDB_LTO4 storage pool and therefore a > copy is in the SQLDB_COPYPOOL storage pool so I don't need another > copy in BKPLTO4POOL and COPYPOOL_LTO3 The SQL database files themselves should be excluded rather than included since you won't get a consistent backup of them with the DB up and running, but I don't know if you do cold backups as well which would want them included. I like to include the directories and just exclude the actual database files (by extension and location) so a bare metal restore is easier. You might consider which management class you include them with if you do backup the db files cold occasionally. > > Any idea how I can work out why a backup copy of these SQL database > backups are ending up in BKPLTO4POOL and stop this from happening? > > It's likely you're getting the files captured by the client even with the db open. Try to exclude them in the inclexcl, or associate them with the right management class. 'Query occupancy' for the TDP node should list everything in the right storage pool. Take a look in the BA client gui and hunt down the database files - that will tell you if they are being stored. If you can see them as individual files, and you've not made a cold backup of the database, then that's the issue. You can delete them from the ba client if you wish and are sure they're not wanted.
Re: DSMADMC login slow on TSM 6.3
On Tue, 2011-12-20 at 21:47 -0500, Spearman, Wayne wrote: > Hello, > We have just installed TSM 6.3 on AIX 7. We are seeing a serious > slowness when we login to TSM with DSMADMC on AIX. The ID prompt comes > up fast enough but it takes anywhere from 6 to 30 seconds for the > password prompt to display. Once in everything is fine. If I use the > Windows DSMADMC to access the AIX TSM 6.3 server I do not see the > problem, the password prompt displays immediately. If I run DSMADMC from > our TSM 5.5 AIX server to access the TSM 6.3 Aix server the password > prompt comes up immediately. Putting passing the ID/PW to DSMADMC does > not help. My peers at other sites are not seeing this issue on their TSM > 6.3 servers. This is killing my scripts. I've search ADSM.ORG, but did > not find anything that helped. Does anyone have any suggestions on how > to correct this problem? > > Thanks, > Wayne > Just a suggestion, but firstly start looking at DNS/hosts name resolution - including forward and reverse lookups for the client and whatever you have in dsm.sys as the server hostname.
Re: TSM Migration Related
On Fri, 2011-12-02 at 22:50 -0800, venkatb wrote: > Hi, > > I have a TSM 5.2 running on AIX, IBM TS3500 library With 6 LTO-1 drives > connected to it. the library capacity is 253 tapes. > > Now we want to move to Latest TSM Version With Latest Library with LTO5 Drives > > Once the new setup is up and running, i want to migrate the DB to latest > version, and also move all my data from LTO1 Cartridges to LTO5 Cat rides. > > so that i can crash all my LTO1 Tapes (Around 1500), > > > 1) Can some pls suggest how i can do this ? > > 2) How to know the size of total data in tapes since day 1 ? > > 3)is these steps are correct ? > first i will define a disk pool, > then move data from the LTO1 to diskpool > then install new version, migrate DB, > the move data from diskpool to new LTO5 pool > > 4)Before Migrating i want to delete some data from the tapes ex: all data of > node1 before 2009 is this possible ? > > 5) Usually when stgpool out of space we cheeck out 100% full tapes from lib > and check in free tape and assign to stgpool, since last5years almost > 1500 full tapes are in boxes, when some restoration comes, TSM will ask for > check in the required volumes, and we check in, once finishes we removes, > during the migration check-in check-out task will become difficult, How can i > shorten this procedure > > 6)usually LTO5 media box shows that 3TB (2:1) compression, whether TSM uses > this compression ratio ? > > It sounds like you have a fairly lengthy list of items to address there, not least being on such an old version of TSM but also how you are managing your storage. In my opinion, you need someone to come and visit you and assess your environment then come up with a plan of action that will get you to where you need to be. A local business partner that knows what they are doing will be able to do that and give you a good idea (and price) for the hardware you actually need rather than some sales pitch. You might be able to upgrade the existing 3584, adding new drives and partitioning, depending on the support status. I suspect you will need at least a new server for TSM, and might want to select what you're doing about platform choice etc while thinking about how to migrate across.
Re: TSM 6.2.1 ANR2032E RESTORE DB: Command failed - internal ser
On Sun, 2011-11-13 at 09:02 -0800, darthlord wrote: > Hi, > > I4m new to TSM 6.2, I4ll appreciate any further assistance to solve some > issues to RESTORE TSM DB into another server. As we are working into a DRP > with TSM 6.2. We had been getting some TSM Restore DB error messages, and > noticed that while restore finished no logs were restored at activelog path. > > Maybe we are missing some step at the restore procedure. The output for what > we are running and the errors are as follow: > What user account are you running these commands as? In my experience running these commands as the TSM instance user is very smooth, but running as, for example, root doesn't work so well.
Re: disk availability in VTL
On Sun, 2011-10-30 at 09:35 +0330, Mehdi Salehi wrote: > Thanks Remco, > VTL needs disk space to provide virtual cartridges and my concern is the > availability of this disk space. You are right! Backup data availability > could be addressed in higher levels like TSM copypools, but I am looking > for inherent disk availability features in IBM VTLs' architecture. For > instance, if an XIV box is connected to TS7680, what happens if the XIV > explodes? > > Thank you, > Mehdi The ProtecTIER allows for replication at the VTL level - i.e. you can have two independent disk systems behind two VTLs and replicate the virtual carts over IP to a remote datacenter. And of course you can have a copy pool in a vault somewhere nice and safe. Whether I would consider the replicated cartridge in a primary storage pool to be enough off site protection to not have a copy pool is a different matter. I'm making the assumption that you want to have two disk systems in different datacenters and replicate between them rather than have two disk systems in the same datacenter and one VTL controlling both?
Re: Follow-up: Question about "Hybrid" method upgrade to TSM V6.2.2 and server-to-server export
We hit the exact same issue in test - so we took a rather butcher-ish approach: - When starting up the 'old' server following the extract, we defined a new, temporary stgpool and directed all new data to that pool. All other volumes were marked 'read only'. - normal night's backup ran, to the temp pools. - The tapes were moved from the old server to the new one's library. That's because there was a new library, but it's not essential, just that the old server doesn't need to know about the tapes, nor should it have access to think they're scratch and start making use of tapes that have useful data on them (!). - started the 'new' server, and ensured that it had access to the tape data (quick test restore was enough for me) - immediately before running the export node command we DELETED THE OLD VOLUMES on the old server - I hated doing that, really I did. The old server only left had in it's database the data that was available to it, i.e. the stuff in the temporary disk stgpool. - With the 'old' server now only containing a tiny amount of new data, the export node * ran just fine. It's a lot of fiddling, especially with changing the destination of copygroups, but it meant it worked and the import is a 40+ hour job for that one. - "Wanda Prather" wrote: > From: "Wanda Prather" > To: ADSM-L@VM.MARIST.EDU > Sent: Wednesday, 14 September, 2011 7:34:02 AM > Subject: [ADSM-L] Follow-up: Question about "Hybrid" method upgrade to TSM > V6.2.2 and server-to-server export > > Posting a follow-up to this thread. > Been there, done that, didn't like it when I tried it. > > Customer had a TSM 5.5 server with ~100G data base. Moving to 6.2.2 > on new hardware. > > Testing showed that the EXTRACT for the upgrade took only 2 hours, but > the INSERTDB would take at least 10 hours. Business-critical backups > run from AS400 systems during the day, with normal Win and Linux > filesystem backups at night, plus some Oracle TDP's, Exchange, etc. > So as to not miss the AS400, Oracle, and Exchange backups, we decided > to do a "hybrid" upgrade. > > The short version of the steps: > > *Do as much ahead of time as possible (like upgrading the TIP, > for example, and running fibre to the new server) > > *Shut down V5.5 > > *Run the extract > > *Bring V5.5 back up in production > > *Let normal backups run overnight to V5.5 > > *On 6.2.2 run the INSERTDB overnight, taking as long as > needed > > *Return in the morning, bring up the 6.2.2 server > > *Define disk storage pools, attach some tape drives (some are > still attached to V5.5) > > *Verify 6.2.2 is ready for prime time by testing some backups > & restores > > *Disable sessions on both servers > > *Swap IP addresses, clean up DNS alias to point to 6.2.2 > > *Bring both servers back up > > *6.2.2 is now production, but the data is 24 hours behind > > *Do a SET SERVERNAME on 5.5 server to OLD > > *Define server-to-server connections > > *Run EXPORT node * from V5.5 to V6.2.2 with fromdate/fromtime > set to merge the data from the past 24 hours into V6.2.2 > > Well, that all worked well (we had done two test runs beforehand, > don't expect to get this right the first try!) up until the EXPORT > NODE, where I ran smack into IC74464. > > I didn't know that, of course, until trying it. What I expected to > see was V5.5 mounting the tapes that were written during the previous > 24 hours. What I saw instead was old tapes being mounted and just > sitting for minutes at a time. I finally cancelled the Export and > tried again with just the AS400 data, that ran tickety-boo. Tried the > Oracle TDP data, and that ran tickety-boo. Tried again with an > ordinary filesystem client, and again the process just wilted and I > eventually cancelled it. > > So research brought me to IC74464, which says: > Directory processing: The FROMDATE / TODATE parameter does not > apply to directories. All directories in a file space are > processed even if the directories were not backed up in the > specified date range. > > So, given that all our clients backed up overnight, the V5.5 server > would eventually have mounted every tape required to export every > directory from every client, in order to pick up the last 24 hours of > filesystem backups. > > I don't see any way it is possible or practical to complete this. > Most of the changed files would have been backed up anyway during the > overnight production backups the first night after implementing > V6.2.2, long before we picked them up with the export. The only thing > we are missing are versions of files that changed twice, once during > the INSERTDB run and again before the first night of V6.2.2 > production. This process might (and it's just a "might") work in a > site that has a DIRMCpool on disk or a VTL for the primary storage > pool, but even then I think it will take an unreasonably l
Re: TSM 6.2.1 DB
- "Andrew Meadows" wrote: > > All, > > We recently started installing fresh tsm 6.2.1 instances in house. I > was > wondering if someone could help me with the following > questions/issues. > > Question 1) > > We have a 500 GB Database allocated. I have that split up into 4 > filesystems > with 127 GB each. Currently Only the first filesystem is being used. > I > thought they should have been used evenly. is there a parameter i need > to > check to enable this? > > > Location Total Space(MB) Used Space(MB) Free > Space(MB) > -- --- --- > --- > /tsmdb001 128,000 37,389 > 90,611 > /tsmdb002 128,000 520 > 127,480 > /tsmdb003 128,000 520 > 127,480 > /tsmdb004 128,000 520 > 127,480 > Yes, this should be evenly spread. If you run 'q dbspace' you will see what's going on. Extend dbspace will allow to you add more dirs if needed. > Question 2) > > With the way Dbbackups are now set up through the client API is is > now > possible to set up remote backups to another TSM Server? > Could i compress or dedupe the backup over to another TSM Server > remotely? > Or does it end up using server to server communication to do that? > Making a backup is a lot easier than making a recovery from that backup. I think it's technically possible to do it but it might not be supported and given the importance of the db backup I'd be keener to keep it simple (and reliable). Maybe if you wanted to go down that route you'd be better to use a server device class.
Re: Problem installing TSM server Instance 6.2
- "Leif Torstensen" wrote: > > I looks like I have a process hanging. I have check for the > administrator to be in the db2users and db2admns group and the > administrator have rights to the the database > > C:\Program Files\Tivoli\TSM\db2\BIN>db2 "select > grantee,securityadmauth from sys > cat.dbauth" > > GRANTEE > SECURITYADMAUTH > > --- > ADMINISTRATOR > Y In the past I've had similar issues on Windows systems, but I find regardless of the permissions of "Administrator" I have better success logging on as the instance's user account (using 'runas') - e.g. if my instance is created under the user tsminst1, I log on as tsminst1 and everything works that wouldn't previously.
Re: TSM 5.4 and 6.2 on the same box
Unfortunately not - you must uninstall the TSM v5 binaries before installing TSM v6. You could try a separate LPAR however. What's the migration method you are using? - "Mehdi Salehi" wrote: > > Hi, > Can TSM 5.4 and 6.2 co-exist on the same AIX box temporarily for > migration > purpose? Any conflict in service names or...? > > Thank you, > Mehdi
Re: TSM5.5/AIX61 Performance Monitoring
- "Shawn Drew" wrote: > > Looking for some tips on performance monitoring. I've been through > the > tuning guide, but I'm looking for > monitoring CPU/Memory, HBA usage, disk/tape performance, etc. > > I'm wondering what are the favorite tools on this list. From what I > can > gather nmon doesn't collect tape drive data, which is one of my major > interests. > > I need to collect historical data for long term trends. Does anyone > know > if you can keep topas output in single, periodic snapshots like nmon? > > > Regards, > Shawn > > Shawn Drew > FWIW, there are some good plugins for Nagios that do that sort of thing and can provide performance data to various graphing addons - or just use Hyperic or something similar.
Re: Change rate performance question
- "cory heikel" wrote: > I have many clients with an average daily change rate of over 50%. > Most of these clients take several hours to back up and show a high > percentage of wait time in the summary table. My question is this: > Would it make sense for these clients to be backed up full each day > instead of incremental? > Without more detail, I'd suggest trying an online image backup of some selected clients and see what difference it makes. You might find, however, that there are pros and cons for image vs incremental - in terms of storage used, performance of other operations during backup, and ability to restore individual files. You could also consider using -incrbydate - just so long as you regularly do a 'normal' incremental since -incrbydate misses deleted files and isn't the most secure option. Where is the delay though - have you looked at the instrumentation to determine if it really is filesystem scanning that is the slow bit?
Re: Disabling automatic mount processes
- "Skylar Thompson" wrote: > Does disabling the library prevent library audits as well? Basically > I'm > trying to keep stuff from getting mounted and interfering with the > audit. Yes it would. If you're doing an 'audit library' use the checklabel=barcode option to make it a mile faster - otherwise it will mount each tape and read the header. If you're doing an audit from barcode it should be more of a 20 minute job than a 6 hour job (or more!). You might consider a quick script to disable all schedules, admin and client, as well as changing migration thresholds etc. Also it might be wise to disable client session for the duration if you want to be really sure. > > On 09/25/2010 02:34 PM, Richard Sims wrote: > > On Sep 25, 2010, at 5:06 PM, Skylar Thompson wrote: > > > >> Does anyone know of a way to temporarily keep TSM from starting > >> automated processes that involve library mounts? I'd like to be > able to > >> keep migrations/reclamations/database backups/whatever from > occurring > >> when trying to diagnose tape library problems. > > > > Depending upon the library, taking it offline will certainly prevent > TSM access. Within TSM you can adjust thresholds and change Type > Admin schedules to Active=No for the duration, but there will be > urgent needs such as DBBackuptrigger which require some kind of > attention. > > > >Richard Sims
New Zealand based TSM user group
Some members of the list might find this of interest: Please join the next New Zealand IBM Storage User Group meeting which will be held on Sep 14th in Auckland, and 15th in Wellington at 3:30pm. This meeting will address: TSM, TPC, XIV and SVC. The agenda for this meeting is as follows: TSM 6.2 - update on new features and real world use TSM tips and tricks Totalstorage Productivity Center - new features XIV - what is it, how does it work, answers to common criticisms SVC - update on new features General tips and tricks, stories to share Register today! : go to http://www.tivoli-ug.org/groups?groupid=257 Xav Paice Consultant Open Systems Specialists Ltd, Wellington mob : +64 21 634 201 Skype: xpaice web : http://www.oss.co.nz - CAUTION: The information contained in this message and any attachment is confidential between Open Systems Specialists Ltd and the intended recipient. Any other person receiving this message in error is asked to respect that confidentiality and not disclose, copy or make use of its contents. If this message has been received in error please notify the sender by return and delete the message from your database. Thank you.
Re: Question about testing version 6 on Linux server
- "Robert Ouzen" wrote: > Hi to all > > > > I need some advice about making a test to install TSM 6 on a Linux > environment, here some questions: > > 1. Did someone already did it and can share some advice (Which > O.S ?) Any of the supported Linux distributions should be fine - generally I'd recommend Red Hat Enterprise Linux 5.5 but SLES also works fine (I've worked with TSM 6.1 on SLES10). Hardware drivers is another factor - check the hardware is on the compatible list with the distro. > 2. My TSM server now is on Aix 5 with Tsm version 5.5.2.0 and > what will be the best way to test it on version 6 Run up a new server with Linux and TSM 6.2.1, then run an export server with no data, then an export node for the nodes you wish to test with, then... configure the clients to talk to the new server and test it. However, the big question for a test environment is where are the storage pools? You'll need tape resource to test it all properly, and won't be wanting to use library sharing with the 5.5 server as the library manager. To set everything up, just follow the TSM 6.2 Installation Guide - the 6.2 version is cleaner than the 6.1 version. Try to avoid configuring the first TSM instance manually, aside from it being tedious there's less checking to see if things are AOK - the wizards actually produce a better result believe it or not. > > a. To do an export / import server That's the one. > > b. I think I read that from version 6 you can do a migration of a > previous database version (did can be done from different O.S Aix / > Linux ?) Can't do that between different OS - and if you stick with AIX you'd be needing some long outage times to do the migration.
Re: Configuring tape library on centOS
- "Mario Behring" wrote: > > Hi list, > > I have installed a TSM 5.5 server on a CentOS 5.4 server and I am > having a hard > time configuring the Tape Library using the TSM Device Driver > (tsmscsi)...despite having done this a thousand times... > > This is what the /proc/scsi/scsi brings: > > Vendor: IBM Model: ULT3582-TL Rev: 310B > > Type: Medium Changer ANSI SCSI revision: 02 > Since you're using an IBM library with LTO-2 drives - go to ftp://ftp.software.ibm.com/storage/devdrvr/Linux/ and use the IBM tape drivers rather than the TSM device driver. See http://www-01.ibm.com/support/docview.wss?rs=663&uid=swg21082581 as well. I didn't realise CentOS was on the supported list :)
Re: Linux Server/OS/lin_tape question/issue
- "Zoltan Forray/AC/VCU" wrote: > Finally, after futzing with this box for a week, we decided to just > nuke > it and install 5.3 clean/virgin. Now it sees all 15 drives. > OK - a great way to fix it but with a big hammer. The end result gives you a nice standard platform and one that's supported for a lot longer than RHEL 4. > However, I can't just nuke 3-production servers, especially > considering > that one is my primary Notes backup server and is always running at > 100% > trying to keep up with incremental/selective/transaction log backups, > thus > the need to determine exactly where the problem is. It's probably about time to raise a PMR with IBM, and a call with Red Hat, while you still can.
Re: Grandfather-Father-Son strategy -- howto?
I echo the other replies to this one - and make the following points: - part of the life of a TSM administrator is to educate users, with the aid of simple and realistic examples rather than TSM jargon. People sometimes find it a hard concept to get, but once they do, they generally come around with one of those great 'eureka' moments. - Yes, using different node definitions would achieve that result, at a cost of efficiency. You end up keeping duplicate data. Do make sure that they understand (and are willing to meet the cost) of what they are asking for. - You could also consider making backupsets of node data and putting them somewhere, or even exports... but again, it's not efficient. - Also you have not mentioned their reasons for wanting this strategy - if it's for SOX/JSOX/etc compliance, I'd be wary of promising TSM as a compliance solution because that's not what it's designed to do. There are add on products for that purpose that do a much better job. I would make the assumption that you are in the same position I often find myself (and I'm sure others on the list have the same as well) - someone has experience with a different product, and wants to ensure that they can recover old data from ages ago, just in case they need it. Many people keep a year or more of monthly archives - you can do that too if you want, but it won't be efficient, and just like a G/F/S tape set, there is a good chance that the mission critical file that was deleted 6 months ago isn't on the monthly archive anyway. I try to understand what sort of data they might need to have history of - if it's documents that might have been deleted, increase the retonly. If it's month-end financial data, use archives. If it's operating system binaries, why do they need to keep it so long - probably a week is fine. Sorry for the long reply... hope that it helps. - "Bjørn Nachtwey" wrote: > Dear all, > > some of our users want to have a grandfather-father-son strategy > using > the tsm backup -- as far as i figured out, such a strategy is not > part > of the tsm approach. > > futher more i found an old discussion (Dec 2004) in the archive of > this > list, where Charles Hart supposed to do each of the backups using a > different nodename that directs to different domains/management > classes > with adapted attributes. > > Is this still the way of realization or can I do something different? > Especially if I want this straregy just for parts of the data? > > thanks, > Bjørn > > > -- > > Dipl.-Ing. Bjørn Nachtwey > Technische Universität Carolo-Wilhelmina zu Braunschweig > Gauss-IT-Zentrum (GITZ) -- Leiter der Abteilung Server > Hans-Sommerstraße 65, 38106 Braunschweig > Telephon: +49 (0)531 / 391 - 5535 > TeleFax: +49 (0)531 / 391 - 5549 > http://www.tu-braunschweig.de/it > mailto: b.nacht...@tu-braunschweig.de > > PGP-Schluessel: > http://www-public.tu-bs.de:8080/~nachtwey/bjoern_nachtwey.asc > PGP-Fingerprint: > B472 526A A903 4AEB 9269 EC0B 9CDE 7465 CE87 >
Re: Q about TSM 6.1 DB and hardware replication
- "mccambly" wrote: > > Hello Wanda (& everyone), > > I thought I would revive this thread to see if anyone had any recent > (hopefully successful) experiences with using hardware replication an > a TSM V6.1+ server to achieve a standby DR TSM server, without needing > to completely shut down the production TSM server. > > Has anyone found that it can (or cannot) be done? > Details of your successful configuration would be very much > appreciated. > > Thanks. > S. > > > Wanda Prather wrote: > > In prior TSM server versions, replicating the TSM DB and log using > hardware > > replication works fine as long as the DB and log are in a > consistency group. > > > > Any issues with hardware replication of the TSM 6.1 DB and log? > With > > appropriate changes to dsmserv.opt, will a DR TSM server be able to > open the > > replicated DB and use it? (Just a little nervous about what all > those DB2 > > services will think..) > > > > Any insight appreciated! > > > > W > I've tried a couple of times using TSM 6.1.2 on Windows, and found it impossible to get the database to start. I tried also with TSM 6.1.3 on Linux and had more success, but couldn't tell if that was because I'd done something right or if it was just that my 'nodeb' was simply a clone of my 'nodea' - the Windows trial was on two completely different machines. I'd love to hear if someone's had this going in a real live production scenario yet - so far I've been making backups to a file devclass and replicating that using hardware, then restoring at the DR location. It's reliable at the cost of recovery time.
Re: Win Server 2008 question
- "Andrew Raibeck" wrote: > > Any one know anything about this ... > > > ... and how to avoid its effects? > > a) Hardware deduplication in your TSM server storage. > > b) TSM deduplication (6.1 and up for server-side, 6.2 for > client-side) > > c) Progressive incremental backup of the system state's System Writer > component (TSM 6.2 client, compatible with TSM version 5.5 and 6.1 > servers) > > (a), (b) and (c) help reduce TSM server storage requirements. > > (c) also helps reduce impact to the TSM server database. > > Best regards, > > Andy Just a side note to Andy's comment - if I understand it correctly, the dedup in TSM works with file pools only. Regrettably that means there's no saving in tape slots, TSM database size, copy pool tapes, etc., but it does allow a heap more data to be stored within a file pool, and with the features in 6.2 this can be realized immediately rather than only after processing. Hardware dedup - e.g. ProtecTIER - is a more complete way to save on TSM storage, but comes at a cost which may or may not be justified by the savings in space alone. What's the impact on restoring the system state when using (c) above? I'm guessing eventually it means more tape mounts unless there's some pretty aggressive collocation going on.
Re: TSM 6.2 formatting issue
- "Steve Harris" wrote: > > Hi all > > > This behaviour is going to break some of my shell scripts. Has > anyone > found a trick to get the old behaviour back? > > > Regards > > Steve > > TSM Admin > Paraparaumu, New Zealand Does it do that from within the shell script as well as on the interactive command line? E.g. if you use: dsmadmc -DISPLaymode=TABle -id=user -pa=pass "select volume_name from volumes where devclass_name='DISK'" ? The reason I ask is that it looks very much like you're getting the output of -displ=list rather than =table, so if you specify table it should be back to normal. Having said that, I don't have a 6.2 instance handy to play with right now. Rgrds, Xav TSM Admin Raumati, New Zealand
Re: time needed to upgrade to tsm 6.x?
- "TSM" wrote: > hello, > > a question to all of you, who had upgraded tsm 5.5 to tsm 6.x so far. > in relation to your tsm 5.5 database size i am interested in your > experience. > > anyone seeing chance to upgrade to tsm 6 in 4 hours with a 70 GB > database? > > > with best regards > stefan savoric Our testing, using Windows and a recent CPU etc, showed an average of about 5GB/hour using disk or tape devices as the media. The other way to do it is to go to a new server and use full backups to the new server, combined with exports for historical data if you can't just let it expire. 70GB in 4 hours is not going to happen (unless only 20GB of that 70 is occupied).
Re: TSM 6.1 automatic database backups
- "Wanda Prather" wrote: > > John, > Make sure you have in the dsmserv.opt file: > ALLOWREORGTABLE NO > > There is a bug in 6.1 that lets the automatic DB table reorgs go nuts > with the log. Yup - nasty effects. http://www-01.ibm.com/support/docview.wss?uid=swg1IC62978 According to IBM this is fixed in 6.1.3 but I've not had the guts to change back and see if it's OK now - can anyone confirm that this is indeed resolved? > > > 1) On one instance, each day a full TSM DB backup gets done, but > within > about 16-18 hours, the archive filesystem is filling up. The archive > filesystem is 50GB, which is of course much bigger than it was under > 5.5. We have only migrated a fraction of the TSM clients over to > this instance, so I shudder to think how much archive space is going > to > be require when all the TSM clients are in place. Can anybody give > me > any tips on reducing the amount of log data that gets created so it > doesn't fill up so fast? Which would point to IC62978 not being fixed yet. If you try the ALLOWREORGTABLE NO and it fixes the issue, I'd advise raising a PMR (see above)
TSM 6 server on a cluster
Does anyone run, or know someone that does, a TSM version 6 server on a cluster of some sort? There's a ton of documentation on using TSM clients with clustered servers, but as far as clustering the TSM server application itself I'm drawing a blank. It wasn't so hard with version 5 but version 6 doesn't seem to want to play ball - any advice sought. The specific need right now is for TSM 6.1 on Windows to be available on an active/passive cluster with auto failover and preferably support for mirroring of the SAN hosting the DB and log, but if there's people doing this with AIX/HACMP or Linux I'd be keen to hear their experiences. Many thanks Xav
Re: TSM server and anti-virus software
- "Wanda Prather" wrote: > > Found this recommendation from TSM support: > > > > http://www-01.ibm.com/support/docview.wss?uid=swg21367186&myns=swgtiv&my > np=OCSSSQWC&mynp=OCSSGSG7&mync=R > > > > Now can somebody give me a helping hand on what that means I need to > do > for a Windows 6.1.3.1 server with Norton Anti-virus - > > > > Should I create exclusions for the disk pool files under Configure > > Filesystem AutoProtect > Options > Exclude Selected Files and > Folders? > Am I warm? Am I missing anything? > > Absolutely on the button. As the article says, ensure the various locations or individual files are all excluded from real time scanning, and watch as the performance of your server improves. In general, exclude the directories for logs and database (since you won't want to specify each one individually unless you have a lot of time on your hands) and if you really want to you can specify files for storage pool volumes, or a common extension if you use one. Just don't specify C:\Windows\System32 as a directory exclusion ;)
Re: Multiple instances on the same server
- "Shawn Drew" wrote: > From: "Shawn Drew" > To: ADSM-L@VM.MARIST.EDU > Sent: Tuesday, 23 March, 2010 8:35:58 AM > Subject: Re: [ADSM-L] Multiple instances on the same server > > Now I'm doubting myself. > The manual shows you how to do it, so I guess that's good enough. > Disregard my previous comment. > > I could have sworn i read about this on the official IBM TSM rss > feed. > There was some random problem and under the solution field, there was > a > statement like "multiple TSM instances on TSM6.x is unsupported and > must > be put into separate LPARs" > > http://www-01.ibm.com/software/support/rss/tivoli/663.xml?rss=s663&ca=rsstivoli > > At around the release time for 6.1 they were saying this due to a problem with one of the beta sites, but it all seems to have gone away now. There would surely be more noise about it if it were unsupported :)
Re: assessing the health TSM installation
- "yoda woya" wrote: > From: "yoda woya" > To: ADSM-L@VM.MARIST.EDU > Sent: Sunday, 14 March, 2010 2:47:10 PM > Subject: [ADSM-L] assessing the health TSM installation > > if I were to be looking to assess the health of TSM, what would be > the top > things to look for off the top of my head (we use a template for this at the office): - database backups are frequent enough and allow for the desired recovery point of the organisation - copy pools and database backups are sent off site (i.e. not left in the library or in a cardboard box beside it) - performance bottlenecks (there's a client and server commands to check this) - spread of tapes - if a restore needs 100 tape mounts then it's not going to be acceptable - daily maintenance routines, is everything getting done or is something missing (maybe expiry never gets done or something like that) - where is the time of the administrator spent, is there a better way to achieve the same result? - what's the history of the installation - has it suffered downtime issues from something, etc? - what's the organisational goals for TSM - do the copygroup settings match that, is there wasted space or is data getting missed? Often I come across installations that are great except for a few minor config settings that prevent perfect operation - pulling tapes out of the library from the primary stgpool without setting an overflow location, or not setting reusedelay on copy pools.
Re: Virtual TSM server - using disk only
- "Gary Bowers" wrote: > My experience with direct connected iSCSI storage on a TSM server is > that it gets abysmal performance unless you turn off Direct IO in > TSM. See other posts for that. It is technically possible, but with > the iSCSI limitation you might not want to use RMD "Raw Device > Mapping" in VMware. I am not sure on this, but it makes sense given > what I have seen and read about here. By the way, NFS and CIFS were > equally bad performers for disk pools with DirectIO turned on. They > seem to really need the filesystem caching. I'm "guessing" that > putting the disks in a VMFS would help buffer the writes, and give > you > decent performance. > > It is something that would need to be tested first. I'm confident > that it would be much faster than WAN connection back to the States. > Yuck. > > Good luck, > > Gary Bowers > Itrus Technologies > > On Mar 11, 2010, at 1:18 PM, Ochs, Duane wrote: > > > Good day everyone, > > Has anyone explored using TSM server (windows) on a VM using Iscsi > > storage ? No library requirement at this time. > > I have multiple European sites within close proximity of each other > > and they have outgrown the WAN coming back to the states. > > Only storage available there is Iscsi and they have a substantial > > VMware implementation which would allow us to ride on a VM if > > feasible/functional. > > > > Thoughts ? > > > > Thanks, > > Duane You probably would want the iSCSI storage linked back via VMWare and .vmdk image files so that Windows has no idea about it being iSCSI or otherwise - just a disk. Gives you more flexibility in the long run, but you would want to test both Direct IO and not to see which performs best in your configuration. I would have thought leaving DIO on would be the best if there's another OS doing filesystem cache somewhere else, but could be wrong there ;)
Re: AIX TSM Client 6.1.3.2 install failure
Both are on the expansion media, which you should be able to download from your Passport Advantage account. > > > Nope, it's not in the download package (gsksa is, but gskta is not). >
Re: 5.5 -> 6.2
- "Remco Post" wrote: > > huuh, I know some of us have huge TSM database, but export/import > for all node data for such a server is highly unlikely to complete in > our lifetime. > > I'd say, either go for the downtime, or just build a new server (maybe > export server) and then just point your clients to the new server. You > need bigger faster hardware anyway for TSM 6. > Most people with larger databases cannot cope with the downtime, measured in days, that it takes to import the database. There are ways to import on a new server whilst leaving the old server running (restore db, new storage pool to leave the old one untouched, export the new data when everything is done) which might be more palatable, but I've not tried them. Mostly I'm finding now that people don't just want to migrate to a new server if they have a massive database - they want to combine that action with splitting into more instances to reduce the db size. Export/import is a good way to achieve that. I'd be keen to try to do a full backup of nodes to the new server, so long as the client can complete that within a reasonable time. If it takes 3 days to make a full backup then the node has no valid backup for 3 days. Typically the client is the slow point rather than the server. I'd be concerned if the amount of time taken to migrate the node data to a new server using 'export node' is too long - that's a background process which can be done in advance of moving the node, but note that it should take only a bit longer than the restore of that node. If it takes a week to restore a node that would be well outside of SLA would it not? The other issue with just doing full backups to the new server is the historical data that still lives on the old server. If it takes a year (or more) for that old data to expire, then surely that means keeping old instances of TSM hanging around for history? Many clients also don't want that as they must return hardware for lease expiry, trade-in, etc. let alone having to maintain yet another box. Not a problem if your RETONLY is 10 days and archives are only kept for a month, but if your archives are there for 7 years you have no choice but to move stuff around somehow. The result is that you must pick the migration method on a per node basis - there are many factors to decide which method is chosen, none of which are ideal.
Re: 5.5 -> 6.2
- "John D. Schneider" wrote: > > > This was very good news for us, too. We have one library master that > serves 9 other TSM servers, plus 5 Lan-free agents. The thought of > having to upgrade ALL of them on the same day was daunting indeed. > But > thankfully, we can do them in groups. Because we have as many as 4 > instances on one server, we will be forced by the upgrade > requirements > to upgrade all of those on the same day. At least, I think that is > true. When I upgraded a test server from 5.4 to 6.1 a couple weeks > ago, > I was told to uninstall 5.4 before installing 6.1, and that they > could > not exist on the same server. Am I understanding this correctly? > The problem with upgrading from v5 to v6 is that you do indeed need to uninstall one before installing the other - not like from 5.4 to 5.5 at all. The upgrade process involves a database dump and import a bit like an unload/reload and unfortunately about as slow - the speed stated by IBM for the import is about 5GB/hour and from my experience that's about right from disk and from LTO-3 tape. The best way to upgrade in my opinion, unless your database is tiny, is to put the new version on a new bit of hardware, and use the 'export server' command to move config from the old to the new, then combine full backups to the new server and 'export node filed=all' to get the data across, finally deleting the nodes from the old server when you're comfortable with it. Regardless, it's a bunch of tape mounts and time, but at least it's a well controlled process and doesn't take down the TSM servers meantime. Let the list know how you got on!
Re: TSM upgrade v5 --> v6 database storage question
Just one point to add to that - with the DS4x00 series storage arrays you only have one preferred controller active at a time per LUN - so if you split the db into two LUNs you have the option to have each LUN running across a separate controller, with I/O performance gains as a result. If you'd even notice the difference is another matter ;) - "Richard Rhodes" wrote: > From: "Richard Rhodes" > To: ADSM-L@VM.MARIST.EDU > Sent: Friday, 19 February, 2010 9:28:45 AM (GMT+1200) Auto-Detected > Subject: Re: [ADSM-L] TSM upgrade v5 --> v6 database storage question > > Easy answer . . . "it depends" . . . > > Here are some questions/comments in no particular order: > > Are you on an array today? > Is the array busy and loaded down? > Does it have multiple raidsets? > What kind of drives does it have (sata, fc10k, fc15k)? > I'm not a windows admin - would the drive letters be separate luns? > If separate luns, would you put them on separate raidsets? > If multiple luns but all on the same raidset, then you are basically > gaining a cmd queue for each lun. > If separate luns and you can put them on separate raidsets, then you > are > getting many more HDD's working for you. > Are you disk I/O bound now? If not, then you probably won't see much > difference on matter what you do. > The big advantage of the array is I/O spread across multiple/many > spindles > and write-back cache. > If you were using a unix system, I'd say to allocate one lun per > raidset, > bring them into a volume group, and create filesystems striped across > the > luns. That's how we do everything. > > rick > > > > > > > Nicholas > Rodolfich >To > THEWEB.COM> ADSM-L@VM.MARIST.EDU > Sent by: "ADSM: > cc > Dist Stor > Manager" > Subject > v6 database > .EDU> storage question > > > 02/18/2010 02:39 > PM > > > Please respond to > "ADSM: Dist Stor > Manager" > .EDU> > > > > > > > Hello All, > > Thanks for your help! > > Upgrading a client on Windows 2003 TSM v5.5.3 to Windows 2008 TSM > 6.1.3. I > am planning the storage and was wondering if it is worth splitting > the > database between multiple file systems. The storage they have for the > database is FCAL on an IBM DS4800. The client's current database is > 65GB > and will probably reduce to 55GB after the upgrade when we purge some > old > data. I was going to do the following > > e:\ database directory > f:\ active log directory > g:\ archive log directory. > > I could do this > > e:\ database directory > f:\ database directory > g:\ database directory > h:\ active log directory > i:\ archive log directory. > > The storage will be all be RAIDed on the DS4800 so I am wondering just > how > much if any performance gains I will see if I split the database up > into > more file systems. I would also like to solicit any opinions on the > storage > configuration (i.e. - RAID?, placement of logs, etc) > > Thanks, > > Nicholas > > - > 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: Virtual TSM
- "Lindsay Morris" wrote: > From: "Lindsay Morris" > To: ADSM-L@VM.MARIST.EDU > Sent: Thursday, 4 February, 2010 2:38:47 AM (GMT+1200) Auto-Detected > Subject: Re: [ADSM-L] Virtual TSM > > "Typical of vendors not to support their own product.." !! > > A little harsh, I think. > > TSM works in a very complex environment, and people who use (that's > us) it > try all kinds of tricks. Some corner cases doubtless get exposed, > where > support rightly refuses to help. > We ought to point out that it's only the most recent versions of ESX that can actually present a Fiberchannel attached tape to a guest in any case. I would suspect that by the time the new version has made it's way through the labs at IBM, support is inevitable - but I've not seen any announcements nor expect them soon. Note that TSM is supported under ESX, just not tape and LAN-Free which were technical limitations only recently resolved. It would be impossible for anyone to support an application using Fiberchannel attached tape on a guest where the hypervisor is incapable of delivering that. TSM is also one of those intensive I/O workloads which is the hardest to virtualise without affecting the other workloads on the host. ESX with the other companion products has a swag of benefits other than consolidation, but performance is a consideration for TSM without the additional complication of VM's.
Re: Virtual TSM
Quoted from the IBM link, the table refers to virtualisation where "the resources are then purely virtual (not dedicated) and/or are not discrete". My confusion, and I'd love someone to clear this up, is where we have RHEL running KVM. Red Hat clearly stated in their customer seminar on RHEV-M that if an app is supported on RHEL 5.4, it's supported under KVM on RHEL 5.4. If I add a PCI card (e.g. multi port HBA with tape attached) to a virtual machine, that is discrete and dedicated, that could be supported but it's a pretty grey area. Anyone care to confirm or deny? As Wanda put very accurately (off list), "when they say something is supported, it means if you call and report a problem, they will work on the problem" - that's the application vendor's support rather than the OS vendor's view of what's certified. Any software vendor is going to want to limit the support to things they can test in the lab - Tivoli might test TSM on RHEL, but maybe not RHEL under RHEV/KVM. That link also mentions non i386 virtualisation - such as LPARs and DSD. My apologies to the OP if this hijacks the conversation - I think it's on topic as you didn't mention which hypervisor you will select. - "Wanda Prather" wrote: > From: "Wanda Prather" > To: ADSM-L@VM.MARIST.EDU > Sent: Wednesday, 3 February, 2010 6:13:05 AM (GMT+1200) Auto-Detected > Subject: Re: [ADSM-L] Virtual TSM > > Yes, you can restore a TSM data base to a new TSM server. > > However, think twice before virtualizing - Tivoli doesn't support the > TSM > server on a VM if you have tape drivers (i.e., physical tape or VTL). > See > below. > > http://www-01.ibm.com/support/docview.wss?rs=663&context=SSGSG7&q1=server+support+vmware&uid=swg21239546&loc=en_US&cs=utf-8&lang=en > > > On Tue, Feb 2, 2010 at 12:06 PM, Micka > wrote: > > > Hi, > > > > I'm looking at virtualising our TSM server.
Re: alternatives to TSM due to license costs
- "Len Boyle" wrote: > Not as full featured as the above products, has anyone been looking at > the open sourced products? > We use Bacula (http://www.bacula.org/) for the smaller customers (and internally) since it does all we need it to do - but note there's some major limitations in capability. It has proved to be reliable and simple to maintain, but for larger customers the volume of data transfer and storage makes it more cost effective to use TSM. So far we've not found any open product that does an incremental forever backup, but are continually looking.
Re: I/O thruput
- "Fred Johanson" wrote: > Del and/or Andy can probably answer this, hopefully in a way that a > non-hardware/OS person, like me, can understand. > > Our hardware guy upgraded a driver on my 6 AIX boxen. As a result, my > thruput went to hell, with backups running, not at Kb/s, but bits/s. > But not on clients with the MSSQL or ORACLE TDP, or SQL-Backtrack. > Those clients went thru at the expected rate. My supposition is that > clients using the API use a different I/O path than regular clients. > > Enquiring minds want to know. this enquiring mind would like to know a bit more info: - what was updated and where - surely there's some details in the change request? - what is the TSM server, version, OS, hardware, etc? Is that where the update went? - what/where is the client? - I gather it's file backups from the AIX boxes that's slow? But the Windows ones are OK? What's the difference other than platform - do they go to different storage pools?
Re: logpinned
- "Geoffrey L. Gill" wrote: > For the past 2 days something has been screwing up backups by filling > the log and this morning I remembered the show logpinned command and > found the server that is causing it. I've cancelled the session but > as > far as I know am at the mercy of TSM to kill it at some point. I > contacted the administrator and they shut down the services but the > sessions still seem to hang out there. > > Take a look also at the 'show logpinned cancel' command if that's not what you used to cancel the session - sometimes it's helpful. If that doesn't work then halting the server will do the trick, but that's not the most tidy or convenient way... assuming you're about to run out of log and crash anyway...
Re: Performance and migration: AIX vs Linux
- "John C. Dury" wrote: > > 1.How hard is it to move from an AIX TSM server box to a Linux > TSM server? I'm hoping it's as easy as building the new box (tape > drive,stg pool etc) and then restoring the DB and tweaking the new > config. I know there is more to it than that but without researching > it yet, that seems like a logical high level overview. > You can't do it that way - DB's cant' be restored to a different platform. Your best bet is to build the new box and do an 'export server' and/or 'export node' to move the definitions, policy, data, etc across. It's the best approach anyway as you get to test each client (which will need the client config changing as well). > 2.Will there be much of a performance difference between and > AIX based TSM server and a Linux based TSM server? Ah that's a big question. It depends on the hardware more than the OS - Linux on the same hardware as AIX would run about the same. Changing from the Power architecture to Intel is a different story as the I/O paths are very different - the Power architecture is much more efficient at moving buffers around than Intel. The new Nehalem chips are reported to be pretty good though. I have a ppt from IBM that explains a little, but it's not detailed enough on the architectural differences. I'm sure your System P sales guy would love to get his teeth into the differences though. > > 3. Going from mixed speeds slots of PCi-X to PCI Express 8x and > 4x slots should be a significant improvement correct? Depends more on what you're connecting to - look for the slowest thing in the loop. It might be that the storage is using an array shared with something busy or a bottleneck between two Fiberchannel switches. > > I know there are a lot of factors here but we are concerned we aren't > getting the best performance for our existing hardware. 30MBs (not > Mbps) for a LTO4 drives seems pretty slow and with 4 4x PCI-E and 4 8x > PCI-E slots, I can balance out the I/O across cards and slots much > better than I can now. > > Comments and criticisms? Linux vs AIX? > Thanks for any insight! When looking at TSM performance you are best to look at the whole system - from client filesystem right through network and database to tape. I'd suggest you start by reading up on the TSM instrumentation http://www-01.ibm.com/support/docview.wss?rs=663&context=SSGSG7&dc=DA400&uid=swg27012867&loc=en_US&cs=UTF-8&lang=en&rss=ct663tivoli for a better picture. You might be surprised at what's causing the low speed.
TSM v5 to v6 database insert
Hi, I've been working on upgrading a client's system from V5.5.2 to v6.1.2, on a new server (Win2k3 x64, SP2), and have got to the point of running the insertdb to get the database from the old machine's extract to the new machine. The insert ran for 7.5 hours and did 29GB of data, dismounted the tape, and is now just sitting (and has been for 14 hours). There's very little CPU activity but DB2 is using heaps of RAM (9GB in a 12GB box) and there's disk activity on the database directories. Anyone know how long I should wait? This is already too long for downtime for the go live, I'm wondering if I need to consider alternative methods to migrate. Xav Paice
Re: emptying disk pool
- "Tuncel Mutlu" wrote: > Hi gurus, > > I have a disk pool migrated once a day to a tape pool, but some data > stays (capacity problems). Until I have solved that, every day I have > to empty the disk pool deleting the data. Here are the questions: > > > 1. Is there any way to empty the disk pool without deleting the > volumes ? The only way I have found is to delete the volumes > disgarding the data (after that re-creating them). > 2. My TSM server is Windows 2003 based (TSM 5.5.3.0). When I delete > a disk volume, the file in Windows stays there, I cannot create it > again after that, so I have to manually delete the files from Windows > and that create the volumes again. Is this the way it should be ? That > prevents me from automating the operation with a script. > > Best Regards, > > Tuncel Mutlu > > As mentioned elsewhere, you might as well not be running the backup in the first place if you're deleting the primary storage pool volumes. After all, the backup doesn't matter, the integrity of the restore is what's important. Don't waste time making a backup and then deleting it - just don't bother with the backup, the result is the same. You don't mention what the capacity problem is, but from your post I suspect it's the speed of migration that doesn't allow you to finish in time before you need the tape drives for something else. In which case there's obviously some tweaking to do around start/finish times and other operations. For the disk pool, have you considered looking at the clients and what data you are backing up? - Large image type backups - e.g. Exhange databases or SAP or similar - could potentially go straight to tape bypassing the disk altogether. - Some servers might be backing up more than is needed, maybe consider splitting them up into a few jobs and run data only backups at some times and data/os backups other times - Consider a less frequent schedule for lower priority servers - tell the people with the cheque book that the server has run out of capacity and you have no means to provide a full backup, therefore the entire business is at risk of data loss. Give an example of what would happen, with the backup data missing due to capacity issues, should a server need a restore. The cost of downtime is usually much higher than the cost of a decent backup. If you're out of tapes, then you really need to sort that out, tape's not expensive. If your library has run out of slots, look into the 'OVFLOcation--=--location' settings of the tape storage pool and the 'move media' command (http://publib.boulder.ibm.com/infocenter/tivihelp/v1r1/topic/com.ibm.itsmcw.doc/b_adminref_windows230.htm#dqx2r_cmd_media_move). Contrary to popular opinion, if you have the time to monitor tape requests and feed tapes in, your library does not need to hold all the tapes in the primary pool.
New Zealand TSM User Group
FYI - in case anyone's interested - there's a TSM User Group in New Zealand, upcoming meetings are in Auckland on 30th Sept and Wellington 7th Oct. For details go to http://www.tivoli-ug.org/groups?groupid=257 Best regards, Xav Paice
Re: how to show the backup time of a fileset?
- "Mehdi Salehi" wrote: > It is a standard incremental backup. > I noticed that when I backup a filesystem "Last Backup Start > Date/Time" gets > a value. but if backing up a directory inside a filesystem, this field > does > not change. > For example: > # dsmc inc /home -subdir=yes (sets the time in tsm server) > # dsmc inc /home/mehdi -subdir=yes (does not set the time in tsm > server) ah - the timestamp is for the last backup of that filespace, a subdir is not counted as the whole filespace. you could try: SELECT ll_name, backup_date FROM backups WHERE node_name='some_node' AND filespace_name='/home' AND hl_name='/home/mehdi/' AND state='ACTIVE_VERSION' If you didn't want a result for every file, you could add ll_name='my_file.foo'. If you use that be aware it might be a little resource intensive and could be best run from a script to output with csv... I guess it's time to ask what it is you're really wanting out of this - if it's confirmation that you got a good backup then you might be better off looking at the client logs, activity log and possibly the amount of data transferred?
Re: SV: the purpose of "file" device class
- "Michael Green" wrote: > On Wed, Sep 23, 2009 at 9:47 AM, Christian Svensson > wrote: > > Hi Eric, > > With Quantum DXi (VTL) can you do the same thing. The DXi has both a > VTL part and a NAS Disk part and both have De-Dup working. > > The NAS part can you connect as local disk via iSCSI. > > iSCSI is not NAS. It's SAN. > NAS is either NFS or CIFS. > Unless I'm missing something... > > Yup - iSCSI is block based and not file based, so it's more of a SAN IMHO, but there's another school of thought that says anything that can run over your normal TCP/IP network isn't a 'proper' SAN as it's not dedicated to storage, it's 'Network Attached'. Nice crossover, shall we say anything of FC/IP, iFCP, or even IPFC...? I might be wrong as I'm not too experienced with the DXi, but I thought that it could dole out storage as NAS (NFS or CIFS), or act as a VTL as an iSCSI/Fiberchannel visible 'tape' device rather than local disk?
Re: end of support tsm 5.5 on z/os ?
- "Norman Gee" wrote: > But there are no other options for us mainframe bigot as TSM 6.x > server > does not exist on z/OS. > Time to start running Linux in partitions - that's supported on 6.
