• Please help support our sponsors by considering their products and services.
    Our sponsors enable us to serve you with this high-speed Internet connection and fast webservers you are currently using at ADSM.ORG.
    They support this free flow of information and knowledge exchange service at no cost to you.

    Please welcome our latest sponsor Tectrade . We can show our appreciation by learning more about Tectrade Solutions
  • Community Tip: Please Give Thanks to Those Sharing Their Knowledge.

    If you receive helpful answer on this forum, please show thanks to the poster by clicking "LIKE" link for the answer that you found helpful.

  • Community Tip: Forum Rules (PLEASE CLICK HERE TO READ BEFORE POSTING)

    Click the link above to access ADSM.ORG Acceptable Use Policy and forum rules which should be observed when using this website. Violators may be banned from this website. This notice will disappear after you have made at least 3 posts.

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

ldmwndletsm

ADSM.ORG Member
#1
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

ADSM.ORG Moderator
#2
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

ADSM.ORG Member
#3
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.
 

Advertise at ADSM.ORG

If you are reading this, so are your potential customer. Advertise at ADSM.ORG right now.

UpCloud high performance VPS at $5/month

Get started with $25 in credits on Cloud Servers. You must use link below to receive the credit. Use the promo to get upto 5 month of FREE Linux VPS.

The Spectrum Protect TLA (Three-Letter Acronym): ISP or something else?

  • Every product needs a TLA, Let's call it ISP (IBM Spectrum Protect).

    Votes: 18 19.6%
  • Keep using TSM for Spectrum Protect.

    Votes: 57 62.0%
  • Let's be formal and just say Spectrum Protect

    Votes: 10 10.9%
  • Other (please comement)

    Votes: 7 7.6%

Forum statistics

Threads
31,583
Messages
134,647
Members
21,649
Latest member
worblehat
Top