Cloud Backup Eligibility and an Automated ONTAP Upgrade in a Three-Hour Window
A two-node ONTAP 9.9.1P4 cluster with 8 SVMs must reach 9.13.1 before quarter end for compliance. The team protects 30 volumes with BlueXP backup and recovery (Cloud Backup) to object storage, but the new 2 TB legal volume vol_legal shows as not eligible in the BlueXP interface. volume show -fields snapshot-policy returns none for vol_legal, which is a read-write volume. A SnapMirror relationship to a DR site protects four other volumes. The change window is three hours, all upgrades must be automated from an Ansible control node using the ONTAP REST API, and the storage team has never upgraded this cluster since installation.
1. Why is vol_legal not eligible for Cloud Backup, and what else should you verify besides the Snapshot policy?
Read the worked answer
Cloud Backup protects a volume by transferring its Snapshot copies, so a volume whose policy is none has nothing to transfer and is excluded from selection. Confirm with volume show -vserver svm_legal -volume vol_legal -fields snapshot-policy,type,state and snapshot policy show. Fix: create and attach a policy whose schedule matches the desired recovery points (hourly plus daily is typical), then refresh discovery in BlueXP. Also verify the entitlement or license on the cluster, that the volume type is supported (read-write FlexVol rather than a DP or temporarily mounted volume), that the Connector has outbound HTTPS to the object store, and the support matrix for the running ONTAP release. If 9.9.1 is below the minimum for a required capability, the upgrade must be sequenced before protection can be enabled.
2. What order do you perform the upgrade and the backup enablement, and how do the SnapMirror relationships affect that decision?
Read the worked answer
Decide on evidence. Run cluster image validate -version 9.13.1 and system node upgrade-revert show, check the supported upgrade path from 9.9.1P4 and whether Cloud Backup supports that release. If Cloud Backup works on 9.9.1, enable vol_legal protection first so a cloud recovery point exists across the change window, then upgrade with ANDU. If 9.9.1 is unsupported for Cloud Backup, upgrade first and enable protection immediately after, accepting that vol_legal has no cloud copy during the window, and state that explicitly in the change record. Either way, do not enter the window with an unhealthy replication state: check snapmirror show -fields healthy,status,lag-time for the four protected volumes and confirm the DR cluster's supported version before starting.
3. What should the Ansible-driven flow do before, during and after the upgrade, and how do you verify or revert?
Read the worked answer
Before: read the current version with cluster image show, assert it matches the expected build, validate the target image, take a configuration backup, confirm no multi-admin verification request is pending, and assert both nodes are healthy with cluster show. During: invoke ANDU through the REST module (cluster image update with both nodes and the target version), poll cluster image show-update-progress for percentage and vetoes, and fail the play on any node error instead of retrying blindly. After: verify system node show -fields version, cluster show, SnapMirror health plus a test snapmirror update, an NFS and SMB mount per SVM, and BlueXP rediscovery. Retain the ANDU log and the config backup; ANDU reverts a failed node automatically, but after success the revert option is time-limited, so confirm it with system node upgrade-revert show before closing the window.