Re: TSM performing full backups where incremental specified
Richard, and others, Thanks for the on- and off-line responses. I have followed up the suggestions made, but so far no success. Richard, I checked to make sure that nothing was strange with the filespaces. I actually did an incremental from the command line, then followed it up immediately with another, and sure enough almost all the files backed up twice. DSMC Q FI shows just one occurrence of each defined filespace, so I don't think anything is happening to them between backups. In this case, it would have had to have happened in about one minute. Q BACKUP on the client shows multiple instances of each file -- one active, the rest inactive. I don't see anything on the details of each file that indicates a change. Last access date, file size, all appear identical. I chose several operating system files that I know have not changed since the last server upgrade (more than a year ago) and they still back up when using INCREMENTAL by itself. The number of files backed up is just a few dozen short of the number inspected - a difference which is attributable to those files that were open (such as log files) and could not be backed up. Obviously, with full backups running each night, my tape count in increasing dramatically. I have run traces, and have a call open with IBM. It has been open for 20 days. They are stumped as well, and have no idea what to do. So, I was trying this avenue again in the hope that someone else may have seen this. -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Richard Sims Sent: Monday, January 28, 2008 5:43 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] TSM performing full backups where incremental specified Kevin - Heck of a problem you have there. I don't do z/OS or Netware, so unlikely that I'll have an answer, but some thoughts... This is too obvious, but: The filespaces involved are not in some way being renamed or deleted in between the mass incrementals? That would cause a full backup. Seems very unlikely to me, but one thing I would consider. Does a 'dsmc q fi' show a singular instance of the suspect file system? Here I'm thinking of some oddity causing the server to believe that the file system is different each time. But, tape consumption would cause this to stand out. In the backup log, does the number of objects backed up equal the number inspected? If a substantive difference, I would look into the exceptions to see what's the basis of their immunity. Also, perform a 'dsmc q ba -detail -ina ___' on one of the files and see if all versions look the same, or there is some different which might incite the backup. And, if you don't see a bunch of versions, it may be possible that some mutation to the policies is causing obliteration of what was backed up the last time. As a last resort, I would run a client trace of your partial versus unqualified incrementals and see if any functional differences stand out in causing the mass backups. If nothing apparent, give TSM Support a call. wacky stuff I can think of, Richard Sims
Re: TSM performing full backups where incremental specified
Kevin, Have you verified that the MODE parameter of the copygoup is not set to Absolute? Neil Strand Storage Engineer - Legg Mason Baltimore, MD. (410) 580-7491 Whatever you can do or believe you can, begin it. Boldness has genius, power and magic. -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Kinder, Kevin P Sent: Tuesday, January 29, 2008 11:44 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] TSM performing full backups where incremental specified Richard, and others, Thanks for the on- and off-line responses. I have followed up the suggestions made, but so far no success. Richard, I checked to make sure that nothing was strange with the filespaces. I actually did an incremental from the command line, then followed it up immediately with another, and sure enough almost all the files backed up twice. DSMC Q FI shows just one occurrence of each defined filespace, so I don't think anything is happening to them between backups. In this case, it would have had to have happened in about one minute. Q BACKUP on the client shows multiple instances of each file -- one active, the rest inactive. I don't see anything on the details of each file that indicates a change. Last access date, file size, all appear identical. I chose several operating system files that I know have not changed since the last server upgrade (more than a year ago) and they still back up when using INCREMENTAL by itself. The number of files backed up is just a few dozen short of the number inspected - a difference which is attributable to those files that were open (such as log files) and could not be backed up. Obviously, with full backups running each night, my tape count in increasing dramatically. I have run traces, and have a call open with IBM. It has been open for 20 days. They are stumped as well, and have no idea what to do. So, I was trying this avenue again in the hope that someone else may have seen this. -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Richard Sims Sent: Monday, January 28, 2008 5:43 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] TSM performing full backups where incremental specified Kevin - Heck of a problem you have there. I don't do z/OS or Netware, so unlikely that I'll have an answer, but some thoughts... This is too obvious, but: The filespaces involved are not in some way being renamed or deleted in between the mass incrementals? That would cause a full backup. Seems very unlikely to me, but one thing I would consider. Does a 'dsmc q fi' show a singular instance of the suspect file system? Here I'm thinking of some oddity causing the server to believe that the file system is different each time. But, tape consumption would cause this to stand out. In the backup log, does the number of objects backed up equal the number inspected? If a substantive difference, I would look into the exceptions to see what's the basis of their immunity. Also, perform a 'dsmc q ba -detail -ina ___' on one of the files and see if all versions look the same, or there is some different which might incite the backup. And, if you don't see a bunch of versions, it may be possible that some mutation to the policies is causing obliteration of what was backed up the last time. As a last resort, I would run a client trace of your partial versus unqualified incrementals and see if any functional differences stand out in causing the mass backups. If nothing apparent, give TSM Support a call. wacky stuff I can think of, Richard Sims IMPORTANT: E-mail sent through the Internet is not secure. Legg Mason therefore recommends that you do not send any confidential or sensitive information to us via electronic mail, including social security numbers, account numbers, or personal identification numbers. Delivery, and or timely delivery of Internet mail is not guaranteed. Legg Mason therefore recommends that you do not send time sensitive or action-oriented messages to us via electronic mail. This message is intended for the addressee only and may contain privileged or confidential information. Unless you are the intended recipient, you may not use, copy or disclose to anyone any information contained in this message. If you have received this message in error, please notify the author by replying to this message and then kindly delete the message. Thank you.
Re: TSM performing full backups where incremental specified
Yes - first thing I checked. Thanks, though! -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Strand, Neil B. Sent: Tuesday, January 29, 2008 12:32 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] TSM performing full backups where incremental specified Kevin, Have you verified that the MODE parameter of the copygoup is not set to Absolute? Neil Strand Storage Engineer - Legg Mason Baltimore, MD. (410) 580-7491 Whatever you can do or believe you can, begin it. Boldness has genius, power and magic. -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Kinder, Kevin P Sent: Tuesday, January 29, 2008 11:44 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] TSM performing full backups where incremental specified Richard, and others, Thanks for the on- and off-line responses. I have followed up the suggestions made, but so far no success. Richard, I checked to make sure that nothing was strange with the filespaces. I actually did an incremental from the command line, then followed it up immediately with another, and sure enough almost all the files backed up twice. DSMC Q FI shows just one occurrence of each defined filespace, so I don't think anything is happening to them between backups. In this case, it would have had to have happened in about one minute. Q BACKUP on the client shows multiple instances of each file -- one active, the rest inactive. I don't see anything on the details of each file that indicates a change. Last access date, file size, all appear identical. I chose several operating system files that I know have not changed since the last server upgrade (more than a year ago) and they still back up when using INCREMENTAL by itself. The number of files backed up is just a few dozen short of the number inspected - a difference which is attributable to those files that were open (such as log files) and could not be backed up. Obviously, with full backups running each night, my tape count in increasing dramatically. I have run traces, and have a call open with IBM. It has been open for 20 days. They are stumped as well, and have no idea what to do. So, I was trying this avenue again in the hope that someone else may have seen this. -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Richard Sims Sent: Monday, January 28, 2008 5:43 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] TSM performing full backups where incremental specified Kevin - Heck of a problem you have there. I don't do z/OS or Netware, so unlikely that I'll have an answer, but some thoughts... This is too obvious, but: The filespaces involved are not in some way being renamed or deleted in between the mass incrementals? That would cause a full backup. Seems very unlikely to me, but one thing I would consider. Does a 'dsmc q fi' show a singular instance of the suspect file system? Here I'm thinking of some oddity causing the server to believe that the file system is different each time. But, tape consumption would cause this to stand out. In the backup log, does the number of objects backed up equal the number inspected? If a substantive difference, I would look into the exceptions to see what's the basis of their immunity. Also, perform a 'dsmc q ba -detail -ina ___' on one of the files and see if all versions look the same, or there is some different which might incite the backup. And, if you don't see a bunch of versions, it may be possible that some mutation to the policies is causing obliteration of what was backed up the last time. As a last resort, I would run a client trace of your partial versus unqualified incrementals and see if any functional differences stand out in causing the mass backups. If nothing apparent, give TSM Support a call. wacky stuff I can think of, Richard Sims IMPORTANT: E-mail sent through the Internet is not secure. Legg Mason therefore recommends that you do not send any confidential or sensitive information to us via electronic mail, including social security numbers, account numbers, or personal identification numbers. Delivery, and or timely delivery of Internet mail is not guaranteed. Legg Mason therefore recommends that you do not send time sensitive or action-oriented messages to us via electronic mail. This message is intended for the addressee only and may contain privileged or confidential information. Unless you are the intended recipient, you may not use, copy or disclose to anyone any information contained in this message. If you have received this message in error, please notify the author by replying to this message and then kindly delete the message. Thank you.
Re: TSM performing full backups where incremental specified
You should be able to write a specific backup command save in the Client directory and have an object defined in the schedule point to that command file on the client. Instead of running an incremental schedule, use a command schedule, and have the command be instructions to run the incremental backup. I am not familiar with NetWare though, so I may be off the mark. George Huebschman Legg Mason -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Kinder, Kevin P Sent: Monday, January 28, 2008 4:19 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] TSM performing full backups where incremental specified I wanted to revisit this issue, which I wrote about last week, to see if the new things I have learned ring a bell with anyone here. I did check and verify on all the suggestions that I received the first time I posted, but none of them were applicable. I do appreciate the responses, however! After upgrading to TSM 5.5 on z/OS 1.7, all of my NetWare clients now do a full backup every night, rather than incrementals. Nothing changed on the clients, I didn't do an autonamereset, and I am not overriding the incremental setting. I am also not using UNICODE. I have discovered through testing that if I simply issue the INCREMENTAL command, either via the command line or via a nightly schedule, that a full backup is done. However, if I follow the incremental with any options (e.g., INCREMENTAL SYS:* -subdir=yes) then the incremental command is processed correctly. Has anyone seen this behavior before? I did several searches, and could only find one item that seemed to apply, concerning a NOCOMPRESSBIT to be placed in the DSM.OPT. I tested that, and it did not work. The problem occurs on clients ranging from 5.2.0.0 to 5.5.0.0, so I have to think it's something in the new server code. As a workaround, what would be the best way to issue the incremental command with the options on a nightly schedule? Thanks for any help that can be provided! Kevin Kinder State of West Virginia IMPORTANT: E-mail sent through the Internet is not secure. Legg Mason therefore recommends that you do not send any confidential or sensitive information to us via electronic mail, including social security numbers, account numbers, or personal identification numbers. Delivery, and or timely delivery of Internet mail is not guaranteed. Legg Mason therefore recommends that you do not send time sensitive or action-oriented messages to us via electronic mail. This message is intended for the addressee only and may contain privileged or confidential information. Unless you are the intended recipient, you may not use, copy or disclose to anyone any information contained in this message. If you have received this message in error, please notify the author by replying to this message and then kindly delete the message. Thank you.
Re: TSM performing full backups where incremental specified
Kevin - Heck of a problem you have there. I don't do z/OS or Netware, so unlikely that I'll have an answer, but some thoughts... This is too obvious, but: The filespaces involved are not in some way being renamed or deleted in between the mass incrementals? That would cause a full backup. Seems very unlikely to me, but one thing I would consider. Does a 'dsmc q fi' show a singular instance of the suspect file system? Here I'm thinking of some oddity causing the server to believe that the file system is different each time. But, tape consumption would cause this to stand out. In the backup log, does the number of objects backed up equal the number inspected? If a substantive difference, I would look into the exceptions to see what's the basis of their immunity. Also, perform a 'dsmc q ba -detail -ina ___' on one of the files and see if all versions look the same, or there is some different which might incite the backup. And, if you don't see a bunch of versions, it may be possible that some mutation to the policies is causing obliteration of what was backed up the last time. As a last resort, I would run a client trace of your partial versus unqualified incrementals and see if any functional differences stand out in causing the mass backups. If nothing apparent, give TSM Support a call. wacky stuff I can think of, Richard Sims
