Re: Http list
PINNI, BALANAND (SBCSI) wrote: Can any one direct me to http /apache list where I can subscribe ??? Sure ... http://httpd.apache.org/lists.html cheers, wayne
Re: Online DB Reorg
John Naylor wrote, in part: OK I ran Remco's sql and it reports my database is 53% fragmented. Maybe this makes you feel better? My result is 99.80, but then my database isn't what it used to be :-)cheers, wayne
Re: Database fragmentation formula (was Re: Online DB Reorg)
Hi Zlatko, If I plug into your formula, I get ... 1492.648 0.81294 14396.6095.29128 (clearly under utilized). But (ADSM V3.1(ancient)) shows ... Available Assigned Maximum MaximumPage Total Used Pct Max. Space Capacity Extension ReductionSizeUsable Pages Util Pct (MB) (MB) (MB) (MB) (bytes) Pages Util - - - --- - - - - 16,380 15,136 1,24428 4,096 3,874,816 183,609 4.7 38.5 This concurs with your utilization calculation, but note I have no DB reduction possible. I'm just noting this strangeness (fragmentation!?) for you, since my ADSM is so old and is being retired. Cheers and thanks for all the great insight you give on ADSM-L, wayne -- Wayne T. Smith -- [EMAIL PROTECTED] -- University of Maine System -- UNET
Re: Visit us at TSM Symposium 2003!
Stapleton, Mark wrote, in part: I and many other contributors don't advertise our firms on the list; ... and I've always wondered why... If I was going to the Symposium, it would be good information to know that Servergraph will be there. It's directly related to the purpose of this list. Maybe some ADSM-related companies wouldn't want to plug their existence because I'm sure Mark is not alone. A public forum on *SM should be open enough to not censor such contributions, IMHO. Sorry, wayne
Re: ITSM Operational Reporting Technology Preview
E Mike Collins wrote: TSM operational reporting is a simple tool designed to help you keep TSM running smoothly on a day-to-day basis. It runs on Windows and supports TSM servers on all platforms.... Fwiw, (as might be expected) it does not run on (the very old VM) Version 3.1.2, as it uses a number of tables unavailable in 3.1.2 (summary, events, etc.). cheers, wayne
Re: TSM on Mainframe
Though I'm not advocating someone install TSM or TSM on a mainframe, I'll offer that we don't IPL our mainframe very often. Here's the output of a command I just entered ... q cplevel VM/ESA Version 2 Release 3.0, service level 9803 Generated at 07/09/98 12:19:20 EST IPL at 03/18/01 07:17:35 EST But then the mainframe isn't as big as some of our Linux/AIX/Solaris servers. ;-) cheers, wayne
Re: how to stop mail??
Marc Levitan wrote, in part: I sent the following to [EMAIL PROTECTED] SET ADSM-L NOMAIL And I received: Your subscription options have been successfully updated. ... The problem is that I STILL AM RECEIVING EMAIL FROM THE LIST!!! Either the mail you are receiving was sent out before your subscription change, or you have another subscription, (or you're mistaken somehow). IMO, subscription problems are best dealt with by the list owner, not the zillion list subscribers that are looking for *SM content. One may reach the list owner by writing to [EMAIL PROTECTED] cheers, wayne
VERITAS Software Announces Product Road Map for Bare Metal Restore Capability
Press Release: For Immediate Release VERITAS Software Announces Product Road Map for Bare Metal Restore Capability Future Bare Metal Restore enhancements focused on VERITAS NetBackup data protection enterprise environments MOUNTAIN VIEW, Calif.- January 6, 2003 - VERITAS Software Corporation (Nasdaq: VRTS), the leading storage software company, today announced plans to focus future product development for VERITAS Bare Metal Restore disaster recovery technology on the VERITAS NetBackup data protection environment. VERITAS Software also announced plans to discontinue future sales of a separate product, VERITAS Bare Metal Restore for IBM Tivoli Storage Manager, effective June 15, 2003. VERITAS Software will continue to provide technical support for Bare Metal Restore for IBM Tivoli Storage Manager (version 3.2.1) through June 15, 2005. ... (end of quote; the entire release may be found at .. http://www.veritas.com/news/press/PressReleaseDetail.jhtml?NewsId=9667 .. cheers, wts)
Re: Filespaces Remain from years ago
Jeff G Kloek wrote, in part: I've just begun to take over this environment from the admin who left. I have a large number of filespaces across a lot of my systems that have not been a part of these systems for years. I'm wondering what governs TSM keeping those filespaces out there. ... *SM never expires file spaces; they mark files to be expired when a backup of their file space is done. So if you just stop backing up a file space (or all file spaces of a node), *SM will expire the inactive files (according to your policies), but will keep the active files (files seen on last backup) forever. Solution: (1) delete filespace NODENAME * for each node for which the backups are no longer needed. These will start background processes to complete the deletions. Once all file spaces for a node are gone, you may (2) delete node NODENAME. NB: if there are many files to be deleted and you don't have a lot of log space, do the deletions a little at a time, and not when other long-running processes are in operation. Hope this helps, wayne
Re: Reclamation not reclaiming carts
You might try doing an AUDIT VOLUME on each. Michael Raine wrote: When running reclamation have the reclaim pct for the STG at 60%. Have several volumes meeting this requirement but TSM does not reclaim the data. It recognized the carts in the activity log but does not reclaim the space. Holiday cheers, wayne -- Wayne T. Smith -- [EMAIL PROTECTED] -- University of Maine System -- UNET
Re: When did DIRMC come about?
Bill Boyer wrote: Does anyone know at what ADSM or TSM level DIRMC was added? I don't, but DIRMC was available in Tivoli ADSM 3.1 -- Wayne T. Smith -- [EMAIL PROTECTED] -- University of Maine System -- UNET
Re: TSM Reporting :: Forward events to Tivoli TEC console
Mark Stapleton wrote, in part: Mr. Morris, it would be nice if you'd put something in the header for your response like Advertisement. ;o) Not understanding ;o), I'll comment that I very much appreciate Mr. Morris's replies. He carefully responds to questions and problems; hardly an advertisement. Apologies if ;o) is similar to :=0 or :-^) cheers, wayne
V4.2.3 ODBC supported on Win98?
The IP22569 ODBC driver readme states The TSM ODBC driver is supported on the following Microsoft operating systems: - Windows 98 - Windows Me - Windows NT 4.0 (SP 4 or higher) - Windows 2000 yet when I try to install it on my Win98SE system, the installer complains that it is not supported on Win95 and Win98. Installer error or READme error or something else? cheers, Wayne Smith -- [EMAIL PROTECTED]
Re: TSM: DB Best Practises ?
Rafael Mendez wrote, in part: Hi Riaan, I would like to share with you my experience here. I have seen how people administering TSM server forget how important is to have planned the AUDITDB. Just one week ago, one of our customers HAD TO execute an audit db after 3 years of not to do it. That causes the TSM server had to be stopped for more than 50 hours!!. (50 hours without backup or any possibility to restore). So, with this expample, my personal opinion is, TSM server administrator should plan one (at least) or two audit db a year. Of course, I am concius about to stop TSM server is not an easy issue but lots of problems could be avoided running the AUDIT DB. It would be interesting that someone outhere gives us a point of view on this issue. I'm of the opinion that if a full-blown auditdb can't be avoided, it's time to start planning for your next B/R vendor. So far, I live with some warts, and tech support has in a couple of instances found work-arounds to the full dbaudit. Just one point of view. cheers, wayne -- Wayne T. Smith -- [EMAIL PROTECTED] -- University of Maine System -- UNET
Re: DB Volume Reorg using Delete DBVOLUME
That would be a nice feature, but, at least on my Tivoli ADSM V3 server, doing a couple of volumes (about 5 gig out of 15 in use) had no effect on reported % utilization whatsoever.cheers, wayne Seay, Paul wrote, in part: One of our TSM Support Staff members went to the advanced class and was led to believe you could get some reorg benefits doing the following Define New DB Volumes whereever you want them. Perform DELETE DBVOLUME commands on each of the existing DBVOLUMEs one at a time which causes the data to be moved. Our DBVOLUMES are on ESS disk so they are not mirrored. Thus, the delete causes a move of all the current data to other volumes. Has anyone ever heard of doing this to get some reorganization benefits? If so, were the benefits, mild or significant? I would not be surprised if massive filespace deletes could be recaptured by doing this.
Re: IMAP Mail Server Issues - Management Class Question
We have a smaller but similar IMAP situation (about 3M files and 60G in use, with exactly double those amounts stored in *SM). I'll comment.. 1. If restore of files changed in past n days is required to shorten (initial) major restore times, why not just do this at restore time with standard DSMC restore parms? 2. One could have a separate process that could duplicate portions of the mailstore, with *SM backing up only those duplicates. For example, before backups, one might tar/zip/whatever each mailbox to a single file (per mailbox). You'd probably be backing up more data (static would be in with new data for each mailbox changed), but *SM DB would be substantially smaller. For example, before backups, one might copy new files to a separate folder and backup only the separate folder. (Yuk to both!). 3. If backups slow because of the large number of DB entries, separate the mailstore and use *SM's virtualmountpoint facility. Cyrus, if that's your IMAP program let's you do this quite easily. 4. Look at your *SM retention policy to make sure it matches your need. You might be surprised to learn how much of your *SM DB is used due to inactive objects (for my relatively low values of retention, 50% of my IMAP objects are inactive; if you keep discarded stuff for a month or more, inactives may dominate your *SM DB!). 5. Consider that among all those LLBean ads stored on your mailstore are mail items critical to your organizations long term and efficient operation. Maybe it's efficient to have someone ask mailbox owners why they have a gigabyte of mail stored yet haven't connected in past 3 months? Maybe it's efficient just to size your backup and IMAP resources to match the need? (any of the copy options of point #2 above have additional costs wrt complexity of operation, reliability of restore, etc.). Does your organization consider *SM resources to be part of the cost of IMAP operations? Maybe it should. Hope this helps, wayne Luke Dahl wrote: Hi All, TSM Server - 4.2.1.15, Solaris 9 TSM Client - 4.2.1.0, Solaris 9 We are backing up an IMAP mail server which creates a new file for every new mail message received. The large number of files (new messages) created is increasing our database size at an alarming rate. We'd like to specify a management class that will retain only the last 32 days worth of NEW messages. It's my understanding that the Retain Only Version parameter applies only to inactive files. Files (messages) are never deleted from the server (our users basically store their mail on the server indefinitely) so they never become marked inactive. So, I'm wondering if I can somehow specify to only backup the most recent 32 days worth of new files? I do not want to include all of the files that reside on the server and I have no way of separating the most recent files into a separate area. Basically, if we lose our mail server we want a method of quickly restoring only the last month's worth of new mail messages. The size of the mail server (~400Gb) limits our ability to provide a restore of all the files in a reasonable amount of time and is burning up our database capacity. Anyone else backing up IMAP mail servers or facing similar issues? Any thoughts or suggestions are much appreciated! Luke Dahl NASA - Jet Propulsion Laboratory 818-354-7117 -- Wayne T. Smith -- [EMAIL PROTECTED] -- University of Maine System -- UNET
Re: how to schedule the reclamation
Mark Stapleton wrote, in part, a week or two ago: You've got half of the problem solved. You should be running two commands per storage pool to be reclaimed: upd stgpool stgpool_name reclaim=60 when you want reclamation to start, followed by upd stgpool stgpool_name reclaim=100 when you want it to stop. (It will stop sooner than the scheduled time if it finishes first.) A few remarks ... 1. The low value that you use (60% in the above example) is completely up to you. Lower values tend to decrease restore times, wear out read/write heads, and potentially to decrease the number of tapes required. Higher values tend to leave more tape drive time to do other *SM actions. My hardware and rate of data change cause my low reclamation value to be more like 75-85 for my collated and copy pools. 2. The current tape's reclamation won't stop when you set recl=100, but will complete (unless you cancel the process). A tape reclamation might be quick, but might be fairly long depending on several data and hardware variables. My reclamations can run over an hour, but are generally somewhat less slow. 3. Although it may have changed in current *SM versions (mine is V3), reclamations of offsite volumes (in a copypool) are selected somewhat differently than others. Tivoli ADSM determines the volumes eligible for reclamation of copypools (just offsite tapes?) when you lower the reclamation value. The reclamation process will continue until all of those volumes are reclaimed ... even if you change to recl=100. 4. Reclamation (in tandem with some other operations such as backups) is one of the activities that can cause your recovery log to become pinned (I don't use roll forward). So, it might pay to keep an eye on the max utilization of your recovery log ... well, it probably will pay to keep an eye on it anyway ;-) Hope this helps, wayne Wayne T. Smith -- [EMAIL PROTECTED] -- University of Maine System -- UNET
Re: multiple reclaim processes
Two quick (and probably obvious) points: - You can do multiple simultaneous reclamations if you have multiple storage pools. Long on tape drives? Create another domain ( storage pool(s)) and split your nodes between them. - MOVE DATA (tape to tape, or tape back to disk) allows multiple simultaneous processes on one storage pool and each is often faster than the corresponding reclamation. The down-side to MOVE DATA is that aggregates are not reconstructed, so your newly filled tape will immediately have reclaimable space. Perhaps a statistician could tell us the expected wasted space remaining after a MOVE DATA. Maybe with too many caveats to be useful, ... but when I switched from exclusively performing MOVE DATAs to exclusively performing reclamation, I gained almost 20% empty volumes. cheers, wayne Wayne T. Smith, [EMAIL PROTECTED], University of Maine System
Re: TSM v4.1 clients NOT compatible with V5.1 server?
Perhaps I missed a response or two to this. In case not ... If I am reading things correctly, all my v4.1 clients are NOT compatible with V5.1 server. Nor is a V5.1 client (where supported) compatible with a V4.1.5 server. Let's not confuse compatible with supported! :-) *SM has been very good in terms of old clients on old boxes still working with new servers. I still have a bunch of version 2 clients backing up DOS machines. Tivoli won't support that, but they also haven't broken it. Win95, and now Win98, are similar ... don't put the version 5.1 client on them, but if you use what is or was once a supported client for the operating system, you'll find they will work. The down-level backup server is a bit more of a problem. Newer clients tend to run, but without new function that requires backup server support. I don't know, but would guess that a 5.1 Windows client backing up to your 4.1 server might have problems with the registry, as the server has (unfortunately) some functional changes with regard to system objects (I forget the version where this breaks (3.1/3.7/4.1)). Hope this helps, wayne Wayne T. Smith [EMAIL PROTECTED] ADSM Technical Coordinator - UNET University of Maine System
Re: management class question?
On 5 Jun 2002 at 11:18, David Longo replied, in part: select node_name,filespace_name,class_name from backups where node_name='NODE' and filespace_name='FSNAME'. You might want to change /class_name/distinct(class_name)/. But then, while there is a default (and perhaps other) management class(es) for files in a file space, a file space does not belong to a management class. Do you want to know the default management class for a file in a file space or the management class for a particular backed up object?cheers, wayne Wayne T. Smith [EMAIL PROTECTED] ADSM Technical Coordinator - UNET University of Maine System
Re: Scheduler Question
On 4 Jun 2002 at 10:02, Luciano Ariceto wrote, in part: I would like to know if it is possible to setup a scheduler to run from monday to saturday. As far as I know, weekday is monday to friday, and weekend is saturday and sunday. Is this possible ? I think it's strange this seems not possible, too. I have 2 schedules, one M-F and the other Sat. Not that I'm looking for it, since our Sat schedule has changed to have a different time from weekday. cheers, wayne Wayne T. Smith [EMAIL PROTECTED] ADSM Technical Coordinator - UNET University of Maine System
Re: Incremental full backups
I agree with Rick. If you're going to use TSM, start by reading the Concepts manual so you understand it. TSM is not a full plus incremental backup system! We know that's hard to believe, because most of us have been there, but you won't be happy or effective with TSM until you understand it's concepts well. Once you do, perhaps with some help from the folks on this mailing list, you'll be able to use TSM to provide the protection you need. Hope this helps, wayne Wayne T. Smith [EMAIL PROTECTED] ADSM Technical Coordinator - UNET University of Maine System
Re: ADSM WinNT client could not finish backup?
On 20 May 2002 at 10:37, Julie Xu wrote, in part: My adsm server ver 3.1.0.3 and the problem WinNT client ver 3.1. This client after check/backup 51,000 files then give error: 05/18/2002 22:29:19 ANS1898I * Processed51,000 files * 05/18/2002 22:29:20 ANS1017E Session rejected: TCP/IP connection failure Wild guess: either CommTimeOut or IdleTimeOut on your server is too small. I have Commtimeout 2400 (seconds) and Idletimeout 600 (minutes!). cheers, wayne Wayne T. Smith [EMAIL PROTECTED] ADSM Technical Coordinator - UNET University of Maine System
Re: copy pools question?
I want to create a set of backup tapes for disaster recovery that would only have the most recent versions of my files, I do not want all the extra versions. Assuming you move data offsite with the same period as you do backups (e.g., daily), you are churning the same amount of data each day. You do keep fewer tapes at the vault, but what is the cost differential? (It depends on your retention policies). I've often wondered the same thing: why doesn't *SM allow us a compromised copypool with only active files in it? The answer is probably IBM hasn't seen sufficient business case to add it to the product. In addition, I think there are real risks in having no older versions available (when the *SM site turns to dust or mud). First, presumably you keep older versions because you have a perceived business need for it. Given that you're probably writing and transporting the same number of tapes, the increased cost of additional tapes and tape storage may be small. Second, needs are high and alternatives are in short supply in times of disaster. Having more than just active files offsite may be very valuable. From my experience, many client disaster recoveries make use of point-in-time restores, where one might have thought simply restoring active files would have been sufficient. Hope this helps, or at least fuels the discussion, wayne Wayne T. Smith [EMAIL PROTECTED] ADSM Technical Coordinator - UNET University of Maine System
*SM 5.1
trivia: The Mac FTP doc file is mostly updated, but says Welcome to the TSM Version 4 Client for Macintosh! cheers, wayne Wayne T. Smith [EMAIL PROTECTED] ADSM Technical Coordinator - UNET University of Maine System
ANS0106E ReadIndex: message index not found for message 12705.
(etc.) for WinNT 5.1 client on Win2k. It turns out that my tsm_images installation directory now has two baclient subdirectories ... one with an older client (probably 4.2.1.??) and the other with files new this month. My installed baclient directory appears to have mostly new files, but DSCAMENG.txt is back-leveled. Reboots, uninstalls and reinstalls do not help. There is no DSM_DIR env. variable set. Bypass: manually copy the newer DSCAMENG.txt file to the production baclient directory. I didn't try it, but suppose that manually discarding the tsm_images directory between uninstall and reinstall probably would have worked. cheers, wayne Wayne T. Smith [EMAIL PROTECTED] ADSM Technical Coordinator - UNET University of Maine System
Re: NetWare, Compression Slow Backups
On 10 Apr 2002 at 16:18, Daniel Sparrman wrote, in part: You shouldn't use Compressalways YES. If the file grows, instead of shrinks, TSM will keep on compressing the file. This will make the backups take a whole lot longer. I disagree with Daniel's conclusion ... at least for some cases. *If* you have a case where compress=on and most files benefit from compression, then I think CompressAlways=Yes can be very beneficial. Yes, the file sizes of some files will grow slightly, but this is far superior to having *SM discarding the entire transaction group and resending everything ... especially with large transactions that take considerable time to transmit. You lose a little instead of losing a lot. On the other hand, I've found (no scientific study!) compression rates relatively independent from backup times. My site has gone from mostly compressing to mostly not compressing. The effect has been less traumatic effects at the client and somewhat larger disk pool needs, as very compressible, but not compressed, data takes substantially more disk space at the backup server. My short answer: (1) Use Compress and CompressAlways together. (2) Mildly avoid compress. If you compress, do because you need to, not because compression values say you're transmitted 1/2 the # bits. Your mileage may vary, wayne :-) Wayne T. Smith [EMAIL PROTECTED] ADSM Technical Coordinator - UNET University of Maine System
Windows client installer minor comment/suggestion
I applaud the excellent quality steps taken with the Windows client, and especially the installer. However I have a couple of minor comments: - The installer calls itself CD Browser on the Windows task bar. (yuk) - The installer displays version 4.2.1.0, even though we might be installing version 4.2.1.30 patch of the product. If you're no going to bother to update the patch number on the installer display, just call it version 4.2.1 so paranoid people won't be worried that they downloaded the wrong thing. Better just to update the installer to display the full version # being installed, IMHO. cheers, wayne Wayne T. Smith [EMAIL PROTECTED] ADSM Technical Coordinator - UNET University of Maine System
Re: Reclamation for copy pools
On 22 Mar 2002 at 13:37, Joni Moyer wrote, in part: Reclamation is set for 60 on both the onsite tape pool and the copy pools(offsite). If you have enough tape drives so that reclamations don't interfere with other need for drives, then this is fine. I don't, so my tape pools are set at reclaim=100 for most of the time, and at reclaim=nn for the times I don't mind reclamations starting. In general reclamations are independent of your protecting your server and client data, except that (1) you need to have enough non-full tapes to write new data, and (2) restores are generally faster from relatively full tapes because the generally require fewer tape mounts. ... and then in turn the reclamation for that volume fails because it cannot be mounted in the silo. I didn't think it was possible to run reclamations for the tapes that are in the vault. How do I prevent reclamation from trying to reclaim these volumes when they are also technically recognized in the copy pool? I'm not sure why you get the failure. You surely can reclaim files from offsite tapes ... *SM simply mounts primary volumes (onsite tapes) in its building of a new copypool tape. I've not tried to reclaim a copypool volume that was onsite; does *SM then use the copypool volume directly? If so, it might have been confused by the sequence (1) determine reclaim of a tape is to proceed, (2) your mark tape as offsite, and (3) try to mount tape, only to find tape is set with access=offsite. Pure speculation. I also have many volumes in the offsite copy pool that are in the status of pending and they are in the offsite vault. Does TSM interact with TMS to bring those volumes back to the copy pool in the silo or do I have to run a job to do this? The pending status exists in case you have a disaster and need to restore an old copy of your DB. You want the tapes, as set in that old DB copy, to continue to hold the expected data and not be overwritten. So you set your reuse delay to what makes sense for your DB backups. If you might someday want to restore a DB backup that is 7 days old, your reuse delay must be at least 7. (The alternative is that you can't trust what's on any tape and so must mount and audit all of them. Yeck). I don't have or know TMS, but here is some of what goes on: Your (normally status=full or filling) tapes are set as access=offsite when you take your tapes to the vault (DRM, if you have it, has a couple of intermediate steps). Eventually, because of inventory expirations (and reclamation), the tapes become status=pending. Once your reuse delay completes, the tapes become status=empty ... still with access=offsite. Now you have some logically empty tapes in your vault. At some point you decide to retrieve these for reuse (again, if you have DRM, there are a few states the tapes can go through). Once you have returned the tapes, (remember they're already status=empty), you update their *SM state to access=readwrite (assuming you're using a private pool and not scratching tapes you're done with). (Sorry for the bad grammar!) If you need it, there is a location field that you can use with the update volume/volhist commands to help keep track of where the tapes are really located (if you don't use DRM). With DRM see the Q DRMEDIA and MOVE DRMEDIA commands. Hope this helps, wayne Wayne T. Smith [EMAIL PROTECTED] ADSM Technical Coordinator - UNET University of Maine System
Re: Procedures for TSM
On 20 Mar 2002 at 14:19, Joni Moyer wrote, in part: I've been studying the TSM manual and changing administrative schedules by trial and error, but I just wanted to know if I have the order of procedures down right. 1. Backup disk to offsite tape pool 2. Backup onsite tape pool to offsite tape pool 3. Migration of the disk pools 4. Expire Inventory 5. Reclamation 6. Client Backups (run at night) Others have spoken about DB/VolHist/DevConfig backups (after 2). I'll add that 4 and 5 can be done any time in that they are independent of offsite protection and getting initial backups. They can be thought of as controlling the utilization of your storage pools and DB. I note that, unless you monkey with reclamation levels, Expire Inventory will tend to kick off reclamations. In my experience with ADSM V3.1 and a relatively small (and even) number of tape drives, reclamations can block other tape activities (restore, migration, etc.) for long periods of time. You might also consider that 6. Client Backups is really step 0, at least it is to my way of thinking. I'm trying to provide a risk management service. I can't restore something until it's backed up, hence Client Backups are step 0 (most important and first ... even if at night!). Everything else *SM does must provide for restoration at almost any time, and backups at expected times. This means I may try to delay migrations (disk to tape copy) as long as possible, but I really want my disk pools migrated by the time the next significant backups occur. *SM's offsite backups (backup to copypool tapes, db backup *after* copypool tapes are built, VolHistory and Devconfig) allow rebuilding of your *SM operations after some backup server location disaster. This backup is good up to the point of the DB backup, with caveats. The caveats include: (1) if you backup to copypool tapes after your offsite DB backup, those copypool tapes are worthless wrt reconstruction of your backup server after a disaster (loss of *SM DB), and (2) it's important to keep your Delay Period for Volume Reuse at least as long as you consider any one DB backup useful. Hope this helps, wayne Wayne T. Smith [EMAIL PROTECTED] ADSM Technical Coordinator - UNET University of Maine System
Re: reporting on backup successes/failures
What would be the best way to produce a report that shows the number of client backup successes vs. failures, for a given day? Tough or impossible to answer, IMHO. What constitutes a failure? If you can understand the answers to that question, you may be able to answer your own question. Is a single file failure, a failure? Is a missed schedule a failure? Is having a scheduled backup for a file space start and complete on different days a failure? Is having a backed up file space not backed up for n days a failure? Is failing to move all data n hours (days) old offsite a failure? Is backing up 10-20G per night, every night, from a desktop a failure? Is a failure related to an enterprise-critical server more of a failure than a failure on a non-critical desktop? Are all failures client failures, or are there server failures? Is wanting to restore a file copy that is not on the backup server a failure? Is keeping a tape pool at 95% instead of 60% reclamation level a failure? cheers, wayne Wayne T. Smith [EMAIL PROTECTED] ADSM Technical Coordinator - UNET University of Maine System
Re: Copygroups
How do you recommend setting up a management class that would allow me to retain backups for 60 days while allowing a PIT restore to any date within the past 60 days? I am thinking I should set the copygroup parameters VERExists, VERDeleted, RETExtra and RETOnly to 60. Does this seem correct? It's probably close. Deranged people such as myself might comment: * If you are doing weekly backups, these numbers are way too high. * If you sometimes do more than one backup in a day, the numbers could be too low. * If you want to do restores from the last 60 backups, 60 would be right for verexists, but 59 would be sufficient for verdeleted, etc. * It sort of depends on what you want to accomplish. Maybe a client expects 60 days to be 2 months. Maybe bump 60 a little. Maybe you backup every day, but client doesn't see a problem on weekends, so maybe bump 60 a little. Maybe client tries to restore today, runs out of time and comes to you tomorrow for help. Maybe bump 60 a little. Of course, if you can identify the files which need this PIT requirement, then considerable *SM DB and STGpool space and processing time might be saved if you have a special management class for the 60- copy files and something considerably less as standard ... but then the client risks making a poor decision. :-) cheers, wayne Wayne T. Smith [EMAIL PROTECTED] ADSM Technical Coordinator - UNET University of Maine System
Re: Tapes and TSM
On 10 Jan 2002 at 15:13, Lawrence Clark wrote, in part: ... Reclaim should be set to around 50% on primary storage pools. I disagree in that I believe that reclamation should be set as low as practical for your situation. Lower reclamation values generally result in quicker restores and a need for fewer tape volumes overall, at the expense of increased tape processing. A 50% reclamation level is often suggested as a rule of thumb. This doesn't mean data for any file system is spread over twice as many tapes as perfectly packed data (0%?!). Likewise, a 90% reclamation level doesn't mean 10 times as many tapes as perfectly packed, as some tapes may be near the reclamation level and some perfectly packed. How important this effect has on relative numbers of tapes is dependent on tape capacity relative to file system size (for perfectly collated by file system storage pools) and other factors. My little 1G tapes and (sometimes slow) manual mounts means that I'm often happy at an 80% reclamation and ecstatic at a 60% level. I have little experience with reclamation of copy pools. Anyone have rules of thumb for reclamation of copy pool volumes? cheers, wayne Wayne T. Smith [EMAIL PROTECTED] ADSM Technical Coordinator - UNET University of Maine System
Re: TSM V4.2.1.20 Windows NT/2000/XP Client Flash
On 11 Jan 2002 at 9:20, Andrew Raibeck kindly wrote, in part: This 4.2.1.20 Windows NT/2000/XP client patch has gone through some function and system testing. We support its use in a production environment. ... I really like the seemingly more frequent patch levels for the Windows client ... and sometimes recommend them for use in a production environment, but this is the first time I recall Tivoli suggesting same. If this is really the one we should be using, why isn't it 4.2.2? I really like the notion that a patch level is there to fix particular problems that affect a relatively small portion of users, was recognized as not having been tested as much as a fix level, and thus potentially not of the quality that we require in our general production use. So I'm ecstatic and disappointed. I wish for Tivoli to find a way out of its apparent testing quagmire, while at the same time recognizing the quality of client installation and operation is superior now to most any time in the past. Maybe all the test time saved by distributing production level patches could be used to provide a more functional VM server? Nah ... been down that Friday Afternoon road. cheers, wayne Wayne T. Smith [EMAIL PROTECTED] ADSM Technical Coordinator - UNET University of Maine System
Re: ADSM v3 on Wy2k...
Zosimo Noriega [EMAIL PROTECTED] wrote, in part.. I know that ADSM V3.1 is not compliance on Windows 2000 but i tried to use this to backup and restore files of Windows 2000 server. I haven't encounter problems, except some open files that we manage to handle it and system objects that we manage to dump into a physical files. Can you please specify clearly what are the problems, incompatibilities, or possible damage on the system when we use this for Windows 2000. If non-support from the vendor, lack of system object and unicode support, as well as lack of newer server features such as backupsets, subfile differencing and journaling are not issues of importance for you, I have seen no problem (using client v3.1.0.8 or 4.2.1.18) on a V3.1 server. I do however wish for a summary table and a serviceable server. If you mean V3.1 client, then I'd be less positive (that was positive?). The V4.2.1.18 client scheduler seems more reliable (the V3.1 scheduler was prone to permanent sleep when the network blipped or backup server was restarted) and many find the restore functions easier to use than with the older client. (We're not a big Windows client user, but have a few servers and a few dozen workstations, mostly NT and 2000). Hope this helps, wayne Wayne T. Smith [EMAIL PROTECTED] ADSM Technical Coordinator - UNET University of Maine System
Re: migration options
Ron wrote, in part.. ... The VM version has been so trouble free and so easy to manage its really hard to understand Tivoli's determination to eliminate the platform. Hear! Hear! ;-( cheers from Maine, wayne Wayne T. Smith [EMAIL PROTECTED] ADSM Technical Coordinator - UNET University of Maine System
Re: Bare metal restore Instructions on SGI ???
On 2 Jan 2002 at 14:29, Keith Kwiatek wrote, in part: what does everyone else do for bare metal restores on SGI? Bare metal restores? I walk the beach, enjoy the sunsets... What? Oh. You didn't mean St. George Island, FL? Never mind. (sorry) Happy New Year to all, wayne Wayne T. Smith [EMAIL PROTECTED] ADSM Technical Coordinator - UNET University of Maine System
Re: Appropriate way to UPGRADE client
On 26 Dec 2001 at 11:15, Malbrough, Demetrius wrote, in part: Is it documented anywhere the appropriate way to upgrade the client? Scenario: You have an NT client at 3.1.0.6 and you want to upgrade it to the latest level of the client which is 4.2.1.18. Do you upgrade to TSM 4.2.1.0 first and then upgrade to the patch of TSM 4.2.1.18? I know of no reason why you'd install the .0 level and then a patch level ... at least not for the *SM clients. But whenever anyone asks me about upgrading Windows *SM clients, I tell them (0) defrag all disks, (1) reboot, (2) uninstall the old client, (3) reboot, (4) install the new client, and, the ever popular: (5) reboot. Not all of these are needed all of the time, but each is useful some of the time. The *SM Windows client installs have been getting *much* better, but I still suggest this sequence. Happy Holidays! wayne Wayne T. Smith [EMAIL PROTECTED] ADSM Technical Coordinator - UNET University of Maine System
Re: Which conference do you recommend?
On 17 Dec 2001 at 10:51, Kai Hintze wrote, in part: Looking at next year's education budget. My boss says he will send me to one (and only one) conference. The two leading contenders at this time are SHARE (March in Nashville) and the Storage Symposium (August in Salt Lake City). I've not been to the latter, but can attest that the SHARE meetings can be wonderful experiences, with plenty of chance for high-quality sessions and personal experiences with developers and other participants. A quick look at (1-hour) sessions shows about 26 directly applicable to TSM, with a few more tangentially interesting. Two of these are requirements sessions where you can have input on the bugs and new features that might someday become part of the product(s). SHARE is not known for its Unix side, but there are some sessions ... take a look at the preliminary agenda at http://www.share.org/ . Also, does anyone know where I can get information from the two sessions titled Everything you always wanted to know about TSM Database, parts 1 and 2 in last years Storage Symposium? The Member's Only portion of www.share.org have year-old proceedings entries for a couple of sessions that are entitled similarly (parts I only). cheers, wayne Wayne T. Smith [EMAIL PROTECTED] ADSM Technical Coordinator - UNET University of Maine System
Re: Linux ext3fs support
On 12 Dec 2001 at 13:37, Kliewer, Vern wrote, in part: Is there currently a way to back up these filesystems? If not, does anyone have any idea when they might be supported? Yes, use the preferences statement VirtualMountPoint for each of your ext3 file systems. cheers, wayne Wayne T. Smith [EMAIL PROTECTED] ADSM Technical Coordinator - UNET University of Maine System
Re: WinXP incompatible with V3 Server
On 16 Nov 2001 at 20:30, Roger Deschner wrote, in part: The only version of the TSM client that works under Windows XP is V4.2.1.15. However, all V4.2.x.x clients are incompatible with any V3 server. This is documented on the Tivoli web page, and I have found it to be true in practice. They simply hang when trying to do a backup. We're having no problem backing up normal files to a VM V3 server. The only hang I've seen was when someone told their client to do subfile differencing (or whatever it is called) ... that caused hung sessions (that could be manually cancelled). Although registry backup on NT appears to work, SYSTEMOBJECT/registry backup on 2000 and XP does not. We run a separate command schedule just before the normal backup window with: ntbackup backup systemstate /F %systemroot%\__Registry_Backup\NTBackup.bkf (all on one line) as the command. Windows does the backup (about 1/4G) and *SM backs up the normal file. Fwiw, we use client 4.2.1.15. Hope this helps, wayne Wayne T. Smith [EMAIL PROTECTED] ADSM Technical Coordinator - UNET University of Maine System
Re: Question. Tivoli Backup Client Version 3.7.2
On 28 Nov 2001 at 10:17, Gent, Chad E. wrote, in part: I have several backups that run using the TSM Scheduler. Sometimes the backups will be missed and we have someone go in and run the back ups manually, This works great but it doesn't write to a log file. The Scheduled backups write to Dsmsched.log and Dsmerror.log. Is there any way for to get the manual backups to write to a log file. The program designer had a bad day. We should have schedule, error, backup, and restore logs, but instead have just what you note. Repeatedly pointing this out to IBM and Tivoli has resulted in no action, presumably because this has been determined to not affect revenue. Maybe in V5? By the way, errors during your ad hoc backups *will* be recorded in the dsmerror.log. cheers, wayne Wayne T. Smith [EMAIL PROTECTED] ADSM Technical Coordinator - UNET University of Maine System
How does one remove a cloptset from a node?
How does one remove a cloptset from a node via command line admin client? My (V3) manual doesn't show a way, and a few guesses all failed. I finally re-installed the old V3 admin gui and removed the setting. Sorry, if this is obvious to everyone. :-( Wayne T. Smith [EMAIL PROTECTED] ADSM Technical Coordinator - UNET University of Maine System
Re: TSM 4.2.1
Reni wrote, in part.. which version/level would you recommend for the clients ? (we run TSM server 4.1.4) My personal favorite was 3.1.0.8, but that might not fit your requirements. :-( You might search the archives of this list (at http://www.adsm.org/ for example) for previous discussions around this topic. Several levels have been suggested, but all have some sort of substantial problem. Fwiw, I am moving many of our Linux and WinNT/2000 machines to the latest available for a number of reasons (that may not be important to you). I'm hopeful that Tivoli will really get kinks worked out at V5. On the other hand, retirement an finding other solutions seem just as likely at this point! :-) cheers, wayne Wayne T. Smith [EMAIL PROTECTED] ADSM Technical Coordinator - UNET University of Maine System
TSM .jar files
I've installed enough *SM versions and levels (including V4.2.1.0) on my desktop Win2000 machine that I don't know which *SM client caused the problem, but .. Whenever I try to start a Java application now (run a .jar file), I get a message that this is a TSM thing ... go away (more or less). If I open File Manager and select Tools, Folder options..., File Types, and scroll to the jar file type ... I see TSM Jar file. Reinstalling Sun's Java Runtime Environment returns JAR to Executable jar file. Anyone else see this? Under what circumstance? cheers, wayne Wayne T. Smith [EMAIL PROTECTED] ADSM Technical Coordinator - UNET University of Maine System
Various comments on V4.2.1.0 client for windows
In my so far futile quest to find a relatively wart-less *SM client version, I've come to the latest and greatest V4.2.1.0. While great improvements have been made, I find (in the windows case) ... 1. The return code problem. Already documented on this list. 2. Unable to backup Win2000. My supported VM 3.1.2.90 server is unable to backup the registry/systemobject. At a time when WinXP is about to debut, my inability to backup Win2000 without manual Ms backups of the registry, is something I wish Tivoli would consider a bug or something necessary of correction. (Backup REG gives ANS1943E; backup Systemobject gives ANS1924E) 3. The default language for the download .EXE file is Chinese. I have a couple of students that probably appreciated this, but a hundred others scrolled to English. To view the dialog box I'm referring to, see ftp://wts.unet.maine.edu/ADSM/_Dumb/ 4. On (my 1st) Win2000 install, the LNKs for the GUI backup are strange or broken (both desktop and off START button). The icon in the executable is OK. To view the icon I'm referring to, see ftp://wts.unet.maine.edu/ADSM/_Dumb/ 5. APAR IC29552 Active file not found with some strange characters in file names, was corrected in 4.1.2, with a DB correction program TSMCLEAN.EXE provided to correct an infected *SM database. When I used it, TSMCLEAN just terminates with a programming error. Perhaps my supported 3.1.2.90 server is confusing TSMCLEAN? 6. It's unclear why the installer leaves 77MB in tsm_images. Is this required for the Win Control Panel repair, modify and uninstall functions? If not, I want my 77MB back; it really matters on those 1 and 2 G NT machines I still have in abundance. 7. The setup wizards are by far the best ever. However, I've watched (cringed) as some of my client users run the backup wizard, then go back to run the schedule wizard (causing the backup wizard to run again). More a nit than a wart. :-) 8. The audit trail for backup and restore are still miserably and conspicuously poor/absent. DSMERROR.LOG contains the appropriate information, as does DSMSCHED.LOG, but ad hoc backups and all restores have no ability to write an audit trail. I want a DSMSCHED-type log that is on by default for ad hoc backups and all restores (please). 9. Include/Exclude. Boo! to whomever implemented the exclude.dir. If you scan recent postings on ADSM-L, you'll be really confused. Trailing slash or not, ... or not, drive/system indicator needed or used or not, trailing splat (*) OK or not. I would guess the rules require no trailing / and/or *, and require a filespace component, but I don't know. Cheers to a recent poster that pointed out one can test an include/exclude list against existing files via little red x found in the Actions, Backup tree view. Cool. (And cheers to the doc writers that put lots of include/exclude examples in the online doc available with the client download. 10. If this were a top-ten list, I'd have put something here. Maybe you have your own favorite wart? V5 will be perfect ... I know it will. cheers, wayne
Re: performance question
(Rob Schroeder wrote on apparently slow backups)... Assuming there are no strange messages in the schedule log (errors, warnings, retries), I'd try the following (individually): (1) for a windows client, I've seen bad performance with settings other than: TCPBUFFSIZE 31 TCPWINDOWSIZE 63 (2) some people have suggested this can correct some performance problems (opposite of what might be intuitive).. largecommbuffers no (3) can the problem be isolated to a particular file system? (4) Do you use windows file compression (don't if performance matters)? (4a) Is the file system and swap file defragmented? Was it converted from fat to NTFS? (5) Do you have a file system with *many* files or directories in it? (6) Do you have large portions of a file system excluded with exclude directives? If so, see if exclude.dir may be used instead. I don't need the answers to any of these questions, but I'm sure many would be interested. I'm also interested in other possibilities. For example, I have a linux system with performance that seems slow and needs to be better. Here are some stats: objects inspected 2.5M objects backed up 35K objects expired 13K data transferred 1.3G duration of backup 6.5H backup failures 6. cheers, wayne
Re: VM TSM server, just some thoughts...
Dwight wrote, in part.. The new IBM Z series processors are being pushed as consolidation servers. rum VM with a whole bunch of virtual LINUX servers... The only TSM server for VM is functionally at 3.1.2 VM LINUX client is at 4.2 ( I don't know if 4.2 clients would talk to 3.1.2 server ?) They can, but at 3.1.2 server capability. That is, no backupsets, no image backups, no adaptive differencing, no system objects, no respect. I do see there is an OS/390 TSM 4.2 server Would a person have to run MVS under VM in order to have a TSM 4.2 server running in this sort of environment A foolish IBM salesman, if there were one, would salivate over this one. maybe I need to get with my Tivoli sales folks to find out what is to be available down the road maybe I just haven't looked in the right place yet... Maybe Tivoli has yet to find or accept the existence a market for S/390 and zSeries. Without exception, Tivoli personnel (I've listened to) have either avoided the subject or said the direction is to have no S/390 wrt TSM. anyone have any thoughts on any of this ?? :-) Next to not playing, the worst thing an athlete can have is indecision. I think that Tivoli has had indecision wrt S/390 servers for a long time. They (or IBM) drove customers away with indecision when customers were using ADSM V1 (few had migrated to a weak ADSM V2). Customers were unable to get long-term commitment for a VM backup server, but a Tivoli ADSM V3 server was produced. Unfortunately, it was late ... very late ... and many customers chose other solutions. The V3 product was a very good upgrade, but the indecision on providing the V3 product and continuing reluctance of Tivoli wrt S/390 sent more customers away. In a financial climate where earnings of 20% per year were expected, one might understand (what I believe was shortsighted). Now a new market is opening for S/390s and zSeries, but the critical backup piece is not available (there is now a Linux client, but not yet a server). Whereas a Linux server might be provided one day, will it be treated as the VM backup server was? Just as Dwight (perhaps) suggested it would be foolhardy to obtain zOS for a TSM server, I think over the years Tivoli may have wondered if people would obtain VM systems to license their VM server (customers won't do that). But are there existing and new VM systems to make a TSM VM server a viable product? I used to think so, but I'm no product manager and know neither the economics nor the company politics of the venture. It seems so long ago that IBM/Tivoli were bragging about how easy it was to port the mostly platform-independent *SM server. :-( cheers, wayne
Re: Which version of TSM Win32 to install - 4.1.2.12, 14, 17, 18 ??
Oops ... you missed 19. :-) Which version should we use for the Win32 client? The Tivoli support site once showed 4.1.2.12 / 14 / 17 and 18 ! Now it has only 4.1.2.12 ! Perhaps you are confusing the maintenance area of the FTP server with the patches area? The patches area has all of these; the maintenance area has only 12. Since a patch level doesn't normally make it to the maintenance area, we appear to be in particularly strange and distressing times. We connot upgrade every month or so, it is therefore important to all of us to get stabilized versions. I agree. I wish Tivoli had a commitment to do this. The availability of patches that correct problems is good, but it has been several months since a maintenance level has been produced, and, IMHO, *years* since a workable client has been produced for my environment. I'll admit to not understanding system objects and their backup and restore, but providing restore of only the most recent registry backup may eventually make us rethink *SM as one of our backup/recovery solutions. Oh yea, being apparently unable to *backup* system objects to the most recent and supported *SM VM server is even worse. Sorry for being such a stick-in-the-mud, Wayne T. Smith [EMAIL PROTECTED] ADSM Technical Coordinator - UNET University of Maine System
Re: Which version of TSM Win32 to install - 4.1.2.12, 14, 17, 18 ??
Jeff Bach wrote, in part.. Explain what server version is unable to backup NT system object (the new one) ... in reply to my comment ... I'll admit to not understanding system objects and their backup and restore, but providing restore of only the most recent registry backup may eventually make us rethink *SM as one of our backup/recovery solutions. Oh yea, being apparently unable to *backup* system objects to the most recent and supported *SM VM server is even worse. The version 3.7 and version 4.1 *SM server for the VM platform has a version 3.1 code base. In other words, the VM server is marketed as v4.1, but at V3.1 capability. For example, my workstation daily receives the following message in the schedule log: 06/21/2001 12:15:36 Incremental backup of volume 'SYSTEM OBJECT' 06/21/2001 12:15:50 ANS1924E The specified system object is not valid. Is there an NTBackup of system object I can do transparently via *SM server and pre-schedule event? Comments and suggestions appreciated! Wayne T. Smith [EMAIL PROTECTED] ADSM Technical Coordinator - UNET University of Maine System
Re: User verification of backups?
Richard supplied a great horse before the cart post, but I think there is substantial merit in the notion of verification of backups, especially if this means enhancing the chance for rapid and complete restores, without surprise, to meet operational objectives. *SM, by itself, is inadequate to ensure verification of backups, IMHO. I'm reminded of incidents with three of my clients in my early days with ADSM. A Netware administrator approached me asking if his backups were up-to- date. I looked (on the backup server) at his file systems and saw each was recently backed up without error. I responded Yes!. I was wrong. The Netware administrator had just experienced a disk crash and couldn't restore the file system. It hadn't been backed up. His predecessor had coded a DOMAIN statement in DSM.OPT (necessary at the time to stop backup of file systems that shouldn't be backed up) and when a new disk and file system was added, the DSM.OPT file was not adjusted. A Windows desktop client approached me with help in restoring his PIM's data base file. He'd received my weekly automatic e-mail suggesting that his file systems were backed up successfully, but couldn't find his PIM's data base file for restore. It wasn't backed up. He had not viewed his DSMSCHED.LOG file since installing his PIM, else he would have seen that ADSM could not read his PIM data base file, since the PIM had an exclusive lock on it. A single file failure was not part of what I could then see at the backup server. Another desktop client approached me asking why he couldn't restore a file that was on his machine the previous week, but inadvertently erased. The reason was that he had decided to conserve power and turn his machine off each night (during his backup window!). My weekly e-mail reminder would have pointed out the problem, but it wouldn't be generated until the next day ... not that it would have helped: he filtered it into a folder that he rarely viewed. So, I very much prefer and encourage user verification of backups. The user (the *SM client) often have an understanding of the importance of their data. *SM information at the backup server to verify backups has increased over time, but wrt verification of backups, I am merely a supporter, as the buck stops here at the data owner (*SM client user). Hope this helps, Wayne T. Smith [EMAIL PROTECTED] ADSM Technical Coordinator - UNET University of Maine System
Re: possible update Path from ADSM 3.1.2 to ????
Wanda wrote, in part.. I don't believe there is any 3.1 server that is still supported by Tivoli. Tivoli ADSM 3.1 for AS/400 goes EOS today. Tivoli ADSM 3.1 for VM EOS has not yet been announced and is listed as requiring 14 months written notice (see http://www.tivoli.com/support/storage_mgr/tivolieoc.html for more information. The extended support for the VM platform is probably due to IBM/Tivoli repackaging V3.1.2 as V3.7 and V4.1. cheers, wayne Wayne T. Smith [EMAIL PROTECTED] ADSM Technical Coordinator - UNET University of Maine System
Re: How Can I reduce the OffSitePool
Diana posts a great question, in part reading ... We are having problems with our DBsize and Recovery Log size. We are in a disk crunch. So I have been looking for ways to reduce the # of files that our DB and Recover Log file keeps track of. Our OnSitePool and our OffSite pool are almost idential in the number of files that are contained in them. We use this pool for DRM. My thought is that if we TRULY have a DR situation we need only provide the last ACTIVE files to our clients. I do not think that we need to provide 18 generations of data files to our company is not producing our product! Therefore, if I could only produce offsitepool information that contained the last active file it would reduce the number of tapes useds, reduce the # of files managed, etc. and maybe help us Anyone know if this could be done or not or have any workarounds that would still fit into a DRM scenario? So the problem, as you see it, is not enough disk space for the DB and log, and you see the DR area as a good possibility for a work- around? I'll venture a few comments ... - DR is for your *SM disaster, not the clients'. Optimally, you're doing *SM DR backups/copies so that your clients expectations of what they have backed up is unaffected. (If you recover from a *SM disaster with only active files, the recovery capabilities of your clients is substantially affected!) - If all those Inactive files are really unimportant to some portion of your clients, then providing a policy or management class with fewer or no Inactives might save substantial disk space. - A copy of a backed up file takes up less space in the *SM DB than the original backup. So if you were to attack this from the copypool side, you'll do a lot more work than if you can omit some of the original backup objects from the *SM DB. - Create a report of filespaces and the number of days since each has had a backup started. You might be surprised to find substantial very old filespaces that your clients wouldn't mind deleting. (Remember that files of a filespace are only changed to Inactive and allowed to expire during a backup and that *SM never backs up a filesystem that no longer exists!) - You're really trying to solve a hardware/resource problem with a policy change. Unless you have both DR and non-DR stgpools, the DR area is not probably one where you can save disk. If you omitted all client data DR (copypools), and that saved you 20-25% of your *SM DB, would that give you enough time to correct the hardware problem? (A serious policy change such as that should be made by someone else (no matter who you are!)). - I think you'll find better result from looking seriously at your client data retention policies and backup selection. Get together with a few of your largest (*SM DB-wise) clients and see if you can meet there needs while excluding some of their files from backup. Realizing that some clients will *never* restore operating system files could have significant effect on your disk space problem. Excluding "temp" files, wherever you might find them could have a huge effect. - (This is a question to all) Does a DB dump and load have the potential of making more space available? Hope this addresses your problem a little and is helpful, wayne Wayne T. Smith [EMAIL PROTECTED] ADSM Technical Coordinator - UNET University of Maine System
Re: Size returned by q vol and q occup don't match.
Dias, Bill (GTIWHQ) wrote, in part.. Our current level of ADSM 3.1.2.50.I know, tell the bean counters. We wanted to know how much storage was being used by different parts of the system, so I wrote a PERL script to retrieve the information. For s... and giggles I added some processing for q occup. Surprise! They don't match. Ok, I understand when the sizes returned by the q vol command are smaller than the those returned by the q occup it is because tapes are checked out of the library. Most of the time the q vol size is larger than the q occup size. Why?? I would have expected equal values. Wild (completely speculation) guess: Maybe this is an artifact of "small file aggregation", where for many operations *SM treats a block of files as an entity. That is, *maybe* QUERY VOL size is measuring aggregate size, whereas QUERY OCCUP size is measuring unexpired data size. (Some of the aggregates contain expired file data). cheers, wayne Wayne T. Smith [EMAIL PROTECTED] ADSM Technical Coordinator - UNET University of Maine System
Re: no delete volume because of segment references
I recently moved my disk random access pools to new disk and met similar messages. "Audit volume xxx fix=yes" corrected the problem in once case, but had to be run twice! In another case, this did not correct the problem and MOVE DATA (to the same storage pool, with the interesting unit set to ACCESS=READONLY) also did not move all of the data. A move DATA to a different (sequential) storage pool successfully moved (3) clusters of files. I could then delete the volume(s). Hope this helps, wayne Wayne T. Smith [EMAIL PROTECTED] ADSM Technical Coordinator - UNET University of Maine System
Re: Install Custom dsm.opt
I have it working at 4.1.1.16 which I am assuming will be as in 4.1.2.12. I can verify that the 4.1.2.12 patch does allow a default DSM.OPT ... sort of. If you unpack the distributed EXE (WinZip does this easily), you can then place your DSM.OPT file in the config subdirectory. It will be used if the installer doesn't have one already. Unfortunately, if your default DSM.OPT file is used, the configuration widget is not invoked. :-( Fwiw, I also eliminated the languages I didn't need. Since I only wanted English, I also removed the language prompt by editing the SETUP.INI file. I then packaged it all up again with Installshield's Package for the Web program (or use your favorite install program builder). Hope this helps, wayne Wayne T. Smith [EMAIL PROTECTED] ADSM Technical Coordinator - UNET University of Maine System
ADSM/VM (again, still, sort of, ... give me air)
This has been a day of good news and bad. The bad news is that a storm is raging throughout the northeast. The good news is that it has apparently stopped about 10 miles south of here. 2 *feet* of snow in southern Maine; less than 2 *inches* here in the greater Bangor area. Yippee! So on to the Tivoli ADSM for VM server. I wish the news were so good. IBM has announced end of service (EOS) for 5697-VM3, the Tivoli ADSM/VM server product as 2002-03-31. Not particularly bad news, but the replacement products are 5697-TS9 or 5698-TSM, both of which are still at the V3.1 functionality for VM. Does anyone else suspect Tivoli/IBM spend more money explaining away the TSM/VM server than keeping it state of the art? VM and world technical leaders Melinda and Gretchen announce end of VM S/390 at Princeton, while countless others are forced away from a great platform by short-sighted, current customer-be-damned marketing. On a good note, a new 0101RSU is now available for the ADSM/VM server (I suggest you order UQ49135, UQ50321, UQ50322 with UQ99312). On a bad note, Tivoli seems to be asking if we really want any of the 3.7/4.1 enhancements. I applaud the requestor and spit on the company that made the request necessary. Finally, ... I must have this wrong, ... did some Tivoli person at SHARE say that the reason for moving away from S/390 servers was no SCSI support? I must have this wrong. Tivoli seems to know how to charge big bucks ... where's the money going? Can IBM management continue on the sidelines? Thanks for letting me vent ... back to work on things I can change, wayne Wayne T. Smith [EMAIL PROTECTED] ADSM Technical Coordinator - UNET University of Maine System
Re: Window Client - Time Change bug
Len kindly replied, in part.. I Think that 4.1.1 is most likely the best one at this time. That is the fixtest for 4.1.1 which is 4.1.1.16. I have found that the fixtests appear to work better then the releases with the windows nt client. Though I might select a fixtest for some backup, I don't think that I want to suggest to my customers that they should all install/upgrade to a fixtest version. Besides, won't 4.1.1.16 re-backup all my NTFS come the next time- shift? :-( Thanks for the comments and suggestions, wayne Wayne T. Smith [EMAIL PROTECTED] ADSM Technical Coordinator - UNET University of Maine System
Re: Window Client - Time Change bug
Which Windows client to distribute/install? I've been waiting and looking and waiting and looking for *many* months. If one seems just right, either you haven't looked at its known problems, or a killer problem will appear tomorrow, or you live with warts on a particular machine. I'm not sure which bothers me more: pummelling of the VM server customers or the poorly designed, implemented and tested Windows client. I used to find it unbelievable that I couldn't get an audit trail from an ad- hoc gui backup (I still do, as the backup interface has worsened in recent versions), but now that I can't find any version to recommend to all my windows users, I fear "enterprise backup" will fall by the wayside for a return to a multitude of local solutions, none of which will include Tivoli nor IBM. Suggestions most welcome, please. Wayne T. Smith [EMAIL PROTECTED] ADSM Technical Coordinator - UNET University of Maine System
Re: Tivoli response time to PMR
George Lesho [EMAIL PROTECTED] wrote, in part.. Hi Petr... the lack of response for the time you cited is far too long. Tivoli, here in the US, gets back next day usually for Level 3 email queries.. I recently used a feedback page to report a problem on the "end of currency" web page http://www.tivoli.com/support/storage_mgr/tivolieoc.html Just a few minutes later I had a response and an hour or so later a response that stated: Thanks for calling this to our attention. I'll forward a fix to the Web Team. Astounding! Of course, it's about a week later, and the web page still points an intel windows unfortunate to the alpha PTF and ftp site :-( Wayne T. Smith [EMAIL PROTECTED] ADSM Technical Coordinator - UNET University of Maine System
Re: Delete of one volume in VOLHIST
how can I delete only one volume in the VOLHIST ? I've bemoaned this deficiency myself. I do a DB Backup every n days, with at least one incremental DB Backup each day in between the full backups. Once I have a new full, I'd like to discard my incremental volhist entries (to free up limited disk; incrementals normally to disk), but that means older full DB Backup entries are discarded. cheers, wayne Wayne T. Smith [EMAIL PROTECTED] ADSM Technical Coordinator - UNET University of Maine System
Re: Volhistory file and DR
Does anyone know of a reason that I would need to send a VOLUMEHISTORY file offsite, given the above information? If you already know the DB backup volids *and* you don't free and reuse tapes between offsite "runs", I don't see the need for it. Let's say, for example, you reclaim or MOVE DATA all info from a tape, and then write on the tape. Your DB backup points to a tape that has been clobbered. Wayne T. Smith [EMAIL PROTECTED] ADSM Technical Coordinator - UNET University of Maine System
Re: Which client version is best for a Win2000-server ?
I find Wanda and Tim's lists credible. Missing from the list are a number of 4.1.2 installation issues such as disappearing include/excludes and inability to provide a tailored dsm.opt. This must be quite depressing or embarrassing to those in Tivoli that work hard to make it a good product. Maybe it's time for a new Tivoli management philosophy that supports current customer needs, not the predominantly marketing view that seems to exist now? No cheers from Maine, wayne Wayne T. Smith [EMAIL PROTECTED] ADSM Technical Coordinator - UNET University of Maine System
Re: Windows 2000 support?
Is ADSM 3.1 support Windows 2000? If I wanna to backup its system, how do I? The only clients with Windows 2000 support are 3.7 and 4.1. So if you have a supported ADSM 3.1 server, use the 3.7 or 4.1 client. If you don't have a supported 3.1 server, then you need to upgrade your server software to a supported level. Hope this helps, wayne Wayne T. Smith [EMAIL PROTECTED] ADSM Technical Coordinator - UNET University of Maine System
Re: Which client version is best for a Win2000-server ?
Gunnar wrote, in part.. Which client version is best for a Win2000-server ? I'm optimistic it will be the next one. ;-) (Both the latest 3.7 and 4.1 Win clients have 2k support). cheers, wayne Wayne T. Smith [EMAIL PROTECTED] ADSM Technical Coordinator - UNET University of Maine System
Re: Custom dsm.opt in Client v4.1.2
Thanks to Jennifer and Arthur for discussing this TSM Windows client bug. Some postings on ADSM-L last year suggest that the problem may have been around since v3.7 (but I can't verify that, as we skipped v3.7 for a number of reasons). We tailor our installables very much as Cornell does. None of files DSM.OPT, dsm.opt, ba_dsm.opt, BA_DSM.OPT nor dsm.smp in the /program files/Tivoli/TSM/config folder get copied during install of v4.1.2. No dsm.opt or dsm.new is created on install. The v4.1.2 wizards are quite wonderful compared to the 10-foot long DSMCUTIL command we used to have to force on our client operators. This tailored DSM.OPT facility is quite important to us however! Can a Tivoli person or anyone else recommend I open a PMR/APAR on the subject, or is support aware and working on the problem? Can I answer this question with a DB search someplace? Thanks, wayne Wayne T. Smith [EMAIL PROTECTED] ADSM Technical Coordinator - UNET University of Maine System
Re: Are TSM 4.1 Clients supported with the Tivoli VM (ADSM 3.1.2.50) server?
(answering my own query) ... Tivoli Support has, quite promptly, answered: The TSM 4.1.2 client is compatible with ADSM 3.1. Some functionality offered by TSM isn't available, but the client will work. IBM/Tivoli recommend you upgrade to TSM before using in a production environment, but I understand that isn't possible when using VM. Thanks to all that answered on and off the list, wayne Wayne T. Smith [EMAIL PROTECTED] ADSM Technical Coordinator - UNET University of Maine System
Re: ADSM DB Errors
[I wrote the following on 27 July, but from an ID caused the post to be rejected .. wts] Quoting Gerrit van Zyl [EMAIL PROTECTED]: Im receiving the following DB errors (during expiration and sometimes when deleting a volume) and I would like to know if a backup - delete - restore of the database will resolve this problem or a audit of the DB or any other recommendations? Aix ver 4.3.2 ADSM Server ver 3.1.2.50 ... 07/21/00 06:00:58 ANRD imutil.c(1296): Error deleting object (0 88937611) ... 07/21/00 06:28:02 ANR0104E astxn.c(1266): Error 2 deleting row from table "AS.Volume.Status". 07/21/00 06:28:02 ANR1181E astxn.c356: Data storage transaction 0:2702006 was aborted. 07/21/00 06:28:03 ANRD imexp.c(4202): Expiration Delete Transaction ... In my limited experience, (1) don't release any DB backups until this is resolved, (2) get thee to ADSM Customer support, and (3) be firm that the problem must be resolved and without a DB audit (unless you really can afford one!). This method has worked for me in the past. However, ... Unable to correct one problem (it also had "error 2 deleting row" (of same table)), I was able to bypass it by marking the tapes being used at the time of the problem as READONLY. That was back in V2, but even today if I allow ADSM 3.1.2.50 to write on any of those tapes, I still/again get this error. Guess I should follow my own advice in (2) above, but the simple bypass (in my case) makes me not want to "waste" time really correcting the DB. Hope this helps, Wayne T. Smith [EMAIL PROTECTED] ADSM Technical Coordinator - UNET University of Maine System
