The restore operation takes a selected configuration backup, and modifies all of the corresponding system settings to reflect those in the backup, including removing aspects of the configuration that were not present at the time of the backup. Administrators should adhere to the following guidelines when planning a restore:
Cross-Platform Restore: A configuration backed up from one appliance platform cannot be restored to a different appliance platform. For example, a ZS4-4 configuration backup cannot be restored to a ZS3-2 appliance. Attempting to restore a configuration to a different platform results in several failures that requires a factory reset to return to a normal state.
Scheduled downtime - The restore process takes several minutes to complete and impacts service to clients, as the active networking configuration and data protocols are reconfigured. Therefore, a configuration restore should only be used on a development system, or during a scheduled downtime.
Service interruption - Clients accessing data on the system through a data protocol, such as NFS, experience service interruption as the network is reconfigured and the service is restarted. If the selected backup copy was taken when a service was disabled by the administrator, that setting is restored, and therefore client sessions are terminated for that protocol.
Session interruption - If restore is initiated from a web browser, that web browser session is also disconnected during the restore process as the network is reconfigured. If the restored configuration does not include the same routing and network address settings used by the current browser connection, or if the browser is connected to a network address managed by DHCP, the browser session is interrupted during the restore. The restore process completes in the background, but you need to reload or point the browser at a new, restored network address to continue. For this reason, it may be desirable to initiate a complex configuration restore from the service processor serial console using the CLI.
Un-cluster, restore, and re-cluster - Configuration backups may be initiated for appliances that are joined in a cluster, but a configuration restore may not be used while systems are actively clustered. The clustering process means that settings are being synchronized between cluster peers, and each peer appliance also is maintaining private settings. For this reason, you must first un-cluster the two systems. Because of the possibility of data loss to unconfigure clustering, contact Oracle support. Then, restore the configuration backup on a selected head, and then re-cluster the two systems, at which point the other system automatically synchronizes itself with the restored configuration.
Root privileges required - Configuration backups include all system metadata, and therefore require all possible privileges and authorizations to create or apply. Therefore, unlike other delegated administrative options, only the root user is authorized to perform a configuration backup or restore.
Verify setting for new features - It is permitted to restore a configuration that was saved before applying a system update to a new version of the appliance software. In some cases, services and properties that were present at the time of the backup may have different effects, and new services and properties may exist in the newer software that did not exist at the time of the backup. Similar to the system update process, the configuration restore process makes every effort to transfer applicable settings, and apply reasonable defaults to those properties that did not exist at the time of the backup. When restoring across software versions, administrators should manually verify settings for new features following the restore.
Password maintenance - The root password is not changed or reverted to the password at the time of the backup if it was different. The current root password is maintained on the system across the restore. For more details about passwords, refer to the summary of Security Considerations.