ADSM-L

Re: [ADSM-L] Odd client behavior

2012-10-19 10:26:09
Subject: Re: [ADSM-L] Odd client behavior
From: "Prather, Wanda" <Wanda.Prather AT ICFI DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Fri, 19 Oct 2012 14:01:04 +0000
If it's the same nodes having the problem repeatedly,
you could try temporarily adding SKIPNTPERMISSIONS YES to the dsm.opt file.
Then the backup ignores changes to the ACL's.
Just to rule out that issue.

If you still have the problem then, I'd open a ticket with Tivoli.
They might have a client trace that would help identify WHY the client chose to 
back up those directories.



 
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Steven Harris
Sent: Friday, October 19, 2012 3:13 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Odd client behavior

Thomas

A distant possibility is that the tree being backed up has a different 
management Class and that has had its copymode set to absolute.

Regards

Steve.

Steven Harris
TSM Admin
Canberra Australia

On 19/10/2012 6:26 AM, Thomas Denier wrote:
> I have obtained a copy of dsmsched.log from one of the offending 
> systems. I don't have the ability to log on to the client system 
> involved, but I have access to a shared folder on the system.
>
> It appears that there is a large segment of the folder tree on one of 
> the drives in which TSM is backing up every folder every day, but is 
> backing up very few of the files contained in the folders.
> I suspect that the file backups that do occur are the result of 
> genuine update activity.
>
> I checked the permissions on some of the files in a folder descended 
> from the shared folder mentioned above. The file permissions were all 
> inherited from the containing folder. The folder has been backed up 
> every day, but the files have not been backed up. This would appear to 
> rule out the possibility that the massive backups are the result of 
> ACL changes propagating down the folder tree.
>
> I used Internet Explorer to look at the creation and update times for 
> some of the folders within the shared folder. Most of these times were 
> months or even years in the past.
>
> Thomas Denier
> Thomas Jefferson University Hospital
>
> -----Ben Bullock wrote: -----
>
>> When we see that symptom, it typically means that some Windows admin 
>> has changed the ACLs on files and pushed it down to all the 
>> subfolders.
>>
>> Typically they are changing permissions back and forth trying to 
>> resolve some issue without realizing that they are causing the TSM 
>> server to backup the files repeatedly.
>>
>> -----Original Message-----
>> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf 
>> Of Thomas Denier
>>
>> We recently noticed an unexpectedly rapid increase in database space 
>> usage on one of our TSM servers. This seems to be the result of two 
>> Windows clients that are consistently backing up hundreds of 
>> thousands of files every night. We checked our other two TSM servers 
>> and found two more Windows clients behaving this way.
>>
>> In all four cases the behavior started during the same backup
>> window:
>> late October 9 and early October 10.
>>
>> All four systems are in the same Windows domain. The domain 
>> administrator does not recall any noteworthy updates on October 9.
>>
>> One of the Windows administrators involved looked at dsmsched.log and 
>> reported that the backups include large numbers of files that have 
>> not been updated or even accessed recently.
>>
>> The four Windows clients have, among them, three Windows levels (XP, 
>> 2003, and 2008), two TSM client levels (5.3 and 6.2), and three 
>> groups of people responsible for system administration.
>>
>> The three TSM servers involved include one 5.5 server and two 6.2 
>> servers. All run under zSeries Linux.
>>
>> I would appreciate any suggestions regarding possible causes for this 
>> behavior.

<Prev in Thread] Current Thread [Next in Thread>