Data Aging is the process of removing old data from secondary storage to allow the associated media to be reused for future backups.
By default, all backup data is retained infinitely. However, you should
change the retention of your data based on your needs. Note that if you continue
to have infinite retention, you will also need infinite storage capacity.
1.
From the CommCell Browser, navigate to Policies | Storage
Policies.
2.
Highlight the Storage Policy.
3.
From the right pane, right-click the Storage Policy
Copy and click the Properties.
4.
Click the Retention tab.
Click the Retain For in the Basic Retention Rules for
All Backups area.
Enter number of days to retain the data.
Enter number of cycles to retain the data.
Click OK.
5.
From the CommCell Browser, click the Reports icon.
6.
Expand Reports and select Data Retention Forecast and
Compliance.
7.
Click Run.
8.
The report will display the data to be pruned when a data
aging job is run.
To ensure only data intended for aging is actually
aged, it is important to identify the data that will be aged based
on the retention rules you have configured. Hence, ensure this report
includes only the data you intend to age.
If necessary, fine-tune your rules so that only the intended
data is aged.
Once you run a data aging job, the data will be lost.
9.
From the CommCell Console, right click the CommServe icon
and click All Tasks | Data Aging.
10.
Select Immediate in the Job Initiation section and
click OK.
11.
You can track the progress of the job from the Job Controller
window. When the job has completed, the Job Controller displays Completed.
Make sure that the job completes successfully. If the job did not complete
successfully, re-run the job.
In all other cases, it is recommended that the Auxiliary Copy feature be used
for extended storage as it actually creates another physical copy of the data,
thereby reducing the risk of data loss due to media failure.
Understanding Extended Retention Rules
Extended retention allows you to retain a specific full (or synthetic full)
backup for an additional period of time. For example, you may want to retain
your monthly full backups for 90 days.
Extended retention rules allow you to define three additional "extended"
retention periods for full (or synthetic full) backups. For example:
You may want to retain your weekly full backups for 30 days.
You may want to retain your monthly full backup for 90 days.
You may want to retain your yearly full backup for 365 days.
A backup job will be selected for extended retention based on its start time.
For example: If a backup job starts at 11:55 pm on August 31st and ends at 1 am
on September 1st, then it will be selected as the last full backup for the month
of August and will be picked up for extended retention.
Setting Up Extended Retention Rules
Use the following steps for setting up the extended retention rules:
Right-click the storage policy copy and click Properties.
Click the Retention tab.
Set the basic retention rules by clicking Retain for and entering the number of days and cycles appropriate for your organization.
Set the extended retention rules as follows:
Click the For
button.
Enter the number of Days
Total to retain the backup.
Click the Keep drop-down list, and select the desired backup
criteria (e.g., Monthly Full).
Click the Grace Days drop-down list and
select the number of days (e.g., 2).
Repeat Step 4 to configure additional extended retention.
Log Backups (transaction, archive, or logical logs) are not considered part
of the backup cycle. Therefore, storage policy cycle retention parameters do not
apply to them.
Log backups may be linked to data backup operations,
which can allow storage policy cycle retention parameters to be applied to them.
This can be achieved as follows:
If a full backup job is run on data, then the next log backup job
will be linked to this full backup job.
These are considered as linked or chained log backups
and are not aged until the linked data
is aged. In addition, the following is also considered:
Logs that need to be copied to secondary copies will not be aged
both on primary and non-primary source
copy
Logs that exist only on one copy will be aged when they are older
than the oldest data
Logs that exist on multiple copies will be aged according to copy
retention days
Logs that exist on multiple copies with the longest retention days
will be aged when they are older than the oldest data
Partial, disabled logs will be aged when they are older than the
oldest data
If a full backup job is run on data and logs, then the next log
backup will not be linked to this full backup job.
As this is an unlinked log backup, by default, this will follow the
unique data aging rules for log backups. If you want such log backups to be aged according to the defined days
retention rule for the data, you can do so as follows:
From the CommCell Browser, select Tools | Control Panel.
Double-click Media Management
Click the Data Aging tab.
Enable the Prune All Database Agent Logs Only By Days Retention Rule
option.
Click OK.
Linking Full and Log Backups for Data Retention
Log backups are linked to a full backup if they are run at the same
time and the
JMEnableJobLinkForSQL_LNDB key created in the client computer.
This is regardless of whether the full backup included data only or
data and logs. Such backups follows the standard data aging rules.
You can
create the key as follows:
From the CommCell Browser, navigate to Client Computers.
Right-click the <Client> and then click Properties.
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.
Data Aging for On Demand backup jobs uses days/time, and ignores cycles and
extended retention rules, 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 Command Line
Interface.
An effective storage policy strategy for SQL On Demand backups is as follows:
The same storage policy should not be used for regular backups and On
Demand backups.
The storage policy copy containing logs of On Demand backups should have
a much longer retention time than other storage policies used by regular
backups for the same instance. This is to prevent the logs of On Demand
backups from being pruned before the data of regular backups, and allow the
database to be fully restored and recovered using the data of old regular
backups and logs afterwards.
By default, Data Aging jobs do not perform a client-side clean-up of
database metadata. However, to ensure that unnecessary data is not left behind, you
can either use the system stored procedures mentioned below per SQL instance:
<sp_delete_backuphistory>
<sp_delete_database_backuphistory>
<sp_delete_backup_and_restore_history>
Or enable client-side clean-up of database metadata process as follows:
From the CommCell Browser, navigate to Client Computer.
Right-click the <CommServe Client> and then click Properties.
