Handling changing files¶

Nightly emails always report errors¶

A very common cause for that is files which are either read-locked from TSM completely (more common on windows OSes) or files that change constantly during backups.

The output from command line dsmc inc or the contents of dsmsched.log will list the progress and results of the backup. If files are changing, the client will retry them later on, several times.

In the below example, the actual files that change are log files under /var/log, and one in particular is hard to back up successfully, /var/log/audit/audit.log.

Normal File-->            85,113 /var/log/secure  Changed
Retry # 1  Normal File-->            21,841 /var/log/messages [Sent]
Retry # 1  Normal File-->            85,113 /var/log/secure [Sent]
Normal File-->           144,000 /var/log/wtmp [Sent]
Normal File-->         1,756,058 /var/log/audit/audit.log  Changed
Retry # 2  Normal File-->            85,113 /var/log/secure [Sent]
Retry # 1  Normal File-->           144,000 /var/log/wtmp [Sent]
Retry # 1  Normal File-->         1,758,725 /var/log/audit/audit.log  Changed
Retry # 2  Normal File-->         1,775,152 /var/log/audit/audit.log  Changed
Retry # 3  Normal File-->         1,784,573 /var/log/audit/audit.log  Changed
Retry # 4  Normal File-->         1,788,872 /var/log/audit/audit.log  Changed
Normal File-->         6,291,591 /var/log/audit/audit.log.1 [Sent]
Normal File-->         6,291,599 /var/log/audit/audit.log.2 [Sent]
Normal File-->         6,291,641 /var/log/audit/audit.log.3 [Sent]
ANS1228E Sending of object '/var/log/audit/audit.log' failed.
ANS4037E Object '/var/log/audit/audit.log' changed during processing.
Object skipped.
Normal File-->         6,291,561 /var/log/audit/audit.log.4 [Sent]
Normal File-->        47,820,447 /var/log/icinga2/icinga2.log  Changed
Retry # 1  Normal File-->        47,820,447 /var/log/icinga2/icinga2.log [Sent]
ANS1802E Incremental backup of '/var' finished with 1 failure(s)

After the fourth retry, the audit.log file was skipped due to constant changes. In this case, we know the answer to why it changes, it is because the access of all files is logged on this particular machine.

So everytime dsmc tries to read audit.log, the local auditing system will log, into that very file, that "dsmc tried to read audit.log, and we allowed it". So when dsmc had read the file and sent it to the server, it checks the last-changed-date and size, noticing those have changed in that time.

Total number of objects inspected:       58,902
Total number of objects backed up:           69
Total number of objects updated:             11
Total number of objects failed:               1
Total objects deduplicated:                  74
Total number of retries:                     30

After all per-file stats, we get a total summary for the current run, with objects failed: 1 in there. This will end up on the nightly report as:

UORUIJSMAMENW   FILE_2000         futu   4     4     4     4     4    HOST1

So in order to get successful runs and clean reports that point out other more "real" errors if they occur, you should add specific EXCLUDE rules to your dsm.sys/dsm.opt files for files.