# Protecting your Amazon FSx for OpenZFS data
Amazon FSx for OpenZFS provides you with the following options to further protect the data stored on your file systems:
+ **Built-in Amazon FSx backups** – Supports your backup retention and compliance needs within Amazon FSx, offering both automatic daily backups and user-initiated backups.
+ **Snapshots** – Enables your users to easily undo file changes and compare file versions by restoring files to previous versions.
+ **On-demand data replication** – Makes it easy to replicate datasets across file systems, within or across AWS Regions and accounts.
+ **AWS Backup** – Creates backups of your FSx for OpenZFS file system that work as part of a centralized and automated backup solution across AWS services in the cloud and on premises.
**Topics**
+ [Protect data with backups](using-backups.md)
+ [Protecting data with snapshots](snapshots-openzfs.md)
+ [Protect data with replication](on-demand-replication.md)
# Protecting your data with backups
With FSx for OpenZFS, backups are file-system-consistent, highly durable, and incremental. To ensure high durability, Amazon FSx stores backups in Amazon Simple Storage Service (Amazon S3).
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 file system 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 FSx for OpenZFS backup contains all of the information that is needed to create a new file system from the backup, effectively restoring a point-in-time snapshot of the file system.
Creating regular backups for your file system is a best practice that complements the replication that FSx for OpenZFS performs for your file system. Amazon FSx backups help support your backup retention and compliance needs. Working with Amazon FSx backups is easy, whether it's creating backups, copying a backup, restoring a file system from a backup, or deleting a backup.
**Topics**
+ [Working with automatic daily backups](#automatic-backups)
+ [Working with user-initiated backups](#user-initiated-backups)
+ [Working with AWS Backup](#aws-backup-and-fsx)
+ [Copying backups](copy-backups.md)
+ [Restoring backups](restoring-backups.md)
+ [Deleting backups](delete-backups.md)
## Working with automatic daily backups
By default, Amazon FSx takes an automatic daily backup of your file system. These automatic daily backups occur during the daily backup window that was established when you created the file system. At some point during the daily backup window, storage I/O might be suspended briefly while the backup process initializes (typically for less than a few seconds). When you choose your daily backup window, we recommend that you choose a convenient time of the day. This time ideally is outside of the normal operating hours for the applications that use the file system.
Automatic daily backups are kept for a certain period of time, known as a retention period. When you create a file system in the Amazon FSx console, the default automatic daily backup retention period is 30 days. The default retention period is different in the Amazon FSx API and CLI. You can set the retention period to be between 1–90 days. Automatic daily backups are deleted when the file system is deleted.
**Note**
While automatic daily backups have a maximum retention period of 90 days, user-initiated backups are kept forever, unless you delete them. For more information about user-initiated backups, see [Working with user-initiated backups](#user-initiated-backups).
You can use the AWS CLI or one of the AWS SDKs to change the backup window and backup retention period for your file systems. Use the [https://docs.aws.amazon.com/fsx/latest/APIReference/API_UpdateFileSystem.html](https://docs.aws.amazon.com/fsx/latest/APIReference/API_UpdateFileSystem.html) API operation or the [https://docs.aws.amazon.com/cli/latest/reference/fsx/update-file-system.html](https://docs.aws.amazon.com/cli/latest/reference/fsx/update-file-system.html) CLI command.
## Working with user-initiated backups
With Amazon FSx, you can manually take backups of your file systems 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 of Amazon FSx file systems never expire, and they are available for as long as you want to keep them. User-initiated backups are retained even after you delete the file system that was backed up. 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](delete-backups.md).
### Creating user-initiated backups
The following procedure guides you through how to create a user-initiated backup in the Amazon FSx console for an existing file system.
**To create a user-initiated file system backup**
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 the name of the file system that 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 your file system backup. 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.
## Working with AWS Backup
AWS Backup is a simple and cost-effective way to protect your data by backing up your Amazon FSx for OpenZFS file systems. 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 file systems, 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.
+ Copy backups across AWS Regions and AWS accounts
+ Monitor all recent backup, copy, and restore activity.
AWS Backup uses the built-in backup functionality of Amazon FSx. Backups taken from 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 file system (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 unlimited retention options and the ability to create scheduled backups as frequently as every hour. In addition, AWS Backup and Amazon FSx retain your immutable backups even after the source file system is deleted. This protects against accidental or malicious deletion.
Backups taken by AWS Backup are considered user-initiated backups, and they count toward the user-initiated backup quota for Amazon FSx. You can view and restore backups taken by AWS Backup in the Amazon FSx console, CLI, and API. However, you can't delete backups taken by AWS Backup in the Amazon FSx console, CLI, or API. For more information about how to use AWS Backup to back up your Amazon FSx file systems and how to delete backups, see [Working with Amazon FSx file systems](https://docs.aws.amazon.com/aws-backup/latest/devguide/working-with-supported-services.html#working-with-fsx) in the *AWS Backup Developer Guide*.
### Deleting backups
You can't delete backups taken by AWS Backup in the Amazon FSx console, CLI, or API. For information on deleting a backup taken by AWS Backup, see [Backup deletion](https://docs.aws.amazon.com/aws-backup/latest/devguide/deleting-backups.html) in the *AWS Backup Developer Guide*. 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.
# Copying backups
You can use Amazon FSx to manually copy backups within the same AWS account to another AWS Region (cross-Region copies) or within the same AWS Region (in-Region copies). You can make cross-Region copies only within the same AWS partition. You can create user-initiated backup copies using the Amazon FSx console, AWS CLI, or API. When you create a user-initiated backup copy, it has the type `USER_INITIATED`.
*Cross-Region backup copies* are particularly valuable for cross-Region disaster recovery. You take backups and copy them to another AWS Region so that in the event of a disaster in the primary AWS Region, you can restore from backup and recover availability quickly in the other AWS Region. You can also use backup copies to clone your file dataset to another AWS Region or within the same AWS Region. You make backup copies within the same AWS account (cross-Region or in-Region) by using the Amazon FSx console, AWS CLI, or Amazon FSx API.
## Backup copy limitations
The following are some limitations when you copy backups:
+ Backups of file systems using the Intelligent-Tiering storage class do not support backup copies.
+ Cross-Region backup copies are supported only between any two commercial AWS Regions, between the China (Beijing) and China (Ningxia) Regions, and between the AWS GovCloud (US-East) and AWS GovCloud (US-West) Regions, but not across those sets of Regions.
+ You can make in-Region backup copies within any AWS Region.
+ The source backup must have a status of `AVAILABLE` before you can copy it.
+ You cannot delete a source backup if it is being copied. There might be a short delay between when the destination backup becomes available and when you are allowed to delete the source backup. You should keep this delay in mind if you retry deleting a source backup.
+ You can have up to five backup copy requests in progress to a single destination AWS Region per account.
## Permissions for cross-Region backup copies
You use an IAM policy statement to grant permissions to perform a backup copy operation. To communicate with the source AWS Region to request a cross-Region backup copy, the requester (IAM role or IAM user) must have access to the source backup and the source AWS Region.
You use the policy to grant permissions to the `CopyBackup` action for the backup copy operation. You specify the action in the policy's `Action` field, and you specify the resource value in the policy's `Resource` field, as in the following example.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "fsx:CopyBackup",
"Resource": "arn:aws:fsx:*:111111111111:backup/*"
}
]
}
```
------
For more information on IAM policies, see [Policies and permissions in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) in the *IAM User Guide*.
## Full and incremental copies
When you copy a backup to a different AWS Region from the source backup, the first copy is a full backup copy. After the first backup copy, all subsequent backup copies to the same destination Region within the same AWS account are incremental, provided that you haven't deleted all previously-copied backups in that Region and have been using the same AWS KMS key. If both conditions aren't met, the copy operation results in a full (not incremental) backup copy.
------
#### [ To copy a backup (Amazon FSx 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**.
1. In the **Backups** table, choose the backup that you want to copy, and then choose **Copy backup**.
1. In the **Settings** section, do the following:
+ In the **Destination Region** list, choose a destination AWS Region to copy the backup to. The destination can be in another AWS Region (cross-Region copy) or within the same AWS Region (in-Region copy).
+ (Optional) Select **Copy Tags** to copy tags from the source backup to the destination backup. If you select **Copy Tags** and also add tags at step 6, all the tags are merged.
1. For **Encryption**, choose the AWS KMS encryption key to encrypt the copied backup.
1. For **Tags - optional**, enter a key and value to add tags for your copied backup. If you add tags here and also selected **Copy Tags** at step 4, all the tags are merged.
1. Choose **Copy backup**.
Your backup is copied within the same AWS account to the selected AWS Region.
------
#### [ To copy a backup (AWS CLI) ]
+ Use the `copy-backup` CLI command or the [CopyBackup](https://docs.aws.amazon.com/fsx/latest/APIReference/API_CopyBackup.html) API operation to copy a backup within the same AWS account, either across an AWS Region or within an AWS Region.
The following command copies a backup with an ID of `backup-0abc123456789cba7` from the `us-east-1` Region.
```
aws fsx copy-backup \
--source-backup-id backup-0abc123456789cba7 \
--source-region us-east-1
```
The response shows the description of the copied backup.
You can view your backups on the Amazon FSx console or programmatically using the `describe-backups` CLI command or the [DescribeBackups](https://docs.aws.amazon.com/fsx/latest/APIReference/API_DescribeBackups.html) API operation.
------
# Restoring backups
You can use an available backup to create a new file system, effectively restoring a point-in-time snapshot of another file system. You can restore a backup using the Amazon FSx console, AWS CLI, or one of the AWS SDKs. You can also restore backups using the AWS Backup console. For more information about using the AWS Backup console, see [Restore an FSx file System](https://docs.aws.amazon.com/aws-backup/latest/devguide/restoring-fsx.html) in the AWS Backup Developer Guide.
**Note**
Backups of Multi-AZ FSx for OpenZFS file systems can be restored only by using the Amazon FSx console or CLI.
Restoring a backup to a new file system takes the same amount of time as creating a new file system. The data restored from the backup is lazy-loaded onto the file system, during which time you will experience slightly higher latency.
**Note**
Restoring from a backup with a given storage class to a file system with a different storage class is not supported.
**To restore a file system from backup (Amazon FSx 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 restore from the **Backups** table, and then choose **Restore backup**. Doing so opens the file system creation wizard.
1. For **File system name - optional**, you can enter a name using a maximum of 256 Unicode letters, white space, and numbers, plus these special characters: \$1 - = . \$1 : /
1. For **Storage capacity**, enter a value that is equal to or greater than the storage capacity of the original file of which the backup was taken, in GiB. The range of valid values is 64–524288 GiB.
1. For **Provisioned SSD IOPS**, you have two options to provision the number of IOPS for your file system:
+ Choose **Automatic** (the default) if you want Amazon FSx to automatically provision 3 IOPS per GiB of SSD storage.
+ Choose **User-provisioned** if you want to specify the number of IOPS. You can provision a maximum of 160,000 SSD IOPS per file system for Single-AZ 1 (non-HA and HA) and a maximum of 400,000 SSD IOPS per file system for Single-AZ 2 (non-HA and HA) and Multi-AZ (HA)\$1. You pay for SSD IOPS that you provision that exceed 3 IOPS per GiB of SSD storage.
**Note**
\$1The maximum SSD IOPS you can provision for Multi-AZ file systems depends on the AWS Region your file system is located in. For more information, see [Data access from disk](performance-ssd.md#data-access-disk).
1. For **Throughput capacity**, you have two options to provide your desired throughput capacity in megabytes per second (MBps). **Throughput capacity** is the sustained speed at which the file server that hosts your file system can serve data.
+ Choose **Recommended throughput capacity** (the default) if you want Amazon FSx to automatically choose the throughput capacity. The recommended value is based on the amount of storage capacity that you chose.
+ Choose **Specify throughput capacity** if you want to specify the throughput capacity value, and choose a value of 64, 128, 256, 512, 1024, 2048, 3072, or 4096 MBps. You pay for additional throughput capacity that you provision above the recommended amount.
You can increase the amount of throughput capacity as needed at any time after you create the file system. For more information, see [Modifying throughput capacity](managing-throughput-capacity.md).
1. In the **Network & security** section, provide networking and security group information:
+ For **Virtual Private Cloud (VPC)**, choose the Amazon VPC that you want to associate with your file system.
+ For **VPC Security Groups**, the ID for the default security group for your VPC should be already added.
+ For **Subnet**, choose any value from the list of available subnets.
1. In the **Encryption** section, for **Encryption key**, choose the AWS Key Management Service (AWS KMS) encryption key that protects your file system's data at rest.
**Note**
When restoring a file system with a storage capacity greater than 128 TiB, you must use the same KMS key that you used when creating the backup. If you want to restore the file system with a new KMS key, you must first copy the backup using the new KMS key, and then restore the file system with this backup.
1. In **Root volume configuration**, you can set the following options for the file system's root volume:
+ For **Data compression type**, choose the type of compression to use for your volume, either **Zstandard**, **LZ4**, or **No compression**. Zstandard compression provides more data compression and higher read throughput than LZ4 compression. LZ4 compression provides less compression and higher write throughput performance than Zstandard compression. For more information about the storage and performance benefits of the volume data compression options, see [Data compression](performance.md#perf-data-compression).
+ For **Copy tags to snapshots**, enable or disable the option to copy tags to the volume's snapshot.
+ For **NFS exports**, there is a default client configuration setting which you can modify or remove. Client configurations define which clients can access the volume and their permissions.
To provide additional client configurations:
1. In the **Client addresses** field, specify which clients can access the volume. Enter an asterisk (`*`) for any client, a specific IP address, or a CIDR range of IP addresses.
1. In the **NFS options** field, enter a comma-delimited set of exports options. For example, enter `rw` to allow read and write permissions to the volume for the specified **Client addresses**.
1. Choose **Add client configuration**.
1. Repeat the procedure to add another client configuration.
For more information, see [NFS exports](creating-volumes.md#nfs-exports).
+ For **Record size**, choose whether to use the default suggested record size of 128 KiB, or to set a custom suggested record size for the volume. Generally, workloads that write in fixed small or large record sizes may benefit from setting a custom record size, like database workloads (small record size) or media streaming workloads (large record size). We recommend using the default setting for the majority of use cases. For more information about the record size setting, see [Configurable volume properties](creating-volumes.md#volume-properties).
+ For **User and group quotas**, you can set a storage quota for a user or group:
1. For **Quota type**, choose `USER` or `GROUP`.
1. For **User or group ID**, choose a number that is the ID of the user or group.
1. For **Usage quota**, choose a number that is the storage quota of the user or group.
1. Choose **Add quota**.
1. Repeat the procedure to add a quota for another user or group.
1. In **Backup and maintenance - *optional***, you can set the following options:
+ For **Daily automatic backup**, choose **Enabled** for automatic daily backups. This option is enabled by default.
+ For **Daily automatic backup window**, set the time of the day in Coordinated Universal Time (UTC) that you want the daily automatic backup window to start. The window is 30 minutes starting from this specified time. This window can't overlap with the weekly maintenance backup window.
+ For **Automatic backup retention period**, set a period from 1–90 days that you want to retain automatic backups.
+ For **Weekly maintenance window**, you can set the time of the week that you want the maintenance window to start. Day 1 is Monday, 2 is Tuesday, and so on. The window is 30 minutes starting from this specified time. This window can't overlap with the daily automatic backup window.
1. For **Tags - *optional***, you can enter a key and value to add tags to your file system. A tag is a case-sensitive key-value pair that helps you manage, filter, and search for your file system.
Choose **Next**.
1. Review the file system configuration shown on the **Create file system** page. For your reference, note which file system settings you can modify after the file system is created.
1. Choose **Create file system**.
# 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.
**Note**
You can't delete backups taken by AWS Backup in the Amazon FSx console, CLI, or API. For information on deleting a backup taken by 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**
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. From the **Backups** table, choose the backup that you want to delete.
1. For **Actions**, choose **Delete backup**.
1. In the **Delete backups** dialog box that opens, confirm that the ID of the backup identifies 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.
# Protecting your data with snapshots
A *snapshot* is a read-only image of an FSx for OpenZFS volume at a point in time. Snapshots offer protection against accidental deletion or modification of files in your volumes. With snapshots, your users can easily view and restore individual folders and files from an earlier snapshot. Doing this enables users to easily undo changes and compare file versions.
Because snapshots are stored alongside your file system's data, 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 are stored in the `.zfs/snapshot` directory at the root of a volume.
**Topics**
+ [Using snapshots to create volumes](#snapshots-volumes)
+ [Creating a snapshot](#creating-snapshots)
+ [Deleting a snapshot](#deleting-snapshots)
+ [Viewing a snapshot](#viewing-snapshots)
+ [Restoring a volume from a snapshot](#restore-volume-from-snapshot)
+ [Restoring individual files and folders](#snapshots-user-restore)
+ [Setting up a custom snapshot schedule](custom-snapshot-schedule.md)
## Using snapshots to create volumes
You can use a snapshot to create a clone volume or a full-copy volume.
A clone volume is a writable copy that is initialized with the same data as the snapshot from which it was created. Clone volumes provide an easy way to support multiple users or applications in parallel from a shared dataset, as well as quickly test new changes to your databases or applications. Clone volumes are created almost instantly and initially consume no additional storage capacity. (They only consume capacity for incremental changes to the source snapshot.) However, each clone volume maintains a dependency on its source snapshot, so you cannot delete this source snapshot while the clone volume is in use. To split a clone from its source snapshot and remove this dependency, you must create a new full-copy volume from that clone.
A full-copy volume is also initialized with the same data as its source snapshot, but is a fully independent writable copy. However, because a full-copy volume requires transferring all of the data from the source snapshot, it can take a significantly longer time to create than a clone volume. Once a full-copy volume is created, it is identical to a standard FSx for OpenZFS volume and does not maintain any relationship to its source snapshot.
For more information on creating clone and full-copy volumes, see [Managing Amazon FSx for OpenZFS volumes](managing-volumes.md).
## Creating a snapshot
You can create an FSx for OpenZFS snapshot using the Amazon FSx console, the AWS CLI, and the Amazon FSx API.
### To create a snapshot (console)
1. Open the Amazon FSx console at [https://console.aws.amazon.com/fsx/](https://console.aws.amazon.com/fsx/).
1. In the left navigation pane, under **OpenZFS**, choose **Snapshots**. Then in the **Snapshots** pane, choose **Create snapshot**.
You can also create a snapshot directly by navigating to the **Snapshots** tab of an individual volume and choosing **Create snapshot**.
1. In the **File system** field of the **Create snapshot** dialog box, choose the file system to create the snapshot on.
1. In the **Volume** field, choose an existing volume you want to take a snapshot of.
1. In the **Snapshot name** field, provide a name for the snapshot. You can use a maximum of 203 alphanumeric characters, and the special characters . - \$1 :
1. Choose **Confirm** to create the snapshot.
The snapshot is ready for use when its status is **Available**.
### To create a snapshot (CLI)
+ To create an FSx for OpenZFS snapshot, use the [create-snapshot](https://docs.aws.amazon.com/cli/latest/reference/fsx/create-snapshot.html) CLI command (or the equivalent [CreateSnapshot](https://docs.aws.amazon.com/fsx/latest/APIReference/API_CreateSnapshot.html) API operation), as shown in the following example.
```
aws fsx create-snapshot \
--volume-id fsvol-123 \
--name snapshot2
```
The command example uses the following parameters:
+ `volume-id` - The ID of the volume that you are taking a snapshot of.
+ `name` - The name of the source snapshot.
After successfully creating the snapshot, Amazon FSx returns its description in JSON format.
## Deleting a snapshot
You can delete an FSx for OpenZFS snapshot using the Amazon FSx console, the AWS CLI, and the Amazon FSx API. After deletion, the snapshot no longer exists, and its data is gone. Deleting a snapshot doesn't affect snapshots stored in a file system backup.
**Note**
A snapshot can't be deleted if it was previously cloned and that clone is still available. Before you can delete the snapshot, you must first delete all of the snapshot's clones.
### To delete a snapshot (console)
1. Open the Amazon FSx console at [https://console.aws.amazon.com/fsx/](https://console.aws.amazon.com/fsx/).
1. In the left navigation pane, under **OpenZFS**,choose **Snapshots**.
1. In the **Snapshots** page, choose the snapshot that you want to delete.
1. In the **Summary** page for the snapshot, choose **Delete**.
### To delete a snapshot (CLI)
+ To delete an FSx for OpenZFS volume, use the [delete-volume](https://docs.aws.amazon.com/cli/latest/reference/fsx/delete-snapshot.html) CLI command (or the equivalent [DeleteVolume](https://docs.aws.amazon.com/fsx/latest/APIReference/API_DeleteSnapshot.html) API operation), as shown in the following example.
```
aws fsx delete-snapshot --snapshot-id fsvolsnap-1234
```
## Viewing a snapshot
You can see the FSx for OpenZFS volumes that are currently on your file system using the Amazon FSx console, the AWS CLI, and the Amazon FSx API and SDKs.
**To view the snapshots on your file system:**
+ **Using the console** – Choose a file system to view the **File systems** detail page. Choose the **Volumes** tab to list all the volumes on the file system, and then choose a volume. The volume's **Summary** page has a **Snapshots** tab that lists the snapshots for the volume.
+ **Using the CLI or API** – Use the [describe-snapshots](https://docs.aws.amazon.com/cli/latest/reference/fsx/describe-snapshots.html) CLI command or the [DescribeSnapshots](https://docs.aws.amazon.com/fsx/latest/APIReference/API_DescribeSnapshots.html) API operation.
## Restoring a volume from a snapshot
You can return a volume to a state saved by a specified snapshot. You use the [restore-volume-from-snapshot](https://docs.aws.amazon.com/cli/latest/reference/fsx/restore-volume-from-snapshot.html) CLI command (or the equivalent [RestoreVolumeFromSnapshot](https://docs.aws.amazon.com/fsx/latest/APIReference/API_RestoreVolumeFromSnapshot.html) API operation), as shown in the following example.
```
aws fsx restore-volume-from-snapshot \
--volume-id fsvol-12345 \
--snapshot-id fsvolsnap-67890 \
--options DELETE_INTERMEDIATE_SNAPSHOTS DELETE_CLONED_VOLUMES
```
The command example uses the following parameters:
+ `volume-id` - The ID of the volume that you are restoring.
+ `snapshot-id` - The ID of the source snapshot. Specifies the snapshot you are restoring from.
+ `DELETE_INTERMEDIATE_SNAPSHOTS` - Deletes snapshots between the current state and the specified snapshot. `restore-volume-from-snapshot` will fail if there are intermediate snapshots and this option isn't used.
+ `DELETE_CLONED_VOLUMES` - Deletes any volumes cloned from this volume. `restore-volume-from-snapshot` will fail if there are any cloned volumes and this option isn't used.
## Restoring individual files and folders
Using the snapshots on your Amazon FSx file system, your users can quickly restore previous versions of individual files or folders. Doing this enables them to recover deleted or changed files stored on the shared file system. They do this in a self-service manner directly on their desktop without administrator assistance. This self-service approach increases productivity and reduces administrative workload.
Linux, macOS, and Windows clients can view snapshots in the `.zfs/snapshot` directory hidden at the root of a volume. The `.zfs` directory is hidden, so it will not appear in any `ls` or `dir` results. You must also specify the `crossmnt` option in the `NFS exports` configuration of your FSx for OpenZFS volume to enable your clients to navigate to this directory.
**To restore a file from a snapshot (Linux, macOS, and Windows clients)**
1. If the original file still exists and you do not want it overwritten by the file in a snapshot, then use your Linux, macOS, or Windows client to rename the original file or move it to a different directory.
1. In the `.zfs/snapshot` directory, locate the snapshot that contains the version of the file that you want to restore.
1. Copy the file from the `.zfs/snapshot` directory to the directory in which the file originally existed.
Data in snapshots is read only. If you want to make modifications to files and folders in a snapshot, you must save a copy of the files and folders to a writable location and make modifications to these copies.
# Setting up a custom snapshot schedule
You can set up a automated custom snapshot schedule for FSx for OpenZFS volumes using the resources and configuration template provided in this topic. The custom snapshot scheduling solution performs user-initiated snapshots of your Amazon FSx volumes on a custom schedule that you define. For example, you can configure a custom schedule to take a snapshot every hour and automatically delete snapshots that are older than two days.
For more information on CRON schedule patterns, see [Schedule expressions for rules](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-create-rule-schedule.html) in the *Amazon CloudWatch Events User Guide*.
## Architecture overview
Deploying this solution builds the following resources in the AWS Cloud:
![\[Diagram showing the custom snapshot schedule CloudFormation template.\]](http://docs.aws.amazon.com/fsx/latest/OpenZFSGuide/images/openzfs-custom-snapshot-architecture.png)
The diagram illustrates the following custom snapshot schedule workflow:
1. The solution CloudFormation template deploys an CloudWatch Event, an AWS Lambda function, an Amazon Simple Notification Service (Amazon SNS) queue, and an IAM role. The IAM role gives the Lambda function permission to invoke the necessary Amazon FSx API operations.
1. The CloudWatch event runs on a schedule you define as a CRON pattern, during the initial deployment. This event invokes the solution’s snapshot manager Lambda function that invokes the Amazon FSx `CreateSnapshot` API operation to initiate a snapshot.
1. The snapshot manager retrieves a list of existing user-initiated snapshots for the specified volume using `DescribeSnapshots`. It then deletes snapshots older than the retention period, which you specify during the initial deployment.
1. The snapshot manager sends a notification message to the Amazon SNS queue on a successful snapshot if you choose the option to be notified during the initial deployment. A notification is always sent in the event of a failure.
### Required permissions
The following permissions are required to use the custom snapshot schedule CloudFormation template:
+ `AWSCloudFormationFullAccess`
+ `AmazonS3FullAccess`
+ `AmazonEventBridgeFullAccess`
+ `IAMFullAccess`
+ `AmazonSNSFullAccess`
+ `AWSKeyManagementServicePowerUser`
+ `AWSLambda_FullAccess`
## CloudFormation template
This solution uses CloudFormation to automate the deployment of the Amazon FSx custom snapshot scheduling solution. To use this solution, download the [fsx-openzfs-scheduled-snapshot.template](https://solution-references.s3.amazonaws.com/fsx/snapshot/fsx-openzfs-scheduled-snapshot.yaml) CloudFormation template.
## Automated deployment
The following procedure configures and deploys this custom snapshot scheduling solution. It takes about five minutes to deploy. Before you start, you must have the ID of a volume on an Amazon FSx file system running in an Amazon Virtual Private Cloud (Amazon VPC) in your AWS account. For more information on creating these resources, see [Creating an Amazon FSx for OpenZFS volume](creating-volumes.md).
**Note**
Implementing this solution incurs billing for the associated AWS services. For more information, see the pricing details pages for those services.
**To launch the custom snapshot solution stack**
1. Download the [fsx-openzfs-scheduled-snapshot.template](https://solution-references.s3.amazonaws.com/fsx/snapshot/fsx-openzfs-scheduled-snapshot.yaml) CloudFormation template. For more information on creating an CloudFormation stack, see [Creating a stack on the AWS CloudFormation console](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-create-stack.html) in the *CloudFormation User Guide*.
**Note**
By default, this template launches in the US East (N. Virginia) AWS Region. Amazon FSx for OpenZFS is currently only available in specific AWS Regions. You must launch this solution in an AWS Region where FSx for OpenZFS is available. For more information, see [Amazon FSx endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/fsxn.html) in the *AWS General Reference*.
1. For **Parameters**, review the parameters for the template and modify them for the needs of your file system volumes. This solution uses the following default values.
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fsx/latest/OpenZFSGuide/custom-snapshot-schedule.html)
1. Choose **Next**.
1. For **Options**, choose **Next**.
1. For **Review**, review and confirm the settings. Select the check box acknowledging that the template creates IAM resources.
1. Choose **Create** to deploy the stack.
You can view the status of the stack in the CloudFormation console in the **Status** column. You should see a status of **CREATE\$1COMPLETE** in about five minutes.
## Additional options
You can use the Lambda function created by this solution to perform custom scheduled snapshots of more than one FSx for OpenZFS volume. The volume ID is passed to the Amazon FSx function in the input JSON for the CloudWatch event. The default JSON passed to the Lambda function is as follows, where the values for `VolumeId` and `SuccessNotification` are passed from the parameters specified when launching the CloudFormation stack.
```
{
"start-snapshot": "true",
"purge-snapshots": "true",
"volume-id": "${VolumeId}",
"notify_on_success": "${SuccessNotification}"
}
```
To schedule snapshots for an additional FSx for OpenZFS volume, create another CloudWatch event rule. You do so using the Schedule event source, with the Lambda function created by this solution as the target. Choose **Constant (JSON text)** under **Configure Input**. For the JSON input, simply substitute the volume ID of the FSx for OpenZFS volume to back up in place of `${VolumeId}`. Also, substitute either `Yes` or `No` in place of `${SuccessNotification}` in the JSON above.
Any additional CloudWatch Event rules you create manually aren't part of the CloudFormation stack for the Amazon FSx custom scheduled snapshot solution. Thus, they aren't removed if you delete the stack.
# Protecting your data with on-demand replication
Amazon FSx for OpenZFS supports on-demand data replication, enabling you to transfer snapshots of data between file systems within and across AWS Regions and accounts. You can use on-demand data replication for a variety of tasks such as:
+ Synchronizing or distributing data to your development or test environments.
+ Establishing and maintaining read replicas to provide scale-out read performance.
+ Maintaining a passive standby file system for use in disaster recovery cases.
With on-demand data replication, Amazon FSx automatically establishes and maintains network connectivity between file systems to handle interruptions and resume data transfer as needed. Amazon FSx also encrypts data in transit and at rest and integrates with AWS RAM to authorize accesss to volumes for data replication across AWS accounts. For more information, see [Shareable AWS resources](https://docs.aws.amazon.com/ram/latest/userguide/shareable.html#shareable-fsx) in the *AWS RAM User Guide*.
On-demand data replication is available for all deployment types in AWS Regions where Amazon FSx for OpenZFS is available. For more information, see [Availability by AWS Region](available-aws-regions.md).
**Topics**
+ [Prerequisites for using on-demand data replication](#access-data-replication)
+ [Performance considerations for on-demand data replication](#on-demand-replication-performance)
+ [Using on-demand data replication](#how-to-use-data-replication)
+ [Monitoring progress of on-demand data replication](#how-to-monitor-data-replication)
+ [Setting up ongoing periodic data replication](ongoing-periodic-data-replication.md)
## Prerequisites for using on-demand data replication
Before using on-demand data replication, make sure that you have met the following prerequisites.
+ Single-AZ 1 (non-HA and HA) file systems must have a provisioned throughput capacity of 256 MBps or above. It is also recommended that Single-AZ 1 (non-HA and HA) file systems have a provisioned SSD IOPS level of 6,000 or above.
+ Single-AZ 2 (non-HA and HA) and Multi-AZ (HA) file systems must have a provisioned throughput capacity of 160 MBps or above. It is also recommended that Single-AZ 2 (non-HA) and Multi-AZ (HA) file systems have a provisioned SSD IOPS level of 6,000 or above.
+ Users or roles must have permission to take the [CreateVolume](https://docs.aws.amazon.com/fsx/latest/APIReference/API_CreateVolume.html) and [CopySnapshotAndUpdateVolume](https://docs.aws.amazon.com/fsx/latest/APIReference/API_CopySnapshotAndUpdateVolume.html) actions in an AWS account. You can control these permissions by using AWS Identity and Access Management (IAM) policies. For more information, see [Actions, resources, and condition keys for Amazon FSx](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonfsx.html#amazonfsx-actions-as-permissions.html) in the *Service Authorization Reference*.
+ To replicate data across file systems in different AWS accounts, the source account must have, at minimum, permission to take the **fsx:PutResourcePolicy**, **fsx:GetResourcePolicy**, and **fsx:DeleteResourcePolicy** actions. The source account must also have permissions to share resources on AWS RAM. To grant these permissions, you can directly attach the [AmazonFSxFullAccess](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonFSxFullAccess), [AmazonFSxConsoleFullAccess](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonFSxConsoleFullAccess), and [AWSResourceAccessManagerFullAccess](https://docs.aws.amazon.com/ram/latest/userguide/security-iam-managed-policies.html#security-iam-managed-policies-AWSResourceAccessManagerFullAccess) AWS managed policies to your IAM roles, groups, and users. The destination account must have the [AWSResourceAccessManagerResourceShareParticipantAccess](https://docs.aws.amazon.com/ram/latest/userguide/security-iam-managed-policies.html#security-iam-managed-policies-AWSResourceAccessManagerResourceShareParticipantAccess) AWS managed policy attached to its IAM roles, groups, and users.
## Performance considerations for on-demand data replication
On-demand data replication shares provisioned throughput with other file system clients. To accommodate data replication activity without impacting other workloads, we recommend provisioning twice the level of throughput capacity that your workload normally needs. You can use Amazon CloudWatch metrics with FSx for OpenZFS to monitor your file system’s performance utilization and scale up your file system’s performance as needed to avoid slowing down your ongoing workloads. For more information, see [Using Amazon FSx for OpenZFS CloudWatch metrics](how_to_use_metrics.md).
## Using on-demand data replication
On-demand data replication only transfers data from the indicated source snapshot, which does not include data from child volumes. To transfer data from child volumes, you must initiate additional data replication jobs using source snapshots from the child volumes.
Each file system can only be used as the source file system or the destination file system for one on-demand data replication task at a time. You must wait until the first on-demand replication task is completed or cancelled before initating another request. You can only have a maximum of twenty concurrent cross-file system replication jobs per account, per AWS Region.
### Replicating data across file systems on the same account
You can create or update a replica volume across file systems that are on the same AWS account by using the Amazon FSx Console, API, or CLI.
#### To update a volume from a snapshot (Console)
1. Open the Amazon FSx console at [https://console.aws.amazon.com/fsx/](https://console.aws.amazon.com/fsx/).
1. In the left navigation pane, choose **Volumes**, and then choose the volume that you would like to use as your destination volume.
1. For **Actions**, choose **Update volume with snapshot**. The **Copy snapshot and update volume** panel displays.
1. Choose the source region of the snapshot
1. Choose the snapshot that you would like to update the volume from.
1. For **Source snapshot copy strategy**, choose **Incremental copy** or **Full copy**. An incremental copy returns the destination volume to the most recent common ancestor that it shares with the source volume and then updates the destination volume, transferring only the data that is not already included in the most recent common ancestor. A full copy will remove any clones, snapshots, and intermediate data on the destination volume and transfer all of the data from the source volume. During incremental copy, your destination volume will be read-only. During full copy, your destination volume will be unmounted and automatically remounted after the transfer is completed.
1. If the destination volume has any **intermediate clones**, **dependent snapshots**, or **intermediate data**, select the checkboxes to delete them. If you are using incremental copy, you must delete all descendent data for the update to succeed.
1. Choose **Update** to update the volume.
#### To update a volume from a snapshot (CLI)
+ To update an FSx for OpenZFS volume with a snapshot, use the [copy-snapshot-and-update-volume](https://docs.aws.amazon.com/cli/latest/reference/fsx/copy-snapshot-and-update-volume.html) CLI command, or the equivalent [CopySnapshotAndUpdateVolume](https://docs.aws.amazon.com/fsx/latest/APIReference/API_CopySnapshotAndUpdateVolume.html) API command, and specify the following properties:
+ `--volume-id` – The ID of the volume that you would like to update.
+ `--source-snapshot-arn` – The ARN of the source snapshot.
+ `--options` – Any intermediate clones, dependent snapshots, or intermediate data that need to be deleted. Valid values are `DELETE_INTERMEDIATE_SNAPSHOTS`, `DELETE_CLONED_VOLUMES`, and `DELETE_INTERMEDIATE_DATA`.
+ `--copy-strategy` – Strategy used to copy data from the source volume. Value values are `FULL_COPY` and `INCREMENTAL_COPY`.
The following example shows how to update a volume with a snapshot using incremental copy and deleting all intermediate clones, dependent snapshots, and intermediate data.
```
aws fsx copy-snapshot-and-update-volume \
--volume-id fsvol-1234567890abcdef0 \
--source-snapshot-arn arn:aws:fsx:555555555555:snapshot/fsvol-1234567890abcdef0/fsvolsnap-021345abcdef6789\
--options DELETE_INTERMEDIATE_SNAPSHOTS DELETE_CLONED_VOLUMES DELETE_INTERMEDIATE_DATA\
--copy-strategy INCREMENTAL_COPY
```
The example above returns the following response.
```
{
"VolumeId": "fsvol-1234567890abcdef0",
"Lifecycle": "AVAILABLE",
"AdministrativeActions": [
{
"AdministrativeActionType": "VOLUME_UPDATE_WITH_SNAPSHOT",
"FailureDetails": {
"Message": "string"
},
"ProgressPercent": 80,
"RequestTime": 2023-11-03T09:26:55-07:00,
"Status": "IN_PROGRESS",
"TargetVolumeValues": {
"OpenZFSConfiguration": {
"RecordSizeKiB": 128,
"DataCompressionType": "ZSTD",
"DeleteIntermediateSnaphots": false,
"DeleteClonedVolumes": false,
"DeleteIntermediateData": true,
"SourceSnapshotARN": "arn:aws:fsx:us-east-1:854733241892:snapshot/fsvol-018a3d05b4d9fc768/fsvolsnap-03b43bd1942a51637",
"DestinationSnapshot": "fsvolsnap-0f753e290e20cc974" }"
}
}]
}
```
### Replicating data across file systems on different AWS accounts using AWS RAM
FSx for OpenZFS integrates with AWS Resource Access Manager (RAM) to allow you to replicate data across file systems that are on different AWS accounts. In the AWS Resource Access Manager (RAM) console, the owner of the source account must first enable resource sharing, and then share the source FSx for OpenZFS volume with the destination account. For more information on enabling and creating a resource share, see [Enable resource sharing within AWS Organizations](https://docs.aws.amazon.com/ram/latest/userguide/getting-started-sharing.html#getting-started-sharing-orgs) and [Creating a resource share](https://docs.aws.amazon.com/ram/latest/userguide/working-with-sharing-create.html) in the *AWS RAM User Guide*.
You will receive a shared resource invitation when the source volume has been shared with your account. Once you accept the invitation, all snapshots associated with the source volume will appear in the list of snapshots that you can replicate to a volume in the FSx for OpenZFS console. For more information, see [To update a volume from a snapshot (Console)](#update-volume-from-snapshot-console). After you’ve created a replica volume, you can continue to update it with any of the subsequent snapshots in the source volume, as long as the source volume continues to be shared.
## Monitoring progress of on-demand data replication
You can monitor the progress of your data replication using the AWS Management Console on the **Volume details** page. When you initiate a replication task, the destination snapshot will enter the **CREATING** state. Once the data transfer is complete, the destination snapshot will become **AVAILABLE**.
You can also use the AWS CLI or Amazon FSx API to track more detailed progress of your replication by using the [describe-volumes](https://docs.aws.amazon.com/cli/latest/reference/fsx/describe-volumes.html) AWS CLI command or the [DescribeVolumes](https://docs.aws.amazon.com/fsx/latest/APIReference/API_DescribeVolumes.html) API operation. to display the `AdministrativeActions` for the destination volume. The `AdministrativeActions` array lists the 10 most recent update actions for each administrative action type. When you initiate an on-demand data replication, a `VOLUME_UPDATE_WITH_SNAPSHOT` action is generated. Progress will be reported using the `ProgressPercent` property.
The following example shows the response for an incremental copy on-demand data replication task.
```
{
"VolumeId": "fsvol-1234567890abcdef0",
"Lifecycle": "AVAILABLE",
"AdministrativeActions": [
{
"AdministrativeActionType": "VOLUME_UPDATE_WITH_SNAPSHOT",
"FailureDetails": {
"Message": "string"
},
"ProgressPercent": 80,
"RequestTime": 2023-11-03T09:26:55-07:00,
"Status": "IN_PROGRESS",
"TotalTransferBytes": 107483152368,
"RemainingTransferBytes": 0
"TargetVolumeValues": {
"OpenZFSConfiguration": {
"SourceSnapshotARN": "stringarn:aws:fsx:555555555555:snapshot/fsvol-1234567890abcdef0/fsvolsnap-021345abcdef6789",
"DestinationSnapshot": "fsvolsnap-021345abcdef6789"
}
}
}]
}
```
When Amazon FSx processes the request successfully, the status changes to `COMPLETED`. If the on-demand data replication task fails, the status changes to `FAILED`, and the `FailureDetails` property provides information about the failure.
# Setting up ongoing periodic data replication
With ongoing periodic data replication, you can set up a schedule that automatically takes a snapshot of a source volume and performs an incremental replication of that snapshot on a destination volume at a certain interval, for example every 15 minutes. You can schedule ongoing periodic data replication between two volumes on FSx for OpenZFS file systems within or across AWS Regions and accounts by using the solution provided in this section.
**Topics**
+ [Architecture overview](#architecture-overview-periodic-replication)
+ [Required permissions](#required-permissions-periodic-replication)
+ [Step 1: Initializing and deploying the application](#step-1-periodic-replication)
+ [Step 2: Monitoring periodic replication](#step2-periodic-replication)
## Architecture overview
Deploying this solution builds the following resources in the AWS Cloud.
![\[Architecture of the periodic data replication solution.\]](http://docs.aws.amazon.com/fsx/latest/OpenZFSGuide/images/openzfs-periodic-data-replication-architecture.PNG)
The diagram illustrates the following periodic replication workflow.
1. AWS Serverless Application Model (SAM) automates the deployment of the FSx for OpenZFS periodic replication solution. For more information about AWS SAM, see [What is the AWS Serverless Application Model (AWS SAM)?](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/what-is-sam.html) in the *AWS Serverless Application Model* User Guide.
1. The SAM template deploys an Amazon EventBridge scheduler, an AWS Lambda function, an Amazon SNS queue, and an IAM role. The IAM role gives the Lambda function permission to call the necessary Amazon FSx API operations.
1. The EventBridge scheduler runs on a schedule you specify as a cron pattern during the initial deployment. For more information about cron patterns, see [Creating an Amazon EventBridge rule that runs on a schedule](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-create-rule-schedule.html) in the *Amazon EventBridge* User Guide. The scheduler invokes a Lambda function that calls the Amazon FSx `CreateSnapshot` API operation to create a snapshot of the source volume.
1. Once the snapshot is available, the Lambda function calls the Amazon FSx `CopySnapshotAndUpdateVolume` API operation to start replicating the source snapshot data to the destination volume.
1. The Lambda function sends a notification message to the Amazon SNS queue when replication starts, if you choose to be notified during the initial deployment. A notification is always sent when a snapshot cannot be created or the replication cannot be initiated.
## Required permissions
The following permissions are required to use the custom snapshot schedule CloudFormation template.
+ `AmazonS3FullAccess`
+ `AWSCloudFormationFullAccess`
+ `AmazonEventBridgeFullAccess`
+ `IAMFullAccess`
+ `AmazonSNSFullAccess`
+ `AWSKeyManagementServicePowerUser`
+ `AWSLambda_FullAccess`
For more information about using IAM to set up permissions, see [How Amazon FSx for OpenZFS works with IAM](security_iam_service-with-iam.md).
## Step 1: Initializing and deploying the application
The following procedure configures and deploys the periodic replication solution. It takes about five minutes to deploy. Before you begin this step, make sure that you have the ID of the source and destination volumes that you would like to initiate the replication between. For more information on these resources, see [Creating an Amazon FSx for OpenZFS volume](creating-volumes.md), [Creating a snapshot](snapshots-openzfs.md#creating-snapshots), and [Using on-demand data replication](on-demand-replication.md#how-to-use-data-replication).
**Note**
Implementing this solution incurs billing for the associated AWS services. For more information, see the pricing details pages for those services.
**To launch the periodic replication solution stack**
1. Follow the instructions on the [Replicate FSx-OpenZFS volumes across file systems](https://serverlessland.com/patterns/eventbridge-lambda-fsx-openzfs-periodic-replication) page to download the serverless pattern.
1. For **Parameters**, review the following parameters for the template and modify them for the needs of your periodic replication. This solution uses the following default values.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fsx/latest/OpenZFSGuide/ongoing-periodic-data-replication.html)
1. In the AWS SAM CLI, run the following command to deploy the resources specified in the SAM template.
```
sam deploy --guided \
--stack-name fsxz-periodic-replication \
--template-file fsx-openzfs-periodic-replication.yaml \
--capabilities CAPABILITY_AUTO_EXPAND CAPABILITY_IAM CAPABILITY_NAMED_IAM
```
You will be asked if you would like to update any parameters.
1. Choose **Enter** to deploy the template.
## Step 2: Monitoring periodic replication
You can monitor the status of the periodic replication workflow using the Amazon FSx Console, AWS CLI, and API. For more information on how to monitor periodic replication using the Amazon FSx Console, see [Monitoring progress of on-demand data replication](on-demand-replication.md#how-to-monitor-data-replication).
To use the AWS CLI or API to track the progress of your replication, call the [describe-volumes](https://docs.aws.amazon.com/cli/latest/reference/fsx/describe-volumes.html) CLI command or the [DescribeVolumes](https://docs.aws.amazon.com/fsx/latest/APIReference/API_DescribeVolumes.html) API operation to view the `AdministrativeActions` array for the destination volume. The following example shows the response for an incremental copy on-demand data replication task.
```
"AdministrativeActions": [
{
"AdministrativeActionType": "VOLUME_UPDATE_WITH_SNAPSHOT",
"ProgressPercent": 100,
"RequestTime": 1699997847.438,
"Status": "COMPLETED",
"TargetVolumeValues": {
"OpenZFSConfiguration": {
"RecordSizeKiB": 128,
"DataCompressionType": "ZSTD",
"DeleteIntermediateSnaphots": true,
"DeleteClonedVolumes": false,
"DeleteIntermediateData": true,
"SourceSnapshotARN": "arn:aws:fsx:us-east-1:609492434915:snapshot/fsvol-0e1ab09de954a352f/fsvolsnap-01dda47dcbb24ddd0",
"DestinationSnapshot": "fsvolsnap-0afef62088c7c9060"
}
},
"TotalTransferBytes": 44144,
"RemainingTransferBytes": 0
},
```