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