CommVault Simpana 8 backup tips: Storage policies and data retention
Learn important data backup tips using CommVault Simpana 8 about storage policies and data retention.
What you will learn in this tip: Anyone who has ever worked with CommVault Simpana 8 knows that it's an elaborate, full-featured backup application. In this article, I will share data backup tips relating to storage policies and data retention with Simpana.
Because space limitations prohibit a comprehensive discussion of all of the best practices for using Simpana 8, I will be focusing my discussion on storage policies and data retention. As I do, I will also be discussing some of the CommVault Simpana's nuances that may cause you to get unexpected results from your data backup jobs.
Storage policies in CommVault Simpana 8
In Simpana, a storage policy is a mechanism that maps data from its original location to the media that is used by the backup. Typically, storage policies are used to control the number of simultaneous streams used during a backup or recovery option. Storage policies can also be used to define retention periods for sub clients.
There are several considerations involving storage policies. For starters, CommVault recommends that you do not make any modifications to a storage policy during an operation that is directly related to the policy. In other words, if you are performing a backup, a recovery operation, a data aging operation, etc., you shouldn't make any changes to the corresponding storage policy until the operation has completed. Doing so can cause the operation to fail. Furthermore, a storage policy cannot be deleted if any related operation is currently running. However, CommVault will allow you to disrupt a policy-based operation by modifying the policy, according to the software's documentation, but they caution against this.
Another best practice regarding storage policies is that if you change a storage policy, you must convert the next backup operation to a full backup. In other words, if you switch to using a different storage policy, you will need to do a full backup. Otherwise, data aging operations won't age any of the data from after the most recent full backup. If you have already changed a storage policy without converting the next backup operation to a full backup, then you can resume the data aging operations by either creating a full backup on the sub client on which you have changed the storage policy, or by waiting until the data's retention criteria has been met.
Data retention periods
CommVault Simpana automatically associates a data retention period for Disaster Recovery Backup data sets. By default, this retention period is set to 60 days and 60 cycles. You can set it at a shorter period (such as 30 days), but CommVault specifically warns against using a shorter retention period. Of course, some organizations may require a longer retention period, or may want to disable the retention period altogether.
If you need to change the retention period, then CommVault recommends that you keep the default setting as the minimum retention period. After doing so, you can use the predefined extended retention rules to configure the software to adhere to your retention requirements.
More resources on CommVault Simpana
Read about how Simpana 8 supports Microsoft Exchange
News on how Simpana now has cloud data storage
Watch a video about CommVault Simpana 8
As you define the retention rules (retention rules are a part of the storage policy) for your backups, it's important to keep in mind that Simpana 8 performs aging differently for multiplexed data than it does for non-multiplexed data. Multiplexed data is not aged until all of the jobs within a single chunk have reached the retention period specified within the storage policy. That way, you don't end up in a situation in which part of a multiplexed dataset is aged while the rest of the multiplexed data is not.
Retention override
Another best practice regarding retention periods is that you need to be aware of the safeguards that are built into Simpana. Even if you define your own retention periods, there are certain types of situations in which the backup software will ignore your rules, which might lead to some unexpected results. As such, a best practice is to take these safeguards into account when you are planning your retention policies as well as any time that you are performing general maintenance.
As you might have guessed from the previous sentence, there are some maintenance actions that can throw your retention settings into disarray. Depending on the action, you may not receive a warning from the software. Some of these actions include:
- Associating a sub client with a different storage policy
- Deleting a client
- Deleting an agent
- Deleting a sub client
If you perform any of these actions, then Simpana will continue to honor the number of retention days that must elapse before the data is aged. However, Simpana will set the number of cycles in the retention period to zero, which essentially tells the software to ignore them. Then, Simpana treats the retention settings as if they were only based on the number of days that have elapsed since the backup was created. Once the specified number of days pass, the backup is aged, which is CommVault-speak for expired. Likewise, the software will completely ignore retention settings for "Data To Be Copied" jobs on source copies.
For the most part, setting up backups through CommVault Simpana 8 is a relatively straightforward process. When you begin making modifications, however, you can impact your backups in some ways that you might not have expected. Adhering to these best practices can help you to avoid surprises.
About the author:
Brien M. Posey, MCSE, has previously received Microsoft's MVP award for Exchange Server, Windows Server and Internet Information Server (IIS). Brien has served as CIO for a nationwide chain of hospitals and was once responsible for the Department of Information Management at Fort Knox. You can visit Brien's personal website at www.brienposey.com.
