Understanding BlueXP Backup and Recovery DataLock and Ransomware Feature TCO
The BlueXP Backup and Recovery DataLock and Ransomware feature is a critical component of data protection, designed to safeguard against ransomware attacks and ensure the integrity and availability of valuable data.
Enabling the DataLock and Ransomware Scan feature can lead to an increase in the TCO cost incurred by the customer. This is because activating the feature may require additional cloud API calls, resulting in additional ongoing expenses. Customers need to assess the potential financial impact and weigh it against the benefits provided by the feature before enabling it.
This blog will explore the calculation of Total Cost of Ownership (TCO) and offer insights on cost reduction strategies that customers can implement.
Understanding DataLock and Ransomware Scan Costing
The DataLock and Ransomware scan Total Cost of Ownership depends on the following factors
- The cost of each ONTAP backup
- Recurring cost from Ontap to readjust retention until date of shared objects
- Cost of running regular scans for ransomware detection
To explain each scenario let’s take an example of a Volume of 1 TB being backed up into the Object store with the DataLock and Ransomware feature enabled.
1. Cost of Each ONTAP Backup
When backing up a new volume of 1TB, ONTAP backs snapshots in 4MB blocks to the S3 object store (1TB snapshots will be stored as 250K objects). Supposing that the snapshot daily change rate is 5%. This would essentially mean that the subsequent backup would only transfer 12.5K objects to the S3 object-store.
For the first transfer, ONTAP uses the Put Object (with retention) and Read-after-write GET Object S3 API call on all the 250K objects to transfer the objects to the S3 object store and stamp the Retention-Until-Date.
For the subsequent incremental backups, ONTAP employs only the Put Object (with retention) and Read-after-write GET Object S3 API operations for the new or modified data that results in generating 12,500 objects. These 12,500 objects are then transferred to the object store, with each object being marked with a Retention-Until-Date.
The approx. S3 API charges incurred to the customers for moving the snapshots on a daily basis would be as follows
- 1-year cost for backing up 1TB with a change rate of 5%:- ~$24
- 1-year cost for backing up 10TB with a change rate of 5%:- ~$245
- 1-year cost for Backing up 100TB with the change rate of 5%:- $2450
|
Cost of each Subsequent Ontap backup |
|||||
|
Average version count per object |
1 |
1 |
|
|
|
|
Number of object versions |
12500 |
237500 |
|
|
|
|
|
|||||
|
API Call |
For unique objects |
For shared objects |
Total |
Cost (per 1000 requests - in $) |
Cost (In $) |
|
List Object Versions |
0 |
0 |
0 |
0.005 |
0 |
|
Head Object |
0 |
0 |
0 |
0.0004 |
0 |
|
Put Object (with retention) |
12500 |
0 |
12500 |
0.005 |
0.0625 |
|
Put Object Retention |
0 |
0 |
0 |
0.005 |
0 |
|
Read-after-write GET Object |
12500 |
0 |
12500 |
0.0004 |
0.005 |
|
Total Cost (For the given snapshot size) |
0.0675 |
||||
2. Recurring cost from ONTAP to re-adjust retention of shared objects
To lock an object, objects should be stamped with a “Retention Until Date” commonly known as RUD. Cloud providers provide a way to set the RUD on the objects moved to the object store during which the object cannot be deleted or overwritten. “Retention Until Date” or RUD is calculated by ONTAP based on the “Snapshot Retention Period” or SRP set by the user and is stamped in the object metadata while writing the objects to the object store. The Snapshot Retention Period’(SRP) is calculated as per the label defined by the user in the Backup policy .
Now let's come back to the example of a 1TB volume, Let's imagine the volume has 3 daily taken S1, S2, and S3. Please keep in consideration that there are blocks shared between the 3 snapshots. When snapshot S1 was taken, the blocks were stamped with RUD(t1). Now when daily snapshot S2, S3 ,S4 ... S28 are taken, they are all stamped with the same RUD(t1) . When S29th snapshot is taken after 28 days have been elapsed, a new RUD(t29) will have been stamped on the S29th snapshot that causes a disparity in the RUD of all the shared blocks.
To address this disparity, ONTAP performs a re-adjustment of the RUD every 28 days and will be stamped with the latest RUD on all the shared blocks. This process ensures that all shared blocks are recomputed and stamped with the latest RUD, thereby maintaining the desired retention date accurately. By periodically re-evaluating and updating the RUD, ONTAP ensures the proper enforcement of retention policies and reduces inconsistencies in the RUD stamps across shared blocks.
|
Recurring cost from Ontap to readjust retention of shared objects (per restamping) |
|||||
|
Average version count per object |
1 |
1 |
|
|
|
|
Number of object versions |
12500 |
237500 |
|
|
|
|
|
|||||
|
API Call |
For unique objects |
For shared objects |
Total |
Cost (per 1000 requests - in $) |
Cost (In $) |
|
List Object Versions |
0 |
237500 |
237500 |
0.005 |
1.1875 |
|
Head Object |
0 |
237500 |
237500 |
0.0004 |
0.095 |
|
Put Object Retention |
0 |
237500 |
237500 |
0.005 |
1.1875 |
|
Total Cost (For the given snapshot size) |
2.47 |
||||
For readjusting the RUD on shared objects, ONTAP uses the ListObjectVersions, HeadObject, and PutObjectRetention S3 APIs. When backing up a new volume of 1TB, ONTAP backups snapshots in 4MB blocks to the S3 object store (1TB snapshot will be stored as 250K objects in the object store). Supposing that the snapshot change rate is 5%. This would essentially mean that the subsequent backup would only transfer 12.5K objects to the S3 object store and the shared objects would be 237.5K. Therefore, the readjusting of retention should be done for all the 237.5K shared objects
The approx. S3 API charges incurred to the customers for readjusting of retention would be as follows
- 1 year cost for 1TB with daily change rate of 5%:- ~$32
- 1 year cost for 10TB with daily change rate of 5%:- ~$320
- 1 year cost for 100TB with daily change rate of 5%:- $3200
3.Cost of running regular scans for ransomware detection
Ransomware scans/Integrity checks are run on the objects stored in the object store to make sure that there are no ransomware attacks on the backups.
By default, ransomware scans are run as soon as the backup activation is completed with a policy that has the DataLock & Ransomware feature enabled. The ransomware scan runs on the latest snapshot available in the volume at the time of scan and does not scan all the snapshots. Also, please note, that by default, the ransomware scan frequency interval is 7 days.
Now users have the option to disable Ransomware Scan from the “Configure Advance Settings” or configure the ransomware scan frequency interval from 1 to 7 days.
Now let's come back to the example of a 1TB volume, l snapshots taken namely S1, S2, S3, S4, S5, S6, and S7. Based on the ransomware scan frequency interval set, (by default, it's set to 7 days), then only snapshot S7 will be scanned. If there is more than 1 snapshot eligible for a scan based on the frequency set, only the latest snapshot among the eligible ones will be scanned.
When conducting Integrity/Ransomware scans, the system performs a "List Object Versions" operation on each object to determine whether any modifications or deletions have occurred due to a Ransomware attack. Approximately 250,000 "List Object Versions" operations are executed for a 1TB size backup to ensure object integrity.
In the event of snapshot corruption, the system will leverage a suite of APIs, including "List Object Versions", "Get Object", "Head Object", "Get Object Retention", "Put Object", "Put Object Retention", and "Read-after-write GET Object". These APIs facilitate the scanning and restoration of objects to their last known good state, version 1 copy . This process ensures that any corruption is addressed and that objects are successfully recovered, enabling the backup system to be reinstated.
The table below outlines the total quantity of API calls executed along with their associated costs.
|
Integrity Scan when there are corruptions and recovery happens - ADC scan (Worst case cost when every object of a backup is overwritten by ransomware) |
|||||
|
|
Unique objects |
Shared objects |
Total |
Cost (per 1000 requests - in $) |
Cost (In $) |
|
% Corruption |
100% |
100% |
|
|
|
|
Corrupt object count |
7500 |
|
|
|
|
|
Average version count per object |
2 |
2 |
|
|
|
|
Number of object versions |
15000 |
485000 |
|
|
|
|
|
|||||
|
List Object Versions |
7500 |
242500 |
250000 |
0.005 |
1.25 |
|
Get Object |
15000 |
485000 |
500000 |
0.0004 |
0.2 |
|
Head Object |
15000 |
485000 |
500000 |
0.0004 |
0.2 |
|
Get Object Retention |
7500 |
242500 |
250000 |
0.0004 |
0.1 |
|
Put Object |
7500 |
242500 |
250000 |
0.005 |
1.25 |
|
Put Object Retention |
7500 |
242500 |
250000 |
0.005 |
1.25 |
|
Read-after-write GET Object |
7500 |
242500 |
250000 |
0.0004 |
0.1 |
|
Total Cost in $ (For the given snapshot size) |
4.35 |
||||
- Total 1-year cost for 1TB with change rate of 5%:- ~$284
- Total 1 year cost for 10TB with change rate of 5%:- ~$2836
- Total 1 year cost for 100TB with change rate of 5%:- $28365
Recommended ONTAP Versions
Customers are advised to update their systems to either ONTAP release version 9.12.1 P13 or 9.13.1 P10. These particular versions include important patches that address issues related to the Retention Until Date stamping. By resolving these issues, the updated versions help to decrease the overall costs associated with the system. This could be because the fixes may lead to more efficient data management, reduce unnecessary API calls, or optimize storage operations, all of which can contribute to lower operational expenses.
Decoupling DataLock and Ransomware Scan Feature
Previously, when the DataLock and Ransomware Scan feature was enabled through the policy, both features were automatically activated simultaneously. This meant that if users wanted to disable the Ransomware Scan feature, they had no option to do so without also disabling the DataLock feature. This lack of flexibility could result in additional charges from the cloud provider if scheduled ransomware scans were enabled.
To avoid these extra charges, users now can disable the scheduled ransomware scans while keeping the DataLock feature active. This allows users to customize their security settings and avoid incurring unnecessary costs from the cloud provider.
Please Note: -
Even if the scheduled ransomware scans are disabled, users can still perform on-demand scans when needed. For example, before a restore operation, users can choose to scan the backup to ensure its integrity and security. This ensures that users have the flexibility to perform necessary scans while maintaining control over their costs and security measures.
Current Behaviour
However, recent updates have addressed this limitation, providing users with the flexibility to selectively enable or disable the Ransomware Scan feature while keeping the DataLock feature active.
- While enabling the DataLock and Ransomware Scan feature through the Backup Policy creation process, both features will be enabled. However, users will have the option to disable ransomware scans on the “Ransomware Scan” widget under the “Configure Advanced Settings” tab under the “Backup Settings” tab on the Volume Dashboard page.
- In order to disable the Ransomware Scan, move the “Enable Ransomware” slider to the left.
- You can re-enable the Ransomware Scan by moving the “Enable Ransomware” slider to the right. You can also set the scheduled ransomware scan to run on a certain frequency ranging from 1 to 7 days.
How to mitigate the costs of DataLock
The strategy to lower the cost of DataLock involves understanding the level of protection that is needed for the given dataset. What is the risk tolerance? If the risk tolerance is very low, then you will want the highest level of protection which will be the most expensive. If the risk tolerance is high, then perhaps DataLock is not required.
Let’s consider the levels of protection customers can choose.
- Standard backup with SnapLock protection: BlueXP backup and recovery’s immutable strategy is powered by NetApp Snapshot™ technology. It uses WAFL® (Write Anywhere File Layout) technology where the original data volume isn’t modified but rather uses new data blocks for updated data. Pointers reference these new data blocks without editing the original data. NetApp SnapLock is built into ONTAP storage systems and is supported out of the box in BlueXP backup and recovery. It acts as a line of defense against ransomware attacks targeting your backup copies.
- DataLock without ransomware scan: The DataLock feature incorporates object storage service WORM capabilities with BlueXP backup and recovery. This provides an additional layer of protection for backup data in the destination storage. DataLock supports the native WORM capabilities of AWS and Azure as well as on-prem StorageGRID object storage. The WORM protection for destination can either be in “Governance” mode or “Compliance mode. For Azure we can configure the protection in “Lock” mode and “Unlock” mode.. While Governance mode offers some flexibility to administrators to overwrite or delete protected data, Compliance mode ensures complete indelibility until RUD expires. This helps meet stringent data security standards of highly regulated environments. The data cannot be overwritten or modified during its lifecycle, providing the strongest level of protection for your backup data copies. With DataLock protecting these volumes as WORM in destination, BlueXP backup and recovery enables end-to-end ransomware protection for your data.
- DataLock with ransomware scan: To provide an additional layer of security for your data, BlueXP backup and recovery includes a ransomware scan and protection feature. It helps detect any attempts to change backup copies and recover a consistent copy of your data. If any attempt is made to overwrite the DataLock-protected WORM data copy, a new version of the object is created discreetly.
The ransomware protection feature in BlueXP backup and recovery will compare the checksum of the two versions of the object and generate an alert if a ransomware attack is detected. These scans are initiated while transferring data to object store, during restore, at regular intervals, or on-demand as required by the user. The restore process is initiated based on the scan process and helps with point-in-time recovery.
The default scan interval is 7 days but it can be set to 1,2,3,4,5,or 6 days. In the example above if the scan interval is 1 day the ransomware scan cost rises to from $6,518 to $45,625.
You can get estimates for the cost associated with DataLock by visiting the BlueXP backup and recovery TCO calculator.
For more information:
Documentation
DataLock and Ransomware protection options
Advanced settings - Enable or disable ransomware scans
Blogs
Fighting Ransomware with NetApp BlueXP Backup and Recovery
The BlueXP Feature that Protects Backups from Ransomware
Cloud Backup: DataLock and Ransomware Protection Support
