ldmwndletsm
ADSM.ORG Senior Member
- Joined
- Oct 30, 2019
- Messages
- 232
- Reaction score
- 5
- 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.
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.
