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

mg_info.txt
Description: Text document