Skip to Content

Backing up your SAP system on a regular basis is important to protect your business against any type of damage that can happen to your hardware or software. In today’s globalized world you cannot afford downtime, so you need to find ways to back up your SAP system while it stays up and running. We have learned about customers trying to use the FlashCopy feature of their storage subsystem and perform the backup on the second copy, so that the SAP system was not interrupted. However, using FlashCopy for backup purposes requires some considerations:

  1. If you do not quiesce your system prior to the FlashCopy, you will not be able to apply journaled changes for the primary SAP database library to this copy because you do not have a starting point for the APYJRNCHG command. In case of data loss, you can then only recover your system to the time of the FlashCopy, but not to the time just before the data loss. Hence this option is not recommended for productive SAP systems.
  2. If you quiesce your system and perform a FlashCopy, you can apply journaled changes for the primary SAP database to this copy. You will need a starting sequence number for the APYJRNCHG command in order to recover to the time just before the data loss. If you are at IBM i 7.3, you can simply look for the sequence number of the journal code J, entry type JQ (“Journal quiesce ASP activity”) in the journal on the primary database. In releases 7.2 and earlier, you need to look for the sequence numbers of journal code J, entry types IA, IN, UA or UN (“IPL or vary on of independent ASP”) on the copy of the database after varying on the FlashCopy result. You need to identify the starting sequence number before you delete the journal receivers from the copy created by FlashCopy.

So what other options do you have to save your data without bringing down your SAP system?

If you are using a High Availability solution based on logical replication, you can perform the backup on the copy of your database, so the SAP system is not affected at all. Check with your HA vendor what you need to consider in order to be able to apply journaled changes after restoring the database library. This is probably the least disruptive, but also the most expensive solution to your backup challenge.

If you are using a High Availability solution based on page-level replication or no High Availability solution at all, you can perform an online backup as described in SAP Note 825473. The “Save While Active” feature allows to back up your database library while the SAP system can stay up and running. It is coming in two flavors:

  1. Saving at a commitment boundary: This option ensures that the backup of the database library is consistent in itself; simply restoring the saved library is giving you a consistent database. This is helpful, for example, if you want to use that library to create a test system as a copy of your production system. However, this type of backup requires that all SAP processes are coming to a commitment boundary at a single point in time. When you start the backup, the system is trying to reach a synchronization point, and during that time no new transactions can start. Depending on the remaining processing time of other open transactions, it can take many minutes or even hours until the checkpoint is reached. For busy systems, this may not be an option.
  2. Saving without commitment boundary (so-called “ragged” save): This option does not wait for a common transaction boundary but starts the backup right away. The downside of this option is, that it is not sufficient to restore the saved database library only, but you also need to restore the associated journal receivers and apply or remove journaled changes in order to reach a consistent database. However, this may not be too much of a problem because you would need the journal receivers anyway for the recovery of your database to the point in time just before the error. The ragged save might still cause a small pause in your SAP operations during the start, but this is much smaller than waiting for commit boundaries in all work processes. It can also fail (or wait somewhat longer) if any transactions with DDL operations (like ALTER TABLE) are open, but in most cases the backup will complete successfully.

IBM has provided a significant enhancement to the online backup capabilities for IFS data in IBM i 7.3: Prior to this release, it was difficult to save certain files that were permanently in use by the SAP system (like developer trace files) or start SAP background processes while the directory to hold the log file was being backed up. With IBM i 7.3, you can set the attributes “Allow write during save” (*ALWCKPWRT) for all objects and “Inherit allow checkpoint writer” (*INHCKPWRT) for all directories underneath /usr/sap and /sapmnt. With those settings, the online backup of the integrated file system no longer conflicts with any activity of the SAP system, prior to IBM i 7.3, the only solution was to exclude certain files and directories with non-critical data from the backup. Further information about this and general online backup capabilities with SAP on IBM i can be found in SAP Note 825473.

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply