Contributors Download PDF of this page
You need to consider the revert issues and limitations before beginning an ONTAP reversion.
Reversion is disruptive.
No client access can occur during the reversion. If you are reverting a production cluster, be sure to include this disruption in your planning.
Reversion affects all nodes in the cluster.
The reversion affects all nodes in the cluster; however, the reversion must be performed and completed on each HA pair before other HA pairs are reverted.
The reversion is complete when all nodes are running the new target release.
When the cluster is in a mixed-version state, you should not enter any commands that alter the cluster operation or configuration except as necessary to satisfy reversion requirements; monitoring operations are permitted.
If you cannot complete the reversion for any reason, contact technical support immediately. If you have reverted some, but not all of the nodes, do not attempt to upgrade the cluster back to the source release.
When you revert a node, it clears the cached data in a Flash Cache module.
Because there is no cached data in the Flash Cache module, the node serves initial read requests from disk, which results in decreased read performance during this period. The node repopulates the cache as it serves read requests.
A LUN that is backed up to tape running on ONTAP 9.x can be restored only to 9.x and later releases and not to an earlier release.
If your current version of ONTAP supports In-Band ACP (IBACP) functionality, and you revert to a version of ONTAP that does not support IBACP, the alternate path to your disk shelf is disabled.
If LDAP is used by any of your storage virtual machines (SVMs), LDAP referral must be disabled before reversion.
In MetroCluster IP systems using switches which are MetroCluster compliant but not MetroCluster validated, the reversion from ONTAP 9.7 to 9.6 is disruptive as there is no support for systems using ONTAP 9.6 and earlier.