Open file for TSM
Hello there, I think this question had been asked before a thousand times but being a new member to TSM, I'll still confused. TSM does not has open file option and recommend to use Open File Manager from St. Bernard Software to back up open file on NT. My question is: Does this means that TSM must use Open File Manager for a complete backup solution on NT ? The official answer from TSM is that we can use dynamic backup to backup file even if it is locked. But the result will not be guarentee. Does it means that we have to use Open File Manager to compensate it ? Does anyone use TSM alone and encounter problem on NT platform for open file ? If the answer for the second question is no, then this Open File Manager seems to be little of use. Regards William Tivoli Software, IBM Software Group, IBM China/Hong Kong Limited 11/F, PCCW Tower, Taikoo Place, 979 King's Road, Hong Kong Internet : [EMAIL PROTECTED] Tel: 2825-7613Fax: 2825-0022
Re: Reclaimable Space
Did you change the position of the write proteted litlle lable on the tape ? Sarver, Theresa (Osky Unix Administrator) [EMAIL PROTECTED] con fecha 28/12/2001 22:29:23 Por favor, responda a ADSM: Dist Stor Manager [EMAIL PROTECTED] Destinatarios: [EMAIL PROTECTED] CC: (cci: Juan Manuel Lopez Azaqon/NATIONAL) Asunto: Reclaimable Space I re-use [Magstar 3570] tapes, and sometimes Tivoli refuses the tape with the following error: 12/28/01 08:13:54 ANR2017I Administrator issued command: LABEL LIBVOLUME LIB2 2ce16c CHECKIN=SCRATCH OVERWRITE=YES 12/28/01 08:13:54 ANR0984I Process 402 for LABEL LIBVOLUME started in the BACKGROUND at 08:13:54. 12/28/01 08:13:54 ANR8799I LABEL LIBVOLUME: Operation for library LIB2 started as process 402. 12/28/01 08:13:54 ANR0609I LABEL LIBVOLUME started as process 402. 12/28/01 08:13:55 ANR8323I 050: Insert 3570 volume 2CE16C R/W into entry/exit port of library LIB2 within 60 minute(s); issue 'REPLY' along with the request ID when ready. 12/28/01 08:13:57 ANR2017I Administrator issued command: QUERY ACTLOG 12/28/01 08:14:04 ANR2017I Administrator issued command: REPLY 050 12/28/01 08:14:04 ANR8499I Command accepted. 12/28/01 08:14:20 ANR8806E Could not write volume label 2CE16C on the tape in library LIB2. 12/28/01 08:14:27 ANR8841I Remove volume from slot 31 of library LIB2 at your convenience. 12/28/01 08:14:27 ANR8802E LABEL LIBVOLUME process 402 for library 2CE16C failed. 12/28/01 08:14:27 ANR0985I Process 402 for LABEL LIBVOLUME running in the BACKGROUND completed with completion state FAILURE at 08:14:27. Does anyone have any idea why this happens, or what I can do to rectify this situation? Thank you in advance for your assistance; Theresa
Re: Restore error message
Long ago in a 3.x version there was a (client) bug that went something like... there were 4 bytes of control info, the last byte indicated if a file was compresses, routines always assumed the 4 bytes would be together within an inbound record... when the randomness of data actually split the 4 byte field across two different inbound records, garbage was loaded into the last 1, 2, or 3 bytes of the control field giving a situation such as you are seeing. In our case, the data was OK but we had to get a client fix before we could get some files back. Maybe this bug has raised its ugly little head again ! ? just FYI Dwight -Original Message- From: Gill, Geoffrey L. [mailto:[EMAIL PROTECTED]] Sent: Sunday, December 30, 2001 8:26 PM To: [EMAIL PROTECTED] Subject: Restore error message Help on a restore. I have a unix admin who sent me this message: That's right, I'm not yet sure if I really have a problem, but on 95% of the files I'm restoring for the psdev root filesystem I get the following error: File thought to be compressed was not Does this mean it was restored, but that we got an error because ADSM thought it would have to uncompress the file as it restored it and in fact didn't? Or are these files NOT being restored? I asked him some questions and have not heard back yet but I thought I'd send this off anyway. To my knowledge he is using the latest TSM client for true64, and the TSM server is AIX 4.3.3 TSM 4.2.1.8 Here are just a few of the messages from the TSM server log: 12/30/01 14:28:09 ANE4032E (Session: 7966, Node: CP-ITS-PSDEV) Error processing '/nroot/': file is not compressed. 12/30/01 14:28:09 ANE4032E (Session: 7966, Node: CP-ITS-PSDEV) Error processing '/nroot/': file is not compressed. 12/30/01 14:28:09 ANE4032E (Session: 7966, Node: CP-ITS-PSDEV) Error processing '/nroot/.sysman': file is not compressed. 12/30/01 14:28:09 ANE4032E (Session: 7966, Node: CP-ITS-PSDEV) Error processing '/nroot/.sysman': file is not compressed. 12/30/01 14:28:09 ANE4032E (Session: 7966, Node: CP-ITS-PSDEV) Error processing '/nroot/.tags': file is not compressed. Anyone seen this? Any help is appreciated. Geoff
Re: Open file for TSM
There are two variants on open file issues that are pertinent to TSM: 1) The file is open by an application, but is available for read access by other applications (such as TSM). Regardless of the TSM copy group serialization setting, TSM can back up these files. The serialization setting affects how TSM handles cases where the file has changed in the middle of backing up the file. STATIC and SHRSTATIC will not store a backup copy on the TSM server if the file changed in the middle of the backup. DYNAMIC and SHRDYNAMIC will allow a backup copy of the file to be stored on the TSM server even if the file has changed in the middle of the backup. When the file has changed in the middle of the backup, then the backup copy is often called a fuzzy backup. Thus DYNAMIC and SHRDYNAMIC will permit fuzzy backups to be stored on the TSM server. Consider: A fuzzy backup means that the file was in one state when the backup started, but in another state by the time the backup finished. As a result, the backup copy may represent an inconsistent state for the file. For certain files, such as message logs that gets appended with new messages on a regular basis, a fuzzy backup may not be a problem. For other files, such as databases, a fuzzy backup could be useless since a restore of this backup would yield an inconsistent database. Therefore, DYNAMIC or SHRDYNAMIC should be used with caution, and only for those cases where you KNOW that restore of a fuzzy backup will result in a usable file. For any file that you are unsure of, consult the owner of the file or the vendor whose application uses that file to determine the backup requirements. St. Bernard's Open File Manager can eliminate fuzzy backup issues because it not only permits access to locked files (see #2 below), but it also presents a consistent image of the file to TSM. That is, even if the file changes during the backup, Open File Manager presents TSM with the unchanged version of the file, so a consistent backup is always taken. 2) The file is open by an application for exclusive use, and is therefore unavailable for read access by any other application (i.e. the file is locked). TSM can not back up files that are locked by another application unless a product to manage open files (such as St. Bernard Software's Open File Manager) is used. If someone told you otherwise, then they are wrong: TSM can not open locked files without Open File Manager (or similar product) regardless of the serialization setting. Whether you require Open File Manager depends on your situation. In some cases, you can use the TSM PRESCHEDULECMD option to shut down applications that locks certain files before the backup starts. After the backup is complete, you can use the TSM POSTSCHEDULECMD option to restart the applications that lock the files. In other cases, you may not care if TSM can back up the file. One trivial example is the Windows pagefile.sys file. With a product like Open File Manager, you could back up pagefile.sys. However, there is no point in doing so since there is never any need to restore pagefile.sys. As to whether you need a product like Open File Manager... well, there is no simple yes or no answer. Most customers run TSM successfully without Open File Manager. You should evaluate your particular situation, i.e. use SHRSTATIC serialization, then see which files can not be backed up because they changed during backup, or were locked. Review these exceptions and evaluate your options for handling them. For some files, you may not care whether they get backed up. For files that changed during backup, determine whether DYNAMIC or SHRDYNAMIC would be appropriate, or whether you can shut down the application that uses the files before running the backup. For files that are locked but need backup, determine whether you can shut down the application that uses the files before running the backup. In the case of mission critical files for which none of these options is viable, you may need to consider using Open File Manager. Regards, Andy Andy Raibeck IBM Software Group Tivoli Storage Manager Client Development Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS Internet e-mail: [EMAIL PROTECTED] The only dumb question is the one that goes unasked. The command line is your friend. Good enough is the enemy of excellence. William SO Ng/Hong Kong/IBM@IBMHK Sent by: ADSM: Dist Stor Manager [EMAIL PROTECTED] 12/31/2001 00:39 Please respond to ADSM: Dist Stor Manager To: [EMAIL PROTECTED] cc: Subject:Open file for TSM Hello there, I think this question had been asked before a thousand times but being a new member to TSM, I'll still confused. TSM does not has open file option and recommend to use Open File Manager from St. Bernard Software to back up open file on NT. My question is: Does this means that TSM must use Open File Manager for a complete backup solution on NT ? The official answer from TSM is that we
Re: Open file for TSM
While OFM will allow open file backups from TSM's (and the backup admins) point of view, it is not a panacea for in-use files. Many applications keep data cached in memory, and neither serialization nor OFM will capture this data. As a trivial example, a user might edit an Excel spreadsheet for days on end without saving, and these mods will not be captured. Some applications (Microsoft Access, famously) allow the disk data to be stably inconsistent, so that tedious manual recovery is required after restoring the backup even if OFM is used. In many cases, good backups are obtained which, when restored, do not represent the true state of the data. As Andy points out, many applications *require* application-specific procedures to achieve usable backups. OFM is no substitute for knowing your data. _ William Mansfield Senior Consultant Solution Technology, Inc Andrew Raibeck [EMAIL PROTECTED] To: [EMAIL PROTECTED] M.COM cc: Sent by: Subject: Re: Open file for TSM ADSM: Dist Stor Manager [EMAIL PROTECTED] IST.EDU 12/31/2001 07:08 AM Please respond to ADSM: Dist Stor Manager There are two variants on open file issues that are pertinent to TSM: 1) The file is open by an application, but is available for read access by other applications (such as TSM). Regardless of the TSM copy group serialization setting, TSM can back up these files. The serialization setting affects how TSM handles cases where the file has changed in the middle of backing up the file. STATIC and SHRSTATIC will not store a backup copy on the TSM server if the file changed in the middle of the backup. DYNAMIC and SHRDYNAMIC will allow a backup copy of the file to be stored on the TSM server even if the file has changed in the middle of the backup. When the file has changed in the middle of the backup, then the backup copy is often called a fuzzy backup. Thus DYNAMIC and SHRDYNAMIC will permit fuzzy backups to be stored on the TSM server. Consider: A fuzzy backup means that the file was in one state when the backup started, but in another state by the time the backup finished. As a result, the backup copy may represent an inconsistent state for the file. For certain files, such as message logs that gets appended with new messages on a regular basis, a fuzzy backup may not be a problem. For other files, such as databases, a fuzzy backup could be useless since a restore of this backup would yield an inconsistent database. Therefore, DYNAMIC or SHRDYNAMIC should be used with caution, and only for those cases where you KNOW that restore of a fuzzy backup will result in a usable file. For any file that you are unsure of, consult the owner of the file or the vendor whose application uses that file to determine the backup requirements. St. Bernard's Open File Manager can eliminate fuzzy backup issues because it not only permits access to locked files (see #2 below), but it also presents a consistent image of the file to TSM. That is, even if the file changes during the backup, Open File Manager presents TSM with the unchanged version of the file, so a consistent backup is always taken. 2) The file is open by an application for exclusive use, and is therefore unavailable for read access by any other application (i.e. the file is locked). TSM can not back up files that are locked by another application unless a product to manage open files (such as St. Bernard Software's Open File Manager) is used. If someone told you otherwise, then they are wrong: TSM can not open locked files without Open File Manager (or similar product) regardless of the serialization setting. Whether you require Open File Manager depends on your situation. In some cases, you can use the TSM PRESCHEDULECMD option to shut down applications that locks certain files before the backup starts. After the backup is complete, you can use the TSM POSTSCHEDULECMD option to restart the applications that lock the files. In other cases, you may not care if TSM can back up the file. One trivial example is the Windows pagefile.sys file. With a product like Open File Manager, you could back up pagefile.sys. However, there is no point in doing so since there is never any need to restore pagefile.sys. As to whether you need a product like Open File Manager... well, there is no simple yes or no answer. Most customers run TSM successfully without Open File Manager. You should evaluate your particular situation, i.e. use SHRSTATIC serialization, then see which files can not be backed up because they changed during backup, or were locked. Review these exceptions and evaluate your options for handling them. For some files, you may not care whether they get
ANRPLANX on OS/390 server
We are currently running TSM 4.1.4.2 on our OS/390 system. We need to enlarge the recovery plan files. I've found the ANRPLANX member in SAMPLIB. Do I just have to run the rexx exec once to update the server or do I need to modify my startup jcl so TSM will invoke the modified ANRPLANX every time I issue the PREPARE? -- Roger Monteith University of North Carolina [EMAIL PROTECTED] (919) 962-2447
Re: Restore Rights
On a UNIX client, if you give them permissions to run dsmc, the only files they have access to are their own. Or the files they normally have permissions too to on the client. They cannot pull back root access only files, etc. This is what I have experienced. I am not sure of any holes or the extent this works with Novell. Loggin as the user and test this out for Novell. Jeff Bach -Original Message- From: Bruce Kamp [SMTP:[EMAIL PROTECTED]] Sent: Friday, December 28, 2001 8:03 AM To: [EMAIL PROTECTED] Subject: Restore Rights Is there a way to give a person rights to olny restore 1 directory on a file server? I'm running TSM 4.1.3 on AIX node is Netware 4.11. Thanks, --- Bruce D. Kamp Network Analyst II Memorial Healthcare System P:(954) 987-2020 x6008 E: [EMAIL PROTECTED] ** This email and any files transmitted with it are confidential and intended solely for the individual or entity to whom they are addressed. If you have received this email in error destroy it immediately. **
Re: ATL P2000 dlt 7000 question
I have not looked at them yet, I beleive it is only a few/one or two. I have asked the operators to note which ones they are to see if it happens to the same ones. Paul -Original Message- From: Robin Sharpe [SMTP:[EMAIL PROTECTED]] Sent: Friday, December 28, 2001 10:49 PM To: [EMAIL PROTECTED] Subject: Re: ATL P2000 dlt 7000 question Hey Paul, Is this happening on many carts or just a few (or just one)? Have you looked at it... maybe it's broke! Robin Sharpe Berlex Labs Coviello, Paul PCoviello@CM To:[EMAIL PROTECTED] C-NH.ORG cc:(bcc: Robin Sharpe/WA/USR/SHG) Subject: 12/28/01 Re: ATL P2000 dlt 7000 question 01:03 PM Please respond to ADSM: Dist Stor Manager ok I guess I spaced it sorry, a lot is going on. anyways it is very intermittent. I say it is impossible the ATL tech also has said it shouldn't be happening but the operators swear that it is. of course I have no idea how they are put in, or wether there are gremlins involved :-) thanks Paul -Original Message- From: Zlatko Krastev/ACIT [SMTP:[EMAIL PROTECTED]] Sent: Thursday, December 27, 2001 7:31 PM To: [EMAIL PROTECTED] Subject: Re: ATL P2000 dlt 7000 question I also remeber such problem so have searched through my mail list archive folder and really found a thread P2000 questions on 14.09 started by ... Coviello, Paul [EMAIL PROTECTED] and answered by ... Robin Sharpe [EMAIL PROTECTED] :-))) And guess what - the subject was slightly different but the problem was the same, the hint was same :-) Paul, since September did the problem disappeared by itself, is it rarely occuring or was resolved but happened again with no same resolution? Zlatko Krastev IT Consultant Robin Sharpe [EMAIL PROTECTED] on 27.12.2001 22:19:27 Please respond to ADSM: Dist Stor Manager [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: Subject:Re: ATL P2000 dlt 7000 question Paul, I remember this same topic being discussed several months ago... I thought it was impossible... how can the library move the slider on the cartridge!? We have a P3000 and have never seen this happen. I don't remember the resolution from that last discussion (or if there was one)... but I'll say again what I said then... call ATL tech support! They are usually pretty helpful. Robin Sharpe Berlex Labs Coviello, Paul PCoviello@CM To:[EMAIL PROTECTED] C-NH.ORG cc:(bcc: Robin Sharpe/WA/USR/SHG) Subject: 12/24/01 ATL P2000 dlt 7000 question 12:40 PM Please respond to ADSM: Dist Stor Manager Hi we have an ATL P2000 with 4 dlt7000's 100 tape capacity. the operations group is seeing DLT tapes coming out of the library write protected. Would anyone care to guess at this? because I can't even come up with a rational explanation nor logical one. :-) I have asked if it is the same tapes, ( going thru list this week) thinking they might have a bad switch but then what moves it! thanks Paul Paul J Coviello Sr Systems Analyst Catholic Medical Center 2456 Brown Ave Manchester NH 03103 (603) 663-5326 [EMAIL PROTECTED]
Re: Please Explain (again)
Well, how to lookup individual sessions: The short answer is SELECT * FROM SUMMARY WHERE ENTITY='nodename' AND ACTIVITY='BACKUP' Multi streamed backups are a great enhancement, but there are some subtleties. With a single streamed backup, you have one session and one statistics report on standard output (if running from a script). If running from a unixcommand line it comes out on your terminal screen. If running from a GUI it is in a window, but has a slightly different format (if I remember correctly). With a multi streamed backup, you have several sessions, as you have stated. But you still get a single statistics report. In the GUI you can see the individual sessions, but on the command line version, there is no indication that it's a multi stream. And this where I think the problem lies. So, when you do the select from summary, you should get several records that start at the same time (or thereabouts). These would be the sessions that make up the multi streamed backup. I think you have to calculate the elapsed time (end-start)... For the ***FLASH*** light bulb just went on over my head! This is why it isn't accurate: Each session on a multi stream backup will be a different elapsed time (probably). Since they are running concurrently, the elapsed time for the backup is of course the end time of the latest session minus the start time of the earliest. But each session has a data transfer time that may mor may not overlap the other sessions. The total data transfer is the sum of those of each session... so it could conceivably be more than the elapsed time. Still doesn't seem to make sense though (light bulb is dimming now and less than an hour of 2001 remains!) I'm really getting curious about this now... guess I'll have to do some tests when I get back to work on Wednesday. Hope everyone has a Safe Happy New Year! Robin Sharpe Berlex Labs Miles Purdy PURDYM@FIPD. GC.CATo:[EMAIL PROTECTED] cc:(bcc: Robin Sharpe/WA/USR/SHG) 12/30/01 Subject: 10:25 AM Re: Please Explain (again) Please respond to ADSM: Dist Stor Manager Hi guys, I do not think any times are wrong nor is there a bug, see example. PS: How do I look up individual sessions for a given backup? Example: Here's how I thought the numbers were arrived at: say processing starts at time zero and runs for 1 hour, 3600 s, just to make it easy, and we backup 100 GB. We also use two streams 50 GB total each, and they run concurrently. %75 of the time is spent sending data, %25 processing overhead. So: total time: 3600 s total bytes: 100 GB aggregate is: 100 * 1024 mb / 3600 = 28 MB /s data transfer time: .75 * 3600 * 2 = 5400 s network throughput is: 100 * 1024 / 5400 = 18 MB / s I think what I meant to say was the network pipe is really _wide_. The network can sustain multiple streams running at full speed. The limiting speed factor may be the server or it may be the network, but I don't think it matters where the speed bottleneck is. So I still don't think it is a bug. Miles -- Miles Purdy System Manager Farm Income Programs Directorate Winnipeg, MB, CA [EMAIL PROTECTED] ph: (204) 984-1602 fax: (204) 983-7557 If you hold a UNIX shell up to your ear, can you hear the C? - [EMAIL PROTECTED] 28-Dec-01 9:56:57 PM As I said a while ago, I think it's a bug. I'm guessing that this is a multi stream backup (I think that has already been established), and the data transfer time is the total of all of the sessions, but the elapsed time is for only one session... can you confirm that Miles? Hopefully you still have records for those sessions in the summary table. Robin Sharpe Berlex Labs Zlatko Krastev/ACIT acit@ATTGLOB To:[EMAIL PROTECTED] AL.NET cc:(bcc: Robin Sharpe/WA/USR/SHG) Subject: 12/27/01 Re: Please Explain (again) 07:30 PM Please respond to ADSM: Dist Stor Manager Sorry, I am taking my words back. Have a look again at the times reported Data transfer time: 8 261.61 sec Elapsed processing time: 01:25:00 This 8261 seconds is definitely much more than 1h25m (5100s) and one of the times is erroneous. Divided by wrong value you're getting one of the rates wrong. Zlatko Krastev IT Consultant Zlatko [EMAIL PROTECTED] 22.12.2001 23:55 Sent by:Zlatko Krastev/ACIT[EMAIL PROTECTED] To:
