Operational Aspects

Backup and Recovery Considerations

Author: Eugene Bonnie
 Objectives

After completing this lesson, you will be able to:

z Describe the backup and recovery strategies in an
SAP XI environment
z Describe SAP XI in a High Availability Environments

© SAP AG 2004, Backup and Recovery Considerations, Eugene Bonnie, 2

 Backup and Recovery Considerations

XI Recovery

© SAP AG 2004, Backup and Recovery Considerations, Eugene Bonnie, 3

 Backup and Recovery Considerations and Challenges

Consistent Backup
„ Business data distributed over several systems
„ Redundant data
„ Different database vendors
Da
Point-in-time Recovery
t ime ta
„ No common checkpoint
w n lo s
„ Data in file systems Do s
Controlled Shutdown/Startup
„ Automated interaction between systems
„ Multiple input sources per system
Inconsistencies

Requirements
„ Distributed processes must ensure data consistency
„ System failures may not have an impact on data consistency
„ Consistent system copies of the whole environment must be possible
„ Not intended for restore after failure of a single system

© SAP AG 2004, Backup and Recovery Considerations, Eugene Bonnie, 4

„ With respect to backup and restore, we distinguish two concepts:

- Individual backup of each system component
- Backup of all system components
„ If a single system component fails, you do not need to restore the complete environment. Only the affected
component has to be restored and recovered to the exact point in time of failure. All database systems
enable recovery to the current point in time by means of log recovery. After recovery of the component,
data consistency in the system environment is restored: all open transactions are rolled back or can be
resumed in all systems, and all committed transactions are recovered.
„ Thus, a consistent backup of the complete system environment (of all systems) is not needed to protect
against failures of single system components.
„ A consistent backup of the complete environment is only needed for disaster recovery (in case the whole
environment is destroyed) or for setting up system copies.
 Prerequisites for Data Consistency

Backup/Restore of a single system component

„ Prevent data loss
„ Ensure database recovery to current point in time (point of failure)
„ No impact on productive system caused by backup
„ Fast backup/restore/recovery
„ Easy handling
Backup/Restore of the complete system environment
„ Synchronization points
„ Consistent system copies
Da
t ime ta
w n lo s
Do s

Inconsistencies

© SAP AG 2004, Backup and Recovery Considerations, Eugene Bonnie, 5

„ Key concepts: RAID protection, implementation of HA solutions, additional offline copies of DB,
different devices for logs and data, DB-log mirroring, logs saved twice on disk and twice on tape, apply
logs regularly to ensure correct recovery, test restore and recovery regularly, avoid restore on production
system, better restore on another system and fix problems afterwards.
„ Depending on the backup method used for a complete environment backup, a complete backup can often
be used to restore and recover just a single system.
„ A consistent copy of the complete environment may be needed to set up a test landscape with production
data. It could serve as a fallback in case of an unsuccessful upgrade or for setting save points during data
migration (so you could go back to a well-defined state if one part of the migration fails).
„ It is not possible to create a 100% consistent copy of the environment by just doing point-in-time restores
of all systems. Because there is no common, synchronized time for all systems, there are always some
modifications that were already done by one system and not yet done by some other system, leading to an
inconsistent state. To get a consistent environment copy, all methods presented in this lesson use some
mechanism to ‘freeze’ any modifications that can result in inconsistencies between systems.
 Other Important Data Security Measures

ƒ RAID protection
ƒ Redundant hardware paths
ƒ Implementation of HA solutions
ƒ Additional offline copies of database
ƒ Different devices for logs and data
ƒ DB log mirroring (on different controllers)
ƒ Logs saved twice on disk and twice on tape
ƒ Apply logs regularly to ensure correct recovery
ƒ Test restore and recovery regularly
ƒ Execute database consistency checks regularly
ƒ Avoid restore on production system

Document the backup and restore process

Ensure operability with regular tests and training

© SAP AG 2004, Backup and Recovery Considerations, Eugene Bonnie, 6

 All in One Server – Backup Scenario

© SAP AG 2004, Backup and Recovery Considerations, Eugene Bonnie, 7

„ Explanations for backup and restore strategies for individual components can be found on the next two
slides.
 Backup and Recovery for Individual System Components

Software Component Data Type Backup and Recovery Method

System Landscape Directory Original Database and Log Backup
Database and log backup, application log
Integration Builder Original backup (for example, jobs in the file system)
Original (messages) Database and log backup, application log backup
and cache
(for example, jobs in the file system). Data
Integration Engine (Integration
Directory) consistency with other systems must be taken
into account.
Original (messages) Database and log backup, application log
and copy (cached backup (for example, jobs in the file system).
Adapter Engine (J2EE) configuration
data from Integration Data consistency with other systems must be
Directory) taken into account.

Adapter configuration and log file backup,

Original
possibly files to be processed or having been
Plain J2EE Adapter Engine processed by the File/FTP adapter.

© SAP AG 2004, Backup and Recovery Considerations, Eugene Bonnie, 8

„ Filesystem backup of the J2EE Engine (standard path /usr/sap/<SID>/JC<inst-nr>).

ƒ Filesystem backup of the Software Deployment Manager (SDM).
„ The SDM contains a list of all deployments that were installed outside of the database, you can see them
within Software Deployment Manager GUI in the SDM Repository view under FileSystem and SAP
J2EEEngine.
ƒ Filesystem backup of the database home directory (standard path SAPDB: <drive>:\sapdb, Oracle:
<drive>:\orant)
ƒ If you run other databases i.e. IBM DB2 Universal Database, refer to online documentation under
backup/restore strategy.
 Backup and Recovery for Individual System Components

Software Component Data Type Backup and Recovery Method

Runtime Workbench Original Database and log backup, application log

backup (for example, jobs in the file system)

© SAP AG 2004, Backup and Recovery Considerations, Eugene Bonnie, 9

„ Web AS Release 6.40 will no longer have SAPDBA capability.

Recommendations for SDM:
• Include online backups as well as logs in daily routine
ƒ A filesystem backup of the Software Deployment Manager (SDM) should be performed after software
deployment and after the implementation of patches.
ƒ Include the complete SDM directory (standard path /usr/sap/<SID>/JC<inst-nr>/SDM) in the backup.
 Recommended Procedure To Restore a J2EE Engine

Install a new system using the installation wizard

SAPinst
ƒ Use exactly the same parameters as in the previous installation you
want to restore.

Java Instances
ƒ Overwrite the installed Java Instance (standard path:
/usr/sap/<SID>/JC<inst-nr>)

Databases

ƒ Import the backup using the database specific management

tools (e.g. SAPDB: Database Manager, Oracle: brrestore).

ƒ After the database has been imported, you also have to import
the available log backups.

© SAP AG 2004, Backup and Recovery Considerations, Eugene Bonnie, 10

„ SDM - Overwrite the installed SDM.

„ Applications - Follow the description in the corresponding Solution Management Guides to recover
your SAP applications.
ƒ Restart - Restart the J2EE Engine
ƒ Results - The J2EE Engine is restored with the last backup
 Split Mirror Backup Overview

Split mirror Online Backup Split mirror Offline Backup

1 Tablespaces set to status BACKUP Production database shut down
2 Mirror disks (A' and B' in the graphic) split and
connected to backup server using:
Split command scenario: split_cmd
SPLITINT scenario: SPLITINT program
3 Tablespaces reset to normal status Production database restarted
4 Mirror disks backed up on backup host
5 Optional: Primary and mirror disks resynchronized using:
Split command scenario: resync_cmd
SPLITINT scenario: SPLITINT program

© SAP AG 2004, Backup and Recovery Considerations, Eugene Bonnie, 11

 Delayed Synchronization – Distributed systems

Backup System 2 System 3

running finished finished Shutdown n-1 systems
and start log backup

System 1
finished

System 1
Online Backup Delta Data Log Backup

System 2
Online Backup Delta Data Log Backup

System 3
Online Backup Delta Data Log Backup

Systems
synchronized

Consistent
backup

© SAP AG 2004, Backup and Recovery Considerations, Eugene Bonnie, 12

„ Offline time can be reduced by taking an online database backup followed by an offline log backup.
„ Steps:
- Take an online backup of all systems.
- Shut down all but one system after the online backup of all systems is finished (application shutdown) and start
a log backup (or initiate logswitch) for these systems.
- Start log backup (or initiate logswitch) on online system after last of the other systems was shut down.
- All systems can be restarted after the log backup / logswitch on the online system was started.
- Details of the procedure may differ for different database systems.
„ To get a consistent state, all systems except one must be down at one point in time. A consistent state is reached,
with systems synchronized, after the last of the n - 1 systems is shut down. Then the log backup of the one system
that stays online can be started. The log backup of the shutdown systems can be started earlier because there cannot
be any changes.
„ A restore can now recover all systems using the logs. Because all but one systems were down, the restore will
provide a consistent state (the time when the log backup / logswitch on system 3 was done).
„ Advantage: Short downtime. The downtime can be even shorter than for stopping all applications because the other
systems may already be restarted after the last system started its log backup / logswitch.
„ Disadvantages: same as for stopping all applications
 Failover/Second Instance Distributed Systems

SAP SAP
SAP BW SAP CRM SAP BW SAP CRM
XI XI

Remote Copy

Consistency Group

© SAP AG 2004, Backup and Recovery Considerations, Eugene Bonnie, 13

„ The concept of consistency groups can also be extended to include remote copies to another site.
 Incomplete Recovery

Recovery to current point in time not possible:

Point-in-time / point-in-log recovery

Possible reasons:
„ Logfiles corrupt
„ Tapes destroyed
„ DB logically corrupt

Not an option if:

„ Single tables dropped
„ Wrong transports imported

Consequences:
„ Data loss
„ Inconsistencies between systems

© SAP AG 2004, Backup and Recovery Considerations, Eugene Bonnie, 14

„ All database systems guarantee that it is always possible to recover to the current point in time after a
system crash. This means that all committed transactions can be recovered after a crash. Because of the
techniques used to exchange data between systems, this also ensures that the systems are in a consistent
state after a system is recovered.
„ Data between systems can only be inconsistent if it proved impossible to recover one of the systems to the
point of the crash, and therefore a recovery to an earlier point in time was performed.
„ Do all you can to avoid a point-in-time restore.
„ Data loss for a few tables (such as unintentionally dropping a table), import of incorrect transports, or
logical corruption are usually insufficient reasons for doing a point-in-time restore. Instead, the system
should be kept running and the errors fixed by importing tables from a test system or an earlier backup,
correcting wrong or inconsistent data, applying correcting transports, and so on. This procedure becomes
more important the longer the system continued running before the error was detected. The data loss
caused by a point-in-time restore is usually more serious for business operation than the energy needed to
fix the problems.
„ Thus, the only reasons for an incomplete recovery are of physical nature.
- Examples: the log files are corrupt (this may also be due to software errors) and cannot be applied,
the log tapes are destroyed, or the database is so logically corrupt that it cannot be fixed at all.
 Alternatives to a Point-in-Time Recovery

To avoid a point-in-time recovery, consider the following:

Single tables lost or damaged
‹ Reconstruct table from a test system
‹ Reconstruct table from redundant data in other tables
‹ Reconstruct table from redundant data in other systems
‹ Restore system on a sandbox and reconstruct table from there

Wrong transports imported

‹ Apply correcting transports

If another solution
Other handling errors seems possible, avoid
‹ Repair inconsistent data point-in-time recovery

© SAP AG 2004, Backup and Recovery Considerations, Eugene Bonnie, 15

 New features in Web AS Release 6.40

New SAP Tool Administration of Oracle Databases

BRSPACE which can be used for:

„ Instance Management
ƒ Manages your database instance or instances if you have Oracle Real
Application Cluster (RAC)

„ Space Management
ƒ Manages space in your database

„ Segment Management
ƒ Manages segments (i.e. tables and indexes) in your database

© SAP AG 2004, Backup and Recovery Considerations, Eugene Bonnie, 16

„ The following applies to BRSPACE:

y BRSPACE is part of BR*Tools and replaces the SAPDBA functions that have not so far been replaced
by other BR*Tools.
y As of SAP Web Application Server 6.40, SAPDBA is no longer being released.
y You can continue to use SAPDBA 6.20 linked to Oracle 9i with SAP Web AS 6.40. However, we
strongly recommend you to only use BR*Tools instead.
y BR*Tools 6.40, including BRSPACE can be used for all SAP Releases based on Oracle 9i.
y For more information on BR*Tools, see the following SAP Notes:
y 646681
y 647697
y 668640
 Summary

You should now be able to:

z Describe the backup and recovery strategies in an

SAP XI environment
z Describe SAP XI in a High Availability Environments

© SAP AG 2004, Backup and Recovery Considerations, Eugene Bonnie, 17