Topics | How To | Support | Related Topics
Storage policies act as the primary channels through which data is included in data protection and data recovery operations. A storage policy forms the primary logical entity through which a subclient or instance is backed up. Its chief function is to map data from its original location to a physical media. The system provides a default iDataAgent storage policy for each media library, stand-alone, or magnetic drive once they are configured.
You can create storage policies to:
For example, where it may be necessary to restore/recover old data, you may want to create a storage policy with longer retention periods when performing data protection operations on a server. On the other hand, if the data being protected is not as critical, you can set a shorter retention period in order to release the media more quickly.
For example, if you set a stream count to three in the storage policy:
When a storage policy is configured to use more than one data stream, it is important that the data streams are equally used; parallel copying using multiple source and destination drives may not be effective if the data is concentrated in one stream. The stream randomization feature enables random choosing of the data streams, increasing the rate of data transfer by copying data from different streams in parallel. See Enable Stream Randomization for instructions.
Also, it is recommended that you configure the tuning parameters to evenly distribute the data across all the streams. You can specify the interval to check the data size in the streams and the threshold to decide data distribution among the streams. See Tune Stream Randomization for instructions.
A secondary copy of a storage policy provides a means of making an additional copy of backed up data and is used in auxiliary copy operations, or data protection operations that create inline copies.
If you are using the Quick Recovery Agent, this agent uses QR Policies for the data included in the agent's Quick Recovery Creation operations. For more information on QR Policies, see QR Policies.
Two types of storage policies can be defined. They are:
The following sections provide a brief description of the storage policies.
A standard storage policy can be created to run both iDataAgent Backup and DataArchiver archiving operations.
The Standard storage policy for iDataAgent Backups is used by subclients associated with iDataAgents, to perform backup and restore operations. Subclients can be configured to use storage policies using one of the following methods:
By default, the retention period for the iDataAgent Backup data is set for an infinite period of time. This retention period can be modified to better suit your data retention needs. If the retention time is changed, it is recommended that you keep this data for a minimum of 15 days and two cycles. For more information on changing retention rules, see Retention.
The Standard storage policy for DataArchiver Archiving is used by subclients associated with DataArchiver agents, to perform archiving and recovery/retrieval of archived data. The retention period for DataArchiver data can only be set by time, not cycles.
By default, the retention period for the DataArchiver data is set to be retained for an infinite period of time. If you want to change this retention time, it is recommended that it be set for a minimum of 365 days.
For more information on the DataArchiver agents, see the appropriate product features page.
| Quick Recovery Agent uses QR policies for QR volume creation and QR volume recovery operations. |
As an extra protection to rebuild your CommCell in the event of a disaster, Disaster Recovery Backup storage policies are used to store metadata to media. This metadata stores information about the CommCell and the backed up data. In case of a system failure, you can get Disaster Recovery Backup data back from the media used by the Disaster Recovery Backup storage policy. Though standard storage policies can be used for Disaster Recovery Backup data, it is not recommended.
A default Disaster Recovery Backup storage policy [CommServeDR (host name)] is automatically created when the first library in the CommCell is configured. This type of storage policy is recommended because it only writes the Disaster Recovery Backup data to the media, and its default retention period is defined as 60 days and 60 cycles, which can be easily changed during configuration. The media being used for this storage policy should be removable to prevent accidental data loss due to system failure. If the first library configured is a magnetic library, change your Disaster Recovery Backup configuration to use a Disaster Recovery Backup storage policy associated with a tape library as soon as the first tape library is configured. You can create as many Disaster Recovery Backup storage policies as needed.
By default, the retention period for Disaster Recovery Backup data is set to be retained for 60 days and 60 cycles. If you want to change the retention time for Disaster Recovery Backup data, it is recommended that you keep the default setting as the minimum with predefined extended retention rules defined as: weekly = 180 days, and monthly = infinite.
For more information, see Disaster Recovery Backup.
Storage policy operations allow you various options for customization and maintenance. These include features such as optimizing tape speeds, verifying data validity for restoring and copying, and ensuring alternate data paths.
Various storage policy operations dealing with creation and maintenance are available in the CommCell Browser at the storage policy level. These options are discussed below.
You can create a storage policy in the CommCell Console from the Storage Policy level. A Storage Policy Wizard guides you through the process of creating a storage policy. By default, the primary copy gets created when a new storage policy is created.
When a storage policy is created, the software automatically creates a primary copy. All data from data protection operations from the subclient(s) is channeled through the primary copy.
In addition, you can create any number of additional secondary copies to the same/different libraries and MediaAgents. These copies are components of storage policies and are used in auxiliary copy operations, and can either be synchronous or selective. For more information about storage policy copies, see Storage Policy Copies.
During an Auxiliary Copy operation, data is copied from the primary copy to the secondary (synchronous or selective) copies that you have defined.
You can configure a copy for Data Verification so that all backups, all full backups, or backups occurring on or after a certain date will be verified during a data verification operation.
The Cloning Policies feature allows you duplicate a storage policy that retains all of the options of the original storage policy. A cloned storage policy is identical to the original policy, except it does not retain the original associated subclients. See Cloning Policies for an overview.
You may decide to delete a storage policy if:
You can view the media that has data that has not yet been copied to all secondary copies within a storage policy. This will help you determine which media are required for operations, and how much data must be copied.
This media can be viewed from the Media Not Copied dialog box.
You can view and perform operations on the jobs that reside on, or are scheduled to be copied to, a storage policy copy. For more information on the View Jobs feature, see Jobs on a Storage Policy Copy. Selecting the Advanced button provides you with additional viewing options, which you can select in the Jobs in Storage Policy Advanced Filter Options dialog box. From here, you can view jobs based on:
Results will display in the Job for Storage Policy Copy window.
You can view the schedules of jobs associated with a storage policy copy. For more information, see Scheduling.
You can configure and run content indexing operations. For more information, see Content Indexing.
When you create a subclient, you must associate that subclient with a storage policy. The associated storage policy enables the data protection/archive operations and recovery/retrieve operations to be conducted for the subclient’s data. When the data stored on media meets its retention criteria and data aging is run, the data is logically deleted (i.e., removed from the CommServe database). If all of the data on a media is pruned, the media is recycled. That is, it is returned to the scratch pool that is currently associated with the storage policy copy containing the media.
It is good practice to limit the number of storage policies in your CommCell environment; this will better utilize your media since media cannot be shared across storage policies. Limiting the number of storage policies means using less media to store your data. Whereas having many storage policies in your environment would utilize much more media to store the same amount of data.
If you currently have many storage policies in your environment, you can consolidate your storage policies by following these steps:
|
CAUTION Do not delete the storage policies that are no longer being used. Deletion of a storage policy prior to all data being aged from the associated media will lead to a loss of data. |
There are several things to consider when reassigning subclient storage policy associations, refer to Considerations: Subclients.
If a storage policy is inactive, it is not recommended that it be deleted due to a potential loss of data if the deletion of the storage policy occurs prior to all the data being aged from the associated media. It is best to disable it for additional subclient associations to to prevent new backup operations from running to that storage policy. For more information, see Disable/Enable Additional Subclient Associations for a Storage Policy. Note that when a storage policy is marked as disabled for subclient associations, the storage policy will not be listed as available when creating/or editing the associations of a subclient. The subclient will also not be available for association when a new client is being installed to the CommServe, which has a disabled storage policy.
The storage policy level media password is used to prevent unauthorized access to the data residing on media used by the system for a storage policy. If not enabled, the CommServe Level Media Password is the default password. To see how to enable this feature, see Password Protect the Media of a Storage Policy.
If you choose to password protect your media, it is essential that you record this password. In certain disaster recovery scenarios, it may be necessary to read your backup data directly from the backup media (using Media Explorer, for example). This password will be required to directly access the media.
If a Storage Policy was changed without converting the next backup operation to a full backup, data aging operations will not age the data after the last full backup until:
In an environment with NAS NDMP file servers, consider the following when creating and using storage policies:
NAS NDMP Load-Balancing - The Drive Pools, Storage Policies, and Subclients for NAS NDMP can be configured so that backup, restore, and auxiliary copy jobs will be spread among different MediaAgent, and thus the processor load for these jobs will occur on different machines. For more information, see Subclients - NAS NDMP - Load-Balancing Considerations.
When a user changes the storage policy association of a subclient, a subclient is deleted, or a client or an agent is deleted, only the retention days must be exceeded for data to be aged. In these cases, retention cycles are set to zero (0). However, when a client or an agent is deconfigured, the associated data will be aged according to the associated storage policy copy’s defined retention time and cycle rules. In this case, retention cycles are honored. If necessary, you can enable the Ignore Cycles Retention on De-Configured Clients option from the control panel’s Media Management Configuration (Service Configuration) dialog box so that the defined retention cycle rules are ignored for the data associated with deconfigured clients.
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 Data Aging.
- NDMP Remote Server
- File System iDataAgent
For NAS NDMP subclients using NRS, there are specific considerations for storage policies to be used. For more information, see NAS NDMP Clients.
- one for full and differential database backups
- one for the storage policy's own Incremental backup.
- one for full and differential database backups
- one for the storage policy's own Incremental backup
- one for transaction log backups.
If you want to perform a synthetic full backup using an alternate MediaAgent (one other than the MediaAgent used for the Primary backup), you must configure an Incremental Storage Policy.
Operations performed with this feature are recorded in the Audit Trail. See Audit Trail for more information.
The Storage Policy Report provides information about the storage policies and associated subclients based on the selected filter criteria.