Objects inspected versus backed up?

ldmwndletsm

ADSM.ORG Senior Member
Joined
Oct 30, 2019
Messages
232
Reaction score
5
Points
0
PREDATAR Control23

I've hunted around all over for this, and concrete answers seem allusive. Linux 8.1.9 on client. Ran a first-time full tonight. The dsmsched.log reports this discrepancy:

04/28/2020 23:10:38 Total number of objects inspected: 189,562
04/28/2020 23:10:38 Total number of objects backed up: 189,509
04/28/2020 23:10:38 Total number of objects updated: 0
04/28/2020 23:10:38 Total number of objects rebound: 0
04/28/2020 23:10:38 Total number of objects deleted: 0
04/28/2020 23:10:38 Total number of objects expired: 0
04/28/2020 23:10:38 Total number of objects failed: 9
04/28/2020 23:10:38 Total number of objects encrypted: 0
04/28/2020 23:10:38 Total number of objects grew: 865

Why is the number of objects inspected greater than the number backed up?

o This was run via the dsmcad scheduler, not a manual backup.

o The 9 failed objects are files that no longer existed when TSM tried to back them up. These are reported like:

04/28/2020 23:06:36 ANS4005E Error processing '/tmp/fname.txt': file not found

But adding those 9 to the objects backed up still comes up 44 shy.

o There are no excludes on the client or server side (Iclopset).

o There are 9 local file systems (XFS) on this client, not counting tmpfs. I am using domain statements in the dsm.sys, one for each file system, e.g.

domain /
domain /tmp
domain /usr

I ran 'dsmc q inclexlc' and it reports:

No exclude filespace statements defined.
Excl Directory /.../.TsmCacheDir IBM Spectrum Protect
Include All /.../* /opt/tivoli/tsm/client/ba/bin/dsm.sys

Anyway, is TSM skipping certain files somewhere on the system by default (e.g. /dev), and simply not reporting this? I don't see /dev listed when I query / in dsmc (not that you'd need that backed up), but there's way more stuff under /dev than the 44 count difference.

Is it simply the case the TSM saw more objects initially when it did its walk through, but then those were gone when it actually started the backup thus accounting for the difference? Seems if that was the case, though, that I'd see other "file not found" messages, but there were only the 9.
 
PREDATAR Control23

With regards to Objects Inspected are the total amount of files on drive. During this it compares which files have changed since last backup. The changed files are backed up hence the difference. So if you had 100 files on drive Objects Inspected would be 100, but if only 10 files had changed since the last backup then backed up would be 10. Why backup a file that hasnt changed.
 
PREDATAR Control23

Thanks, but as I said, this was a first-time full. The only thing that seems to make sense would be if a file was there when it first inspected the file system and was then subsequently deleted before it could back it up. However, if that's the case then I would have expected to see more than just the 9 failed messages (file not found) since the difference was more than 9.

BUT maybe it simply walks the file system first and determines how many objects there are and then compares that number against what it backs up during a second walk? Or does it instead calculate the number of all objects as it's backing up changed files under the file system, in which case it only has to perform a single walk? But given that this was a first-time full, only the former seems reasonable to account for the discrepancy, and there would be plenty of latency between the time it completed the initial count and the time a given file was deleted before it could back it up.

KEY QUESTION: If it issues a message like this in the dsmsched..log:

04/28/2020 23:06:36 ANS4005E Error processing '/tmp/fname.txt': file not found

then how far ahead of time does it determine the file needs to be backed up before it sees that it's gone?
 
Top