Working with backups - FSx for ONTAP

Working with backups

With FSx for ONTAP, you can take automatic daily backups and user-initiated backups of the volumes on your file system. Amazon FSx backups are per volume; that is, each backup contains only the data in a particular volume. Amazon FSx backups are highly durable and incremental.

Amazon FSx backups are incremental, whether they are generated using the automatic daily backup or the user-initiated backup feature. This means that only the data on the volume that has changed after your most recent backup is saved. This minimizes the time required to create the backup and saves on storage costs by not duplicating data. When you delete a backup, only the data unique to that backup is removed. Each Amazon FSx backup contains all of the information that is needed to create a new volume from the backup, effectively restoring a point-in-time snapshot of the file system volume.

Creating regular backups for your volumes is a best practice that helps support your backup retention and compliance needs. Working with Amazon FSx backups is easy, whether it's creating backups, restoring from a backup, or deleting a backup.

Amazon FSx supports backing up ONTAP FlexVol volumes (on all file systems) and FlexGroup volumes (on file systems created after November 15, 2023) with an OntapVolumeType of RW (read-write). Support for backing up FlexGroup volumes on existing file systems is scheduled for a future maintenance window. In order to back up your data, your volume and your file system's primary SSD storage tier must both have enough available storage capacity to take a backup snapshot. For the backup snapshot to be taken, the additional capacity consumed by the volume snapshot cannot cause the volume to exceed 98% utilization. It is best practice to not exceed 80% utilization of your volume's primary SSD storage tier.


Amazon FSx does not currently support backing up data protection (DP) volumes or load-sharing (LS) volumes.

How backups work

Amazon FSx backups use snapshots – point-in-time, read-only images of your volumes – to maintain incrementality between backups. Each time a backup is taken, Amazon FSx first takes a snapshot of your volume (the snapshot is stored in your volume, and consumes space on your SSD storage tier). Amazon FSx then compares this snapshot to the previous backup snapshot (if one exists) and copies only the changed data into your backup. If no prior backup snapshot exists, then the entire contents of the most recent backup snapshot is copied into your backup. After the latest backup snapshot is successfully taken, Amazon FSx deletes the previous backup snapshot. The snapshot used for the latest backup remains in your volume until the next backup is taken, when the process repeats.

Working with automatic daily backups

By default, Amazon FSx creates an automatic daily backup of your file system's volumes. These automatic daily backups occur during the daily backup window that is automatically set for each file system upon its creation, and the daily backup window can be modified at any time. We recommend that you choose a convenient time of the day for your daily backup. This time ideally is outside of the normal operating hours for the applications that use your volumes.

When you create a file system using the AWS Management Console, the AWS CLI, or the API, the default automatic daily backup retention period is 30 days. You can modify the retention period for automatic backups to any number of days between 1 and 90. Setting the retention period to 0 days using the Amazon FSx CLI or API turns off automatic daily backups.

The daily backup window and the backup retention period are system-level settings that apply to all of the volumes on your file system. You can use the Amazon FSx console, the AWS CLI, or the API to change the backup window and backup retention period for your file systems, and to turn automatic daily backups on or off. For more information, see Updating a file system.


Automatic daily backups have a maximum retention period of 90 days, but backups that you create, also called user-initiated backups (including backups created using AWS Backup) are kept forever unless you or the AWS Backup service deletes them. For more information about user-initiated backups, see Working with user-initiated backups.

When you delete a volume, you also delete the automatic daily backups for that volume. Amazon FSx provides the option to create a final backup of a volume before you delete it. The final backup is kept forever, unless you delete it.

Working with user-initiated backups

With Amazon FSx, you can manually take backups of your file system's volumes at any time. You can do so using the Amazon FSx console, API, or the AWS Command Line Interface (AWS CLI). Your user-initiated backups are incremental relative to other backups that may have been created for a volume and are retained forever, unless you delete them. User-initiated backups are retained even after you delete the volume or the file system the backups were created on. You can delete user-initiated backups only by using the Amazon FSx console, API, or CLI. They are never automatically deleted by Amazon FSx. For more information, see Deleting backups.

Creating user-initiated backups

The following procedure guides you through how to create a user-initiated backup in the Amazon FSx console for a volume of an existing file system.

To create a user-initiated backup of a volume
  1. Open the Amazon FSx console at

  2. Navigate to File systems and choose the ONTAP file system that you want to back up a volume for.

  3. Choose the Volumes tab.

  4. Choose the volume you want to back up.

  5. From Actions, choose Create backup.

  6. In the Create backup dialog box that opens, provide a name for your backup. Backup names can be a maximum of 256 Unicode characters, including letters, white space, numbers, and the special characters . + - = _ : /

  7. Choose Create backup.

You have now created a backup of one of your file system's volumes. You can find a table of all your backups in the Amazon FSx console by choosing Backups in the left side navigation. You can search for the name you gave your backup, and the table filters to only show matching results.

When you create a user-initiated backup as this procedure described, it has the type USER_INITIATED, and it has the CREATING status until it is fully available.

Copying tags to backups

When you create or update a volume in the Amazon FSx API or AWS CLI, you can enable CopyTagsToBackups to automatically copy any tags from your volumes to backups.


If you specify tags while creating a user-initiated backup (including the name tag when you create a backup using the Amazon FSx console), tags are not copied from the volume even if you've enabled CopyTagsToBackups.

For more information about tagging, see Tag your Amazon FSx resources. For more information about enabling CopyTagsToBackups, see To create a volume (CLI) and To update a volume's configuration (CLI) or CreateVolume and UpdateVolume in the Amazon FSx API Reference.

Using AWS Backup with Amazon FSx

AWS Backup is a simple and cost-effective way to protect your data by backing up your Amazon FSx for NetApp ONTAP volumes. AWS Backup is a unified backup service designed to simplify the creation, restoration, and deletion of backups, while providing improved reporting and auditing. AWS Backup makes it easier to develop a centralized backup strategy for legal, regulatory, and professional compliance. AWS Backup also makes protecting your AWS storage volumes, databases, and file systems simpler by providing a central place where you can do the following:

  • Configure and audit the AWS resources that you want to back up.

  • Automate backup scheduling.

  • Set retention policies.

  • Monitor all recent backup, copy, and restore activity.

AWS Backup uses the built-in backup functionality of Amazon FSx. Backups created using the AWS Backup console have the same level of file system consistency and performance, are incremental relative to any other Amazon FSx backups you take of your volume (user-initiated or automatic), and offer the same restore options as backups taken through the Amazon FSx console. If you use AWS Backup to manage these backups, you gain additional functionality, such as the ability to create scheduled backups as frequently as every hour. You can add an additional layer of defense to protect backups from inadvertent or malicious deletions by storing them in an AWS Backup Vault.


AWS Backup doesn't support backing up FlexGroup volumes.

Backups created by AWS Backup are considered user-initiated backups, and they count toward the user-initiated backup quota for Amazon FSx. For more information, see Quotas that you can increase. You can view and restore backups created by AWS Backup in the Amazon FSx console, CLI, and API. However, you can't delete backups created by AWS Backup in the Amazon FSx console, CLI, or API. For more information about how to use AWS Backup to create, restore, and delete backups of your Amazon FSx file systems, see Working with Amazon FSx File Systems in the AWS Backup Developer Guide.

Restoring volume backups

You can restore a volume backup to a new volume, effectively restoring a point-in-time snapshot of a volume. You can restore a backup using the console, AWS CLI, or the API and one of the AWS SDKs. .

When you restore a backup, the volume’s tiering policy that you specify determines when data is tiered off to capacity pool storage. When restoring a backup to a volume with a tiering policy of All, a periodic background process tiers the data to the capacity pool. When restoring a backup to a volume with a tiering policy of Snapshot Only or Auto, data is tiered to the capacity pool if the SSD utilization for the file system is greater than 50%, and the cooling rate is determined by the tiering policy’s cooling period.

When you restore a FlexGroup volume backup on a file system that has a different number of high-availability (HA) pairs from the original file system, Amazon FSx might add additional constituent volumes to ensure that the constituents are evenly distributed.


Your restored volume will have the same volume style as the original volume. You can't change the volume style when restoring.

The following procedure guides you through how to restore a backup using the console to create a new volume.

To restore FSx for ONTAP volume backups to a new volume (Console)
  1. Open the Amazon FSx console at

  2. In the navigation pane, choose Backups, and then choose the FSx for ONTAP volume backup that you want to restore.

  3. In the upper right Actions menu, choose Restore backup. The Create volume from backup page appears.

  4. Choose the FSx for ONTAP File system and Storage virtual machine that you want to restore the backup to from the dropdown menus.

  5. Under Volume details, there are several selections. First, enter the Volume name. You can use a up to 203 alphanumeric or underscore (_) characters.

  6. For Volume size, enter any whole number in the range of 20–314572800 to specify the size in mebibytes (MiB).

  7. For Volume type, choose Read-Write (RW) to create a volume that is readable and writable or Data Protection (DP) to create a volume that is read-only and can be used as the destination of a NetApp SnapMirror or SnapVault relationship. For more information, see Volume types.

  8. For Junction path, enter a location within the file system to mount the volume. The name must have a leading forward slash, for example /vol3.

  9. For Storage efficiency, choose Enabled to enable the ONTAP storage-efficiency features (deduplication, compression, and compaction). For more information, see FSx for ONTAP storage efficiency.

  10. For Volume security style, choose either Unix (Linux), NTFS, or Mixed. A volume's security style determines whether preference is given to NTFS or UNIX ACLs for multi-protocol access. The MIXED mode is not required for multi-protocol access and is only recommended for advanced users.

  11. For Snapshot policy, choose a snapshot policy for the volume. For more information about snapshot policies, see Snapshot policies.

    If you choose Custom policy, you must specify the policy's name in the custom-policy field. The custom policy must already exist on the SVM or in the file system. You can create a custom snapshot policy with the ONTAP CLI or REST API. For more information, see Create a Snapshot Policy in the NetApp ONTAP Product Documentation.

  12. For Tiering policy cooling period, valid values are 2-183 days. A volume's tiering policy cooling period defines the number of days before data that has not been accessed is marked cold and moved to capacity pool storage. This setting only affects the Auto and Snapshot-only policies.

  13. In the Advanced section, for SnapLock Configuration, you can leave the default Disabled setting or choose Enabled to configure a SnapLock volume. For more information about configuring a SnapLock Compliance volume or a SnapLock Enterprise volume, see Creating a SnapLock Compliance volume and Creating a SnapLock Enterprise volume. For more information about SnapLock, see Working with SnapLock.

  14. Choose Confirm to create the volume.

To restore an FSx for ONTAP volume backup to a new volume (CLI)

Use the create-volume-from-backup CLI command, or the equivalent CreateVolumeFromBackup API command to restore a volume backup to a new volume.

  • $ aws fsx create-volume-from-backup --backup-id backup- 08e6fc1133fff3532 \ --name demo --ontap-configuration JunctionPath=/demo, SizeInMegabytes=100000, \ StorageVirtualMachineId=svm-0f04a9c7c27e1908b, TieringPolicy={Name=ALL}

    The system response for a successful request:

    { "Volume": { "CreationTime": 1692721488.428, "FileSystemId": "fs-07ab735385276ed60", "Lifecycle": "CREATING", "Name": "demo", "OntapConfiguration": { "FlexCacheEndpointType": "NONE", "JunctionPath": "/demo", "SizeInMegabytes": 100000, "StorageEfficiencyEnabled": true, "StorageVirtualMachineId": "svm-0f04a9c7c27e1908b", "StorageVirtualMachineRoot": false, "TieringPolicy": { "Name": "ALL" }, "OntapVolumeType": "DP", "SnapshotPolicy": "default", "CopyTagsToBackups": false, }, "ResourceARN": "arn:aws:fsx:us-east-1:752825163408:volume/fs-07ab735385276ed60/fsvol-0b6ec764c9c5f654a", "VolumeId": "fsvol-0b6ec764c9c5f654a", "VolumeType": "ONTAP", } }

Deleting backups

Deleting a backup is a permanent, unrecoverable action. Any data in a deleted backup is also deleted. Do not delete a backup unless you're sure you won't need that backup again in the future. You can't delete backups created by AWS Backup, which have type AWS Backup, in the Amazon FSx console, CLI, or API. For information on deleting backups created by AWS Backup, see Deleting Backups in the AWS Backup Developer Guide.


Do not delete the common snapshot on the volume because it is used to maintain incrementality between your backups. Deleting the common snapshot on the volume will cause the next backup to be of the entire volume rather than an incremental backup that only captures changed data since the previous backup.

To delete a backup
  1. Open the Amazon FSx console at

  2. From the console dashboard, choose Backups from the left side navigation.

  3. Choose the backup that you want to delete from the Backups table, and then choose Delete backup.

  4. In the Delete backups dialog box that opens, confirm that the ID of the backup identifies the backup that you want to delete.

  5. Confirm that the check box is checked for the backup that you want to delete.

  6. Choose Delete backups.

Your backup and all included data are now permanently and irrecoverably deleted.


There are a variety of factors that influence the rate of backup and restore operations. Backup and restore operations are background processes that have a lower priority relative to client IO operations that include NFS, CiFS, and iSCSI data read and writes. These operations utilize the unused portion of your file system’s throughput capacity, and can take from a few minutes to a few hours to complete depending on the size of your backup and the amount of unused throughput capacity on your file system. Other factors that affect the rate at which a backup is created or restored include the storage tier in which your data is stored and the dataset profile. We recommend that you create the first backups of your volumes when most of the data is on SSD storage. Datasets containing mostly small files will typically take longer to backup and restore as compared to similarly sized datasets that contain mostly large files. This is because processing large numbers of small files consumes more CPU cycles and network overhead than processing fewer large files.

Generally, you can expect the following backup rates when backing up data stored in the SSD storage tier:

  • 750 MBps across several concurrent backups containing mostly large files.

  • 100 MBps across several concurrent backups containing mostly small files.

Generally, you can expect the following restore rates:

  • 250 MBps across several concurrent restores containing mostly large files.

  • 100 MBps across several concurrent restores containing mostly small files.