I often get asked what backup & recovery and DR solutions are available for Azure NetApp Files. There are several options available today, both natively built into the service, as well as external solutions. In this article I’ll describe five scenarios I come across most often in the field. I’ll list some of the most obvious ‘pros‘ and ‘cons‘ for each solution, but it is by no means a comprehensive list.
1. ANF snapshots
“Snapshots are not backups!” said only every backup vendor ever. They’re not wrong, but boy are snapshots handy! ANF snapshots offer a great first line of defense, that can be part of a multi-layer data protection approach. Snapshots are space efficient (pointer based) and highly performant.
Creating or restoring snapshots only takes a couple of seconds and has no performance impact on the source volume whatsoever. Snapshots have a superior RTO/RPO, especially when you’re talking multiple TBs of data that need to be backed up in a short time frame.
You can create on-demand snapshots through the Portal or API or you can configure a snapshot policy, which allows you to take hourly/daily/weekly/monthly snapshots at a specific time. If you need more granular scheduling options, you can check out the Azure NetApp Files Snapshot Scheduler logic app.
ANF snapshots operate at the block level and are crash consistent by default. Microsoft provides a tool called AzAcSnap (Azure Application Consistent Snapshot), which provides application-aware snapshots for SAP HANA.
One of the coolest features is that all snapshots are exposed (read-only) inside the source volume itself, through the hidden .snapshot folder. This allows for self-service recovery and it lets you easily copy out snapshot data. Optionally, you can disable this functionality.
Now for the not so nice part; a snapshot is linked to its source volume, meaning if for whatever reason the volume goes offline, your snapshot data will be unavailable also.
You can read more on ANF snapshots in this very extensive Docs article.
Pros
– ANF snapshots are built on superior NetApp ONTAP copy-on-write technology
– Superior RTO/RPO; seconds to create/restore a snapshot and no source volume performance impact
– Space efficient, storing only changed blocks
– On-demand or policy based snapshots
– No additional cost (apart from snapshot data consumption)
– Up to 255 snapshots per volume
– Snapshot data exposed through hidden .snapshot folder
*update March 2022: ANF snapshots now support single file restore (public preview)
Cons
– Snapshot data consumes logical volume space, volumes need to be sized accordingly
– Crash consistent by default
– Snapshot data is linked to the source volume
2. ANF Backup (public preview)
I’m very excited to finally be able to speak publicly about Azure NetApp Files Backup! ANF Backup transitioned from private preview into public preview this month (September 2021). ANF Backup provides a fully managed backup service for long-term retention.
ANF Backup builds on top of ANF snapshots. ANF Backup copies the snapshot data (according to a retention schedule you configure) to ZRS-enabled Azure storage. The completed backup is self-contained and does not rely on the source volume and its snapshots, meaning if your source volume goes offline, you will still be able to access your backup data.
ANF Backup does provide data efficiency –> the first backup is a full baseline backup, for all subsequent backups only the changed blocks are stored, meaning incremental forever. Data transfer takes place on the back-end, meaning there’s no impact to front-end volume performance! Pricing options for ANF backup are available on the pricing page.
Pros
– Fully managed backup service built natively into ANF
– Long-term retention on cost effective storage
– ZRS-enabled storage, replicates data synchronously across three Availability Zones in the region
– Space efficient, storing only changed blocks (incremental forever)
– Backup operation does not consume front-end volume performance
Cons
– Microsoft public preview terms and conditions apply
– Limits apply during preview
3. ANF Cross Region Replication
CRR provides data protection through asynchronous replication of the ANF volume and its snapshots to its cross-region replication pair (e.g. West Europe <–> North Europe). This makes CRR a good fit for DR scenarios, such as region-wide outages or disasters.
The ANF volume is replicated on a 10-minute, hourly or daily schedule. Transfer takes place across the Azure backbone, meaning blazing fast transfer speeds.
Both the source and target CRR volumes need to be ANF volumes, however you can opt to select a lower service tier for the target CRR volume and only change it to a higher tier in case of an actual DR. The service level of the volumes does not impact CRR replication speed.
More details on CRR, including the standard and non-standard region pairs can be found here. Pricing is available on the pricing page.
Pros
– Cross region protection
– Replicates entire volume, including snapshots
– Fast replication speed, independent of volume service level
– Target volume can reside on a lower service level
Cons
– Microsoft public preview terms and conditions apply
*update: ANF CRR has been GA since October 2021, read more in this blog.
– Limited replication schedule
– Replication technology and therefor will replicate front-end (application) errors to the target
4. ANF snapshots with offloading
This scenario builds on top of the ANF snapshot functionality in combination with the hidden .snapshot folder. Snapshot data is copied out, over the front-end protocol (NFS/SMB) to a storage destination of your liking. The storage destination can be cheap and deep (e.g. Azure Blob), AZ redundant, geo redundant, on-prem, it’s up to you.
This scenario even supports copying out the data between different subscriptions and Azure AD tenants utilizing cross subscription VNnet peering.
There’s a variety of copy tools that can be used, triggered manually or on a schedule. You can choose to copy out all the snapshots, or just a single one. You can even drill down into the snapshot folder and only copy out a select subset of data.
Please note, once you copy out the snapshot data, you lose the data efficiency. For example; assume a 4TB ANF volume with a daily snapshot. After one week you have 7 snapshots, which are only consuming changed data. If you now copy out all the snapshot data over the front-end, you are copying 7x4TB=28TB total. You can opt to leverage a target storage device that offers data optimization (dedupe, compression) like Cloud Volumes ONTAP by NetApp.
Pros
– Flexibility in storage targets and copy tools
– Copy all snapshots or a more granular subset of data
– Copy between different Azure subscriptions or tenants
Cons
– Data efficiency is lost on copy
– Copy operation consumes front-end volume performance
5. Azure Backup
Let me be very clear: ANF Backup and Azure Backup are two different backup services offered by Azure and there’s no integration between them. Utilizing Azure Backup you can indirectly backup data residing on ANF (or any other storage for that matter), as long as Azure Backup supports the specific application. Azure Backup currently supports MSSQL, SAP HANA and PostgreSQL.
N.B. Regular VM backups through Azure Backup will not include any ANF data.
6. 3rd party solutions
There’s a variety of 3rd party backup solutions which can be used to backup ANF. Basically any solution that can do a streaming (front-end) SMB/NFS/NAS backup will work for ANF. Think of vendors like Commvault, Rubrik, Veeam etc.
Depending on the exact workload, these vendor may provide agents to create an application-aware backup. Commvault even offers application aware backups with ANF snapshots integration for SAP HANA, very cool!
Pros
– Application-aware backups through agents
Cons
– Backup consumes front-end volume performance
– Cost and licensing