Cloud Backup policy configuration settings

Contributors netapp-tonacki

This document describes the backup policy configuration settings for Cloud Backup.

Backup schedules

Cloud Backup enables you to create multiple backup policies with unique schedules for each working environment. You can assign different backup policies to volumes that have different recovery point objectives (RPO).

Each backup policy provides a section for Labels & Retention that you can apply to your backup files.

A screenshot of the Backup Schedule settings when creating a backup policy.

There are two parts of the schedule; the Label and the Retention value:

  • The label defines how often a backup file is created from the volume. You can select among the following types of labels:

    • You can choose one, or a combination of, hourly, daily, weekly, monthly, and yearly timeframes.

    • You can select one of the system-defined policies that provide backups and retention for 3 months, 1 year, and 7 years.

    • If you have created custom backup protection policies on the cluster using ONTAP System Manager or the ONTAP CLI, you can select one of those policies.

  • The retention value defines how many backup files for each label (timeframe) are retained. Once the maximum number of backups have been reached in a category, or interval, older backups are removed so you always have the most current backups. This also saves you storage costs because obsolete backups don’t continue to take up space in the cloud.

For example, say you create a backup policy that creates 7 weekly and 12 monthly backups:

  • each week and each month a backup file is created for the volume

  • at the 8th week, the first weekly backup is replaced by the weekly backup for the 8th week (keeping a maximum of 7 weekly backups)

  • at the 13th month, the first monthly backup is replaced by the monthly backup for the 13th month (keeping a maximum of 12 monthly backups)

DataLock and Ransomware protection

Cloud Backup provides support for DataLock and Ransomware protection for your volume backups. These features enable you to lock your backup files and scan them to detect possible ransomware on backup files. This is an optional setting that you can define in your backup policies when you want extra protection for your volume backups for a cluster.

Both of these features protect your backup files so that you’ll always have a valid backup file to recover data from in case of a ransomware attack on your source data. It’s also helpful to meet certain regulatory requirements where backups need to be locked and retained for a certain period of time. When DataLock and Ransomware Protection is enabled, the cloud bucket that is provisioned as a part of Cloud Backup activation will have object locking and object versioning enabled.

This feature does not provide protection for your source volumes, only for the backups of those source volumes. Use NetApp Cloud Insights and Cloud Secure, or some of the anti-ransomware protections provided from ONTAP to protect your source volumes.

Caution
  • If you plan to use DataLock and Ransomware protection, you must enable it when creating your first backup policy and activating Cloud Backup for that cluster.

  • DataLock and Ransomware protection can’t be disabled for a cluster once it has been configured. Do not enable this feature on a cluster to try it out.

What is DataLock

DataLock protects your backup files from being modified or deleted for a certain period of time. This functionality uses technology from the object storage provider for "object locking". The period of time that the backup file is locked (and retained) is called the DataLock Retention Period. It is based on the backup policy schedule and retention setting that you defined; plus a 14 day buffer. Any DataLock retention policy that is less than 30 days is rounded up to 30 days minimum.

Be aware that old backups are deleted after the DataLock Retention Period expires, not after the backup policy retention period expires.

Let’s look at some examples of how this works:

  • If you create a Monthly backup schedule with 12 retentions, your backups are locked for 12 months (plus 14 days) before they are deleted (replaced by the next backup file).

  • If you create a backup policy that creates 30 daily, 7 weekly, 12 monthly backups there will be three locked retention periods. The "30 daily" backups would be retained for 44 days (30 days plus 14 days buffer), the "7 weekly" backups would be retained for 9 weeks (7 weeks plus 14 days), and the "12 monthly" backups would be retained for 12 months (plus 14 days).

  • If you create an Hourly backup schedule with 24 retentions, you’d think that Backups are locked for 24 hours. However, since that is less than the minimum of 30 days, each backup will be locked and retained for 44 days (30 days plus 14 days buffer).

    You can see in this last case that if each backup file is locked for 44 days, you’ll end up with many more backup files than would typically be retained with an hourly/24 retentions policy. Usually, once Cloud Backup creates the 25th backup file it would delete the oldest backup to keep the maximum retentions at 24 (based on the policy). The DataLock retention setting overrides the policy retention setting from your backup policy in this case. This could affect your storage costs as your backup files will be saved in the object store for a longer period of time.

What is Ransomware protection

Ransomware protection scans your backup files to look for evidence of a ransomware attack. The detection of ransomware attacks is performed using checksum comparison. If potential ransomware is identified in a backup file versus the previous backup file, that newer backup file is replaced by the most recent backup file that does not show any signs of a ransomware attack. (The file that was identified as having a ransomware attack is deleted 1 day after it has been replaced.)

Ransomware scans happen at 3 points in the backup and restore process:

  • When a backup file is created

    The scan is not performed on the backup file when it is first written to cloud storage, but when the next backup file is written. For example, if you have a weekly backup schedule set for Tuesday, on Tuesday the 14th a backup is created. Then on Tuesday the 21st another backup is created. The ransomware scan is run on the backup file from the 14th at this time.

  • When you attempt to restore data from a backup file

    You can choose to run a scan before restoring data from a backup file, or skip this scan.

  • Manually

    You can run an on-demand ransomware protection scan at any time to verify the health of a specific backup file. This can be useful if you’ve had a ransomware issue on a particular volume and you want to verify that the backups for that volume are not affected.

Caution A ransomware scan requires that the backup file is downloaded to your Cloud Manager environment (where the Connector is installed). This can incur extra egress costs from your cloud provider if you have deployed the Connector on your premises. Therefore, we recommend that you deploy the Connector in the cloud, and that it is in the same region as the bucket where your backups are being stored.

DataLock and Ransomware Protection settings

Each backup policy provides a section for DataLock and Ransomware Protection that you can apply to your backup files.

A screenshot of the DataLock and Ransomware Protection settings when creating a backup policy.

You can choose from the following settings for each backup policy:

  • None (Default)

    DataLock protection and ransomware protection are disabled.

  • Governance (Not available with StorageGRID)

    DataLock is set to Governance mode where users with specific permissions (see below) can overwrite or delete backup files during the retention period. Ransomware protection is enabled.

  • Compliance

    DataLock is set to Compliance mode where no users can overwrite or delete backup files during the retention period. Ransomware protection is enabled.

Note The StorageGRID S3 Object Lock feature provides a single DataLock mode that is equivalent to Compliance mode. An equivalent Governance mode is not supported, so no users have the capability to bypass retention settings, overwrite protected backups, or delete backups.

Supported working environments and object storage providers

You can enable DataLock and Ransomware protection on ONTAP volumes from the following working environments when using object storage in the following public and private cloud providers. Additional cloud providers will be added in future releases.

Source Working Environment Backup File Destination

Cloud Volumes ONTAP in AWS

Amazon S3

On-premises ONTAP system

Amazon S3
NetApp StorageGRID

Requirements

  • Your clusters must running ONTAP 9.11.1 or greater

  • You must be using Cloud Manager 3.9.21 or greater

  • For AWS, the Connector must deployed in the cloud

  • The following S3 permissions must be part of the IAM role that provides the Connector with permissions. They reside in the "backupS3Policy" section for the resource "arn:aws:s3:::netapp-backup-*":

    • s3:GetObjectVersionTagging

    • s3:GetBucketObjectLockConfiguration

    • s3:GetObjectVersionAcl

    • s3:PutObjectTagging

    • s3:DeleteObject

    • s3:DeleteObjectTagging

    • s3:GetObjectRetention

    • s3:DeleteObjectVersionTagging

    • s3:PutObject

    • s3:GetObject

    • s3:PutBucketObjectLockConfiguration

    • s3:GetLifecycleConfiguration

    • s3:ListBucketByTags

    • s3:GetBucketTagging

    • s3:DeleteObjectVersion

    • s3:ListBucketVersions

    • s3:ListBucket

    • s3:PutBucketTagging

    • s3:GetObjectTagging

    • s3:PutBucketVersioning

    • s3:PutObjectVersionTagging

    • s3:GetBucketVersioning

    • s3:GetBucketAcl

    • s3:BypassGovernanceRetention

    • s3:PutObjectRetention

    • s3:GetBucketLocation

    • s3:GetObjectVersion

      "s3:BypassGovernanceRetention" must be added only if you want your Admin users to be able to overwrite/delete backup files locked using Governance mode.

  • For StorageGRID:

    • The Connector must be deployed on your premises (it can be installed in a site with or without internet access)

    • StorageGRID 11.6.0.3 and greater is required for full support of DataLock capabilities

Restrictions

  • DataLock and Ransomware protection is not available if you have configured archival storage in the backup policy.

  • The DataLock option you select when activating Cloud Backup (either Governance or Compliance) must be used for all backup policies for that cluster. You cannot use both Governance and Compliance mode locking on a single cluster.

  • If you enable DataLock, all volume backups will be locked. You can’t mix locked and non-locked volume backups for a single cluster.

  • DataLock and Ransomware protection is applicable for new volume backups using a backup policy with DataLock and Ransomware protection enabled. You can’t enable this feature after Cloud Backup has been activated.

Archival storage settings

When using certain cloud storage you can move older backup files to a less expensive storage class/access tier after a certain number of days. Note that archival storage can’t be used if you have enabled DataLock.

Data in archival tiers can’t be accessed immediately when needed, and will require a higher retrieval cost, so you need to consider how often you may need to restore data from archived backup files.

When creating backup files in AWS or Azure, each backup policy provides a section for Archival Policy that you can apply to your backup files.

A screenshot of the Archival Policy settings when creating a backup policy.

  • In AWS, backups start in the Standard storage class and transition to the Standard-Infrequent Access storage class after 30 days.

    If your cluster is using ONTAP 9.10.1 or greater, you can choose to tier older backups to either S3 Glacier or S3 Glacier Deep Archive storage in the Cloud Backup UI after a certain number of days for further cost optimization. Learn more about AWS archival storage.

    Note that if you choose S3 Glacier or S3 Glacier Deep Archive in your first backup policy when activating Cloud Backup, then that tier will be the only archive tier available for future backup policies for that cluster. And if you select no archive tier in your first backup policy, then S3 Glacier will be your only archive option for future policies.

  • In Azure, backups are associated with the Cool access tier.

    If your cluster is using ONTAP 9.10.1 or greater, you can choose to tier older backups to Azure Archive storage in the Cloud Backup UI after a certain number of days for further cost optimization. Learn more about Azure archival storage.

  • In GCP, backups are associated with the Standard storage class by default.

    You can use the lower cost Nearline storage class, or the Coldline or Archive storage classes. However, you configure these other storage classes through Google, not through the Cloud Backup UI. See the Google topic Storage classes for information about changing the default storage class for a Google Cloud Storage bucket.

  • In StorageGRID, backups are associated with the Standard storage class.

    There is no archival tier available at this time.