Introduction

An SAP System comprises of executable programs, profiles, logs, master and transaction
data etc. While SAP data is stored in a relational database the other entities are files
stored in Operating System level files. Hence a backup of SAP system consists of database
files and SAP files such as programs, log files, and so on, which are stored centrally under
/usr/sap/... .
Operating system tools are used to back up this directory tree, which is part of the
hierarchical file system. As this data generally only changes when profile parameters are
modified or after an upgrade, or application of kernel patch, you only need to perform a
backup of OS level files in such cases. The transport requests are also stored as OS level
file and backed up using OS file backup tools ( e.g. tar ) .
However, for database objects the situation is completely different, as we describe in this
document. Since the data in the database it is generally very dynamic, SAP data requires
a comprehensive backup strategy.

Backup, Recovery and all other DBA related activity

General Approach for Backup-Restore of a SAP ERP system
The backup method and requirements of a specific system component mainly depends on
the type of data that the component holds.
In a SAP ERP Business Suite System Landscape we have to deal with different kinds of data
as a candidate for backups:
Data managed by databases
Data in files which are managed directly by the applications
Software of the applications
Configuration files of the software components
Log files of the software components

For each of the above kinds of data different backup methods and concepts need to be
used. In the following we will refer to the first two kinds as application data or business
data to distinguish them from the application software, configuration files and log files.

The backup method then also depends on the following factors:
Does the component hold original data (which means the component is the leading
system for some pieces of data) or replicated data? When speaking of replicated
data, we mean both data that is merely replicated from another system and data that
is derived from another systems data.
The time needed to replicate data: Depending on the time it takes to restore replicated
data from the originals it might not be necessary to backup the replicates.
The type of data
The type of system managing the data

In SAP Business Suite landscapes we have system components that do not hold any
application data, system components whose application data is managed by a database
system and system components that manage their application data by themselves. Based on
these factors, we may categorize the system components into different broad classifications.

Application Data
In general, all systems that hold originals of application data must be backed up carefully
to avoid the loss of important business information. On the other hand systems that hold only
replicated data could be rebuilt from the original data sources so there might be no need to
do a backup. For exmple, LiveCache systems draw data from a source system e.g. SCM
APO . This replicated data can either be rebuilt from scratch or from the delta data.

The backup method to be used for the component then depends on the type of data
management: It can be a database and log backup in case of database-managed
application data or a file system backup in case of file-based data managed by the
application itself. In all cases aspects of data consistency between the system components
must be regarded for system components that exchange data.

Backup and Restore of Software and Configuration Data

Apart from business critical application data the system and application software itself may
be worth being backed up. This can prevent from a new installation in case all or parts of
the software have been destroyed. As a new installation will always be possible, this backup
is not mandatory. A general recommendation is to backup the application software at least
once after it has been installed or after it has been upgraded. Note that restoring a backup
of the system or application software is generally only possible if it is restored to exactly the
same hardware.

Installing the software often requires a large amount of configuring and customizing. So
saving this kind of information may also be important to provide a fast restore and to avoid
time and effort after possible failures of a component. As the configuration may change
more often that the software, the configuration files should generally be backed up on a
regular basis or each time the configuration has been modified.

The following items should be considered when planning a B&R strategy for software and
configuration files:
Operating system
DBMS software
SAP software and file systems
Log files (SAP and other)
Software of other system components (file systems, configuration files, log files)
Files used for data transfer or interface implementation (for example, ftp-files)




Directory structure for Oracle based systems

The following figure depicts critical directory structures for Oracle based systems which need to be
considered at the time of backup restore .



An SAP System comprises of executable programs, profiles, logs, master and transaction data etc.
While SAP data is stored in a relational database the other entities are files stored in Operating
System level files. Hence a backup of SAP system consists of database files and SAP files such as
programs, log files, and so on, which are stored centrally under /usr/sap/... .
Operating system tools are used to back up this directory tree, which is part of the hierarchical file
system. As this data generally only changes when profile parameters are modified or after an
upgrade, or application of kernel patch, you only need to perform a backup of OS level files in
such cases. The transport requests are also stored as OS level file and backed up using OS file
backup tools ( e.g. tar ) .
SAP Database Backup tools
The database server plays an important role in the server technology of SAP Business Solutions. In
response to customers requesting support for administrative tasks, SAP has included several
database administration tools in the standard SAP System package.

These tools can be used, for example, for backup and recovery. For a long time, only basic backup
programs (for example dd, cpio, tar) were available for open operating systems like UNIX. These
are not suitable for backing up a relational database because they do not:
Deal with special problems that might occur during database backup
Provide tape management
Therefore, SAP offers its own backup programs. These tools enable you to easily and completely
back up the SAP system, so that your system runs smoothly. There is also a BACKINT interface that
integrates the most common client/server backup programs.

SAP provides the following BR*Tools for Oracle database administration:

BRBACKUP, BRARCHIVE, BRRESTORE, and BRRECOVER ( Database backup, restore and
recovery)
BRCONNECT
BRSPACE (database statistics, database check, cleanup logs and traces)

Using External Backup Tools for SAP database backup/restore
External backup management tools can be used to backup/restore SAP database. SAP BR*Tools can call
the BACKINT interface program so as to communicate with an external backup program.
BACKINT processes the requests for backup, restore, and inquire, and executes them using the corresponding
backup tool. If the Media Management Software (MMS) is a client/server program, BACKINT communicates
with the server program running on the backup server.



Recommended Backup cycles , Backup sets and media pool

In the examples below the tape administration is controlled by BRBACKUP and BRARCHIVE.
These tools can be executed interactively from BRTOOLS or can be scheduled in SAP
Transaction DB13.
Nevertheless, the strategies shown in the examples below are valid for other backup
strategies such as BACKINT or RMAN.




To be able to deal with a faulty backup, several generations of backups have to be
available.
Therefore, for this example, the retention period is set to 28 days and consequently 27
backup generations are available in the event of database failure. The tape pool ought to
contain several reserve tapes, shown as + x in the above graphic. The additional
tapes we recommend approximately 30% of the required number are intended as a
reserve in case the amount of data to be backed up greatly increases or an extra
unplanned backup becomes necessary.
Using a separate tape pool, you also need to back up the redo log information generated
during the day, which is temporarily stored on a separate large disk until the tape
backup. As this data is necessary to recover a database after restoring a data backup,
never set the retention period for the redo log tapes to less than the retention period for
the data backup tapes. Particularly in the case of an online backup, it is best to always
back up redo logs directly after the data backup.
Without redo log information the online backup is worthless.
As the redo log information is much more dynamic than the database data, even more
reserve tapes are required.
We recommend you to back up the redo logs twice for extra security, so that you need 2
x (52 + x) tapes in the redo log tape pool.
In case an external backup management software like HP Data Protector, Tivoly etc.
are used then the media management functions are handled by the backup management
software.
If the software is SAP certified then use BACKINT interface for integration of
scheduling, backup, restore, parallelization etc.