The availability of this feature is limited based on the license type, region, and other criteria. To access this feature, contact your Druva Account Manager or Druva Support. This article/documentation is subject to change based on the continuous improvements to this feature.
In our day-to-day lives, we like to arrange our books, clothes, and other items in a way that helps us keep the more frequently used ones at an arm’s reach, while the less frequently used ones take a back seat. We call this behavior “being organized” and this sense of organization helps us save some precious time. Now, when you apply the same sense of organization in your data protection with Phoenix, you not only save time but money too. Say hello to Long Term Retention, or as we like to call it - LTR!
Before using this feature, it’s a good idea for you to identify data suitable for long term retention. This is the data that you wouldn’t mind keeping away for a while but is still important enough to retain (say for compliance purposes). Also, you shouldn’t mind a higher RTO for this data, which means that it can have a higher tolerable recovery time. Upon successfully identifying such data, by using Phoenix that leverages the capabilities of Amazon Glacier Deep Archive (GDA as cold tier) for data protection, you can:
Reduce your overall data protection cost by up to 30%.
Protect data for the long term to address legal and compliance needs.
Meet your RTO SLAs with the latest backups.
Several pieces are involved in how your data gets to the cold tier and is restored. Let’s take a look at the workflow to know how it works.
Note: Long Term Retention (LTR) is not available for Phoenix Gov cloud.
Here’s what happens:
You identify the backup sets that protect the data that you deem suitable for long term retention. This is the data that you want to retain for one year or longer and for which the RTO requirement relaxes after 15 days.
You buy credits based on your estimation of LTR and Non-LTR data.
You then set the retention period as one year or more in the backup policy and enable LTR for this policy.
Note: The one-year retention period can be in the form of daily, weekly, monthly, or yearly backups. For example:
And, then comes the best part! You begin getting cost benefit immediately on your storage. All data in the LTR backup sets consume lower credits.
Snapshots older than 15 days of an LTR-enabled backup set are transitioned to the cold tier.
At the time of restore, this data is first retrieved from the cold tier and stored in the warm tier, where it resides temporarily for at most 10 days, and then restored.
On a high level, this is pretty much it! But, to get the most out of this feature, you need to know the details of the eligibility criteria, the data restore process, and early delete fees. Read on to find out!
Terms to know
- Warm snapshots: Warm snapshots are point-in-time copies of backup data of the last 15 days. These snapshots are stored in the Amazon S3 storage. Data from warm snapshots can be restored immediately.
- Cold snapshots: Cold snapshots are point-in-time copies of backup data older than 15 days. These snapshots are stored in the Amazon Glacier Deep Archive. To restore data from cold snapshots, data needs to be first retrieved from Amazon Glacier Deep Archive before a restore can be triggered.
The eligibility criterion for LTR
The cold tier is designed to reduce cost on data that you retain for long term. Hence, only the backup sets for which the retention period is greater than or equal to one year are eligible for LTR.
The LTR enable option is available only for the backup policies with LTR-eligible retention period. For more information on enabling LTR, see Enabling Long Term Retention.
Note: In the case of Hyper-V and VMware, when LTR is enabled for a backup policy, file-level restore on cold snapshots is not supported.
Say you had LTR enabled on a backup policy and based on this backup policy, your data moved to the cold tier. Upon disabling LTR, data will stop getting transferred to the cold tier. However, your existing data in the cold tier will remain in the cold tier until it expires.
Impact on non-LTR backup policies
In short, there is no intelligent tiering for non-LTR backup policies. All the snapshots are stored in the warm tier. You can initiate restoration from non-LTR backup sets regardless of the age of the snapshot.
Restoration of cold-tier data
At the time of restore, data from the cold tier is retrieved, moved temporarily to the warm tier, and then restored. Once you click Restore and initiate the restoration process, the data retrieval from cold tier and its restore from the warm tier happen automatically. Warmed up data is deleted from the warm tier after 10 days.
RTO for cold data = data retrieve time + data restore time
Data retrieve time is the time needed to identify the cold blocks and initiate and retrieve data blocks from the cold tier (typically 12-36 hours).
Data restore time is the time needed to restore the data. This is similar to the restoration of data from the warm tier once the data retrieval process from the cold tier is complete.
When you enable LTR, you begin getting a 30% cost reduction on your credits from that moment on. This cost reduction is applicable to the total size of the associated backup set(s) post deduplication. Let us explain this to you in detail. Take a look at the following comparison between credit consumption of a backup set with LTR not enabled (A) and a backup set with LTR enabled (B).
|Backup Set||LTR Enabled?||Data size after deduplication||Credit consumption rate per TB||Credits consumed||Credit Savings|
|A||No||100 TB||1 credit per month||100||0|
|B||Yes||100 TB||0.7 credit per month||70||30|
As you can see, with the same size of data stored (100 TB), you can save 30 credits in a month by enabling LTR.
Calculation of credit consumption
The formula to calculate the total number of credits consumed for a backup set is as follows:
Credit Consumption (in Credits) = (Deduped backup set data size)* (Credit consumption rate per TB per month)* (number of months the data is retained for)
Early delete fee
If you delete your data before the one-year retention period completes, Druva incurs an early delete cost. Hence, we charge you an early delete fee depending on the size of your data that you deleted early from the cold tier. The early delete fee is recorded in your billing.
Conditions for early delete fee
An early delete fee will apply if your snapshots get expired due to reduction of the retention period.
An early delete fee will apply if you manually delete the cold snapshots, backup sets or servers with cold snapshots.
Note: Snapshots older than one year (after LTR enable) will not incur any early delete fee.
Calculation of early delete fee
We’d calculate the early delete fee for early deletion of snapshots, backup sets, and servers (provided some or all data resides in the cold tier) and the same would reflect in your billing. Early deletion refers to the data that gets deleted before one year of the retention period. The early delete fee is calculated based on the size of the data that gets deleted from the cold tier earlier than one year.
Early Delete Fee (in credits) = 0.35*(12 - # months in cold tier)*(Data deleted in TB)
In this article, we gave you an insight into LTR that has a list of benefits such as saving you money, helping you address compliance, and meet your RTO SLAs.
Now that you’ve fairly understood the feature, go ahead and do some savings by enabling LTR!