How can I recover a file with previous permissions?

ldmwndletsm

ADSM.ORG Senior Member
Joined
Oct 30, 2019
Messages
232
Reaction score
5
Points
0
PREDATAR Control23

Hi,

Is there a way to restore earlier owner, group or permissions for a file if that's the only things that's changed?

I created a manifest for a file system containing a list of the directories and files, checksums, sizes, modtimes and attributes. I then ran an 'incr' on the file system. Restored, validated against the manifest -- all okay. Later, I changed the owner of a file, the group of a second file and the permissions of a third file and ran another incr. Now, when I query the backup for the details on those three files it reports them as active, but it shows no inactive versions. However, it does show the Accessed and Inode Changed dates/times for the attribute updates. I'm guessing it doesn't show inactive versions because it didn't actually back them up again, following those attribute changes, it just updated its metadata, right? However, when I restore the file system using a pitdate and pittime just after the first incr, everything checks just dandy against the manifest except the owner, group and permissions respectively for those three files. They were restored with their later attributes, not their earlier ones.

How can I get the original versions of those back with their previous attributes? Does TSM not support this?
 
PREDATAR Control23

How can I get the original versions of those back with their previous attributes?
You did it the right way, however a previous version must exist.

Are directories bound to a DIRMC?
If yes, what's the retention and number of versions?
If no, what's the number of versions for the management class with the longest retention in that domain?

Where I am getting at is that if the original directory was backed up 100 days ago, but the longest retention is 90 days, the original directory or previous version would expire after you backed up the new one because the original now became inactive.

Likewise, if the longest retention only keeps 1 version, you only get one version.
 
PREDATAR Control23

You did it the right way, however a previous version must exist.

Ah, that explains it. So simple, so obvious, yet so elusive [sigh ...].

On a side note, there is one contradiction in the IBM document: https://www.ibm.com/support/pages/client-attributes-checked-change-during-incremental-backups

wherein they say that a uid or gid change results in just a metadata update whereas a ctime change affects a backup, but a uid or gid change will update the ctime, so this really makes no sense.

Are directories bound to a DIRMC?
If yes, what's the retention and number of versions?
If no, what's the number of versions for the management class with the longest retention in that domain?

Yes, but the copy group has 'No limit' for all four values. Both files and directories use the same management class for all that stuff so as near as I can tell, this would not be a factor.

Where I am getting at is that if the original directory was backed up 100 days ago, but the longest retention is 90 days, the original directory or previous version would expire after you backed up the new one because the original now became inactive.

Likewise, if the longest retention only keeps 1 version, you only get one version.

Right. That would afford a good explanation if that were the case, and that was something that I thought about, but then I remembered that we had 'No Limit', so I was puzzled over the behavior.

BTW: What happens if directories have smaller retention times than files for a given node?

For example, suppose you have two management classes: MC_A, MC_B, so MC_B sorts last alpabetically, and let's say they both have 'Retain Only Versions' set to 365, and there are no others with a larger value. If you're not forcing a node to use MC_A, it will use MC_B, right? But lets say that MC_B is not set as the default and MC_A is, and both have 'Retain Extra Versions' set to 50, but MC_B has lower values for 'Versions Data Exists' and 'Versions Data Deleted' than MC_A. It would seem then that if you didn't force files to use MC_B, then files will be assigned to MC_A since its the default. You now have a situation wherein the first two of the four values will be different for files versus directories.What happens then?

I have actually seen this situation on some other nodes (no DIRMC statement in the stanza and no includes to overtly force files for a particular namespace to be bound to a specific management class) that I'm not administering wherein when I query a backup name space, it reports MC_B for the directories, and that concurs with what I understand about how it decides which one to choose if you're not forcing it, and DEFAULT for the files. However, when I check, I see that MC_B is not the default, it's MC_A instead. So unless I've misunderstood something, those nodes are using different settings for values 1-2 of the 4, and the same settings for values 3-4, for directories versus files. Seems like a potential issue?
 
PREDATAR Control23

BTW: What happens if directories have smaller retention times than files for a given node?
You won't be able to restore the directory, but if you restore a file in the directory, the server knows the directory name and will create the directory, it will inherit the permission of the parent directory.
 
PREDATAR Control23

Thanks, yes, that all makes sense, but I'm still shaky on the metadata updates and how TSM tracks these.

Question 1: I create a new file on Jul 1 (perm=600), and I run a backup. On Jul 10, I change the perm to 644, and I run a backup. If I recover the version from Jul 1 will I get the perm of 600 restored or instead the latest, 644?

Question 2: Same as above but on Jul 15, I modify the file and I change the perm to 755 and I run a backup.
Clearly, if I restore the file from Jul 15 then I'll get everything the way it was then and perm will be set to 755, but if I restore the parent directory from Jul 10 then I will get the version of the file from Jul 1 since there is no version from Jul 10 (only a metadata update). But in this case, will the perm for the version from Jul 1 will be restored with the way it was on Jul 1 (600), the way it was on Jul 10 (644) or the way it was following the most recent metadata update (755) on Jul 15?

In other words, does TSM track a history of these metadata updates, or does it instead always replace the previous metadata values, for the given file, with the latest?
 
Top