3570 Library Question
Hi, I'v got a question about the IBM3570 Library on a RS/6000 server. The library is able to push the tapes further in the slots than the standard place, further to the door. The tapes are in that case checked out. I saw it happend in the full-automatic mode of the library. Now the library is in control by TSM, i want that it can do the same thing. In stat of using the input/output, i want to checkout the tapes by push the tapes to the door, so i can checkout more than one tape and i can see which tapes are checked out. TSM is not able to do this. I tried to find a way that AIX can do it for me, but i'm not succesful. I tried tapeutil, and don't know any other util. who can do this for me. Does anybody knows the answer? TIA, Maurice van 't Loo The Netherlands
Offsite tapes
I backed up the primary stg pools to copy pools for offsite backups. I ejected the tapes from copy pools and sent to offsite. How can i determine the tapes to be returned from offsite in order to use again? The access type of the volumes were set to offsite after ejecting from the tapes library. Any help from you is really appreciated, thanks. Zosimo Noriega A D N O C IST-ITD DMSS Tel - 6024987
Re: Slow Restores on Netware
On Tue, 28 Aug 2001 09:40:11 -0700, Bill Boyer wrote: >Are you compressing the Netware volume? If the Netware is compressed at the volume level, there is no compression going on during the file transfers to or from TSM. The very nature of the volume strucutre itself is compressed, and puts no compression stress on either the client or TSM server. -- Mark Stapleton ([EMAIL PROTECTED])
Re: Slow Restores on Netware
On Mon, 27 Aug 2001 21:49:52 -0500, you wrote: >Is it me or is a restore of Netware data slow? I get at best 5.6g per >hour off of a 21g per hour drive. TSM backs it up fast but takes way >to long to restore. Does anyone else have this problem and if so what >do you do? Rather than just shrugging and saying "Netware", I'd like to offer more useful dialog. Not knowing what your network is like, I'd say that a 5GB+/hour restore on Netware is pretty damn good, considering that Netware, like Windows, is comprised of a zillion small files and a rather convoluted directory structure. It takes a while for those Intel-dependent OSs a while to rebuild file structures. -- Mark Stapleton ([EMAIL PROTECTED])
Re: Turning off migration and reclamation
On Mon, 27 Aug 2001 14:47:41 -0600, you wrote: >I am new to TSM. In the OS/390 Administrator's Guide, it recommends >that you turn off migration and reclamation while you backup the >database. Is there any other way to do this besides setting the HIGHMIG >and RECLAIM parameters on each storage pool to 100 and then resetting >them back to the original percentages after the backup is done? Sounds like a winner to me. (Do you really leave migration and reclamation running by default?) -- Mark Stapleton ([EMAIL PROTECTED])
Re: NT Journal Backups
As i know, journal file systems and journal services are completly different. A journal file systems works with his filesystems like a database, put the changes in a log, make the changes and if succesfull, delete the record from the log. If the OS crashes during a write action, your filesystem can survive. The journal service makes a list of the files that are changed. So, if you do a backup, it looks into the list and does a backup of that files. The client don't needs to check the whole filesystem anymore to see which files are changed. If you have a NT of W2k fileserver with over a million files, the backuptime could be down from jl. 4 hours to an half hour. Greetings, Maurice van 't Loo Compare Computers The Netherlands - Original Message - From: "Andrew Webster" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, August 31, 2001 9:47 AM Subject: NT Journal Backups > Been reading up on 4.2 Journal Backups. > > Windows 2000 provides a journal file system (NTFS 5) but the TSM 4.2 client doesn't use it. (as I understand it) Instead it implements it owns journal service (daemon) that monitors the filesystems and updates a database when it changes. This seems odd, when NTFS 5 supports journaling and has an associated API. > > Can someone from Tivoli explain why the client was implemented this way? > > Regards > > Andrew Webster
Re: Cannot delete tape in empty status... media state is incorrect
Did you already try to label the tape again with an 'overwrite=yes' ? Greetings, Maurice
Re: Question regarding exclude.list
The list is in the right order, but you forget the subdir's exclude /usr/* excludes all files in this dir, but not in the dirs under that. So: exclude /usr/.../* include/usr/local/.../* exclude /tmp/* or: exclude.dir /usr/ include /usr/local/.../* exclude.dir /tmp/ Greetings, Maurice van 't Loo Compare Computers The Netherlands - Original Message - From: "James, Doug" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, August 31, 2001 10:24 PM Subject: Question regarding exclude.list > I have a problem with the exclude list on a UNIX server. I have the > information, below, but it boils down to why is TSM backing up files that > are supposed to be excluded? > > > dsm.opt file contents (all commented out) > * SErvername A server name defined in the dsm.sys file > *SErvername tsmtest > *domain /spdata /tftpboot /var/adm/csd > *domain /spdata /tftpboot /dbbackup0 /u09 > *domain /dbbackup1 /dbbackup2 /dbbackup3 /dbbackup4 /dbbackup5 > /dbbackup6 /d > > exclude.list file contents > exclude /usr/* > include /usr/local/* > exclude /tmp/* > > From the server dsmc prompt, executed " inc /usr ". I expected files under > " /usr/local/* " to be backed up, and all others to be excluded. Instead, > all files under " /usr " were backed up (see below). What did I do wrong? > > Normal File--> 5,157 /usr/websm/html/images/wsmMasthead.gif > [Sent] > Directory--> 512 /usr/websm/lib/perl5 [Sent] > Normal File--> 630,103 /usr/websm/lib/libwebsm.so [Sent] > Directory--> 512 /usr/websm/lib/perl5/SWM [Sent] > Normal File--> 199,133 /usr/websm/lib/perl5/SWM/Swm.pm [Sent] > Normal File-->10,587 /usr/websm/lib/perl5/SWM/SwmDefault.pm > [Sent] > Successful incremental backup of '/usr' > > Total number of objects inspected: 52,615 > Total number of objects backed up: 32,040 > Total number of objects updated: 0 > Total number of objects rebound: 0 > Total number of objects deleted: 0 > Total number of objects expired: 0 > Total number of objects failed: 0 > Total number of bytes transferred: 415.11 MB > Data transfer time: 262.68 sec > Network data transfer rate:1,618.23 KB/sec > Aggregate data transfer rate:729.37 KB/sec > Objects compressed by: 37% > Elapsed processing time: 00:09:42 > > > > > Blue Cross Blue Shield of Florida, Inc., and its subsidiary and > affiliate companies are not responsible for errors or omissions in this e-mail message. Any personal comments made in this e-mail do not reflect the views of Blue Cross Blue Shield of Florida, Inc. >
