Increase your recovery point agility with custom snapshot policies on Amazon FSx for NetApp ONTAP

Data has become a vital asset for individuals and businesses alike. As data continues to grow at an unprecedented pace, it becomes increasingly important for organizations to have robust data management solutions in place that address specific data protection and recovery requirements. When making decisions on how to achieve their recovery point SLAs, customers evaluate options such as backups, replication, and snapshots.

Storage volume snapshots are a powerful data protection technology that can help customers make sure of the availability, reliability, and security of their data. Amazon FSx for NetApp ONTAP provides fully managed, shared storage in the AWS Cloud with the popular data access and management capabilities of FSx for ONTAP. Snapshots are enabled by default with FSx for ONTAP filesystems.

In this post, we discuss the benefits of FSx for ONTAP volume snapshots, as well as their differences from backups. We cover how snapshots are orchestrated via snapshot policies and schedules. Then, we walk you through the process to create custom snapshot policies to suit your business recovery-point objectives (RPO).  The methods discussed in this post can help you in ensuring your data is protected and recoverable in the event of data loss.

Benefits of FSx for ONTAP volume snapshots

FSx for ONTAP volume snapshots let you create point-in-time images of a volume. Snapshots are created near instantly, as the technology leverages the efficient redirect on write approach (which utilizes pointers to blocks, as opposed to copying blocks when changes are made). Snapshots are stored alongside your file system’s data, so they consume the file system’s storage capacity. However, snapshots consume storage capacity only for the changed portions of files since the last snapshot. Snapshots provide a quick and efficient way to capture and recover data, reducing the risk of data loss and the ability to recover data swiftly.

• Fast and efficient: With snapshots created near-instantly, and storage efficient, you can create a snapshot in seconds, and it won’t impact your system performance.
• Reduced risk of data loss: With snapshots, your users can easily view and restore individual files or folders from an earlier snapshot. This enables users to self-service and easily undo changes and compare file versions. In the event of a system failure, you can quickly restore your data to the previous (or required) snapshot. Learn more about how to restore data from snapshots here.
• Reduced downtime: With snapshots, as the data is stored on the same file system, you can quickly recover your data, reducing the amount of downtime your business experiences.
• Cost-effective: Snapshots are a cost-effective way to protect your data. Only changed portions of the data consume storage capacity, and you can create multiple snapshots of the same volume with minimal storage consumption.

Differences between a snapshot and backups

Although snapshots are an excellent way to protect your data, they aren’t a replacement for actual backups. There are several differences between a snapshot and an actual backup:

Visit this link for more information on backups with FSx for ONTAP. 

Overview of snapshot policies and schedules

Organized and orchestrated volume snapshots are managed through snapshot policies and schedules. A snapshot policy is a set of rules that defines how snapshots are created and managed. The snapshot schedule within a snapshot policy defines when snapshots are created and the number of snapshots to retain. The main configurable components in a snapshot policy are:

• Schedule – time scheduled in the system scheduler (you can create new and custom job schedules).
• Count – number of snapshots to retain (maximum number of snapshots per volume is 1023).
• Prefix – by default, FSx for ONTAP forms the names of Snapshot copies by appending a timestamp to the job schedule name, though you can substitute this for a prefix name if required.
• SnapMirror Label – if your volume is the source of a custom SnapMirror/SnapVault relationship, then you can specify this option if you want that specific labelled snapshot to be transferred to the destination filesystem.

FSx for ONTAP provides three default snapshot schedules. However, snapshot policies and schedules can be customized to meet your specific protection and recovery requirements. For example, you can set up a policy to take a snapshot every hour and keep the last 24 snapshots, or you can set up a policy to take a snapshot once a day and keep the last seven days’ worth of snapshots.

The three built-in snapshot policies for FSx for ONTAP are:

• default
• default-1weekly
• none

Prerequisites

The following section assumes that the reader is familiar with the FSx for ONTAP file system, and has access to an SSH console.

• Fsxadmin username and password
• Access to an FSx for ONTAP File System management endpoint (see here.)
• SSH console (putty, shell, etc.)

Background

To view the snapshot policy details, you can log in to the management console via SSH to the IP address of the management endpoint, and enter “snapshot policy show”.

Figure 1: Built-in snapshot policy details

The default snapshot policy operates in the following way on the volume to which it has been assigned:

• Take snapshots every hour and maintain 6 snapshots.
• Take snapshots every day and maintain 2 snapshots.
• Take snapshots every week and maintain 2 snapshots.

The default-1weekly snapshot policy operates in the following way on the volume to which it has been assigned:

• Take snapshots every hour and maintain 6 snapshots.
• Take snapshots every day and maintain 2 snapshots.
• Take snapshots every week and maintain 1 snapshot.

The none snapshot policy doesn’t create any snapshots.

Follow this link for more information on how FSx for NetApp ONTAP works with default snapshots.

Note that the schedule name is selected from the job schedule of the system, and this is covered later on in this post.

By default, when you create new volumes, the default snapshot policy is applied, though this default behavior can be customized to suit your requirements. This configuration setting is set at the SVM level. Therefore, the volumes inherit this default, unless another snapshot policy is specified when a volume is created.

To view which policies are applied to your volumes, you can view “Snapshot policy name” in the AWS web console by selecting the file system and selecting the volume, or by entering the ::> volume show -fields snapshot-policy command as per the following via the command line:

Figure 2: Viewing snapshot policies assigned to volumes

Creating custom snapshot policies

Where the default snapshot policies don’t match your requirements, you can create custom snapshot policies. You can configure custom snapshot policies to create the recovery point object (RPO) required by your application and business needs.

After collecting your requirements, the steps to create and implement custom snapshot policies are:

• create the job schedule entries (similar to cron)
• create the snapshot policy, with entries to suit requirements
• apply to the volume/s required

Create job schedules

In this example, we create a requirement example for “AppX”, and detail the process to create the custom snapshot policy to suit. The example vserver is named AppX.

The first task is to create the specific job schedules to match the frequency and window requirements. The job schedule uses cron expression like syntax to specify the entries.

::> job schedule cron create -name AppX_Hourly  -dayofweek "Monday-Friday" -hour 6-18 -minute 10
::> job schedule cron create -name AppX_Daily  -dayofweek * -hour 23  -minute 0
::> job schedule cron create -name AppX_Monthly -month * -day 1 -hour 2 -minute 0

These schedules are filesystem wide and can be applied to volumes on the file system. To create SVM specific policies, add the “-vserver <svm name>” to the previous commands.

To view the schedules created, enter the command “::>job schedule show” to see the schedules created (and existing schedules).

Figure 3: View job schedules

Create snapshot policy

With the custom schedules now created, you can proceed to create the custom snapshot policy. In the syntax of the command entry, enter in the schedule names created and the count of snapshots to retain as per your requirements.

::> snapshot policy create -policy AppX_Policy -schedule1 AppX_Hourly -count1 12 -schedule2 AppX_Daily -count2 14 -schedule3 AppX_Monthly -count3 2 -enabled true

Validate that you have created the snapshot policy according to the requirements and that it is enabled.

Figure 4: View snapshot policy

Apply custom snapshot policy

Apply the custom snapshot policy to the volume/s required. The snapshot policy can be applied in three different variants:

• Apply to existing volume
• Apply to volume at creation time
• Apply snapshot policy to SVM and all newly created volumes inherit the snapshot policy

To apply to an existing volume, see the following example being applied to volume name “AppX_data01” in vserver “AppX”:

::> vol modify -vserver AppX -volume AppX_data01 -snapshot-policy AppX_Policy

To apply at volume creation, if entering via the AWS Management Console, you can select the volume snapshot policy, select Custom policy, and provide the name of the custom snapshot policy. If creating volumes via the FSx for ONTAP CLI, then enter the following snapshot policy information command when creating the new volume/s.

::> vol create -vserver AppX -volume AppX_data02 -aggregate aggr1 -size 1gb -snapshot-policy AppX_Policy

To apply the custom snapshot policy as the new default policy for all new volumes created in the specific SVM, then you must modify the SVM snapshot default.

::> vserver modify -vserver AppX -snapshot-policy AppX_Policy

Validate the successful application of your custom policy:

::> volume show -fields snapshot-policy
::> vserver modify -vserver AppX -snapshot-policy AppX_Policy

Figure 5: View custom snapshot policy on volume

Now with the custom snapshot policy applied, the snapshots are taken as per the policy schedules. To validate this, enter the “snap list -vserver AppX” command and the snapshots will be listed. In the following list, you can see the volumes that have been configured with the AppX_Policy have now been performing the snapshot as per the custom schedule. Meanwhile, the AppX_root volume is performing snapshots per the default snapshot schedule.

Figure 6: View of snapshots performed

Conclusion

In this post, we covered how you can use Amazon FSx for NetApp ONTAP snapshots to create fast and efficient recovery points to meet your recovery SLAs. Furthermore, you can leverage snapshots to create FlexClones, which are read-write presentations of data volumes. We discussed the differences between snapshots and backups, namely how they are different in terms of purpose, retention, recoverability, and redundancy. We covered the principles of snapshot policies, how they are applied, and the default values within FSx for ONTAP. Then, we walked you through a custom snapshot policy creation example and showed you examples of applying it at the volume level and SVM level.

By using custom snapshot schedules, you can achieve flexibility and agility to meet your application and business requirements. To learn more, visit the documentation or visit the Data Protection on FSx for ONTAP tutorial.