Previous Topic: Storing Change Detection Information for Physical BackupsNext Topic: Backing Up Special CMS Minidisks


Detecting Changes During Physical Incremental Backups

When defining the incremental backup job template file, the change detection options have the following meaning:

Hash

If the base catalog contains file-level detail, a changed track or group of blocks is to be detected by first computing a hash value of each CKD track or FBA group of blocks, then comparing the hashed results to the corresponding values in the base catalog.

If the base catalog contains domain-level detail, Hash specifies that a change is to be detected by hashing the contents of the entire minidisk and comparing the hashed results to the corresponding values in the base catalog.

The data is written to tape as the hash value is computed. If the hash value indicates that the minidisk has not changed, the data is overwritten on the tape. This may require a previous tape to be remounted if the data spans tapes. The assumption is made that most minidisks change day-to-day. If this is not the case at your site, you might want to turn off change detection for these minidisks or you might want to exclude them from the incremental backup.

None

None specifies that hashing will not be done at all; CA VM:Backup does not detect changes and performs a full backup of the minidisk. You may not want CA VM:Backup to detect changes if a minidisk changes frequently, and you want to minimize the chance that CA VM:Backup may remount a tape to overwrite the data on the tape.