FSx for ONTAP Backups

In our FSx for NetApp ONTAP series, we continue to one of the most vital topics: Backups. But did you know there are two types of backup with this service? Let’s compare the native backup and AWS Backup in this post.

General

As you might remember, AWS backup works differently from other backup solutions because we are talking about a snapshot-based approach and not a file-based one.

This approach has several advantages: no need for a backup agent, instant backup windows, and no additional system load - as backup is done on the storage and block level.

Consequently, your first snapshot contains all data, and all subsequent ones only have the differences from the one before. If you did classical images, you would need to pay a multiple of your hard drive size. But with the techniques we are using on AWS, you only pay for the data you change.

With this knowledge, we arrive at a formula for how you calculate your aggregate backup space:

raw_capacity + raw_capacity * daily_change_rate/100 * retention_time

Quick example: If you have 100 TB of capacity and a daily change rate of 3% with 90 days of retention, you can expect 370 TB of backup size (and cost).

FSx for NetApp ONTAP Native Backup

The first type of backup is the Amazon FSx for NetApp ONTAP (FSxN) native one: it simply uses the described snapshot technology to keep a local list of previous snapshots. It runs daily in a defined period and has a default retention of seven days (1 - 90 days are possible).

A significant caveat is that these automatic backups are tied to their volume. In NetApp terminology, these are called FlexVols, and snapshots use the inherent capabilities of the WAFL filesystem not to copy data but to create pointers to the used blocks on disk. As soon as a snapshot is requested, there will be another list of pointers to the data blocks at this point. As soon as the original volume changes, there will be new blocks, and the maps between the actual volume and the snapshot will diverge.

FSxN Snapshots

But that also means another thing: if you delete the FlexVol, all those automatic snapshots will be deleted as well.

There is a big difference with manual, user-initiated backups: These will be completely standalone, and volume deletion will not affect them.

AWS Backup

While AWS Backup uses the same mechanics as the native backup, its backups are always independent of the originating volume. It also includes more scheduling options:

  • adjustable frequency between hourly and monthly backups
  • layering different policies allows for a classic Grandfather-Father-Son (GFS) backup, not only rolling snapshots
  • the ability to copy into different regions for disaster recovery scenarios
  • WORM ability to lock contents against deletion (which might be a good idea with ransomware threats rising)

Summary

After learning about the differences, you should be able to determine which type of backup is more appropriate for your workload. Most people will generally prefer the versatility and robustness of AWS Backup to the native technologies.

Similar Posts You Might Enjoy

Multi-AZ Block Storage for EKS - Architecture

On the heels of the recent announcement of our consulting offer for multi-AZ block storage for EKS, it is worth discussing some of the base technologies. Let’s look into the idea and how it works under the hood. - by Thomas Heinen

Multi-AZ Block Storage for EKS - New Consulting Offer

Today we announce a new consulting offer on the AWS Marketplace: Multi-AZ Block Storage for EKS. Finally, you can use block-based storage for your specialized workloads, which is highly available. - by Thomas Heinen

Multi-AZ Block Storage for EKS - Solution Overview

Did you already encounter an application on EKS which does not perform well with EFS storage or which even needs dedicated block storage with multi-AZ capabilities? In this case, we have prepared something for you: We now support you with creating multi-AZ block storage for your EKS clusters and add facilities to monitor, manage and troubleshoot them with easy building blocks. - by Thomas Heinen , Kobi Biton