Have they considered the use of groups?  Once the group has access they can add 
or remove users as needed.
I understand that the home directories will have the user instead of a group, 
but anything that affects the whole tree or a large part should be a group.
One thing we have done in the past is cross training, if possible cross train a 
security admin in the ways of backups.  If they have to live with the pain they 
might see the error of their ways.  The reverse is also true.
Something to consider, skip NTFS permissions except 1 day per week.

Andy Huebner

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Rick Adamson
Sent: Friday, May 28, 2010 7:19 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Any way to avoid full backup of data relocated on TSM 
client file system??

Steve, Yes that is an option but also would have consequences in a 
restore/recovery situation. The clusters are where the company's user home and 
group directories live, hence permissions are somewhat granular to say the 
least. In a recovery situation they would be lost or at a minimum restored 
incorrectly which would lead to the all too frequent scenario of blaming the 
backup architect.

Probably the most I can do at this point is to continue making sure that they 
are aware of the resulting cost when these changes are made. Then they can 
decide if they want to pay the bill or push back on the planned changes, which 
is usually fruitless as the person or department making the changes will hide 
behind the claim that it needs to be done for "compliance".

I just wanted to make sure there wasn't some way to deal with it that I may 
have been overlooking.

Thank you
~Rick


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Steve Harris
Sent: Friday, May 28, 2010 12:59 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Any way to avoid full backup of data relocated on TSM 
client file system??

Rick, Ben

Isn't that what the SKIPNTPERMISSIONS client option is for?


Regards

Steve.

Steven Harris
TSM Admin
Paraparaumu, New Zealand.


On Thu, 27 May 2010 11:52:15 -0600, Ben Bullock <BBullock AT BCIDAHO DOT COM>
wrote:
> I have had that problem also in the past and found no suitable way to get
> around it. We considered just not backing up the ACLs, but that was
deemed
> unacceptable, so we just had to grin and bear it.
>
> As I understand it, the ACLs are actually part of the Windows files, so
> there is no way to separate those changes from normal changes to the
file.
>
> Ben
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf 
> Of
> Conway, Timothy
> Sent: Thursday, May 27, 2010 11:28 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: [ADSM-L] Any way to avoid full backup of data relocated on
TSM
> client file system??
>
> I've never done it, and don't like it, but subfile backup?
>
>
> 73,
> Tim Conway
> JBS USA | 1770 Promontory Ci | Greeley, CO 80634| USA
> Direct: 970-506-7998  | Fax: 970.336.6195
> email: Timothy.Conway AT jbssa DOT com
> JBS Server Team
>
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf 
> Of
> Rick Adamson
> Sent: Wednesday, May 26, 2010 9:21 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: [ADSM-L] Any way to avoid full backup of data relocated on TSM
> client file system??
>
> We have an operations and security team that is constantly either moving
> client data or changing a file spaces inheritable ACL's, which in turn
> results in the next backup recognizing this as "changed" or "new" data
and
> backing it up again. This results in wasted storage and reduces the
> retention history.
>
>
>
> Can anyone tell me if there is a way to prevent this from happening or
how
> they deal with these situations? For example; in the event of permission
> changes can TSM just update the existing backup data with the ACL changes
> and not re-backup the actual files/directories?
>
>
>
> I am regularly dealing with this on several clustered file servers that
> have about 10tb of data so when this happens the impact to storage is
> pretty intense. Unfortunately, most of the time I do not know the changes
> are taking place until the damage is done and then have to extend the
time
> to investigate the cause so I can explain the space usage.
>
>
>
> All comments welcome and appreciated...
>
>
>
> ~Rick Adamson
>
>    Jackonville,FL

This e-mail (including any attachments) is confidential and may be legally 
privileged. If you are not an intended recipient or an authorized 
representative of an intended recipient, you are prohibited from using, copying 
or distributing the information in this e-mail or its attachments. If you have 
received this e-mail in error, please notify the sender immediately by return 
e-mail and delete all copies of this message and any attachments.

Thank you.