• 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.

Directory modification times?

ldmwndletsm

ADSM.ORG Member
Joined
Oct 30, 2019
Messages
183
Reaction score
2
Points
0
Running TSM 8.1.11 on Linux. I have 'No Limit' set to all parameters for copy group. I have 'DIRMC managementclass_name' and 'include * managementclass' to force all binding.

The modification time on any directory will change if a file immediately under there changes (not that it couldn't change for other reasons, too). So `/bin/ls -ld /home/username` reports a recent modtime (.bash_history changes almost every day, for example).

[ Question 1 ]
Why does `/bin/dsmc q backup /home/username -detail -inactive` report only the first (initial-full) backup of the directory but no later modification times?

All the times reported from `q backup -detail` (Modified, Accessed, Inode changed) all match each other, and the Inode does match what the OS reports (`/bin/ls -lid /home/username`), but there is no entry for any later versions of the directory. I'm not expecting TSM to re-back up the directory and its contents, but If the modtime on the directory changes almost every day then why does TSM not report that newer modification time?

The only thing that I can deduce is that TSM isn't going to take another backup of the directory since we're running Incrementals, and instead it will simply record the updated modification time in the database, so if and when it's restored then maybe (just maybe) it will apply that modtime, but /bin/dsmc does not report it. However, it does report all older backups of the constituent files, e.g., .bash_history, and those times (-detail) do look correct respectively.

[ Question 2 ]
If TSM is tracking modtimes for directories then do those changes count against your VERExists, VERDeteled, RETExtra and RETOnly values in the copy group?

[ Question 3 ]
What about other metadata changes to directories (permission, ownership) or even files?

So if a file's owner or permissions are changed, but not its modtime or size -- in other words, let's say something that would not force another backup but would only update the TSM database -- then does that count toward any of the copy group parameters? Or are you given unlimited changes on those sorts of things?


################################################################################################
I've never been clear on any of this witchcraft when it comes to TSM. It always seems to be hidden away. For example, I know of no way to inquire from TSM what it thinks the permissions are for an object that it's backed up. And I played around with this a while back, and as I recall, when you restore the latest backup of a file, you get the permissions for the file as of the last backup of the directory that it lives under. For example, if fileA receives a first-time full on October 1, and then its permissions are changed on Oct 11, again on Oct 16, and again on Oct 20 then TSM might only report the version from October 1 since that's the only time that it was actually backed up, but the TSM database was updated with the permission changes on each of those respective backups of the directory (or file system?). If you restore using the pitdate/time for that first one then you will get the permissions associated with the file when first TSM backed it up. If you restore from any pittdate/time after Oct 11 onward then you might get the permissions from Oct 20. I don't recall if there was a way to restore permissions from interim backups of the directory (interim updates to the database) given that a backup of the actual file was not taken, only an update to the database as far the file's metadata. If an actual backup had been taken then yes. As I recall, it was tricky, and there were some anomalies, so maybe I just didn't understand the logic.
 

Advertise at ADSM.ORG

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

DigitalOcean $100 Credit

Support ADSM.ORG and get DigitalOcean FREE credit. DigitalOcean currently offer a $100, 60-day Free Credit for new accounts. Sign-up here:

DigitalOcean Referral Badge

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: 20 18.7%
  • Keep using TSM for Spectrum Protect.

    Votes: 65 60.7%
  • Let's be formal and just say Spectrum Protect

    Votes: 13 12.1%
  • Other (please comement)

    Votes: 9 8.4%

Forum statistics

Threads
31,897
Messages
135,988
Members
21,783
Latest member
london
Top