Working with 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).

Working with backups

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

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

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

Amazon FSx supports backing up ONTAP FlexVol volumes (on all file systems) and FlexGroup volumes with an OntapVolumeType of RW (read-write).

Note

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

There are limits to the number of backups that you can store per file system and per volume. For more information, see Quotas that you can increase and Resource quotas for each file system.

How backups work

Amazon FSx backups use snapshots – point-in-time, read-only images of your volumes – to maintain incrementality between backups. Each time a backup is taken, Amazon FSx first takes a snapshot of your volume. The backup snapshot is stored in your volume, and consumes space on your SSD storage tier. Amazon FSx then compares this snapshot to the previous backup snapshot (if one exists) and copies only the changed data into your backup.

If no prior backup snapshot exists, then the entire contents of the most recent backup snapshot is copied into your backup. After the latest backup snapshot is successfully taken, Amazon FSx deletes the previous backup snapshot. The snapshot used for the latest backup remains in your volume until the next backup is taken, when the process repeats. To optimize backup storage costs, ONTAP preserves a volume's storage efficiency savings in its backups.

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

Storage requirements

In order to take backups of your volumes, both your volume and your file system must 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.

Working with automatic daily backups

Automatic daily backups of your file system's volumes are enabled by default when you create a file system. You can enable or disable automatic daily backups for a file system at any time. Automatic daily backups occur during the daily backup window, which is automatically set when you create a file system. You can modify the daily backup window at any time. We recommend that you choose a time of the day for your daily backup that is outside of the normal operating hours for the applications that use your volumes for better backup performance. For more information, see Backup and restore performance.

You can set the retention period for automatic daily backups to between 1 and 90 days in the console when creating a file system or at any time. The default automatic daily backup retention period is 30 days. The service deletes an automatic daily backup once its retention period expires. Using the CLI or API you can set the retention period to between 0 and 90 days; setting it to 0 turns off automatic daily backups.

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

You can't create a volume backup 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 the Amazon Backup service deletes them.

You can manually delete an automatic daily backup using the 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. for more information, see Deleting backups.

Working with 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 more information, see Deleting backups.

You cannot create a volume backup if the volume is offline. For more information, see Backups and offline volumes.

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, the service does not copy tags from the volume, even if CopyTagsToBackups is enabled.

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 read and writes. All background processes, including backup and restore operations, 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.

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. Amazon Backup makes it easier to develop a centralized backup strategy for legal, regulatory, and professional compliance. Amazon Backup 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 backups you take of your volume (user-initiated or automatic), and offer the same restore options as backups taken through the Amazon FSx console. If you use Amazon Backup to manage these backups, you gain additional functionality, such as the ability to create scheduled backups as frequently as every hour. You can add an additional layer of defense to protect backups from inadvertent or malicious deletions by storing them in an Amazon 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 in 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, effectively restoring a point-in-time snapshot of a volume using the console, CLI, or API.

When restoring a backup, all the data is first written to the SSD storage tier before the service begins tiering data to the capacity pool storage according to the tiering policy you set for the restored volume. When restoring a backup to a volume with a tiering policy of All, a periodic background process tiers the data to the capacity pool. When restoring a backup to a volume with a tiering policy of Snapshot Only or Auto, data is tiered to the capacity pool if the SSD utilization for the file system is greater than 50%, and the cooling rate is determined by the tiering policy’s cooling period.

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

For step-by-step instructions to restore a backup to a new volume, see Restoring a backup to a new volume.

Note

A restored volume always has the same volume style as the original volume. You can't change the volume style when restoring.

Deleting backups

You can delete 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. For instructions describing how to delete backups, see Deleting a backup.

You can't delete backups created by Amazon Backup, which have type Amazon Backup, in the Amazon FSx console, CLI, or API. For information on deleting backups created by Amazon Backup, see Deleting backups in the Amazon Backup Developer Guide.

You cannot delete a volume's backup if the volume is offline. For more information, see Backups and offline volumes.

Important

Do not delete the common snapshot on the volume because it is used to maintain incrementality between your backups. Deleting the common snapshot on the volume will cause the next backup to be of the entire volume rather than just an incremental backup.

Backups and offline volumes

You can't create or delete volume backups if that volume is offline. Use the volume show ONTAP CLI command to determine a volume's current state and status.

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

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