ldmwndletsm
ADSM.ORG Senior Member
- Joined
- Oct 30, 2019
- Messages
- 232
- Reaction score
- 5
- Points
- 0
Using 8.1.3 on Linux here. Has anyone ever seen a case wherein a directory is not restored with the correct modtime, as in the modtime that it had at the time the backup was taken is different than when restored?
I had a small amount of data under an ext4 file system (/users/user-name). All the data lives under /users/user-name/export. There was a previous incr (first-time backup) run around February 10 EST. Last night, I added a few files and a subdirectory, and I ran an incr on the client, and when I restored it to a different location (an xfs file system: /home), everything was correct, but the export directory had an older modtime from around the 10th EST (or 11th UTC), but otherwise, the metadata was correct.
Here are the modtimes (UTC) for the export directory:
2020-02-21T02:25:47Z (time according to the OS prior to the backup)
2020-02-11T03:10:58Z (time according to the OS following the recover)
All the constituent files had the correct content (MD5 digest), modtimes, sizes, permissions ... all that stuff. I then added some more files, and another subdirectory or two, ran another incr, restored everything, and again, same situation as before. I then added a few more files, and another subdirectory (export/test2), ran another incr, recovered again, and this time export/test2 also had an older modtime.
Here are the modtimes (UTC) for the second directory (export/test2):
2020-02-21T02:25:31Z (time according to the OS prior to the backup)
2020-02-21T00:34:14Z (time according to the OS following the recover)
I've seen this behavior a few times over the years with EMC NetWorker wherein you recover a bunch of data and maybe a couple of directories might not be restored with their original modtimes (it was very seldom and very random), but nothing way in the future or the past or anything like that.Thus far, I've not seen any weirdness from TSM either other than this same oddity. It's almost as if it's restoring the modtime from the first time it backed it up and not resetting it to what it was thereafter. I would think it would store that information in the metadata on the TSM database and update it every time a backup runs, assuming the modtime on the affected directory was different than before, so it could reset it appropriately when recovering.
Anyway, I don't think a different restored modtime for a directory is much to fuss about for me since the directory structure and the files are all restored just dandy, including the metadata (or attributes stored in the inode) for both files and directories. However, I was curious if anyone else has observed this behavior?
I had a small amount of data under an ext4 file system (/users/user-name). All the data lives under /users/user-name/export. There was a previous incr (first-time backup) run around February 10 EST. Last night, I added a few files and a subdirectory, and I ran an incr on the client, and when I restored it to a different location (an xfs file system: /home), everything was correct, but the export directory had an older modtime from around the 10th EST (or 11th UTC), but otherwise, the metadata was correct.
Here are the modtimes (UTC) for the export directory:
2020-02-21T02:25:47Z (time according to the OS prior to the backup)
2020-02-11T03:10:58Z (time according to the OS following the recover)
All the constituent files had the correct content (MD5 digest), modtimes, sizes, permissions ... all that stuff. I then added some more files, and another subdirectory or two, ran another incr, restored everything, and again, same situation as before. I then added a few more files, and another subdirectory (export/test2), ran another incr, recovered again, and this time export/test2 also had an older modtime.
Here are the modtimes (UTC) for the second directory (export/test2):
2020-02-21T02:25:31Z (time according to the OS prior to the backup)
2020-02-21T00:34:14Z (time according to the OS following the recover)
I've seen this behavior a few times over the years with EMC NetWorker wherein you recover a bunch of data and maybe a couple of directories might not be restored with their original modtimes (it was very seldom and very random), but nothing way in the future or the past or anything like that.Thus far, I've not seen any weirdness from TSM either other than this same oddity. It's almost as if it's restoring the modtime from the first time it backed it up and not resetting it to what it was thereafter. I would think it would store that information in the metadata on the TSM database and update it every time a backup runs, assuming the modtime on the affected directory was different than before, so it could reset it appropriately when recovering.
Anyway, I don't think a different restored modtime for a directory is much to fuss about for me since the directory structure and the files are all restored just dandy, including the metadata (or attributes stored in the inode) for both files and directories. However, I was curious if anyone else has observed this behavior?
