CA VM:Backup stores the following change-detection information in the catalog for each of the following backup formats.
CA VM:Backup stores file and minidisk date information in the catalog.
Note: Date is the default option for CMS backups.
CA VM:Backup uses a hash value to determine whether the contents of a file or minidisk have changed.
When creating file-level catalogs, CA VM:Backup computes a hash value of the contents of each file that is backed up and stores the values in the catalog.
When creating domain-level catalogs, CA VM:Backup computes a hash value of the contents of each minidisk that is backed up and stores the values in the catalog.
Select this option if you have applications that use non-CMS access methods that do not update the information in the file status table (FST) when modifying files or minidisks.
CA VM:Backup uses a hash value to determine whether the contents of a minidisk have changed.
When creating file-level catalogs, CA VM:Backup computes a hash value of the contents of each CKD track or FBA group of blocks that is backed up. CA VM:Backup stores the values in the catalog.
When creating domain-level catalogs, CA VM:Backup computes a hash value of the contents of each minidisk that is backed up. CA VM:Backup stores the values in the catalog.
Hash is the default option for physical backups.
CA VM:Backup does not save hash values for change detection. When you select None, CA VM:Backup cannot detect changes. Incremental backup jobs will perform a full backup of these minidisks.
Note: You may decide against saving hash values for physical backups if a minidisk changes or is restored frequently. Not saving hash values reduces the number of CPU cycles that CA VM:Backup uses and can result in improved backup performance.
When backing up SFS and BFS data, CA VM:Backup always computes a special hash value to detect changes in a file space. The entry in the Change Detection field has no effect.
To allow CA VM:Backup to detect changes, specify the same type of change detection in the full backup and incremental backup templates. When you specify different types of change detection for the full and incremental backups, CA VM:Backup is unable to detect changes when the incremental backup is submitted.
When CA VM:Backup is unable to detect changes for a domain in an incremental backup, a full backup is taken of that domain. If you specify CMSALLOC as the backup format in an incremental backup job template, CA VM:Backup automatically performs a full backup. CA VM:Backup ignores the specifications in the template for detecting changes.
When you select Date change detection, CA VM:Backup compares the date that is stored in the catalog with the current date of the file or minidisk to be backed up. This comparison determines whether the contents of the file or minidisk have changed.
When you select Hash change detection, CA VM:Backup recomputes the hash value for each file, CKD track, FBA group of blocks, or minidisk. The product compares this hash value with the value stored in the catalog to determine whether the contents of the file or minidisk have changed.
When you select None for an incremental backup, CA VM:Backup does not detect changes and performs a full backup.
Example
For a CMS backup, you select Date for a full backup. CA VM:Backup does not compute and store hash values for data. You then select Hash for the incremental backup. CA VM:Backup cannot determine whether data has changed because there are no hash values in the catalog that the full backup created. Therefore, CA VM:Backup performs a full backup instead of an incremental backup.
|
Copyright © 2014 CA Technologies.
All rights reserved.
|
|