For a detailed description of the feature, see the following topics:
Related Topics:
Data Aging is the removal of data from media that has aged. Data Aging first ages data based on the retention rules of a storage policy copy, and then removes that data based on the media recycling rules of the associated media. This will ensure data recoverability going back n number of days, which is specified in the user-defined retention rules. Only data that is classified as aged is removed when data aging operations are run.
Storage policy copies have configurable parameters called retention rules. These rules are called Basic Retention Rules and Extended Retention Rules (These are explained in the following sections.) In order to age data, both the Basic Retention Rules of retention days and retention cycles, and the Extended Retention Rules based on extended intervals of days must be exceeded for all jobs in a cycle. Most agents follow these rules. However, some have their own unique rules, as described in Agents With Unique Rules.
Data must be copied from a source copy (either the primary or a specified source copy) to a secondary copy during an auxiliary copy operation before data can be aged from that source copy.
After data is qualified to be aged, this data will be removed from media based on the following rules:
When all the data on a specific media is aged, that media is automatically recycled back to a scratch pool to be used again for future data protection operations. If you wish to perform data recovery operations from data that has been aged or save the media containing the data for future use, see Accessing Aged Data.
Most agents follow basic retention rules. See Support Information - Data Aging for more information.
Basic retention rules are defined by retention time and retention cycles. These parameters determine how much data is retained and for how long. For a cycle to be eligible for data aging, both of its retention time and retention cycles must be exceeded.
Retention time is defined as the amount of time that a cycle needs to be available for a single subclient. Retention time is calculated in terms of 24 hour days from the completion time of the last data protection job in a cycle until the start time of the data aging job.
Retention cycles are defined as the number of cycles that needs to be available for a single subclient. A full cycle begins with a full backup and includes all other non-full backups up to, but not including, the next full backup. When a full backup job runs, it is counted as a cycle.
The default settings for time and cycle parameters are set to infinite, but can be changed to better suit the retention requirement of the data being secured.
A cycle is defined as a group of data protection operations, starting with a full backup, including all subsequent data protection operations up to, but not including, the next full backup. A full backup without any subsequent incremental or differential backups is still counted as a cycle.
Each subclient has its own cycles. Each subclient is associated with a storage policy, and multiple subclients can share the same storage policy. Therefore, a single storage policy can contain cycles for multiple subclients.
| This example illustrates a storage policy that contains four full backup cycles of Subclient A and two full backup cycles of Subclient B. |
|
The backup data is retained in terms of the following:
The retention period implicitly suggests a relation between the amount of time that you want the data to remain restorable and the number of full backup cycles that you expect to complete during that time period. For example, a retention period of 14 days, 2 full cycles suggests that 2 full backup cycles are completed in a time period of 14 days, one full cycle a week. Consequently, for this subclient, it would be appropriate to schedule full backups on a weekly basis.
As another example, a retention period of 28 days, 2 full cycles suggests that 2 full backup cycles are completed in a time period of 28 days, one full cycle every two weeks. It would therefore be appropriate to schedule full backups on a biweekly basis.
As demonstrated by these examples, the full backup cycle (i.e., the length of time between full backups) for subclients, should be established by the ratio of the retention period parameters, specifically:
Length of time/Number of full cycles = Full backup cycle
For data to be aged from a primary or source copy, the following basic retention rules apply:
For data to be aged from a secondary copy (that is not a source copy), the following basic retention rules apply:
The following Storage Policy Copy Properties settings would result in data not being retained in the storage policy copy. Thus, these settings are only permitted for primary copies configured with at least one synchronous copy association:
Basic retention rules can be established from the Basic Retention Rules pane of the Retention tab of the Copy Properties dialog box, then the aging of data on that copy is based on time and cycles.
| This example illustrates four cycles, Cycle1, Cycle2, Cycle3, and Cycle4. Cycle1 includes F1, I1 and I1. Cycle2 includes F2, I2, and I2, Cycle3 includes F3, and I3, and Cycle4 includes F4 (F4 is still considered a cycle). When F2 completes on 9/8, the cycle count is two, when F3 completes on 9/15, the cycle count is three, and when F4 completes on 9/22, the cycle count is four. |
 |
| The way data is aged during data aging is dependent on the data retention rule that is defined for storage policy copies. If the retention rule is set for every 14 days and three cycles, data from the first full backup cycle will become eligible for data aging only when F4 completes on 9/22. Once F4 completes on 9/22, three cycles are available to meet the cycle retention criteria. Because Cycle1 completes on 9/6, it also meets the retention criteria you set of 14 days. Since the data from Cycle1 exceeds both retention criteria, it is eligible for data aging on 9/23. |
 |
|
|
When a user changes the storage policy association of a subclient, a subclient is deleted, or an agent or client is deconfigured, only the retention days must be exceeded for data to be aged. In these cases, retention cycles are set to zero (0). With this, users can temporarily suspend the activity of a client to age data without uninstalling the client software and without meeting the cycle retention requirement, thereby freeing up media faster for new data. For more information, see Suspend Use of a Client Computer Temporarily. |
Extended retention rules are defined in terms of weeks, months, and years. This enables you to retain data for a much longer period of time than with Basic Retention Rules. Each rule starts on the current day and counts backward in time according to each rule. Hence, if there are multiple extended retention rules, then there may be multiple reasons why a full backup is retained and not aged.
For each extended retention rule you must specify whether the first or last full backup within the time period of the rule is to be kept. If you select last full backup, only the last full backup within the time period will be picked if there are no remaining full data protection schedules for that subclient during that period.
See Also:
You can use a standard calendar or define and use a specific custom calendar. See Custom Calendar for more information.
|
|
Only full backup jobs can be retained by extended retention rules. Note that full backup jobs for some agents are not self contained because they require data from subsequent jobs in order to be successfully restored, and therefore, cannot be retained by extended retention rules. Since Oracle online and SQL File/File Group (FFG) full backup jobs are dependant upon corresponding transaction logs for restorability, their data will not be retained by extended retention rules. |
Extended Retention Rules are based on the following:
| All Fulls | All Full Backups |
| Weekly Full | The first or last full backup of every calendar week. |
| Monthly Full | The first or last full backup of every standard or custom calendar month. |
| Quarterly Full | The first or last full backup of every standard or custom calendar quarter year. |
| Half-yearly Full | The first or last full backup of each standard or custom calendar half year. |
| Yearly Full | The first or last full backup of each standard or custom calendar year. |
Note: If there are no custom months defined for the current time period, data aging operations will use the default standard calendar month definitions.
Extended retention rules allow you to retain data for extended periods of time. These rules can be defined from the Retention tab of the Copy Properties dialog box.
The following example illustrates if extended retention rules are selected for this copy and a data aging operation is run, based on the dates of a standard calendar. Note that these dates may differ if you are using a custom calendar.
|
The retention rules of this example are as follows:
If data aging is run on 1/23/03, then:
|
 |
|
|
|
Not all agents support standard data aging rules. The following agents have unique data aging rules due to the nature of their data and operations. See Support Information - Data Aging for more information.
Data Aging rules are unique for the DB2, Informix, and Sybase iDataAgents. This section describes these rules.
DB2 log files are aged at the backup set level; Informix and Sybase log files are aged at the instance level. For these iDataAgents, archive and logical log backups are not considered part of the backup cycle. Therefore storage policy cycle retention parameters do not apply to them and have their own set of data aging rules, as described in Transaction/Archive/Logical Log Backups.
|
|
For the DB2 and Informix, retention cycles are not used for copies involved in operations from the command line. For such operations, data is aged according to the associated retention time. |
Data Aging rules are unique for the Lotus Notes Database iDataAgents. This section describes these rules.
The Lotus Notes Database iDataAgent transaction log backups are not considered part of the backup cycle. Therefore, storage policy cycle retention parameters do not apply to them and have their own set of data aging rules, as described in Transaction/Archive/Logical Log Backups.
Data Aging rules are unique for the Oracle and Oracle RAC iDataAgents. The following sections describe these rules.
When a Data Aging job is run, the BackupPieceName UNAVAILABLE command is automatically issued to RMAN to disable specific backup pieces in the Oracle Recovery Catalog database that were pruned from the Media Manager CommServe tables. Any backup pieces that were aged from the system's database that have exceeded their retention criteria will be marked as unavailable in the Oracle Recovery Catalog database through this methodology. You can delete these specific backup pieces by creating and enabling the OracleDeleteAgedBackupPiece registry key. For mixed mode environments, where the CommServe is at the current release and the Oracle client is at a prior release, the synchronization is achieved through different means (e.g., CROSSCHECK) and you should consult the documentation for that prior release for more information.
By default the timeout for Oracle CROSSCHECK per instance is 600 seconds during data aging in mixed mode environments. You can modify this value (or disable the option) by using the OraCrossCheckTimeOut registry key.
|
|
For the Oracle and Oracle RAC iDataAgents, keep in mind that after uninstalling the iDataAgent software, CROSSCHECK will no longer be performed by the system to synchronize entries in the CommServe Database with the RMAN catalog. If either of these iDataAgents is later re-installed, then the next data aging job will synchronize the RMAN catalog with the CommServe Database unless the data on tape has been deleted (such as the case where the tape/volume was used for other backups and has been pruned). |
Data Aging for Archive Log files needs to be understood to prevent unintended loss of data. The storage policy for the archive log files is defined at the Instance (or database) level. This means that all the subclients defined for the instance use the same storage policy for backing up the archive log files and have their own set of data aging rules, as described in Transaction\Archive\Logical Log Backups.
A selective online full operation that consists of archive logs and oracle data can also be linked to the logs of a separate job, which was initiated within the time frame of the selective online full operation. These logs and the selective online full are then considered as one entity within the software, regardless of whether or not separate jobs have the same job ID. Therefore, they are copied to synchronous and selective copies together during auxiliary copy operations and are aged together. If any part of the selective online full is missing from a copy, the full will not be considered as a valid full and will not be counted as a cycle during data aging. Consider the following:
Data Aging for Oracle On Demand backup jobs uses days/time, and ignores cycles, as the determining factor for pruning the data. Therefore, once the retention time criteria has been met, all data (for both data and logs) is pruned that was backed up using the storage policy specified in the RMAN script that was run through the Command Line Interface.
Consider the following when developing a storage policy strategy for Oracle On Demand backups:
See Running RMAN Scripts using the Command Line Interface for more information.
An Oracle RMAN retention policy can be configured for each database. When
RMAN retention rules are in effect, RMAN considers the backup jobs comprising
data files and control files as obsolete, that is, no longer needed for
recovery, according to criteria that you specify in the
CONFIGURE RETENTION POLICY command. When
you run DELETE OBSOLETE or
CROSS CHECK operations, RMAN ages data by
freeing disk and tape space used by backups that are no longer needed.
Do not configure RMAN retention policy if you want to retain data using the data
aging feature provided in the CommCell console. To disable the RMAN retention
policy, use the following command: CONFIGURE RETENTION
POLICY TO NONE. This ensures that data will only be aged according to the
retention rules specified in the associated storage policy copy.
Data Aging rules are unique for the Microsoft SQL Server, Microsoft SQL Server 2000, and the Microsoft SQL Server 2005 iDataAgents. The following sections describe these rules.
Data Aging for the SQL Server iDataAgents performs the following stored procedures that you may have been manually running on Enterprise Manager. When Data Aging is run, the system ages these histories from the CommServe database and the SQL Server.
When you perform a back in time restore (i.e., restoring to a backup cycle earlier than the current backup cycle), all differential and transaction log backups which were run after the full backup from which the restored data was obtained will not be able to be aged until a new full backup is run. Running a full backup after performing a back in time restore releases the older backups and subsequent log backups for data aging.
SQL Server iDataAgent's transaction log backups are not considered part of the backup cycle. Therefore, storage policy retention cycle parameters do not apply to them and have their own set of data aging rules, as described in Transaction/Archive/Logical Log Backups.
Data Aging rules are unique for the DataMigrator and DataArchiver agents. All data and jobs in a migration or archive operation, must meet the basic or extended retention rules in days (as specified in a copy of a DataMigrator/Archiver storage policy) in order to be aged. The DataMigrator and DataArchiver agents do not support retention cycles.
|
|
To promote consistent data availability of all of the data migrated or archived by the DataMigrator and DataArchiver agents, it is recommended that all subclients be associated with storage policies whose primary copies have the same retention period. |
The Quick Recovery Agent can age, or delete, QR Volumes that are older than the retention period specified in the associated QR Policy. The Quick Recovery Agent will also attempt to free any destination volumes that were marked as allocated, or locked, but are not currently referenced by any QR Volume. For example, this condition may arise when a Create/Update QR Volume job is terminated unexpectedly. QR Volume data aging takes place in the context of the data aging job that runs periodically on the CommServe.
The following constraints apply to QR Volume data aging:
The QR Agent creates snapshots or QR Volumes for use with Recovery Director. These snapshots and QR Volumes are aged as described in the Quick Recovery section above. However, Recovery Director has the following exception: When a snapshot or QR Volume is part of a work flow, and jobs from that workflow are running, the snapshot or QR Volume cannot be aged until all of the jobs in the work flow are complete.
This is true even in cases where the snapshot or QR Volume has passed its retention period, and Data Aging is run on the CommServe.
ASR backups are only performed in full, there are no incremental or differential ASR backups. Therefore, ASR backups are aged in full, and independently of other backup operations. For example, an ASR backup will be preserved past its retention period until another ASR backup is run, even if full backups have been run on the client.
Transaction/archive/logical log (log) backups are not considered part of the backup cycle. Therefore, storage policy cycle retention parameters do not apply to them. The following are the unique data aging rules for log backups:
The sections that follow include the data aging of other scenarios.
If data aging is performed on a primary copy and there are no secondary copies defined, the data on the primary copy can be aged provided the data has exceeded its specified retention criteria.
| In this example, the retention criteria of the primary copy is set to five days and one cycle. If data aging is run on 9/13, no data is eligible for data aging. Although the retention criteria of one cycle is met, data has not been retained for a 5 day period. |
 |
| However, if data aging is run again on 9/17, F1 and I1 can be aged, as the retention rule of one cycle and five days is met. |
 |
The data aging of a secondary copy is dependent on the selected retention criteria set for that copy. In the following example, the primary copy has a retention rule of four days and two cycles, and the synchronous copy has a retention rule of two days and two cycles.
| In this example, if data aging is run on 9/18, no data can be aged from the primary copy because the retention rule of the primary copy was not met. However, F1 and I1 from the synchronous copy can be aged because the retention rule of the synchronous copy of two days and two cycles was met. |
 |
Data aging can be performed on a storage policy that has synchronous and/or selective copies defined. Data can be aged according to its retention rule) from the primary copy only when all data that is eligible to be aged has been copied to all active copies during an auxiliary copy operation.
| In this example, the data retention rule for the primary copy is set to one day and one cycle. (The retention rule of the secondary copy is greater than the retention rule of the primary copy. Data from Tape 1, Tape 2, and Tape 3 was copied to the secondary copy when an auxiliary copy job is run on 9/13. If data aging is run on 9/15, data from Tape 1, Tape 2, and Tape 3 can be aged. |
 |
| In this example, the data retention rule for the primary copy is also set to one day and one cycle. (The retention rule of the secondary copy is greater than the retention rule of the primary copy.) Data from Tape 1, Tape 2 and Tape 3 has not yet been copied to the secondary copy. If data aging is run on 9/14, no data can be aged from the primary copy. Data that has exceeded its retention criteria cannot be aged until that data is copied to the secondary copy. |
 |
The source copy feature allows you to select a copy other than the primary copy to be used as the source copy from which data is copied during an auxiliary copy operation. A source copy can be selected from the Copy Policy tab of the Copy Properties dialog box.
The rules for data aging on source copies are as follows:
The following examples illustrate how data is aged from a storage policy that has three copies; primary copy Primary_01, Secondary_01, and Secondary_02. Secondary_02 uses Secondary_01 as a source copy. The retention rules for each copy are as follows:
| In the first example, if a data aging operation is run on 10/2, F1 can be aged from the primary copy as the retention rule for F1 was met. Data from Secondary_01 cannot be aged as it is the source copy for Secondary_02, and data has not yet been copied to Secondary_02. |
 |
| In the next example, F1 can be aged from Secondary_01 after an auxiliary copy operation copies that data onto Secondary_02 on 9/2, and a data aging operation is run on 10/2. |
 |
If data aging is performed on a storage policy that has an incremental storage policy enabled, the data aging operation counts backup cycles across both full and incremental storage policies. Data on a full storage policy is aged based on the retention of the full storage policy, and data on the incremental policy is aged based on the retention rules of the incremental policy.
If the incremental storage policy is also being used as a regular storage policy (and has full backups), the full backups will be also aged according to any basic and extended retention rules that are set.
It is recommended that the retention rule for the full storage policy is greater than the incremental storage policy. Data on incremental policy will be aged earlier if it has shorter retention than the full storage policy. If the incremental storage policy has longer retention than a full storage policy, this may result in dangling incremental jobs.
|
In this example, a full storage policy has a basic retention rule of 7 days and 3 cycles. An incremental storage policy has a basic retention rule of 3 days and 2 cycles. If data aging is run on 10/2, F1 and F2 can be aged from the full storage policy. I1, D1, I2, D2, I3, and D3 can be aged from the incremental storage policy. |
 |
For more information on incremental storage policies, see Incremental Storage Policy.
If data aging is performed on a storage policy copy that has disabled jobs, these jobs are aged differently. If the disabled job is a full backup job, the entire cycle is marked as disabled. In this case, data aging does not count the disabled full backup as a valid cycle. If the disabled job is an incremental or differential backup and the full backup job is not disabled, the cycle is counted as a valid cycle. For more information on disabled jobs, see Storage Policy Copy Operations.
|
In this example, the data retention rule for the primary copy is set to one day and four cycles. Prior to the job being disabled, there are five cycles (the most recent being F5 and the oldest being F1). In this case, the oldest cycle (F1, I1) could be aged because they satisfy the retention criteria of both days and cycles. When the second cycle becomes disabled, there are only four valid cycles. The oldest cycle will count F1, I1, F2, and I2 as one cycle, and F3, F4, F5 will be counted as independent cycles. If a data aging operation is run on 9/14, and F2 and I2 are marked as disabled, none of the cycles on this storage policy can be aged.
|
 |
Magnetic disks offer the best choice of media type for fast data protection and recovery operations. Magnetic disks are often used to spool the data before it is archived to tape for long term and/or offsite storage. Using Managed Disk Space data on magnetic disks can be retained as long as possible without running out of disk capacity and affecting future data protection operations. Managed Disk Space provides a way to prune data according to disk capacity in addition to the existing retention criteria which is usually defined by number of days as well as full cycles of data. This adds another layer of retention parameter in addition to specified days/cycles.
Two disk capacity thresholds for managed disk space can be defined. They are:
When disk capacity reaches a high threshold, e.g., 85%, older data automatically qualify for removal. They are removed from the disk if they meet their retention criteria and have been copied to appropriate secondary copies. The aging process automatically stops when the disk capacity reaches a low threshold, e.g., 70%.
Once the managed disk is set up the process runs automatically without user intervention to manage disk capacity. Data protection operations are retained on disk longer than usual providing the benefits of magnetic storage without having to spend manual efforts to manage the disk capacity.
The Enable Managed Disk Space for magnetic data option is available in the Retention tab of the Copy Properties dialog box. (By default, this option is disabled in all copies.)
The pre-defined thresholds for disk capacity for a magnetic library can be defined in the Mount Paths tab of the Library Properties (associated with a magnetic library) dialog box.
Data Aging determines the pruning based on jobs - jobs with older data (based on the creation time of its first archive file) is pruned first. Once the Data Aging operation determines the jobs to be pruned, data will be deleted based on the established threshold. The frequency for checking the disk space and deleting data is determined by the frequency established in the Interval (Minutes) between magnetic space updates option established in the Service Configuration tab of the Media Management Configuration dialog box in the Control Panel.
See Enable Managed Disk Space for Magnetic Data for step-by-step instructions.
The following other types of data can be removed during a data aging operation:
The following table describes when job history is removed based on the type of job history and the status of the job:
| Job Type | Job Status | When it is Aged |
| Data Protection Job History/Disaster Recovery Backup Job History | Successful | With its associated data, which is aged based on the associated storage policy copy's defined retention rules. |
| Failed/Killed | 90 Days | |
| Data Recovery Job History (including CDR Recovery operations) | Any | 90 Days |
| Administration Job History | Any | 90 Days |
|
|
Job history is also removed during the deletion of a storage policy or storage policy copy. |
The number of days job history will be retained before it is aged can be changed from the default of 90 days using the jobHistoryLifeSpan registry key.
If you want to change the number of days that DataArchiver recovery job history is kept, you can use the archiverRestoreHistoryLifeSpan registry key.
When the specified retention rule of Audit Trail data is exceeded, Audit Trail operations are aged when a data aging operation is run. For more information, see Audit Trail.
Data from Erase Backup/Migrate operations can be aged as follows:
Data aging operations can either be run on demand or started immediately. By default, data aging is run every day at 12:00 p.m.
The Data Aging Options dialog box allows you to either start a data aging operation immediately from the Run Immediately option, or schedule it using the Schedule option. You can also run a data aging operation from the Command Line Interface. For more information, see Command Line Interface.
Data Aging can be enabled or disabled on a storage policy copy. Disabling Data Aging prevents a Data Aging operation from aging data from a copy when the operation is run, even after the retention rules for that copy have been met.
Alerts allow you to send notifications related to data aging events. Alerts can be configured during the initiation of a data aging operation. For a detailed explanation of Alerts, see Alerts and Monitoring.
Click the Job Retry tab in the Data Aging Options dialog box to access the Job Running Time options, when you either Start Data Aging or Schedule Data Aging.
You can also specify the maximum number of allowed restart attempts and the interval between restart attempts for all data aging jobs. For procedures, see Specify Job Restartability for the CommCell.
For more information on these subjects, see Job Restart and Job Running Time.
If data stored on tape media exceeds its retention rule and the data aging operation is run, the data is logically deleted. If all of the data on a media is aged, the media is recycled; that is, it is returned to the scratch pool that is currently associated with the storage policy copy that writes to the media. If you wish to save the data on the media for future recovery, see Accessing Aged Data. Once the tape media is re-used, the data that was originally written to it cannot be restored.
Media that has an active status is not recycled back to the scratch pool until the media has a non-active status.
For more information, see Media Recycling.
Keep in mind these considerations when performing a data aging operation:
System may override the user defined retention rules under the following cases:
When a user changes the storage policy association of a subclient, a subclient is deleted, or an agent or client is deconfigured, only the retention days must be exceeded for data to be aged. In these cases, retention cycles are set to zero (0).
If a user changes the storage policy association of a subclient:
All subclient data that was backed up through the previous storage policy will be aged based on its storage policy copy retention time (days) rule only. If you select to run a full backup after changing the storage policy, all subclient data on the new storage policy will be aged according to its retention time and cycle rules. If you select to run a non-full backup as the next backup operation, it is recommended that you run a full backup as soon as possible. All non-full backups run before a full backup will be retained as a partial cycle according to the new storage policy copy's retention cycle rule (even though not a full cycle). The non-full backups (partial cycle) will be aged when the new storage policy copy's retention time and cycle rules are met.
For more information, see Associate a Subclient to a Storage Policy.
This software supports all these modes by setting the retention property on each data object when submitting a Cclip which is used to register the data with Centera for storage. The Cclip reflects a retention date that is based on the number of retention days on the Storage Policy Copy Properties. Once the date is set on the Cclip, changing the Storage Policy Copy to a shorter retention will not change the existing Cclips and attempts to prune the data on the device will be denied until it is aged based on the Cclip value. (For information on Cclips and setting-up the data retention on Centera Clusters, refer to the Centera documentation.)
The Data on Media and Aging Forecast Report provides real-time and historical information from of data protection jobs, associated media, data aging forecast and recyclable media.
The Data Aging Job Summary Report provides real-time and historical information about data aging operations.
