Tech ONTAP Blogs
Tech ONTAP Blogs
Most real applications don’t sit on a single volume. SQL Server splits data and logs. Oracle spreads data, redo, and archives. VMware clusters span multiple datastores. That design is normal — and it’s also why backup and restore get hard fast.
If your application touches more than one volume, a snapshot of one disk isn’t enough. You need every related volume captured at the same moment. Miss that by even a fraction of a second, and restore can leave you with a database or VM estate that looks fine on paper but won’t come back cleanly.
Consistency Groups (CGs) in Google Cloud NetApp Volumes Flex Unified ONTAP-mode solve that. They let you treat a set of volumes as one unit — so you can snapshot, clone, and protect the whole application together, not one LUN at a time.
New to ONTAP-mode? We recommend starting with Introducing ONTAP-mode for NetApp Volumes for an overview of the architecture. ONTAP-mode is the foundation that makes Consistency Groups — and the workflows below — possible.
Most cloud block storage services give you per-disk snapshots. That sounds fine — until you try to restore.
In that 480 ms gap, your database wrote thousands of transactions. The two snapshots are no longer in sync. Restore them together and you get a corrupt or inconsistent database — exactly when you can least afford it.
Workarounds (quiesce-the-app, lock writes, run sequential snapshots, hope for the best) are operationally painful and break under load. They also don't scale to VMware clusters with dozens of datastores spread across volumes.
Consistency Groups solve this at the storage layer. They guarantee that every volume and LUN in the group is captured at the same logical instant, and they let you snapshot, clone, replicate, and restore the entire application as a single unit.
If your application spans more than one volume, the first thing you need is a snapshot you can actually trust. Consistency Groups let you capture every LUN and volume behind that application in a single point in time. Out of the box, that gives you a crash-consistent image across the whole set. When you need more than that — for example with SQL Server on Windows — you can make the snapshot application-aware by integrating with the Microsoft VSS snapshot provider on the host, or by using tools like NetApp Console Backup and Recovery or NetApp SnapCenter to coordinate quiesce and snapshot timing. The point is simple: when you restore, you’re restoring the application, not guessing whether two volumes still match.
That same model makes dev, test, and refresh workflows much easier. Instead of copying data and logs separately — and hoping they line up — you can clone the entire application in seconds. For a database, that means data files, transaction logs, and the rest of the supporting volumes together. Because clones are built on ONTAP copy-on-write, they take almost no extra space at creation time and only consume capacity as the clone changes.
Real applications are rarely flat. A SQL Server deployment might keep data and logs in separate groups, while a larger estate may need different protection boundaries for different tiers. Nested Consistency Groups handle that without forcing you to redesign storage. You can create child CGs such as data_cg and log_cg, then roll them into a parent CG like mssql_cg. That lets you protect the full application as one unit when you need to, while still managing individual tiers when that makes more sense.
Consistency Groups also fit naturally into a broader protection and DR strategy. They work with the ONTAP data services customers already rely on — SnapMirror for replication, SnapVault for backup, and FlexClone for rapid copies — so primary, secondary, and Dev/Test environments can follow the same protection model instead of treating each volume as its own project.
And you can do all of this through Google Cloud. The workflows in this blog run through the gcloud CLI, authenticated with your Google Cloud IAM identity. There’s no separate ONTAP admin credential to manage, no extra management endpoint to open, and no second control plane to learn just to protect applications the way they’re actually built.
Databases are one of the clearest examples. SQL Server, Oracle, PostgreSQL, and MySQL often spread data files, transaction logs, and supporting volumes like TEMPDB across separate LUNs for performance. That layout works well day to day, but it makes backup and restore harder unless you treat those volumes as one application. With Consistency Groups, a snapshot is a single recoverable image of the database, not a set of disks captured at slightly different times. A CG clone goes further: DBAs can mount a fully isolated copy on another VM for dev, test, reporting, or QA refresh in seconds instead of running a long copy job and hoping the pieces still match.
The same idea applies to VMware on Google Cloud. A vSphere cluster rarely lives on one datastore. VMs are spread across multiple datastores, and a meaningful restore point often needs to cover all of them together. Consistency Groups let you snapshot the datastores behind a workload — or an entire cluster — as one unit. That matters for tenant migrations, upgrade rollback, and ransomware recovery, where restoring one datastore while leaving others behind can create more cleanup work than the original outage.
Test, dev, QA refresh, and CI/CD workflows benefit in a very practical way. Instead of waiting for overnight batch windows to refresh non-production environments from production, teams can create a consistent copy in seconds. That makes it much easier to spin up parallel test environments, run upgrade rehearsals, or support CI/CD pipelines that need realistic data without repeatedly copying full datasets or provisioning new capacity up front.
Ransomware resilience is another place CGs change the outcome. When protection is done volume by volume, recovery often turns into manual reconciliation: which snapshot belongs with which, and are they still in sync? With Consistency Groups, you get an atomic snapshot of the full application stack, so recovery means bringing the application back to a known-good state in one step — not stitching together a partial recovery after the fact.
Below is an end-to-end example of protecting a Microsoft SQL Server on Google Cloud with nested Consistency Groups in Google Cloud NetApp Volumes Flex Unified ONTAP-mode. You'll create child CGs for data and logs, group them under a parent CG, take a CG snapshot, clone the database, and map the cloned LUNs to a second VM — all through the gcloud CLI.
What we will do:
The parent CG (mssql_cg) groups child CGs for data and logs. Production LUNs are presented to mssqlvm1. A CG snapshot captures the database consistently, and a CG clone (clonecg) can be mapped to mssqlvm2 for isolated testing or refresh.
The commands below follow this flow step by step.
Create initiator group for the SQL Server VMs.
Below example creates one igroup for the production SQL Server and another igroup for the clone target VM.
[demo@demovm]:~$ gcloud netapp storage-pools execute ontapmodepool --location=us-central1-a "igroup create -ostype windows -igroup mssqlvm1 -protocol iscsi -initiator iqn.1991-05.com.microsoft:mssqlvm1.cvsdemo.internal"
output: ''
[demo@demovm]:~$ gcloud netapp storage-pools execute ontapmodepool --location=us-central1-a "igroup create -ostype windows -igroup mssqlvm2 -protocol iscsi -initiator iqn.1991-05.com.microsoft:mssqlvm2.cvsdemo.internal"
output: ''
[demo@demovm]:~$ gcloud netapp storage-pools execute ontapmodepool --location=us-central1-a "igroup show -igroup mssqlvm1 -v "
output: |+
Vserver Name: gcnv-bc2553acb2200f4-svm-01
Igroup Name: mssqlvm1
Protocol: iscsi
OS Type: windows
Portset Binding Igroup: -
Igroup UUID: 3a886cc1-7385-11f1-856b-2984232b736e
ALUA: true
Initiators: iqn.1991-05.com.microsoft:mssqlvm1.cvsdemo.internal (logged in)
...
[demo@demovm]:~$ gcloud netapp storage-pools execute ontapmodepool --location=us-central1-a "igroup show -igroup mssqlvm2 -v"
output: |+
Vserver Name: gcnv-bc2553acb2200f4-svm-01
Igroup Name: mssqlvm2
Protocol: iscsi
OS Type: windows
Portset Binding Igroup: -
Igroup UUID: 445a51a4-7385-11f1-856b-2984232b736e
ALUA: true
Initiators: iqn.1991-05.com.microsoft:mssqlvm2.cvsdemo.internal (logged in)
...
[demo@demovm]:~$
Below example creates a data consistency group that consists of two LUNs, both mapped to the production SQL server in a single command.
[demo@demovm]:~$ gcloud netapp storage-pools execute ontapmodepool --location=us-central1-a "consistency-group create -vserver gcnv-bc2553acb2200f4-svm-01 -consistency-group data_cg -lun-count 1 -size 50G -lun-prefix mssqldatavol -lun-os-type windows -volume-count 2 -igroup mssqlvm1"
output: ''
[demo@demovm]:~$ gcloud netapp storage-pools execute ontapmodepool --location=us-central1-a "consistency-group show -consistency-group data_cg"
output: |+
(vserver consistency-group show)
Parent
Consistency Consistency
Vserver Group Group State Size Available Used
---------- ------------- ------------- ------- ---------- ---------- ---------
gcnv-bc2553acb2200f4-svm-01 data_cg - online 103GB 103.0GB 648KB
...
[demo@demovm]:~$ gcloud netapp storage-pools execute ontapmodepool --location=us-central1-a "lun show -m"
output: |+
Vserver Path Igroup LUN ID Protocol
---------- ---------------------------------------- ------- ------ --------
gcnv-bc2553acb2200f4-svm-01 /vol/data_cg_1/mssqldatavol_1 mssqlvm1 0 iscsi
gcnv-bc2553acb2200f4-svm-01 /vol/data_cg_2/mssqldatavol_1 mssqlvm1 1 iscsi
2 entries were displayed.
...
[demo@demovm]:~$
Logs typically live on their own dedicated volume for I/O isolation. Below example creates a LUN for storing MSSQL logs.
[demo@demovm]:~$ gcloud netapp storage-pools execute ontapmodepool --location=us-central1-a "consistency-group create -vserver gcnv-bc2553acb2200f4-svm-01 -consistency-group log_cg -lun-count 1 -size 20G -lun-prefix mssqllogvol -lun-os-type windows -volume-count 1 -igroup mssqlvm1"
output: ''
[demo@demovm]:~$ gcloud netapp storage-pools execute ontapmodepool --location=us-central1-a "consistency-group show -consistency-group log_cg"
output: |+
(vserver consistency-group show)
Parent
Consistency Consistency
Vserver Group Group State Size Available Used
---------- ------------- ------------- ------- ---------- ---------- ---------
gcnv-bc2553acb2200f4-svm-01 log_cg - online 20.60GB 20.60GB 324KB
...
[demo@demovm]:~$ gcloud netapp storage-pools execute ontapmodepool --location=us-central1-a "lun show -fields size,consistency-group,mapped"
output: |+
vserver path size mapped consistency-group
--------------------------- ----------------------------- ---- ------ -----------------
gcnv-bc2553acb2200f4-svm-01 /vol/data_cg_1/mssqldatavol_1 50GB mapped data_cg
gcnv-bc2553acb2200f4-svm-01 /vol/data_cg_2/mssqldatavol_1 50GB mapped data_cg
gcnv-bc2553acb2200f4-svm-01 /vol/log_cg_1/mssqllogvol_1 20GB mapped log_cg
3 entries were displayed.
...
[demo@demovm]:~$
This is what makes CGs powerful for real applications — protect data and log as a single atomic unit, but keep the ability to manage them independently when you need to.
[demo@demovm]:~$ gcloud netapp storage-pools execute ontapmodepool --location=us-central1-a "consistency-group create -vserver gcnv-bc2553acb2200f4-svm-01 -consistency-group mssql_cg -consistency-groups data_cg,log_cg"
output: ''
[demo@demovm]:~$ gcloud netapp storage-pools execute ontapmodepool --location=us-central1-a "consistency-group show -consistency-group mssql_cg"
output: |+
(vserver consistency-group show)
Parent
Consistency Consistency
Vserver Group Group State Size Available Used
---------- ------------- ------------- ------- ---------- ---------- ---------
gcnv-bc2553acb2200f4-svm-01 mssql_cg - online 123.6GB 123.6GB 992KB
...
[demo@demovm]:~$ gcloud netapp storage-pools execute ontapmodepool --location=us-central1-a "consistency-group show -fields parent-consistency-group"
output: |+
(vserver consistency-group show)
vserver consistency-group parent-consistency-group
--------------------------- ----------------- ------------------------
gcnv-bc2553acb2200f4-svm-01 data_cg mssql_cg
gcnv-bc2553acb2200f4-svm-01 log_cg mssql_cg
gcnv-bc2553acb2200f4-svm-01 mssql_cg -
3 entries were displayed.
...
[demo@demovm]:~$
At this point the SQL Server VM can discover the iSCSI LUNs, initialize them in Windows, and the DBA can place data files and log files on the respective volumes.
[demo@demovm]:~$ gcloud netapp storage-pools execute ontapmodepool --location=us-central1-a "consistency-group snapshot create -vserver gcnv-bc2553acb2200f4-svm-01 -consistency-group mssql_cg -snapshot mssql_snap1 -consistency-type application"
output: |+
(vserver consistency-group snapshot create)
...
[demo@demovm]:~$ gcloud netapp storage-pools execute ontapmodepool --location=us-central1-a "consistency-group snapshot show -instance"
output: |+
(vserver consistency-group snapshot show)
Vserver Name: gcnv-bc2553acb2200f4-svm-01
Consistency Group Name: mssql_cg
Parent Consistency Group Name: -
CP Count (for sorting): 316
Snapshot UUID: 207a1782-7391-11f1-856b-2984232b736e
Snapshot Copy Name: mssql_snap1
Consistency Type: application
Comment: -
Snapmirror Label: -
Create Time: Mon Jun 29 08:04:17 2026
Protection Group Generation: -
Is Snapshot Copy Partial?: false
List of Volume Names with this Snapshot Copy: data_cg_1, data_cg_1, log_cg_1
List of Volume Names Missing this Snapshot Copy: -
Snapshot UUID: 207a1782-7391-11f1-856b-2984232b736e
Take write fence: true
...
[demo@demovm]:~$
Snapshots can go beyond crash consistency when you integrate with the Microsoft VSS snapshot provider on Windows hosts, or orchestrate protection through NetApp Console Backup and Recovery or NetApp SnapCenter. Those integrations quiesce the application at the right moment so the CG snapshot reflects a recoverable database state.
This is the moment that typically changes how customers think about Dev/Test refresh. This creates a space efficient writable copy of the database that can be used for Dev/Test workflows.
[demo@demovm]:~$ gcloud netapp storage-pools execute ontapmodepool --location=us-central1-a "consistency-group clone create -vserver gcnv-bc2553acb2200f4-svm-01 -clone-consistency-group clonecg -source-snapshot-name mssql_snap1 -source-parent-consistency-group mssql_cg"
output: ''
[demo@demovm]:~$ gcloud netapp storage-pools execute ontapmodepool --location=us-central1-a "consistency-group show -fields parent-consistency-group"
output: |+
(vserver consistency-group show)
vserver consistency-group parent-consistency-group
--------------------------- ----------------- ------------------------
gcnv-bc2553acb2200f4-svm-01 clonecg -
gcnv-bc2553acb2200f4-svm-01 data_cg clonecg
gcnv-bc2553acb2200f4-svm-01 data_cg mssql_cg
gcnv-bc2553acb2200f4-svm-01 log_cg clonecg
gcnv-bc2553acb2200f4-svm-01 log_cg mssql_cg
gcnv-bc2553acb2200f4-svm-01 mssql_cg -
6 entries were displayed.
...
[demo@demovm]:~$ gcloud netapp storage-pools execute ontapmodepool --location=us-central1-a "lun show"
output: |+
Vserver Path State Mapped Type Size
--------- ------------------------------- ------- -------- -------- --------
gcnv-bc2553acb2200f4-svm-01 /vol/clonecg_data_cg_1/mssqldatavol_1 online unmapped windows 50GB
gcnv-bc2553acb2200f4-svm-01 /vol/clonecg_data_cg_2/mssqldatavol_1 online unmapped windows 50GB
gcnv-bc2553acb2200f4-svm-01 /vol/clonecg_log_cg_1/mssqllogvol_1 online unmapped windows 20GB
gcnv-bc2553acb2200f4-svm-01 /vol/data_cg_1/mssqldatavol_1 online mapped windows 50GB
gcnv-bc2553acb2200f4-svm-01 /vol/data_cg_2/mssqldatavol_1 online mapped windows 50GB
gcnv-bc2553acb2200f4-svm-01 /vol/log_cg_1/mssqllogvol_1 online mapped windows 20GB
6 entries were displayed.
...
[demo@demovm]:~$
The clone is created in seconds, regardless of database size, and consumes no additional capacity until it diverges from the source.
At this point, the cloned LUNs exist but are not yet visible to the clone VM. Mapping them to clone target VM is the final step.
The cloned LUNs need to be exposed to the clone target VM's igroup so it can discover them over iSCSI.
[demo@demovm]:~$ gcloud netapp storage-pools execute ontapmodepool --location=us-central1-a "lun map -vserver gcnv-bc2553acb2200f4-svm-01 -igroup mssqlvm2 -path /vol/clonecg_data_cg_1/mssqldatavol_1"
output: ''
[demo@demovm]:~$ gcloud netapp storage-pools execute ontapmodepool --location=us-central1-a "lun map -vserver gcnv-bc2553acb2200f4-svm-01 -igroup mssqlvm2 -path /vol/clonecg_data_cg_2/mssqldatavol_1"
output: ''
[demo@demovm]:~$ gcloud netapp storage-pools execute ontapmodepool --location=us-central1-a "lun map -vserver gcnv-bc2553acb2200f4-svm-01 -igroup mssqlvm2 -path /vol/clonecg_log_cg_1/mssqllogvol_1"
output: ''
[demo@demovm]:~$ gcloud netapp storage-pools execute ontapmodepool --location=us-central1-a "lun show -m"
output: |+
Vserver Path Igroup LUN ID Protocol
---------- ---------------------------------------- ------- ------ --------
gcnv-bc2553acb2200f4-svm-01 /vol/clonecg_data_cg_1/mssqldatavol_1 mssqlvm2 0 iscsi
gcnv-bc2553acb2200f4-svm-01 /vol/clonecg_data_cg_2/mssqldatavol_1 mssqlvm2 1 iscsi
gcnv-bc2553acb2200f4-svm-01 /vol/clonecg_log_cg_1/mssqllogvol_1 mssqlvm2 2 iscsi
gcnv-bc2553acb2200f4-svm-01 /vol/data_cg_1/mssqldatavol_1 mssqlvm1 0 iscsi
gcnv-bc2553acb2200f4-svm-01 /vol/data_cg_2/mssqldatavol_1 mssqlvm1 1 iscsi
gcnv-bc2553acb2200f4-svm-01 /vol/log_cg_1/mssqllogvol_1 mssqlvm1 2 iscsi
6 entries were displayed.
...
[demo@demovm]:~$ gcloud netapp storage-pools execute ontapmodepool --location=us-central1-a "lun show -fields size,size-used"
output: |+
vserver path size size-used
--------------------------- ------------------------------------- ---- ---------
gcnv-bc2553acb2200f4-svm-01 /vol/clonecg_data_cg_1/mssqldatavol_1 50GB 20.16GB
gcnv-bc2553acb2200f4-svm-01 /vol/clonecg_data_cg_2/mssqldatavol_1 50GB 20.16GB
gcnv-bc2553acb2200f4-svm-01 /vol/clonecg_log_cg_1/mssqllogvol_1 20GB 5.07GB
gcnv-bc2553acb2200f4-svm-01 /vol/data_cg_1/mssqldatavol_1 50GB 20.16GB
gcnv-bc2553acb2200f4-svm-01 /vol/data_cg_2/mssqldatavol_1 50GB 20.16GB
gcnv-bc2553acb2200f4-svm-01 /vol/log_cg_1/mssqllogvol_1 20GB 5.07GB
6 entries were displayed.
...
[demo@demovm]:~$
You now have a point-in-time, fully writable, isolated copy of production running on a separate VM — with zero impact on the source database.
For decades, enterprise storage teams have relied on Consistency Groups to protect their most demanding workloads. Bringing that same primitive to Google Cloud NetApp Volumes Flex Unified ONTAP-mode means:
If your application spans more than one volume, you should be using Consistency Groups.