# Protecting your data with volume backups
With FSx for ONTAP, you can protect your data by taking automatic daily backups and user-initiated backups of the volumes on your file system. Creating regular backups for your volumes is a best practice that helps support your data retention and compliance needs. You can restore volume backups to any existing FSx for ONTAP file system you have access to that is in the same AWS Region where the backup is stored. Working with Amazon FSx backups makes it is easy to create, view, restore, and delete backups of your volumes.
Amazon FSx supports backing up ONTAP volumes with an `OntapVolumeType` of read-write (RW).
**Note**
Amazon FSx doesn't support backing up data protection (DP) volumes, load sharing mirror (LSM) volumes, or destination volumes for FlexCache and SnapMirror.
**Topics**
+ [
## How backups work
](#how-backups-work)
+ [
## Storage requirements
](#storage-requirements)
+ [
## Automatic daily backups
](#automatic-backups)
+ [
## User-initiated backups
](#user-initiated-backups)
+ [
## Copying tags to backups
](#copy-tags-to-backups)
+ [
## Using AWS Backup with Amazon FSx
](#aws-backup-and-fsx)
+ [
## Restoring backups to a new volume
](#restoring-backups)
+ [
## Backup and restore performance
](#backup-performance)
+ [
## Backing up SnapLock volumes
](#snaplock-backup)
+ [
# Creating user-initiated backups
](creating-backups.md)
+ [
# Restoring a backup to a new volume
](to-restore-backups.md)
+ [
# Restoring a subset of data
](data-subset-restore.md)
+ [
# Monitoring progress when restoring a backup
](monitor-backup-restore.md)
+ [
# Deleting backups
](how-to-delete-backups.md)
## How backups work
All Amazon FSx backups (automatic daily backups and user-initiated backups) are incremental, which means that they only store changes in the data since the previous backup was completed. This minimizes both the time required to create a backup and the amount of storage used by each backup. Incremental backups optimize storage costs by not storing duplicate data. FSx for ONTAP backups are per volume, with each backup containing only the data of one specific volume. Amazon FSx backups are stored redundantly across multiple Availability Zones to achieve high durability.
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 backup snapshot is stored in your volume, and consumes storage space on the volume. 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. To optimize backup storage costs, ONTAP preserves a volume's storage efficiency savings in its backups.
When you [delete](how-to-delete-backups.md) a backup, only the data unique to that backup is deleted. 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 volume.
There are limits to the number of backups that you can store per AWS account and per volume. For more information, see [Quotas that you can increase](limits.md#soft-limits) and [Resource quotas for each file system](limits.md#limits-ontap-resources-file-system).
**Note**
If you use NDMP for backups, ONTAP does not allow maintenance activities such as patch operations to proceed while an NDMP transfer is in progress. To avoid delaying patches, Amazon FSx will abort any active NDMP transfer sessions when a patch operation is applied during your file system's maintenance window. Once patching is complete, you will need to manually restart your NDMP transfer sessions from the client side, as Amazon FSx cannot automatically resume them. To avoid backup interruptions, we recommend using Amazon FSx backups or AWS Backup, which support concurrent backup and patch operations.
## Storage requirements
Your volume and your file system must each have enough available SSD storage capacity to store a backup snapshot. When taking a backup snapshot, the additional storage capacity consumed by the snapshot cannot cause the volume to exceed 98% SSD storage utilization. If this happens, the backup will fail. You can [increase a volume's](manage-volume-capacity.md) or [file system's](storage-capacity-and-IOPS.md#increase-primary-storage) SSD storage at anytime to ensure that your backups won't be interrupted.
## Automatic daily backups
When you create a file system, automatic daily backups are enabled by default for your file system's volumes. You can enable or disable automatic daily backups for existing file systems at any time. Automatic daily backups for all volumes occur during the file system's daily backup window, which is automatically set when you create a file system. You can modify the daily backup window at any time. For optimal [backup performance](#backup-performance), we recommend that you choose a daily backup window that is outside of the normal operating hours when clients and applications are accessing the data on your volumes. We also recommend choosing a backup window that does not overlap with your file system's maintenance window. If the windows overlap, maintenance activities take precedence and automated backups occur after maintenance is complete. Backups that are already in progress will continue during maintenance, however, new backup creation may not occur until maintenance is complete. If maintenance runs for the full duration of the window, automated backups may not occur during that window.
Using the console, you can set the retention period for automatic daily backups to a value from 1 to 90 days when creating a file system or at any time. The default automatic daily backup retention period is 30 days. Amazon FSx deletes an automatic daily backup once its retention period expires. Using the AWS CLI and API, you can set the retention period to a value from 0 to 90 days; setting it to 0 turns off automatic daily backups.
Automatic daily backups, the daily backup window, and the backup retention period are file system settings, and apply to all volumes on your file system. You can use the Amazon FSx console, the AWS CLI, or API to change these settings. For more information, see [Updating file systems](updating-file-system.md).
You can't create a volume backup (automatic daily backups or user-initiated backups) if the volume is offline. For more information, see [Viewing offline volumes](offline-volumes.md).
**Note**
Automatic daily backups have a maximum retention period of 90 days, but [user-initiated backups](#user-initiated-backups) that you create, which include backups created using AWS Backup, are retained forever unless you or AWS Backup deletes them.
You can manually [delete](how-to-delete-backups.md) an automatic daily backup using the Amazon FSx console, CLI, and API. 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.
## User-initiated backups
With Amazon FSx, you can manually take backups of your file system's volumes at any time using the AWS Management Console, AWS CLI, and API. 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](how-to-delete-backups.md) only by using the Amazon FSx console, API, or CLI. They are never automatically deleted by Amazon FSx.
For instructions on how to create a user-initiated backup, see [Creating user-initiated backups](creating-backups.md).
## Copying tags to backups
When you create or update a volume using the CLI or API, you can enable `CopyTagsToBackups` to [automatically copy any tags](creating-volumes.md#create-volume-cli) on your volume to its backups. However, if you add any tags while creating a user-initiated backup, including naming a backup when you use the console, Amazon FSx does *not* copy tags from the volume, even if `CopyTagsToBackups` is enabled.
## 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. Using AWS Backup makes it easier to develop a centralized backup strategy for legal, regulatory, and professional compliance. It 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 user-initiated backups taken of your volume, and offer the same restore options as backups taken using the Amazon FSx console. Using AWS Backup to manage these backups provides additional functionality, including 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 a [backup vault](https://docs.aws.amazon.com/aws-backup/latest/devguide/vaults.html).
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](limits.md#soft-limits). You can view and restore backups created by AWS Backup using 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, see [Getting started with AWS Backup](https://docs.aws.amazon.com/aws-backup/latest/devguide/getting-started.html) in the AWS Backup Developer Guide.
AWS Backup can't back up volumes that are offline.
You can use tags to select which of your FSx for ONTAP resources are protected in a backup plan. These tags must be applied at the volume level rather than the file system level as a whole. For more information, see [Assigning resources to a backup plan](https://docs.aws.amazon.com/aws-backup/latest/devguide/assigning-resources.html) in the AWS Backup Developer Guide.
## Restoring backups to a new volume
You can restore a volume backup to a new volume on a file system that is in the same AWS Region that the backup is stored in. You cannot restore a backup to a file system that is located in a different AWS Region than the backup.
When restoring a backup on FSx for ONTAP second-generation file systems, clients can mount and read data from a volume while it is being restored. Clients can mount the volume you are restoring and read the file data once Amazon FSx has loaded all the metadata onto the new volume and the volume reports a lifecycle status of `CREATED`. You can find a volume's lifecycle state on the [**Volumes detail**](viewing-volumes.md) page in the Amazon FSx console and in the response of the [describe-volumes](https://docs.aws.amazon.com/v2/documentation/api/latest/reference/fsx/describe-volumes.html) CLI command.
When reading data from a volume while it is being restored from a backup, if the data has not been downloaded onto the volume yet, you will incur read latencies of up to tens of milliseconds for the first access. These reads are cached in the SSD tier, and you can expect sub-millisecond read latencies for subsequent reads.
The amount of time it takes for Amazon FSx to make a volume available for read-only access is proportional to the amount of file metadata stored in the backup. File metadata typically consumes 1-7% of the overall backup data depending on the average file size in your data set (small file data sets consume more metadata than large file data sets).
When you restore a FlexGroup volume backup to a file system that has a different number of [high-availability (HA) pairs](HA-pairs.md) than the original file system, Amazon FSx adds additional constituent volumes to ensure that the constituents are evenly distributed.
**Note**
Amazon FSx does not support read access to data while a volume is being restored from a backup for either SnapLock volumes or for any volumes on first-generation file systems. When restoring these backups, the volume becomes available to mount and access data after the restore process is completed, and all metadata and data are loaded onto the new volume.
When restoring a backup, all data is initially written to the SSD storage tier. While the restore is in progress, data is tiered to the capacity pool storage in accordance with the [tiering policy](volume-storage-capacity.md#volume-data-tiering) of volume being restored. Since data is first written to the SSD tier, Amazon FSx will pause the restoration process if the file system runs out of SSD storage space. The restore automatically resumes as soon as sufficient SSD space becomes available to continue the process. If the restored volume's tiering policy is `All`, a periodic background process tiers the data to the capacity pool. If the restored volume's tiering policy is `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.
If your workload requires consistent sub-millisecond read latencies when restoring a backup to a new volume on second-generation file systems, we recommend that you set the volume’s tiering policy to `None` when initiating the restore, and then wait until all data has been fully downloaded onto the volume before you access it. All data will be loaded into SSD storage before you attempt to access it, providing you with consistent low-latency access to your data.
For step-by-step instructions on how to restore a backup to a new volume, see [Restoring a backup to a new volume](to-restore-backups.md).
On second-generation file systems you can also restore just a subset of data from a backup without having to wait for the entire restore operation to complete. Restoring just a subset of a backup's data enables you to resume operations faster in the event of accidental deletion, modification, or corruption of data. For more information, see [Restoring a subset of data](data-subset-restore.md).
You can monitor the progress when restoring a backup on a second-generation file system in the AWS Management Console, AWS CLI, and API. For more information, see [Monitoring progress when restoring a backup](monitor-backup-restore.md).
**Note**
You can't create a volume snapshot or perform snapshot-based operations such as cloning, SnapMirror replication, and creating backups of a volume while it is being restored from a backup.
A restored volume always has the same volume style as the original volume. You can't change the volume style when restoring.
## Backup and restore performance
A variety of factors can influence the performance of backup and restore operations. Backup and restore operations are background processes, which means they have a lower priority relative to client IO operations. Client IO operations include NFS, CIFS, and iSCSI data and metadata reads and writes. All background processes utilize only 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 backup and restore performance 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 have lower performance 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.
## Backing up SnapLock volumes
You can back up [SnapLock](snaplock.md) volumes for additional data protection. When you restore a SnapLock volume, the volume's original settings—such as the default retention, minimum retention, and maximum retention—are preserved. Write once, read many (WORM) settings and Legal Hold are also preserved.
**Note**
You can't back up a SnapLock FlexGroup volume.
You can restore a SnapLock volume's backup as a SnapLock or a non-SnapLock volume. However, you can't restore a non-SnapLock volume's backup as a SnapLock volume.
For more information, see [How SnapLock works](how-snaplock-works.md).
# Creating user-initiated backups
The following procedure describes how to create a user-initiated backup of a volume.
You cannot create a volume backup if the volume is offline. For more information, see [Viewing offline volumes](offline-volumes.md).
**To create a user-initiated backup (console)**
1. Open the Amazon FSx console at [https://console.aws.amazon.com/fsx/](https://console.aws.amazon.com/fsx/).
1. Navigate to **File systems** and choose the ONTAP file system that you want to back up a volume for.
1. Choose the **Volumes** tab.
1. Choose the volume you want to back up.
1. From **Actions**, choose **Create backup**.
1. 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 . \$1 - = \$1 : /
1. Choose **Create backup**.
You have now created a backup of one of your file system's volumes. You can see all of 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.
# Restoring a backup to a new volume
The following procedures describe how to restore an FSx for ONTAP backup to a new volume using the AWS Management Console and AWS CLI. When restoring a volume to a second-generation file system, you can [monitor](monitor-backup-restore.md) the progress using the AWS Management Console, AWS CLI, and API.
**To restore a volume backup to a new volume (Console)**
1. Open the Amazon FSx console at [https://console.aws.amazon.com/fsx/](https://console.aws.amazon.com/fsx/).
1. In the navigation pane, choose **Backups**, and then choose the FSx for ONTAP volume backup that you want to restore.
1. In the upper right **Actions** menu, choose **Restore backup**. The **Create volume from backup page appears.**
1. Choose the FSx for ONTAP **File system** and **Storage virtual machine** that you want to restore the backup to from the dropdown menus.
1. In the upper right **Actions** menu, choose **Restore backup**. The **Create volume from backup page appears.**
1. Choose the FSx for ONTAP **File system** and **Storage virtual machine** that you want to restore the backup to from the dropdown menus.
1. Under **Volume details**, there are several selections. First, enter the **Volume name**. You can use up to 203 alphanumeric or underscore (\$1) characters.
1. For **Volume size**, enter any whole number in the range of 20–314572800 to specify the size in mebibytes (MiB).
1. 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](managing-volumes.md#volume-types).
1. 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`.
1. For **Storage efficiency**, choose **Enabled** to enable the ONTAP storage-efficiency features (deduplication, compression, and compaction). For more information, see [Storage efficiency](managing-storage-capacity.md#storage-efficiency).
1. 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.
1. For **Snapshot policy**, choose a snapshot policy for the volume. For more information about snapshot policies, see [Snapshot policies](snapshots-ontap.md#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](https://docs.netapp.com/us-en/ontap/data-protection/create-snapshot-policy-task.html) in the NetApp ONTAP Product Documentation.
1. 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.
1. 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 [Understanding SnapLock Compliance](snaplock-compliance.md) and [Understanding SnapLock Enterprise](snaplock-enterprise.md). For more information about SnapLock, see [Protecting your data with SnapLock](snaplock.md).
1. Choose **Confirm** to create the volume.
1. If you are restoring the backup to a second-generation file system, you can monitor the backup restore progress on the **Updates** tab on the **Volume** page. For more information, see [Monitoring progress when restoring a backup](monitor-backup-restore.md).
**To restore a backup to a new volume (CLI)**
Use the [ create-volume-from-backup](https://docs.aws.amazon.com/cli/latest/reference/fsx/create-volume-from-backup.html) CLI command, or the equivalent [ CreateVolumeFromBackup](https://docs.aws.amazon.com/fsx/latest/APIReference/API_CreateVolumeFromBackup.html) 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 restore request to restore a backup to a second-generation file system looks as follows. The response includes the `"AdministrativeActions"` object which provides status and progress information about 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",
---> "AdministrativeActions": [
{
"AdministrativeActionType": "DOWNLOAD_DATA_FROM_BACKUP",
"RequestTime": 1685729972.069,
"Status": "PENDING"
}
] <----
}
}
```
The system response for a successful request to restore a backup to a first-generation file system looks as follows.
```
{
"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",
}
}
```
When restoring a volume to a second-generation file system, you can [monitor the progress](monitor-backup-restore.md) using the AWS Management Console, AWS CLI, and API.
# Restoring a subset of data
You can restore a subset of data from a backup while it is being restored to a new volume on second-generation file systems without having to wait until the entire backup data set has been fully restored.
The following procedure lists the steps to take when you need to recover a subset of data when restoring a backup, and can't wait for the entire restore to complete:
**To restore a subset of data while restoring a backup**
1. Open the Amazon FSx console at [https://console.aws.amazon.com/fsx/](https://console.aws.amazon.com/fsx/).
1. In the **Backups** page, locate the backup that contains the version of the data that you want to restore.
1. In the upper right **Actions** menu, choose **Restore backup**. The **Create volume from backup page appears.**
1. Choose the FSx for ONTAP **File system** and **Storage virtual machine** that you want to restore the backup to from the dropdown menus.
1. Under **Volume details**, configure the volume to meet your needs.
1. Choose **Confirm** to create the volume.
1. [Monitor the progress](monitor-backup-restore.md) of the backup restore.
1. [Mount the volume](supported-fsx-clients.md) being restored when it reports a lifecycle status of `CREATED`.
1. Locate the subset of the data on the volume you need to copy.
1. Copy the data to the existing volume that your application uses.
1. Once the required data from the backup has been copied over to the target location, you can delete the volume being restored before it completes to optimize utilization of file system resources.
# Monitoring progress when restoring a backup
You can monitor the progress when restoring a volume backup to second-generation file system in the AWS Management Console, AWS CLI, and API. As with all Amazon FSx administrative actions, a backup restore status is available in the console, CLI, and API for 30 days after the operation is completed.
**To monitor progress when restoring a backup (console)**
Open the Amazon FSx console at [https://console.aws.amazon.com/fsx/](https://console.aws.amazon.com/fsx/).
1. In the left navigation menu, choose **Volumes**.
1. Choose the volume that the backup is being restored to.
1. Choose the **Updates** tab.
1. The **Backup restore** **Update type** provides the following information:
+ **PENDING** indicates that the file metadata is being downloaded onto the volume. The volume's **Lifecycle state** is **CREATING**.
+ **IN\$1PROGRESS** indicates that the volume is available and clients can mount the volume with read-only access to data. The **Progress %** shows the percentage of data that has been downloaded to the volume.
+ **COMPLETED** indicates that all data has been downloaded to the volume, and the backup restore is complete. Clients now have read-write access. For `RW` volumes, the volume's type changes from `DP` to `RW` at this point.
**To monitor progress when restoring a backup (CLI)**
+ When you restore a backup to a new volume on a second-generation FSx for ONTAP file system, you can monitor the progress of the restore using the [https://docs.aws.amazon.com/fsx/latest/APIReference/API_DescribeVolumes.html](https://docs.aws.amazon.com/fsx/latest/APIReference/API_DescribeVolumes.html) CLI command.
When restoring a backup to a second-generation file system, the response includes the `AdministrativeActions` object, which provides status information about the data downloading process. The
```
$ aws fsx describe-volumes
{
“Volumes”: [
{
“CreationTime”: 1691686114.674,
“FileSystemId”: fs-029ff92192bd4d375,
“LifeCycle”: “CREATING”,
“Name”: vol1,
“OntapConfiguration”: {
“FlexCacheEndpointType”: “NONE”,
“JunctionPath”: “/vol1”,
“SizeInMegabytes”: 100000,
“StorageEfficiencyEnabled”: true,
“StorageVirtualMachineId”: “svm-0ed1d714019426ca9”,
“StorageVirtualMachineRoot”: false,
“TieringPolicy”: {
“Name”: “ALL”
},
“OntapVolumeType”: “DP”,
“SnapshotPolicy”: “default”,
“CopyTagsToBackups”: false,
},
“ResourceARN”: “arn:aws:fsx:us-east-1:630831496844:volume/fs-08ac75f715c6aec76/fsvol-094c015af930790fa”,
“VolumeId”: “fsvol-094c015af930790fa”,
“VolumeType”: “ONTAP”,
“AdministrativeActions”: [
{
“AdministrativeActionType”: “DOWNLOAD_DATA_FROM_BACKUP”,
“RequestTime”: 1685729972.069,
“Status”: “PENDING”
}
]
}
```
Once Amazon FSx loads all of the file metadata onto the restored volume, these fields have the following values:
+ `"LifeCycle": "CREATED"` – indicates that the volume is ready to be mounted.
+ `"OntapVolumeType": "DP"` – indicates that the volume is read-only while the file data is downloading.
+ `"ProgressPercent` –shows the percentage of file data that is loaded onto the volume.
+ `"Status": "IN_PROGRESS"` – downloading the file data to the volume is in progress.
At this stage in the restore process you can mount the volume with read-only access to all the data in the backup that you are restoring.
When Amazon FSx has completed downloading all the file data onto the new volume, clients have full read-write access if this is `RW` volume. The indicators have the following values:
+ `"LifeCycle": "CREATED"` – unchanged
+ `"OntapVolumeType": "RW"` – indicates that clients have full read-write access.
+ `"Status": "COMPLETED"` – indicates that the restore is complete.
If the restore process fails, the `AdminstrativeAction > Status` will have a value of `FAILED`. An error message is provided in the `FailureDetails` object. For more information, see [AdministrativeActionFailureDetails](https://docs.aws.amazon.com/fsx/latest/APIReference/API_AdministrativeActionFailureDetails.html) in the Amazon FSx API Reference
# Deleting backups
You can delete both automatic daily backups and user-initiated backups of your volumes using the Amazon FSx console, Amazon FSx API, or AWS Command Line Interface (AWS CLI). 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 a backup if the source volume is [offline](offline-volumes.md).
You can delete a volume while it is being restored from a backup on all FSx for ONTAP file systems. Deleting a volume during the restore effectively cancels the in-progress restore operation.
**Note**
Amazon FSx doesn't support deleting the most recent `AVAILABLE` backup of an ONTAP volume unless all other backups of the volume have been deleted.
To delete backups created using AWS Backup, see [Deleting backups](https://docs.aws.amazon.com/aws-backup/latest/devguide/deleting-backups.html) in the AWS Backup Developer Guide.
**To delete a backup (console)**
1. Open the Amazon FSx console at [https://console.aws.amazon.com/fsx/](https://console.aws.amazon.com/fsx/).
1. From the console dashboard, choose **Backups** from the left side navigation.
1. Choose the backup that you want to delete from the **Backups** table, and then choose **Delete backup**.
1. In the **Delete backups** dialog box that opens, confirm that the ID of the backup shown is the backup that you want to delete.
1. Confirm that the check box is checked for the backup that you want to delete.
1. Choose **Delete backups**.
Your backup and all included data are now permanently and irrecoverably deleted.
**To delete a backup (CLI)**
+ Use the delete-backup CLI command or the equivalent DeleteBackup API action to delete an FSx for ONTAP volume backup, as shown in the following example.
```
$ aws fsx delete-backup --backup-id backup-a0123456789abcdef
```
The system response includes the ID of the backup being deleted, and its lifecycle status with a value of `DELETED`, indicating that the request was successful.
```
{
"BackupId": "backup-a0123456789abcdef",
"Lifecycle": "DELETED"
}
```