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
|
