Recently I had an opportunity to work with the NetApp BlueXP™ control plane to test the integration of the NetApp Cloud Backup service with applications that make use of databases residing on ONTAP hosted LUNs. Backing up a database requires more than a file system snapshot. To create a usable and restorable snapshot of a database, the database must be in the proper state. Most databases refer to it simply as “backup mode.” You don’t want to keep operating with the database in backup mode for too long. So, your ONTAP administrator must be ready to create the LUN snapshots quickly so that the application can be returned to normal operations as soon as possible.
For this reason, the process of putting a database in backup mode, triggering the snapshot, and reverting the backup mode is usually automated. In this blogpost, I will show you how to use a single REST API command to achieve your 3:2:1 backup strategy.
This one command can be added to your automation framework. For an electronic health record (EHR) application, this framework is typically an Ansible script or is driven by the NetApp SnapCenter® licensed capability. The command triggers the ONTAP Snapshot and copies the data to StorageGRID. The BlueXP backup and recovery capability automatically refreshes to make the backup data available for restores. This solution can be applied to an EHR implementation or any similar application.
To start, you need the following ingredients:
- ONTAP 9.10 or later
- StorageGRID (I tested with 11.6, but earlier versions will also work)
- BlueXP backup and recovery (formerly Cloud Backup)
You have to perform several preparation steps, but only once.
Add a consistency group
A normal database spans multiple ONTAP LUNs. For this EHR example, we use a ratio of four LUNs per volume. If you need additional LUNs, a new volume is created. We group these volumes in a single consistency group by using the ONTAP System Manager GUI.
Create a SnapMirror policy
We need to create a custom SnapMirror policy. This policy creates a label that uniquely identifies the Snapshot data blocks to copy to StorageGRID. To create the policy, use the following two CLI commands:
snapmirror policy create -vserver <vserver name> -policy <policy name> -create-snapshot-on-source false -transfer-schedule-name daily
snapmirror policy add-rule -vserver <vserver name> -policy <policy name> -snapmirror-label <label name> -keep <number of snapshots to keep on StorageGRID>
Let’s clarify:
- <vserver name> is the name of the admin (cluster) storage virtual machine (SVM). If you are not sure what the admin Vserver name is, you can use the command vserver show and then identify the Vserver name whose type is admin. For example:
vserver show
Admin Operational Root
Vserver Type Subtype State State Volume Aggregate
----------- ------- ---------- ---------- ----------- ---------- ----------
<name> data default running running Test_ root vserver_ root_aggr
<node name> node - - - - -
<cluster name> admin - - - - -
<node name> node - - - - -
- <policy name> should follow your naming convention if you have one. In my case, I used EHRsnapmirrorpolicy.
- <label name> should follow your naming convention if you have one. In my case, I used EHR.
- <number of snapshots to keep on StorageGRID> is a number that indicates how many Snapshot copies should be kept in the object store. For example, I want to keep 30 days of backups. Therefore, in this case, the number is 30.
- <transfer-schedule-name> refers to the frequency of transfers between ONTAP and StorageGRID—if there is a new Snapshot copy with the EHR label to transfer. You can use this schedule to decouple the ONTAP Snapshot copy (triggered by the backup script) from the data transfer from ONTAP to StorageGRID. For example, I plan to run the backup script once a day, but the actual time may vary day to day. In this case, I could have used transfer-schedule-name hourly so that ONTAP would check the existence of a Snapshot copy with the appropriate label every hour. On the other hand, perhaps I want to run the backup script multiple times a day, but transfer the data only at night. In that case, a daily schedule would move data at a specific time each day.
Query for the UUID
At this point, we have almost everything we need:
- The SnapMirror policy that sets the transfer schedule, the label, and the number of Snapshot copies to keep
- The consistency group that ties together all the volumes that contain LUNs for the application
The final puzzle piece is the consistency group universal unique identifier (UUID). This UUID is an internal ONTAP ID that we can expose through ONTAP REST APIs. This UUID is used to trigger the consistency group Snapshot copy and, subsequently, the backup of the data to StorageGRID. Because this command is also a REST API call, it is a good time to test our ability to talk to ONTAP through REST API commands. I recommend that you use a Linux distribution with a curl package installed.
In Microsoft Windows, I had some fun trying to get the command to work due to the usage of single versus double quotation marks. If any of you readers have a working incantation for the following command in a Windows environment, please post it in comments. Here is the command:
curl -X GET -k -u <ONTAP user name>:<password> https://<IP address>/api/application/consistency-groups?svm.name=<vserver-name>
Let’s clarify again:
- <ONTAP user name> is self-explanatory, though the role of this user should be allowed sufficient permissions to perform the query. I used admin because it’s my lab, and why not.
- <password> is also self-explanatory; it’s the password of said user name. Note that you do not have to put the user name and passwords in plaintext, but it’s easier for this example. We support alternative authentication mechanisms (keys, certificates, and so on).
- <IP address> is the cluster management IP address.
- <vserver name> is the name of the ONTAP storage virtual machine (SVM) hosting the volumes that are used by the application and the consistency group that we created earlier. It is not the same Vserver name that was used in the SnapMirror commands. If you use the vserver show command one more time, this Vserver type should be data.
The preceding curl command should return something like the following (I am showing only the top of the response because it contains the UUID that we are looking for):
{
"records": [
{
"uuid": "68a60448-3aa0-11ed-b4ab-00a098b4fdc2",
…
Your UUID will be different, but you get the idea.
Enable BlueXP backup
Now it is time to enable the BlueXP backup for the application LUNs, using the BlueXP canvas. The initial configuration of the BlueXP manager, and for that matter the installation and configuration of StorageGRID as an S3 target, are beyond the scope of this blog post.
The following steps (documented with screenshots) assume that you have already added the on-premises ONTAP system or systems to your BlueXP canvas. They also assume that you have a working StorageGRID infrastructure, along with information about how to connect to it as an S3 client. If the application LUNs are the first volumes to be backed up to StorageGRID, a wizard appears. From that wizard, you can add StorageGRID as the backup target, select the appropriate volumes and policies, and enable the backup.
If you already use BlueXP backup to protect other ONTAP volumes to this StorageGRID instance, the steps are similar, though without the benefit of the guiding wizard.
In both cases, the high-level steps are similar:
- Select the ONTAP volumes.
- Ensure that the appropriate policy is applied to those volumes.
- Activate the backup.
The following screenshots walk you through how to enable ONTAP hosted LUN backups to the StorageGRID grid through the first-time-use wizard:
- From the BlueXP canvas, select the ONTAP system and click Enable to launch the wizard that enables you to add StorageGRID as the backup target.
2. Provide the StorageGRID fully qualified domain name (do not use the IP address), the port, and the access and secret keys that allow you to connect to StorageGRID as an S3 client. Note that the FQDN information required does not refer to the StorageGRID management IP address. The FQDN refers to a StorageGRID end point that serves S3 APIs. Then click Next.
3. On the next window, make sure that you select the policy that you created previously. In my case, it was EHRsnapmirrorpolicy. Click Next.
4. In Backup Settings, you are presented with a view like the following. Select the appropriate volumes/LUNs and click Activate Backup.
That concludes your preparation steps—which you should have to do only once.
Create your Snapshot copy—with one command
And the single command to create a Snapshot copy of your consistency group volumes and to back up your data in a 3:2:1-compliant mode is…
curl -X POST -k -u <ONTAP user name>:<password> https://<IP address>/api/application/consistency-groups/<CG UUID>/snapshots -d '{ "name": "<snapshot name>", "consistency_type": "application", "comment": "this rocks", "snapmirror_label": "<label name>" }'
Again, let’s clarify:
- <ONTAP user name> is the same as in the earlier step.
- <password> is the same as in the earlier step.
- <IP address> is the same as in the earlier step.
Make sure that you replace the UUID with your own insanely long and inhuman number. Please pay attention to the usage of quotation marks around the names. For example: in "<snapshot name>", keep the quotes and replace the <snapshot name> with your own name. I used the date of the Snapshot copy; for example, "Nov11".
The "consistency_type" should be set to "application" only if the host application is quiesced for the Snapshot copy. Otherwise, replace "application" with "crash".
"<label name>" should be the same label that you used in the SnapMirror policy that you created earlier. Otherwise, the backup will not transfer to StorageGRID.
Note: Every time you invoke the automation script (which now includes this command), a new Snapshot copy is created and is subsequently transferred to StorageGRID. It may seem advantageous, and it certainly has some merit. The danger here is that running the automation more times than expected can result in having fewer days of backups on StorageGRID. In my case, I plan to run the backup daily and to keep 30 days of backups. However, if I run the automation script twice in 1 day, I will end up with 29 days of backups instead of 30.
If you want the best of both worlds, I list some suggestions here, but I will not belabor them in this blog post:
- It is possible to create ad hoc backups by using the BlueXP backup GUI, and those backups would not count toward your retention total.
- It is also possible to have multiple SnapMirror policy rules under the same SnapMirror policy. Each rule would have its own label and number of Snapshot copies to keep. You modify the previous consistency group Snapshot and backup command to use either the label for the daily backup or the label for the ad hoc backup. The upshot here is that the number of daily Snapshot copies to keep would not be diluted by any ad hoc backups.
Let’s recap
With ONTAP, StorageGRID, and BlueXP backup, it’s easy to protect your applications. Adding a single REST API call to the automation framework that you use to quiesce the database for backup is a simple and powerful method of protecting any application with a 3:2:1 architecture.
ONTAP transfers any Snapshot copies with the appropriate label to StorageGRID on a user-defined schedule. After the transfer is complete, BlueXP backup makes the backup data available for restores within the hour (the BlueXP restore GUI refresh period cannot be configured manually). For example, an ONTAP to StorageGRID Snapshot copy that started at noon is complete at 12:30 p.m. At the latest, the backup job is available for restores by 1:30 p.m.