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 <bbull...@bcidaho.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:ads...@vm.marist.edu] On Behalf Of > Conway, Timothy > Sent: Thursday, May 27, 2010 11:28 AM > To: ADSM-L@VM.MARIST.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.con...@jbssa.com > JBS Server Team > > > -----Original Message----- > From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of > Rick Adamson > Sent: Wednesday, May 26, 2010 9:21 AM > To: ADSM-L@VM.MARIST.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
