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 <psz1 AT cornell DOT 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.Denier AT jefferson DOT 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: psz1 AT cornell DOT edu
> 719 Rhodes Hall, Ithaca, NY 14853-3801
>
|
