Share perms are stored in the registry, so backed up with a system state backup. If all the files are getting backed up again he must have changed the filesystem perms too.
On Mon, 11 May 2015 22:13 Paul Zarnowski <p...@cornell.edu> wrote: > This is a problem for NTFS because the amount of metadata associated with > an object is more than you can put into the TSM database. Thus, TSM puts > it into the storage pool, along with the object. What this means is that > when the meta changes, the object has to be backed up again. This is not a > problem for Unix/NFS, because there isn't much metadata and it can all be > put into the TSM DB, which means if it changes it's just a DB update and > not another backup of the object. > > Bad enough for backups, but imagine if you had a PB-scale GPFS filesystem > and someone unwittingly makes such a change. Now you're talking about > having to recall all of those objects in order to back them up again. > Ugh. End of game. > > ..Paul > > > At 04:54 PM 5/11/2015, Nick Marouf wrote: > >Hello > > > > From my experience changing share permission will force tsm to backup all > >the data once more. A solution we used in the past was to assign groups > >instead of users to shares. > > > >Changes to group membership is behind the scenes in AD, and is not picked > >up by TSM at the client level. > > > > > >On Mon, May 11, 2015 at 2:39 PM, Thomas Denier < > thomas.den...@jefferson.edu> > >wrote: > > > >> One of our TSM servers is in the process of backing up a large part of > the > >> contents of a Windows 2008 file server. I contacted the system > >> administrator. He told me that he had changed share permissions but not > >> security permissions, and did not expect all the files in the share to > be > >> backed up. Based on my limited knowledge of share permissions I wouldn't > >> have expected that either. Is it normal for a share permissions change > to > >> have this effect? How easy is it to make a security permissions change > >> while trying to make a share permissions change? > >> > >> Thomas Denier, > >> Thomas Jefferson University > >> The information contained in this transmission contains privileged and > >> confidential information. It is intended only for the use of the person > >> named above. If you are not the intended recipient, you are hereby > notified > >> that any review, dissemination, distribution or duplication of this > >> communication is strictly prohibited. If you are not the intended > >> recipient, please contact the sender by reply email and destroy all > copies > >> of the original message. > >> > >> CAUTION: Intended recipients should NOT use email communication for > >> emergent or urgent health care matters. > >> > > > -- > Paul Zarnowski Ph: 607-255-4757 > Assistant Director for Storage Services Fx: 607-255-8521 > IT at Cornell / Infrastructure Em: p...@cornell.edu > 719 Rhodes Hall, Ithaca, NY 14853-3801 >