Why does TSM still report an old time for a directory?

[ldmwndletsm]

Several questions here regarding modtime and change of status time (ctime) updates for directories and files. This is on Linux.

I run something like this:

q backup /var/cache/man/ -subdir=yes -fromdate=2020-02-19

I see a number of files reported. All good. I then run this:

q backup /var/cache/man/index.db -fromdate=2020-02-19 -detail -inactive

I see only one entry with a backup date of 2019-10-03 18:25:16 and the following additional time details:

Modified: 2018-11-03 03:41:47 Accessed: 2018-11-03 03:41:47 Inode changed: 2018-11-03 03:41:47

This concurs with the ctime and mtime (`ls -lcd --full-time filename`; `ls -ld --full-time filename`) reported by the OS.

1. Is TSM telling me that it was first backed up on 2019-10-03 18:25:16, but the modtime for the file changed on 2018-11-03 03:41:47 so it backed it up again? If so then why doesn't it report another entry with the new backup date?

2. Or is it instead telling me that only the modtime or ctime changed (e.g. maybe a permission change) but not the content so it simply reports the Inode changed date/time? If so, then we can assume that if the file is recovered then TSM will use that information to reset its modtime accordingly? That right? How do you know what date/time the database was updated with that information?

3. How does it determine that the file didn't change from 2019-10-03 18:25:16? It can't just compare the size, right? It's not using hashes is it?

But clearly, when the ctime or mtime changes for any file under /var/cache/man then the ctime or mtime on the 'man' directory itself should also change.

4. So why is it that when I run:

q backup /var/cache/man -subdir=yes -detail

I see only one entry from 2019-10-03? The OS reports a time and date as of today. This directory gets changed every day. Why does the query not report that?

 

[marclant]

1. Is TSM telling me that it was first backed up on 2019-10-03 18:25:16, but the modtime for the file changed on 2018-11-03 03:41:47 so it backed it up again?

No, Spectrum Protect is telling you that the version of this file that you are looking at was backed up on 2019-10-03 18:25:16. It is not telling you if it's the first, second or 30th time it has been backed up.

If so then why doesn't it report another entry with the new backup date?

2019-10-03 18:25:16 is the new entry

2. Or is it instead telling me that only the modtime or ctime changed (e.g. maybe a permission change) but not the content so it simply reports the Inode changed date/time?

Files are backed up if they changed. A file can change even if not modified, for example, a change in permissions or attributes.

If so, then we can assume that if the file is recovered then TSM will use that information to reset its modtime accordingly?

Spectrum Protect with recover the file as it was at the time of the backup with the same attributes it had.

ow do you know what date/time the database was updated with that information?

The backup date is when the Spectrum Protect database was update.

How does it determine that the file didn't change from 2019-10-03 18:25:16? It can't just compare the size, right? It's not using hashes is it?

https://www.ibm.com/support/pages/client-attributes-checked-change-during-incremental-backups

I see only one entry from 2019-10-03? The OS reports a time and date as of today. This directory gets changed every day. Why does the query not report that?

I don't follow.

 

[ldmwndletsm]

Thanks. I think in my first question, I didn't notice that the dates reported for the "modified, accessed, inode changed" line was older than the first line where the most recent backup time was reported so I inadvertently mentally swapped them.

For that last question, I think what I meant was that if the directory gets updated daily due to the fact one or more constituent files has changed (or something that might affect the modtime for the directory) then why would TSM instead only report an older time for it? Maybe it only has to update the database with the metadata for the directory, e.g. a modtime change or permission change, etc.? So it only reports the first (initial backup) backup time when it first saw it, unlike files wherein every time the file changes (not the metadata) it has to back it up, so you may see multiple versions of files but usually not with directories. That sound right?

Fro question 3, thanks for the link. That well answers the methodology. I had looked instead at this:

https://www.ibm.com/support/knowledgecenter/SSEQVQ_8.1.7/client/r_opt_updatectime.html

It wasn't clear in the above document if they were saying:

1. ctime will only work if you have GPFS. So if you're instead using, say, ext3, and someone makes a permission change, then TSM won't back it up (seems illogical).

OR:

2. If you have GPFS and you want TSM to honor ctime then you must set the updatectime option.

OR:

3. If you have GPFS then you can force TSM to back up the entire file even if it's only the metadata that's changed, by setting the updatectime option. Otherwise, it would only back up the metadata.

Anyway, your link provided the answers for my purposes.