Checking that the System can be Recovered if Necessary

Objective

After completing this lesson, you will be able to Apply the Backup and Recovery Strategy with ZDO.

Backup and Recovery Strategy

This section shows the backup and recovery strategies during a maintenance event with Zero Downtime Option (ZDO) of Software Update Manager (SUM).

When you are performing a ZDO upgrade, database logging as well as the HADR solution (only if available in the system) run throughout the complete upgrade which includes the uptime on the bridge subsystem. Additionally, regular backups of file system and database are regularly triggered in the background. While the complete upgrade is performed in parallel to productive business operations of end-users, it is ensured by SUM that the upgrade could be revoked at any time in case of an issue related to the upgrade procedure.

The revoke of the upgrade will be executed by the built-in reset feature in SUM. However, if the upgrade already passed the restart and switch to the target release, the reset is no longer possible. For this scenario, it is recommended to take a backup to recover the system to a consistent state before the restart happened.

Resetting the ZDO Procedure

Software Update Manager is equipped with a built-in reset feature that removes all upgrade-related artifacts in the system as well as in the database.

Like in every SUM upgrade, the reset can be started in the SUM UI by choosing Reset in the menu. In Zero Downtime Option, the reset procedure is different in case the rollover to the bridge subsystem already happened. Hence, there are two cases that should be considered:

Case A: Reset before rollover to bridge

As long as the business users were not rolled over to the bridge subsystem and the phase REQ_USER_ROLLOVER_PREP has not been passed, the reset is executed like in the standard upgrade procedure during uptime processing. For more information, see in the SUM Guide chapter Running the Software Update ManagerWorking with the SUM ToolResetting the Update.

The complete reset happens in uptime and end-users are not impacted.

Case B: Reset during bridge runtime

Caution

Make sure that phase REQ_USER_ROLLBACK_PREP has not been passed. If this occurs, the switch to the target release would have happened already. In this case, a restore of the system is required in order to use the reset option in SUM. For details on backup and restore in ZDO, see the section Backup Request in Software Update Manager of this lesson below.

Start the reset procedure in the same way like described above. In the SUM UI, choose MenuReset.

If the user rollover to the bridge subsystem has already been performed and the phase REQ_USER_ROLLOVER_PREP is completed, the reset is split into two steps:

Step 1 will remove the read-only restrictions on the tables. After this removal, the users can continue with regular production operation and all read-only tables are writable again. The target versions of tables (cloned tables) are no longer written. This step happens in uptime and end-users are not impacted.

Step 2 removes all artifacts related to the bridge subsystem. The reset procedure for ZDO can be executed completely in the uptime if the following conditions are met:

  • Source release SAP Basis 755 or higher. This release corresponds to SAP S/4HANA 2020 or higher.
  • SAP kernel 781 or a higher version. See the prerequisites for the SAP kernel used in SAP Note 3215062 Information published on SAP site. For more information about the SAP Kernel conditions, see also SAP Note 3169721.

Otherwise, step 2 of the following procedure requires downtime. You can push this downtime to the next regular downtime window according to your maintenance plan.

Backup Request in Software Update Manager

During a ZDO update, the business users continue to work until the very end of the maintenance event. Only for the time of the cut-over, the users have to log off from the system. Assuming a major issue would happen after switching over to the new release, the system has to be restored to a point in time where the source release was active. For this, a consistent full system backup is recommended that includes:

  • a synchronous state of the database
  • the SUM directory
  • the system and instance directories
  • the kernel directory

A dialog asks you in phase SUMASK_ZDO_CONFIGURATION whether you want to run a system backup during the transition from the bridge subsystem to the target subsystem.

If the checkbox Yes, request the backup in the Configuration phase SUMASK_ZDO_CONFIGURATION (1) is checked, a further dialog in phase REQ_ZDO_SYSTEM_BACKUP (2) of roadmap step Postprocessing prompts you to start the system backup.

The dialog phase REQ_ZDO_SYSTEM_BACKUP is executed only after you initiated the rollback to the original system in the target release in phase REQ_USER_ROLLBACK_PREP. The phase prompts you to start the system backup:

Code Snippet
Copy code
Switch to dark mode
123
The Bridge subsystem has been stopped. Caution: To be able to reset the ZDO upgrade from this point, back up now the complete SUM directory including all subdirectories! Also, the current state of the database, the system and instance directories, and the kernel directory need to be taken to be able to restore to a consistent state.

Hint

If the system backup is taken in phase REQ_ZDO_SYSTEM_BACKUP, also the reset functionality is available until the same phase (REQ_ZDO_SYSTEM_BACKUP). In case of a major issue, the restore would bring back the system to this phase. From here, you can perform the reset like described above in case B.

Log in to track your progress & complete quizzes