Re: TSM trying to backup its own, open files..........
How does it know it is really its own file? You have to exclude it if you do not want TSM to try. -Original Message- From: Zoltan Forray/AC/VCU [mailto:[EMAIL PROTECTED]] Sent: Friday, February 22, 2002 9:30 AM To: [EMAIL PROTECTED] Subject: TSM trying to backup its own, open files.. Why is TSM trying to backup its own, open files ? I thought it was smart enough to not do this ? I am getting this error message from an NT 6a node ! The client is 4.2.1.20 02/21/2002 20:47:46 ANE4037E (Session: 11678, Node: INFO-OFFICE) File '\\info-office_vcu\c$\Program Files\Tivoli\TSM\baclient\dsmsched.log' changed during processing. File skipped. Also, what is wrong with this exclude statement in my client options file: Exclude *:\WINNT\Profiles\* I get these errors: 02/21/2002 20:49:54 Retry # 1 Normal File-- 1,024 \\info-office_vcu\c$\WINNT\Profiles\Administrator\ntuser.dat.LOG ** Unsuccessful ** Zoltan Forray Virginia Commonwealth University - University Computing Center e-mail: [EMAIL PROTECTED] - voice: 804-828-4807
Re: TSM trying to backup its own, open files..........
Hi Zoltan! As far as I know TSM did always backup it's own logfile, unless you explicitly tell it not to. As for your exclude: change it into *:\WINNT\Profiles\...\* Kindest regards, Eric van Loon KLM Royal Dutch Airlines -Original Message- From: Zoltan Forray/AC/VCU [mailto:[EMAIL PROTECTED]] Sent: Friday, February 22, 2002 15:30 To: [EMAIL PROTECTED] Subject: TSM trying to backup its own, open files.. Why is TSM trying to backup its own, open files ? I thought it was smart enough to not do this ? I am getting this error message from an NT 6a node ! The client is 4.2.1.20 02/21/2002 20:47:46 ANE4037E (Session: 11678, Node: INFO-OFFICE) File '\\info-office_vcu\c$\Program Files\Tivoli\TSM\baclient\dsmsched.log' changed during processing. File skipped. Also, what is wrong with this exclude statement in my client options file: Exclude *:\WINNT\Profiles\* I get these errors: 02/21/2002 20:49:54 Retry # 1 Normal File-- 1,024 \\info-office_vcu\c$\WINNT\Profiles\Administrator\ntuser.dat.LOG ** Unsuccessful ** Zoltan Forray Virginia Commonwealth University - University Computing Center e-mail: [EMAIL PROTECTED] - voice: 804-828-4807 ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. **
Re: TSM trying to backup its own, open files..........
Because it has it open ? My real issue is why this only occurs on *1* node ? Seay, Paul [EMAIL PROTECTED] Sent by: ADSM: Dist Stor Manager [EMAIL PROTECTED] 02/22/2002 09:32 AM Please respond to ADSM: Dist Stor Manager To: [EMAIL PROTECTED] cc: Subject:Re: TSM trying to backup its own, open files.. How does it know it is really its own file? You have to exclude it if you do not want TSM to try. -Original Message- From: Zoltan Forray/AC/VCU [mailto:[EMAIL PROTECTED]] Sent: Friday, February 22, 2002 9:30 AM To: [EMAIL PROTECTED] Subject: TSM trying to backup its own, open files.. Why is TSM trying to backup its own, open files ? I thought it was smart enough to not do this ? I am getting this error message from an NT 6a node ! The client is 4.2.1.20 02/21/2002 20:47:46 ANE4037E (Session: 11678, Node: INFO-OFFICE) File '\\info-office_vcu\c$\Program Files\Tivoli\TSM\baclient\dsmsched.log' changed during processing. File skipped. Also, what is wrong with this exclude statement in my client options file: Exclude *:\WINNT\Profiles\* I get these errors: 02/21/2002 20:49:54 Retry # 1 Normal File-- 1,024 \\info-office_vcu\c$\WINNT\Profiles\Administrator\ntuser.dat.LOG ** Unsuccessful ** Zoltan Forray Virginia Commonwealth University - University Computing Center e-mail: [EMAIL PROTECTED] - voice: 804-828-4807
Re: TSM trying to backup its own, open files..........
Try: Exclude *:\WINNT\Profiles\...\* -Original Message- From: Zoltan Forray/AC/VCU [SMTP:[EMAIL PROTECTED]] Sent: Friday, February 22, 2002 6:30 AM To: [EMAIL PROTECTED] Subject:TSM trying to backup its own, open files.. Why is TSM trying to backup its own, open files ? I thought it was smart enough to not do this ? I am getting this error message from an NT 6a node ! The client is 4.2.1.20 02/21/2002 20:47:46 ANE4037E (Session: 11678, Node: INFO-OFFICE) File '\\info-office_vcu\c$\Program Files\Tivoli\TSM\baclient\dsmsched.log' changed during processing. File skipped. Also, what is wrong with this exclude statement in my client options file: Exclude *:\WINNT\Profiles\* I get these errors: 02/21/2002 20:49:54 Retry # 1 Normal File-- 1,024 \\info-office_vcu\c$\WINNT\Profiles\Administrator\ntuser.dat.LOG ** Unsuccessful ** Zoltan Forray Virginia Commonwealth University - University Computing Center e-mail: [EMAIL PROTECTED] - voice: 804-828-4807
Re: TSM trying to backup its own, open files..........
Thanks for the suggestion on the EXCLUDE statement. As for the error, this node is the only one that issues this error message ? There are plenty of other NT/W2K clients and none of them exclude the TIVOLI\TSM directory ? So why the error message from this node ? Loon, E.J. van - SPLXM [EMAIL PROTECTED] Sent by: ADSM: Dist Stor Manager [EMAIL PROTECTED] 02/22/2002 09:43 AM Please respond to ADSM: Dist Stor Manager To: [EMAIL PROTECTED] cc: Subject:Re: TSM trying to backup its own, open files.. Hi Zoltan! As far as I know TSM did always backup it's own logfile, unless you explicitly tell it not to. As for your exclude: change it into *:\WINNT\Profiles\...\* Kindest regards, Eric van Loon KLM Royal Dutch Airlines -Original Message- From: Zoltan Forray/AC/VCU [mailto:[EMAIL PROTECTED]] Sent: Friday, February 22, 2002 15:30 To: [EMAIL PROTECTED] Subject: TSM trying to backup its own, open files.. Why is TSM trying to backup its own, open files ? I thought it was smart enough to not do this ? I am getting this error message from an NT 6a node ! The client is 4.2.1.20 02/21/2002 20:47:46 ANE4037E (Session: 11678, Node: INFO-OFFICE) File '\\info-office_vcu\c$\Program Files\Tivoli\TSM\baclient\dsmsched.log' changed during processing. File skipped. Also, what is wrong with this exclude statement in my client options file: Exclude *:\WINNT\Profiles\* I get these errors: 02/21/2002 20:49:54 Retry # 1 Normal File-- 1,024 \\info-office_vcu\c$\WINNT\Profiles\Administrator\ntuser.dat.LOG ** Unsuccessful ** Zoltan Forray Virginia Commonwealth University - University Computing Center e-mail: [EMAIL PROTECTED] - voice: 804-828-4807 ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. **
Re: TSM trying to backup its own, open files..........
I find it useful to have the dsmsched.log file backed up. That way if I have a user turn up with no backups for something after a system crash, I can pull down the dsmsched.log from the TSM backups and see why (believe me, it has happened before!) SO instead of excluding the dsmsched.log, I bind it to a management class that specifies SERIALIZATION=SHRDYNAMIC. That tells TSM to go ahead and back it up, whether it's changing or not. (My management class name for this is CHANGING, so to bind the file to that ruleset, you specify: INCLUDE *:\...\dsmsched.log CHANGING in your dsm.opt file, or the appropriate client option set) We use the same technique for other sequential log files; then you get a backup of whatever is in there, up to the last few lines. Do NOT use this technique for data bases, where change can occur in the middle of the file. It also won't work where the error is due to the file being LOCKED, rather than being open for output. Just another idea.. Wanda Prather The Johns Hopkins Applied Physics Lab 443-778-8769 [EMAIL PROTECTED] Intelligence has much less practical application than you'd think - Scott Adams/Dilbert -Original Message- From: Seay, Paul [mailto:[EMAIL PROTECTED]] Sent: Friday, February 22, 2002 9:32 AM To: [EMAIL PROTECTED] Subject: Re: TSM trying to backup its own, open files.. How does it know it is really its own file? You have to exclude it if you do not want TSM to try. -Original Message- From: Zoltan Forray/AC/VCU [mailto:[EMAIL PROTECTED]] Sent: Friday, February 22, 2002 9:30 AM To: [EMAIL PROTECTED] Subject: TSM trying to backup its own, open files.. Why is TSM trying to backup its own, open files ? I thought it was smart enough to not do this ? I am getting this error message from an NT 6a node ! The client is 4.2.1.20 02/21/2002 20:47:46 ANE4037E (Session: 11678, Node: INFO-OFFICE) File '\\info-office_vcu\c$\Program Files\Tivoli\TSM\baclient\dsmsched.log' changed during processing. File skipped. Also, what is wrong with this exclude statement in my client options file: Exclude *:\WINNT\Profiles\* I get these errors: 02/21/2002 20:49:54 Retry # 1 Normal File-- 1,024 \\info-office_vcu\c$\WINNT\Profiles\Administrator\ntuser.dat.LOG ** Unsuccessful ** Zoltan Forray Virginia Commonwealth University - University Computing Center e-mail: [EMAIL PROTECTED] - voice: 804-828-4807
Re: TSM trying to backup its own, open files..........
Zoltan, It's simply a timing and resource issue from client to client. The file is certainly being updated by dsmc during the scheduled backup - if dsmc flushes text to the file during the time it's moving it, you get the error. It can depend on aggregate size, size of the dsmsched.log file, and probably a lot of other things. Not worth loosing sleep over, though. When I run into a situation where someone wants to keep the contents of dsmsched.log (rather than excluding it), I create a new management class (usually named DYNAMIC) with dynamic serialization set in the backup copygroup and include the dsmsched.log file to that management class. Bill Smoldt STORServer, Inc. -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of Zoltan Forray/AC/VCU Sent: Friday, February 22, 2002 8:01 AM To: [EMAIL PROTECTED] Subject: Re: TSM trying to backup its own, open files.. Because it has it open ? My real issue is why this only occurs on *1* node ? Seay, Paul [EMAIL PROTECTED] Sent by: ADSM: Dist Stor Manager [EMAIL PROTECTED] 02/22/2002 09:32 AM Please respond to ADSM: Dist Stor Manager To: [EMAIL PROTECTED] cc: Subject:Re: TSM trying to backup its own, open files.. How does it know it is really its own file? You have to exclude it if you do not want TSM to try. -Original Message- From: Zoltan Forray/AC/VCU [mailto:[EMAIL PROTECTED]] Sent: Friday, February 22, 2002 9:30 AM To: [EMAIL PROTECTED] Subject: TSM trying to backup its own, open files.. Why is TSM trying to backup its own, open files ? I thought it was smart enough to not do this ? I am getting this error message from an NT 6a node ! The client is 4.2.1.20 02/21/2002 20:47:46 ANE4037E (Session: 11678, Node: INFO-OFFICE) File '\\info-office_vcu\c$\Program Files\Tivoli\TSM\baclient\dsmsched.log' changed during processing. File skipped. Also, what is wrong with this exclude statement in my client options file: Exclude *:\WINNT\Profiles\* I get these errors: 02/21/2002 20:49:54 Retry # 1 Normal File-- 1,024 \\info-office_vcu\c$\WINNT\Profiles\Administrator\ntuser.dat.LOG ** Unsuccessful ** Zoltan Forray Virginia Commonwealth University - University Computing Center e-mail: [EMAIL PROTECTED] - voice: 804-828-4807
Re: TSM trying to backup its own, open files..........
Zoltan Forray/AC/VCU wrote: Why is TSM trying to backup its own, open files ? I thought it was smart enough to not do this ? I am getting this error message from an NT 6a node ! The client is 4.2.1.20 02/21/2002 20:47:46 ANE4037E (Session: 11678, Node: INFO-OFFICE) File '\\info-office_vcu\c$\Program Files\Tivoli\TSM\baclient\dsmsched.log' changed during processing. File skipped. Hello, maybe your Copy Serialization. ... for the used backup ManagementClass is set to Static and you may try a shared dynamic if you want so. You can check the setting this with a query copy DOMAINNAME active MANAGEMENTCLASSNAME t=backup f=d Also, what is wrong with this exclude statement in my client options file: Exclude *:\WINNT\Profiles\* I get these errors: 02/21/2002 20:49:54 Retry # 1 Normal File-- 1,024 \\info-office_vcu\c$\WINNT\Profiles\Administrator\ntuser.dat.LOG ** Unsuccessful ** Zoltan Forray Virginia Commonwealth University - University Computing Center e-mail: [EMAIL PROTECTED] - voice: 804-828-4807
Re: TSM trying to backup its own, open files..........
Are your client options file consistent across your environment? Check include/exclude statements are consistent and also the location of you schedule file. Zoltan Forray/AC/VCU [EMAIL PROTECTED] Sent by: ADSM: Dist Stor Manager [EMAIL PROTECTED] 22-Feb-2002 15:07 Please respond to ADSM: Dist Stor Manager [EMAIL PROTECTED] To: ADSM-L cc: Subject:Re: TSM trying to backup its own, open files.. Thanks for the suggestion on the EXCLUDE statement. As for the error, this node is the only one that issues this error message ? There are plenty of other NT/W2K clients and none of them exclude the TIVOLI\TSM directory ? So why the error message from this node ? Loon, E.J. van - SPLXM [EMAIL PROTECTED] Sent by: ADSM: Dist Stor Manager [EMAIL PROTECTED] 02/22/2002 09:43 AM Please respond to ADSM: Dist Stor Manager To: [EMAIL PROTECTED] cc: Subject:Re: TSM trying to backup its own, open files.. Hi Zoltan! As far as I know TSM did always backup it's own logfile, unless you explicitly tell it not to. As for your exclude: change it into *:\WINNT\Profiles\...\* Kindest regards, Eric van Loon KLM Royal Dutch Airlines -Original Message- From: Zoltan Forray/AC/VCU [mailto:[EMAIL PROTECTED]] Sent: Friday, February 22, 2002 15:30 To: [EMAIL PROTECTED] Subject: TSM trying to backup its own, open files.. Why is TSM trying to backup its own, open files ? I thought it was smart enough to not do this ? I am getting this error message from an NT 6a node ! The client is 4.2.1.20 02/21/2002 20:47:46 ANE4037E (Session: 11678, Node: INFO-OFFICE) File '\\info-office_vcu\c$\Program Files\Tivoli\TSM\baclient\dsmsched.log' changed during processing. File skipped. Also, what is wrong with this exclude statement in my client options file: Exclude *:\WINNT\Profiles\* I get these errors: 02/21/2002 20:49:54 Retry # 1 Normal File-- 1,024 \\info-office_vcu\c$\WINNT\Profiles\Administrator\ntuser.dat.LOG ** Unsuccessful ** Zoltan Forray Virginia Commonwealth University - University Computing Center e-mail: [EMAIL PROTECTED] - voice: 804-828-4807 ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. **
Re: TSM trying to backup its own, open files..........
Thank you and others for the clue. I had forgot about checking the backup copy group for this node (it has its own while most others share common ones). The mode was set to SHRSTATIC vs SHRDYNAMIC (not sure why since everything else is SHRDYNAMIC ??). I have fixed and activated. This should fix it. Again, thanks everyone.. Zoltan Forray Virginia Commonwealth University - University Computing Center e-mail: [EMAIL PROTECTED] - voice: 804-828-4807 Prather, Wanda [EMAIL PROTECTED] Sent by: ADSM: Dist Stor Manager [EMAIL PROTECTED] 02/22/2002 10:04 AM Please respond to ADSM: Dist Stor Manager To: [EMAIL PROTECTED] cc: Subject:Re: TSM trying to backup its own, open files.. I find it useful to have the dsmsched.log file backed up. That way if I have a user turn up with no backups for something after a system crash, I can pull down the dsmsched.log from the TSM backups and see why (believe me, it has happened before!) SO instead of excluding the dsmsched.log, I bind it to a management class that specifies SERIALIZATION=SHRDYNAMIC. That tells TSM to go ahead and back it up, whether it's changing or not. (My management class name for this is CHANGING, so to bind the file to that ruleset, you specify: INCLUDE *:\...\dsmsched.log CHANGING in your dsm.opt file, or the appropriate client option set) We use the same technique for other sequential log files; then you get a backup of whatever is in there, up to the last few lines. Do NOT use this technique for data bases, where change can occur in the middle of the file. It also won't work where the error is due to the file being LOCKED, rather than being open for output. Just another idea.. Wanda Prather The Johns Hopkins Applied Physics Lab 443-778-8769 [EMAIL PROTECTED] Intelligence has much less practical application than you'd think - Scott Adams/Dilbert -Original Message- From: Seay, Paul [mailto:[EMAIL PROTECTED]] Sent: Friday, February 22, 2002 9:32 AM To: [EMAIL PROTECTED] Subject: Re: TSM trying to backup its own, open files.. How does it know it is really its own file? You have to exclude it if you do not want TSM to try. -Original Message- From: Zoltan Forray/AC/VCU [mailto:[EMAIL PROTECTED]] Sent: Friday, February 22, 2002 9:30 AM To: [EMAIL PROTECTED] Subject: TSM trying to backup its own, open files.. Why is TSM trying to backup its own, open files ? I thought it was smart enough to not do this ? I am getting this error message from an NT 6a node ! The client is 4.2.1.20 02/21/2002 20:47:46 ANE4037E (Session: 11678, Node: INFO-OFFICE) File '\\info-office_vcu\c$\Program Files\Tivoli\TSM\baclient\dsmsched.log' changed during processing. File skipped. Also, what is wrong with this exclude statement in my client options file: Exclude *:\WINNT\Profiles\* I get these errors: 02/21/2002 20:49:54 Retry # 1 Normal File-- 1,024 \\info-office_vcu\c$\WINNT\Profiles\Administrator\ntuser.dat.LOG ** Unsuccessful ** Zoltan Forray Virginia Commonwealth University - University Computing Center e-mail: [EMAIL PROTECTED] - voice: 804-828-4807
Re: TSM trying to backup its own, open files..........
Zoltan, Shared Dynamic is a very powerful and very dangerous serialization option. Please make certain that the person who made the decision to use that understands the implications. This serialization option will try to back up a file 4 times and then save the file on the first try during which the file contents didn't change. The danger comes with files that continually change and potentially with applications that require multiple files to be synchronized, like databases. Net result - you may or may not be able to accurately restore those applications. The normal and accepted setting is Shared Static, as you had with the problem client. So you were fixing the one client that was configured properly when you should fix all the others. This will give an error if the file changes on all four attempts so that a human can decide what to do with the application backup. If your university IT personnel understand the implications of Shared Dynamic and choose to live with the restore consequences, then you can take the rest of the day off. Otherwise, you may have a short weekend. ;-) Bill Smoldt STORServer, Inc. -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of Zoltan Forray/AC/VCU Sent: Friday, February 22, 2002 8:50 AM To: [EMAIL PROTECTED] Subject: Re: TSM trying to backup its own, open files.. Thank you and others for the clue. I had forgot about checking the backup copy group for this node (it has its own while most others share common ones). The mode was set to SHRSTATIC vs SHRDYNAMIC (not sure why since everything else is SHRDYNAMIC ??). I have fixed and activated. This should fix it. Again, thanks everyone.. Zoltan Forray Virginia Commonwealth University - University Computing Center e-mail: [EMAIL PROTECTED] - voice: 804-828-4807 Prather, Wanda [EMAIL PROTECTED] Sent by: ADSM: Dist Stor Manager [EMAIL PROTECTED] 02/22/2002 10:04 AM Please respond to ADSM: Dist Stor Manager To: [EMAIL PROTECTED] cc: Subject:Re: TSM trying to backup its own, open files.. I find it useful to have the dsmsched.log file backed up. That way if I have a user turn up with no backups for something after a system crash, I can pull down the dsmsched.log from the TSM backups and see why (believe me, it has happened before!) SO instead of excluding the dsmsched.log, I bind it to a management class that specifies SERIALIZATION=SHRDYNAMIC. That tells TSM to go ahead and back it up, whether it's changing or not. (My management class name for this is CHANGING, so to bind the file to that ruleset, you specify: INCLUDE *:\...\dsmsched.log CHANGING in your dsm.opt file, or the appropriate client option set) We use the same technique for other sequential log files; then you get a backup of whatever is in there, up to the last few lines. Do NOT use this technique for data bases, where change can occur in the middle of the file. It also won't work where the error is due to the file being LOCKED, rather than being open for output. Just another idea.. Wanda Prather The Johns Hopkins Applied Physics Lab 443-778-8769 [EMAIL PROTECTED] Intelligence has much less practical application than you'd think - Scott Adams/Dilbert -Original Message- From: Seay, Paul [mailto:[EMAIL PROTECTED]] Sent: Friday, February 22, 2002 9:32 AM To: [EMAIL PROTECTED] Subject: Re: TSM trying to backup its own, open files.. How does it know it is really its own file? You have to exclude it if you do not want TSM to try. -Original Message- From: Zoltan Forray/AC/VCU [mailto:[EMAIL PROTECTED]] Sent: Friday, February 22, 2002 9:30 AM To: [EMAIL PROTECTED] Subject: TSM trying to backup its own, open files.. Why is TSM trying to backup its own, open files ? I thought it was smart enough to not do this ? I am getting this error message from an NT 6a node ! The client is 4.2.1.20 02/21/2002 20:47:46 ANE4037E (Session: 11678, Node: INFO-OFFICE) File '\\info-office_vcu\c$\Program Files\Tivoli\TSM\baclient\dsmsched.log' changed during processing. File skipped. Also, what is wrong with this exclude statement in my client options file: Exclude *:\WINNT\Profiles\* I get these errors: 02/21/2002 20:49:54 Retry # 1 Normal File-- 1,024 \\info-office_vcu\c$\WINNT\Profiles\Administrator\ntuser.dat.LOG ** Unsuccessful ** Zoltan Forray Virginia Commonwealth University - University Computing Center e-mail: [EMAIL PROTECTED] - voice: 804-828-4807
Re: TSM trying to backup its own, open files..........
Thanks for the info. First, I (and the rest of this hallway) are the main university IT personel staff, especially when it comes to TSM. There are only 2 of us handling TSM administration for all 67 (and increasing) nodes. Second, yes I understand the implications of SHRDYNAMIC. In most cases, we don't have a choice. This server, in particular, has files open, 24x7. So, some backup is better than no-backup. If I had to DR restore this box, I would rather have open, in use files restored, than completely missing from the backup. In fact, I am not sure who came up with the default of trying 5-times for an open/changing file. The first time we stumbled across the implications of this value was when a 15-gig file was transfered 5-times and screwed up the evenings backups, causing all kinds of cascading events/failures (caused this backup to take many more hours than it should have !!). AFAIAC, 2-tries should be enough !! Again, thanks for the help and suggestions. Zoltan Forray Virginia Commonwealth University - University Computing Center e-mail: [EMAIL PROTECTED] - voice: 804-828-4807 Bill Smoldt [EMAIL PROTECTED] Sent by: ADSM: Dist Stor Manager [EMAIL PROTECTED] 02/22/2002 11:51 AM Please respond to ADSM: Dist Stor Manager To: [EMAIL PROTECTED] cc: Subject:Re: TSM trying to backup its own, open files.. Zoltan, Shared Dynamic is a very powerful and very dangerous serialization option. Please make certain that the person who made the decision to use that understands the implications. This serialization option will try to back up a file 4 times and then save the file on the first try during which the file contents didn't change. The danger comes with files that continually change and potentially with applications that require multiple files to be synchronized, like databases. Net result - you may or may not be able to accurately restore those applications. The normal and accepted setting is Shared Static, as you had with the problem client. So you were fixing the one client that was configured properly when you should fix all the others. This will give an error if the file changes on all four attempts so that a human can decide what to do with the application backup. If your university IT personnel understand the implications of Shared Dynamic and choose to live with the restore consequences, then you can take the rest of the day off. Otherwise, you may have a short weekend. ;-) Bill Smoldt STORServer, Inc. -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of Zoltan Forray/AC/VCU Sent: Friday, February 22, 2002 8:50 AM To: [EMAIL PROTECTED] Subject: Re: TSM trying to backup its own, open files.. Thank you and others for the clue. I had forgot about checking the backup copy group for this node (it has its own while most others share common ones). The mode was set to SHRSTATIC vs SHRDYNAMIC (not sure why since everything else is SHRDYNAMIC ??). I have fixed and activated. This should fix it. Again, thanks everyone.. Zoltan Forray Virginia Commonwealth University - University Computing Center e-mail: [EMAIL PROTECTED] - voice: 804-828-4807 Prather, Wanda [EMAIL PROTECTED] Sent by: ADSM: Dist Stor Manager [EMAIL PROTECTED] 02/22/2002 10:04 AM Please respond to ADSM: Dist Stor Manager To: [EMAIL PROTECTED] cc: Subject:Re: TSM trying to backup its own, open files.. I find it useful to have the dsmsched.log file backed up. That way if I have a user turn up with no backups for something after a system crash, I can pull down the dsmsched.log from the TSM backups and see why (believe me, it has happened before!) SO instead of excluding the dsmsched.log, I bind it to a management class that specifies SERIALIZATION=SHRDYNAMIC. That tells TSM to go ahead and back it up, whether it's changing or not. (My management class name for this is CHANGING, so to bind the file to that ruleset, you specify: INCLUDE *:\...\dsmsched.log CHANGING in your dsm.opt file, or the appropriate client option set) We use the same technique for other sequential log files; then you get a backup of whatever is in there, up to the last few lines. Do NOT use this technique for data bases, where change can occur in the middle of the file. It also won't work where the error is due to the file being LOCKED, rather than being open for output. Just another idea.. Wanda Prather The Johns Hopkins Applied Physics Lab 443-778-8769 [EMAIL PROTECTED] Intelligence has much less practical application than you'd think - Scott Adams/Dilbert
Re: TSM trying to backup its own, open files..........
Zoltan, The number of retries can be determined by you. If you only want 2 then set this value in client options file changingretries2 Zoltan Forray/AC/VCU [EMAIL PROTECTED] on 02/22/2002 05:10:46 PM Please respond to ADSM: Dist Stor Manager [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc:(bcc: John Naylor/HAV/SSE) Subject: Re: TSM trying to backup its own, open files.. Thanks for the info. First, I (and the rest of this hallway) are the main university IT personel staff, especially when it comes to TSM. There are only 2 of us handling TSM administration for all 67 (and increasing) nodes. Second, yes I understand the implications of SHRDYNAMIC. In most cases, we don't have a choice. This server, in particular, has files open, 24x7. So, some backup is better than no-backup. If I had to DR restore this box, I would rather have open, in use files restored, than completely missing from the backup. In fact, I am not sure who came up with the default of trying 5-times for an open/changing file. The first time we stumbled across the implications of this value was when a 15-gig file was transfered 5-times and screwed up the evenings backups, causing all kinds of cascading events/failures (caused this backup to take many more hours than it should have !!). AFAIAC, 2-tries should be enough !! Again, thanks for the help and suggestions. Zoltan Forray Virginia Commonwealth University - University Computing Center e-mail: [EMAIL PROTECTED] - voice: 804-828-4807 Bill Smoldt [EMAIL PROTECTED] Sent by: ADSM: Dist Stor Manager [EMAIL PROTECTED] 02/22/2002 11:51 AM Please respond to ADSM: Dist Stor Manager To: [EMAIL PROTECTED] cc: Subject:Re: TSM trying to backup its own, open files.. Zoltan, Shared Dynamic is a very powerful and very dangerous serialization option. Please make certain that the person who made the decision to use that understands the implications. This serialization option will try to back up a file 4 times and then save the file on the first try during which the file contents didn't change. The danger comes with files that continually change and potentially with applications that require multiple files to be synchronized, like databases. Net result - you may or may not be able to accurately restore those applications. The normal and accepted setting is Shared Static, as you had with the problem client. So you were fixing the one client that was configured properly when you should fix all the others. This will give an error if the file changes on all four attempts so that a human can decide what to do with the application backup. If your university IT personnel understand the implications of Shared Dynamic and choose to live with the restore consequences, then you can take the rest of the day off. Otherwise, you may have a short weekend. ;-) Bill Smoldt STORServer, Inc. -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of Zoltan Forray/AC/VCU Sent: Friday, February 22, 2002 8:50 AM To: [EMAIL PROTECTED] Subject: Re: TSM trying to backup its own, open files.. Thank you and others for the clue. I had forgot about checking the backup copy group for this node (it has its own while most others share common ones). The mode was set to SHRSTATIC vs SHRDYNAMIC (not sure why since everything else is SHRDYNAMIC ??). I have fixed and activated. This should fix it. Again, thanks everyone.. Zoltan Forray Virginia Commonwealth University - University Computing Center e-mail: [EMAIL PROTECTED] - voice: 804-828-4807 Prather, Wanda [EMAIL PROTECTED] Sent by: ADSM: Dist Stor Manager [EMAIL PROTECTED] 02/22/2002 10:04 AM Please respond to ADSM: Dist Stor Manager To: [EMAIL PROTECTED] cc: Subject:Re: TSM trying to backup its own, open files.. I find it useful to have the dsmsched.log file backed up. That way if I have a user turn up with no backups for something after a system crash, I can pull down the dsmsched.log from the TSM backups and see why (believe me, it has happened before!) SO instead of excluding the dsmsched.log, I bind it to a management class that specifies SERIALIZATION=SHRDYNAMIC. That tells TSM to go ahead and back it up, whether it's changing or not. (My management class name for this is CHANGING, so to bind the file to that ruleset, you specify: INCLUDE *:\...\dsmsched.log CHANGING in your dsm.opt file, or the appropriate client option set) We use the same technique for other sequential log files; then you get a backup of whatever is in there, up to the last few lines. Do NOT use this technique for data bases, where change can occur in the middle of the file. It also won't work where
Re: TSM trying to backup its own, open files..........
Here's a thought... Those open files- run a script to copy them to *.copy right before your backup starts ??? my 2cents. Gabriel C. Wiley ADSM/TSM Administrator AIX Support Phone 1-614-308-6709 Pager 1-877-489-2867 Fax 1-614-308-6637 Cell 1-740-972-6441 Siempre Hay Esperanza Zoltan Forray/AC/VCUTo: [EMAIL PROTECTED] [EMAIL PROTECTED]cc: Sent by: ADSM: Subject: Re: TSM trying to backup its own, open files.. Dist Stor Manager [EMAIL PROTECTED] .EDU 02/22/2002 12:10 PM Please respond to ADSM: Dist Stor Manager Thanks for the info. First, I (and the rest of this hallway) are the main university IT personel staff, especially when it comes to TSM. There are only 2 of us handling TSM administration for all 67 (and increasing) nodes. Second, yes I understand the implications of SHRDYNAMIC. In most cases, we don't have a choice. This server, in particular, has files open, 24x7. So, some backup is better than no-backup. If I had to DR restore this box, I would rather have open, in use files restored, than completely missing from the backup. In fact, I am not sure who came up with the default of trying 5-times for an open/changing file. The first time we stumbled across the implications of this value was when a 15-gig file was transfered 5-times and screwed up the evenings backups, causing all kinds of cascading events/failures (caused this backup to take many more hours than it should have !!). AFAIAC, 2-tries should be enough !! Again, thanks for the help and suggestions. Zoltan Forray Virginia Commonwealth University - University Computing Center e-mail: [EMAIL PROTECTED] - voice: 804-828-4807 Bill Smoldt [EMAIL PROTECTED] Sent by: ADSM: Dist Stor Manager [EMAIL PROTECTED] 02/22/2002 11:51 AM Please respond to ADSM: Dist Stor Manager To: [EMAIL PROTECTED] cc: Subject:Re: TSM trying to backup its own, open files.. Zoltan, Shared Dynamic is a very powerful and very dangerous serialization option. Please make certain that the person who made the decision to use that understands the implications. This serialization option will try to back up a file 4 times and then save the file on the first try during which the file contents didn't change. The danger comes with files that continually change and potentially with applications that require multiple files to be synchronized, like databases. Net result - you may or may not be able to accurately restore those applications. The normal and accepted setting is Shared Static, as you had with the problem client. So you were fixing the one client that was configured properly when you should fix all the others. This will give an error if the file changes on all four attempts so that a human can decide what to do with the application backup. If your university IT personnel understand the implications of Shared Dynamic and choose to live with the restore consequences, then you can take the rest of the day off. Otherwise, you may have a short weekend. ;-) Bill Smoldt STORServer, Inc. -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of Zoltan Forray/AC/VCU Sent: Friday, February 22, 2002 8:50 AM To: [EMAIL PROTECTED] Subject: Re: TSM trying to backup its own, open files.. Thank you and others for the clue. I had forgot about checking the backup copy group for this node (it has its own while most others share common ones). The mode was set to SHRSTATIC vs SHRDYNAMIC (not sure why since everything else is SHRDYNAMIC ??). I have fixed and activated. This should fix it. Again, thanks everyone.. Zoltan Forray Virginia Commonwealth University - University Computing Center e-mail: [EMAIL PROTECTED] - voice: 804-828-4807 Prather, Wanda [EMAIL PROTECTED] Sent by: ADSM: Dist Stor Manager [EMAIL PROTECTED] 02/22/2002 10:04 AM Please respond to ADSM: Dist Stor Manager To: [EMAIL PROTECTED] cc: Subject:Re: TSM trying to backup its own, open files.. I find it useful to have the dsmsched.log file backed up. That way if I have a user turn up with no backups for something after a system crash, I can pull down the dsmsched.log from the TSM backups and see why (believe me, it has happened before!) SO instead of excluding the dsmsched.log, I bind it to a management class that specifies SERIALIZATION=SHRDYNAMIC. That tells TSM to go ahead and back it up
Re: TSM trying to backup its own, open files..........
Gabriel, Your method works for most files. We use the preschedule command copy selected files before the backup. Then the postschedule command to delete the copies after the backup. -Original Message- From: Gabriel Wiley [SMTP:[EMAIL PROTECTED]] Sent: Friday, February 22, 2002 9:30 AM To: [EMAIL PROTECTED] Subject:Re: TSM trying to backup its own, open files.. Here's a thought... Those open files- run a script to copy them to *.copy right before your backup starts ??? my 2cents. Gabriel C. Wiley ADSM/TSM Administrator AIX Support Phone 1-614-308-6709 Pager 1-877-489-2867 Fax 1-614-308-6637 Cell 1-740-972-6441 Siempre Hay Esperanza Zoltan Forray/AC/VCUTo: [EMAIL PROTECTED] [EMAIL PROTECTED]cc: Sent by: ADSM: Subject: Re: TSM trying to backup its own, open files.. Dist Stor Manager [EMAIL PROTECTED] .EDU 02/22/2002 12:10 PM Please respond to ADSM: Dist Stor Manager Thanks for the info. First, I (and the rest of this hallway) are the main university IT personel staff, especially when it comes to TSM. There are only 2 of us handling TSM administration for all 67 (and increasing) nodes. Second, yes I understand the implications of SHRDYNAMIC. In most cases, we don't have a choice. This server, in particular, has files open, 24x7. So, some backup is better than no-backup. If I had to DR restore this box, I would rather have open, in use files restored, than completely missing from the backup. In fact, I am not sure who came up with the default of trying 5-times for an open/changing file. The first time we stumbled across the implications of this value was when a 15-gig file was transfered 5-times and screwed up the evenings backups, causing all kinds of cascading events/failures (caused this backup to take many more hours than it should have !!). AFAIAC, 2-tries should be enough !! Again, thanks for the help and suggestions. Zoltan Forray Virginia Commonwealth University - University Computing Center e-mail: [EMAIL PROTECTED] - voice: 804-828-4807 Bill Smoldt [EMAIL PROTECTED] Sent by: ADSM: Dist Stor Manager [EMAIL PROTECTED] 02/22/2002 11:51 AM Please respond to ADSM: Dist Stor Manager To: [EMAIL PROTECTED] cc: Subject:Re: TSM trying to backup its own, open files.. Zoltan, Shared Dynamic is a very powerful and very dangerous serialization option. Please make certain that the person who made the decision to use that understands the implications. This serialization option will try to back up a file 4 times and then save the file on the first try during which the file contents didn't change. The danger comes with files that continually change and potentially with applications that require multiple files to be synchronized, like databases. Net result - you may or may not be able to accurately restore those applications. The normal and accepted setting is Shared Static, as you had with the problem client. So you were fixing the one client that was configured properly when you should fix all the others. This will give an error if the file changes on all four attempts so that a human can decide what to do with the application backup. If your university IT personnel understand the implications of Shared Dynamic and choose to live with the restore consequences, then you can take the rest of the day off. Otherwise, you may have a short weekend. ;-) Bill Smoldt STORServer, Inc. -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of Zoltan Forray/AC/VCU Sent: Friday, February 22, 2002 8:50 AM To: [EMAIL PROTECTED] Subject: Re: TSM trying to backup its own, open files.. Thank you and others for the clue. I had forgot about checking the backup copy group for this node (it has its own while most others share common ones). The mode was set to SHRSTATIC vs SHRDYNAMIC (not sure why since everything else is SHRDYNAMIC ??). I have fixed and activated. This should fix it. Again, thanks everyone.. Zoltan Forray Virginia Commonwealth University - University Computing Center e-mail: [EMAIL PROTECTED] - voice: 804-828-4807 Prather, Wanda [EMAIL PROTECTED] Sent by: ADSM: Dist Stor Manager [EMAIL PROTECTED] 02/22/2002 10:04 AM Please respond to ADSM: Dist Stor Manager To: [EMAIL PROTECTED] cc: Subject:Re: TSM trying to backup its own, open files.. I find
Re: TSM trying to backup its own, open files..........
Zoltan, it is really depends on what your backing up. Some files that you may back up 'open' may be worthless when restored so why even bother backing them up. Mark -Original Message- From: Zoltan Forray/AC/VCU [mailto:[EMAIL PROTECTED]] Sent: Friday, February 22, 2002 12:11 PM To: [EMAIL PROTECTED] Subject: Re: TSM trying to backup its own, open files.. Thanks for the info. First, I (and the rest of this hallway) are the main university IT personel staff, especially when it comes to TSM. There are only 2 of us handling TSM administration for all 67 (and increasing) nodes. Second, yes I understand the implications of SHRDYNAMIC. In most cases, we don't have a choice. This server, in particular, has files open, 24x7. So, some backup is better than no-backup. If I had to DR restore this box, I would rather have open, in use files restored, than completely missing from the backup. In fact, I am not sure who came up with the default of trying 5-times for an open/changing file. The first time we stumbled across the implications of this value was when a 15-gig file was transfered 5-times and screwed up the evenings backups, causing all kinds of cascading events/failures (caused this backup to take many more hours than it should have !!). AFAIAC, 2-tries should be enough !! Again, thanks for the help and suggestions. Zoltan Forray Virginia Commonwealth University - University Computing Center e-mail: [EMAIL PROTECTED] - voice: 804-828-4807 Bill Smoldt [EMAIL PROTECTED] Sent by: ADSM: Dist Stor Manager [EMAIL PROTECTED] 02/22/2002 11:51 AM Please respond to ADSM: Dist Stor Manager To: [EMAIL PROTECTED] cc: Subject:Re: TSM trying to backup its own, open files.. Zoltan, Shared Dynamic is a very powerful and very dangerous serialization option. Please make certain that the person who made the decision to use that understands the implications. This serialization option will try to back up a file 4 times and then save the file on the first try during which the file contents didn't change. The danger comes with files that continually change and potentially with applications that require multiple files to be synchronized, like databases. Net result - you may or may not be able to accurately restore those applications. The normal and accepted setting is Shared Static, as you had with the problem client. So you were fixing the one client that was configured properly when you should fix all the others. This will give an error if the file changes on all four attempts so that a human can decide what to do with the application backup. If your university IT personnel understand the implications of Shared Dynamic and choose to live with the restore consequences, then you can take the rest of the day off. Otherwise, you may have a short weekend. ;-) Bill Smoldt STORServer, Inc. -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of Zoltan Forray/AC/VCU Sent: Friday, February 22, 2002 8:50 AM To: [EMAIL PROTECTED] Subject: Re: TSM trying to backup its own, open files.. Thank you and others for the clue. I had forgot about checking the backup copy group for this node (it has its own while most others share common ones). The mode was set to SHRSTATIC vs SHRDYNAMIC (not sure why since everything else is SHRDYNAMIC ??). I have fixed and activated. This should fix it. Again, thanks everyone.. Zoltan Forray Virginia Commonwealth University - University Computing Center e-mail: [EMAIL PROTECTED] - voice: 804-828-4807 Prather, Wanda [EMAIL PROTECTED] Sent by: ADSM: Dist Stor Manager [EMAIL PROTECTED] 02/22/2002 10:04 AM Please respond to ADSM: Dist Stor Manager To: [EMAIL PROTECTED] cc: Subject:Re: TSM trying to backup its own, open files.. I find it useful to have the dsmsched.log file backed up. That way if I have a user turn up with no backups for something after a system crash, I can pull down the dsmsched.log from the TSM backups and see why (believe me, it has happened before!) SO instead of excluding the dsmsched.log, I bind it to a management class that specifies SERIALIZATION=SHRDYNAMIC. That tells TSM to go ahead and back it up, whether it's changing or not. (My management class name for this is CHANGING, so to bind the file to that ruleset, you specify: INCLUDE *:\...\dsmsched.log CHANGING in your dsm.opt file, or the appropriate client option set) We use the same technique for other sequential log files; then you get a backup of whatever is in there, up to the last few lines. Do NOT use this technique for data bases, where change can occur in the middle of the file. It also won't work where the error is due
