ADSM-L

Re: [ADSM-L] Tracking Permission Changes

2007-12-12 10:54:31
Subject: Re: [ADSM-L] Tracking Permission Changes
From: Dave Mussulman <mussulma AT UIUC DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 12 Dec 2007 09:53:50 -0600
On Tue, Dec 11, 2007 at 09:43:29AM -0600, Shawn Drew wrote:
> I'm trying to figure out when the permission of certain files changed.   I
> ran a few tests, and I'm not sure I like the behavior of TSM.  Maybe I'm
> missing something.
>
> - I backed up a file a month ago.
> - The file hasn't changed for a month
> - Today I changed the permission from 644 to 444.
> - I ran a "dsmc i" and it didn't back up the file again, just updated:
> "Total number of objects updated:   1"
> - When I browse the files for restore, there was no indication of the
> permission change
> - When I restore the file with a point-in-time from before this update, it
> still restores the file with the current permission!
>
> It doesn't seem this is how it should work, but I do understand that the
> metadata of the file is probably stored in the TSM DB and there is
> probably no facility to maintain metadata history.    Does this seem
> strange to anyone?

Hi Shawn,

AFAIK, TSM doesn't keep a back history of unix file permissions.  It's
one of those "gotcha" cases where point-in-time restores from inactive
versions aren't actually point-in-time (because they'll use whatever the
active file's permissions are.)  It does seem strange.

It's also not consistent with different file types.  NTFS permissions
are stored with the file, and so you'll see an active/inactive increment
when permissions are changed.  The QuickFacts explains it as "this is
warranted as the attributes are vital to the files."  I'm not sure why
that's true for Windows and not Unix.  (Other than the fact my Unix
admins would probably figure it out and be able to move on if they had
to do a restore and then adjust permissions.  My Windows admins would
make a much bigger fuss about recreating that permissions structure.)

I'm not sure how other file/attribute combinations are handled (zfs,
ext2/3 extended attributes, ufs, macos) but it would be nice if that was
consistent and/or documented somewhere.  At first blush, I'd at least
want that information backed up (I'm not sure ext2 extended attributes
are backed up at all) and, it would be great they were versioned with
the files.

Dave