Protecting your data with volume backups - FSx for ONTAP
Services or capabilities described in Amazon Web Services documentation might vary by Region. To see the differences applicable to the China Regions, see Getting Started with Amazon Web Services in China (PDF).

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 Amazon Web Services 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 does not support backing up data protection (DP) volumes, load sharing mirror (LSM) volumes, or destination FlexCache volumes.

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 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 Amazon Web Services account and per volume. For more information, see Quotas that you can increase and Resource quotas for each file system.

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 or file system's 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, 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.

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 Amazon 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 Amazon CLI, or API to change these settings. For more information, see Updating a file system.

You can't create a volume backup (automatic daily backups or user-initiated backups) if the volume is offline. For more information, see Backups and offline volumes.

Note

Automatic daily backups have a maximum retention period of 90 days, but user-initiated backups that you create, which include backups created using Amazon Backup, are retained forever unless you or Amazon Backup deletes them.

You can manually delete 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 Amazon Web Services Management Console, Amazon 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 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 Create a user-initiated backup.

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 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 Amazon Backup with Amazon FSx

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

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

  • Automate backup scheduling.

  • Set retention policies.

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

Amazon Backup uses the built-in backup functionality of Amazon FSx. Backups created using the Amazon 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 Amazon 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.

Backups created by Amazon 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 Amazon Backup using the Amazon FSx console, CLI, and API. However, you can't delete backups created by Amazon Backup in the Amazon FSx console, CLI, or API. For more information, see Getting started with Amazon Backup in the Amazon Backup Developer Guide.

Amazon Backup can't back up volumes that are offline.

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 Amazon Web Services Region that the backup is stored in. You cannot restore a backup to a file system that is located in a different Amazon Web Services Region than the backup.

When you restore a FlexGroup volume backup to a file system that has a different number of high-availability (HA) pairs 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 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 Restore a backup.

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.

Deleting backups

You can delete both automatic daily backups and user-initiated backups of your volumes. 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 cannot delete a backup if the source volume is offline. For instructions about how to delete backups, see Delete a backup.

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.

You can't delete backups created by Amazon Backup, which have type Amazon Backup using the Amazon FSx console, CLI, or API. Instead, you need to use the Amazon Backup console and CLI. For more information, see Deleting backups in the Amazon Backup Developer Guide.

Important

Do not delete the common snapshot on the volume because it is used to maintain incrementality between your backups. Deleting a volume's common snapshot will cause the next backup to be a full backup of the volume instead of an incremental backup.

To determine which snapshot is a volume's common snapshot, use the volume snapshot show ONTAP CLI command.

volume snapshot show -volume volume-name

In the output, the name of the common snapshot has the format of backup-id, where id is a 17 digit alphanumeric string, as shown in the following example:

FsxIdabc12345::> volume snapshot show -volume test_vol ---Blocks--- Vserver Volume Snapshot Size Total% Used% -------- -------- --------------------------- -------- ------ ----- dest-svm test_vol snap1 144KB 0% 3% snap2 832KB 0% 16% ---> backup-abcdef0123456789a 4.87MB 0% 53% <--- weekly.2024-05-26_0015 5.02MB 0% 54% weekly.2024-06-02_0015 2.22MB 0% 34% daily.2024-06-04_0010 284KB 0% 6% daily.2024-06-05_0010 4.29MB 0% 50% hourly.2024-06-05_0705 168KB 0% 4% 8 entries were displayed.

Backups and offline volumes

You can't create or delete volume backups when the source volume is offline. You can use the volume show ONTAP CLI command to determine a volume's current status.

volume show -vserver svm-name

For information about accessing the ONTAP CLI on your file system, see Using the NetApp ONTAP CLI.

FsxIdabc12345::> volume show -vserver vs1 Vserver Volume Aggregate State Type Size Available Used% --------- ------------ ------------ ---------- ---- ---------- ---------- ----- vs1 vol1 aggr1 online RW 2GB 1.9GB 5% vs1 vol1_dr aggr0_dp online DP 200GB 160.0GB 20% vs1 vol2 aggr0 online RW 150GB 110.3GB 26% vs1 vol2_dr aggr0_dp online DP 150GB 110.3GB 26% vs1 vol3 aggr1 online RW 150GB 120.0GB 20% vs1 vol3_dr aggr1_dp online DP 150GB 120.0GB 20% vs1 vol4 aggr1 online RW 200GB 159.8GB 20% 7 entries were displayed.

To bring an offline volume back online, use the volume online ONTAP CLI command, as shown in the following example:

FsxID-abcdef123456::> volume online -volume volume_name -vserver svm_name Volume 'vs1:vol1' is now online.