&KDSWHU %DFNXSDQG5HFRYHU\ 

&RQWHQWV

Overview ..................................................................................................................3–2
Restore.....................................................................................................................3–2
Backup .....................................................................................................................3–3
Tape Management.................................................................................................3–13
Performance ..........................................................................................................3–20
Useful SAP Notes..................................................................................................3–24

System Administration Made Easy 3–1

Chapter 3: Backup and Recovery
Overview

2YHUYLHZ

The most important aspect of a technical implementation is establishing an effective backup

and recovery strategy. This process entails a restore of all, or part, of the database after
hardware or software errors and a recovery during which the system is updated to a point
just before the failure. There are many situations other than disk failures that may require a
restore and recovery.
Your backup strategy should be as uncomplicated as possible. Complications in backup
strategy can create difficult situations during restoration and recovery. Procedures, problem
identification, and handling must be well documented so all individuals clearly understand
their roles and required tasks. This strategy should also not adversely impact daily business.
This chapter discusses backup and restore of your system. The details of a specific database
are covered in the database administration chapter(s). The information in this chapter will
help you better understand the concepts that enhance your operating environment and
access the methods that best suit your needs.

5HVWRUH

Usually a restore is done to:

< Recover after a disaster
< Test your disaster recovery plan
< Copy your database to another system
(For additional details on the first two items, see chapter 2; and for details on the last item,
see chapter 23.)
The business requirement for speed in a restore is driven by the need to get the system
quickly operational after a disaster. This way, the company can continue to do business.

6WUDWHJ\
Business recovery time is the result of the time needed to:
< Find the problem
< Repair the damage
< Restore the database
Factors that affect the chosen restore strategy include:
< Business cost of downtime to recover
< Operational schedule
< Global or local users
< Number of transactions an hour
< Budget

Release 4.6A/B
3–2
 Chapter 3: Backup and Recovery
Backup

The actual process to restore R/3 and the database will not be covered in this book. This
critical task has specific system dependencies, and we leave it to a specialist to teach. If a
restore must be done, contact a specialist or your Basis consultant. Work with your DBA or
consultant to test and document the restore process for your system. With proper training,
you should be able to do the restore.

If the restore is not done properly and completely, it could fail and must be restarted, or be
missing other files. There may be special data that you must record about your database to
recover it. Work with your specialist to identify and document this data.

7HVWLQJ5HFRYHU\
Since the restore procedure is one of the key issues of the R/3 System, database recovery
must be regularly maintained and tested. See chapter 2, Disaster Recovery.

%DFNXS

Backup is like insurance. You only need a backup if you need to restore your system.

:KDWWR%DFNXSDQG:KHQ
There are three categories of files to backup:
< Database
< Log files
< Operating system files
Note; you may need to use different tools to backup all the files. Some tools may only be
able to backup one or two of the three categories of files that need to be backed up. Example,
using the SAP DBA Calendar DB13 for on Microsoft SQL Server, it can backup the database
and the transaction log, but not the operating system files.
'DWDEDVH

:KDW

This is the core of the R/3 system and your data. Without the database backup, you cannot
recover the system.

:KHQ

The frequency of a full database backup determines how many days back in time you must
go to begin the restore:
< If a daily full backup is done, you will need yesterday’s full backup.
Only logs since yesterday’s backup need to be applied to bring the system current.
< If a weekly full backup is done, you will need last week’s full backup.
All the logs for each day (since the full backup) must now be applied to bring the system
current.

System Administration Made Easy

3–3
Chapter 3: Backup and Recovery
Backup

A daily full backup reduces the number of logs that need to be applied to bring the database
current. This backup reduces the risk of not getting a current database backup because of a
“bad” (unusable) log file.
If a daily full backup is not done, more logs would need to be applied. This step lengthens
the recovery process time and increases the risk of not being able to recover to the current
time. A point may be reached when it would take too long to restore the logs, because so
many logs need to be applied. For additional safety, we recommend that you do a full
monthly database backup in addition to the full daily backups.

([DPSOH:HHNO\%DFNXS

A restore from last week’s full backup that was done four days ago.
< There are 10 logs a day.
< A total of 40 logs (10 logs per day × 4 days) need to be restored.
< It takes 120 minutes to restore the log file from tape to disk (40 log x 3 minutes per
log).
< It takes 200 minutes to restore the log files to the database (40 logs x 5 minutes per
log).
< The total time to do the restore, excluding database files, is 320 minutes (5.3 hours).

([DPSOH:HHNO\%DFNXS

A restore from last night’s full backup

< There are maximum of 10 logs a day.
< It takes 30 minutes to restore the log file from tape to disk (10 log x 3 minutes per
log).
< It takes 50 minutes to restore the log files to the database (10 logs x 5 minutes per
log).
< The total time to do the restore, excluding database files, is 80 minutes (1.3 hours).
As you can see, the weekly backup takes four times longer to recover than a daily
backup.

These examples show that the time it takes to do a log restore depends on how many days
back you have to go to get to the last full backup. Increasing the frequency of the full backup
(with less days between full backups) reduces the recovery time.
Also consider maintaining two backup cycles of the logs on disk to reduce the need to
restore these logs from tape.

Release 4.6A/B
3–4
 Chapter 3: Backup and Recovery
Backup

7UDQVDFWLRQ/RJV

:KDW

Transaction logs are critical to the database recovery. These logs contain a record of the
changes made to the database, which is used to roll forward (or back) operations. It is
critical to have a complete chain of valid log backups. If you have to restore and one log is
corrupted, you cannot restore past the corrupt log.

Weekly Full Backups

If the system crashes on Thursday, a log on Tuesday is corrupt. You can only recover to
the last good log on Tuesday. Everything after that is lost.

Transaction log is stored in a directory, which must not be allowed to become full. If the
transaction log fills the available filespace, the database will stop, and no further processing
can be done in the database (and consequently) in R/3. It is important to be proactive and
periodically back up the transaction logs. Refer to the chapter specific to your database for
more information.

:KHQ
The frequency of the log backups is a business decision based on:
< Transaction volume
< Critical period(s) for the system
< Amount of data senior management is willing to lose
< Resources to perform the backups and take them offsite
Also see the examples in the database section above.

If your transaction volume is high, decrease the time interval between log backups. This
reduced time interval decreases the amount of data that could be lost in a potential data
center disaster.

+RZ

To back up transaction logs:

1. Backup the transport log to disk.
2. Copy the backup of the transaction log to an offsite backup file server.
This backup file server should ideally be in another building or in another city. A
separate location increases the chance that the log files will be preserved if the primary
data center (containing the R/3 servers) is destroyed.

System Administration Made Easy

3–5
Chapter 3: Backup and Recovery
Backup

3. Back up the backup of the transaction logs on both servers (the R/3 server and the
offsite backup file server) to tape each day along with the other operating system-level
files.
If you do not have an offsite backup server, back up the transaction log backups to tape
after each log backup and immediately send the tape offsite.

Do not back up the logs to the tape drive in “append” mode and append multiple
backups on the same tape. If a data center disaster occurs, the tape with all these logs
will be lost.

2SHUDWLQJ6\VWHP/HYHO)LOHV

:KDW

Operating system level files, which must also be backed up, are for:
< Operating environment (for example, system and network configuration)
< R/3 files
 Spool files, if stored at the operating system level
(system profile: rspo/store_location = G)
 Change management transport files located in /usr/sap/trans
< Other R/3 related applications
 Interface or add-on products, such as those used for EDI or taxes, that store their
data or configuration outside the R/3 database.
The amount of data is small in relation to the R/3 database. Depending on how your system
is used, the above list should only require several hundred megabytes to a few gigabytes of
storage. In addition, some of the data could be “static” and may not change for months.

:KHQ

The frequency of the operating system level backup depends on the specific application. If
these application files must be kept in sync with the R/3 System, they must be backed up at
the same frequency as the log backup files. An example of this situation is a tax program
that stores its sales tax data in files external to the R/3 database. These files must be in sync
with the sales orders in the system.
A simple and fast method to back up operating system files is to copy all data file directories
to disk on a second server; from the second server, you can back up those files to tape. This
process minimizes file downtime.
Use the sample schedule below to determine your backup frequency:

%DFNXS7\SHV
Backup types is like a three-dimension matrix, where any combination can be used:
< What is backed up: full database vs incremental of the logs
< How the backup taken: online vs offline
< When the backup is made: scheduled vs nonscheduled (ad-hoc)

Release 4.6A/B
3–6
 Chapter 3: Backup and Recovery
Backup

:KDW,V%DFNHG8S
< Full database backup
A backup of the entire database.
Advantages:
 The entire database is backed up at once, making the restore of the database easier
and faster. There are less logs that need to be applied to bring the restored database
current.
Disadvantages:
 Takes longer to run than an incremental log backup. Because of the longer backup
window there is more impact on the users while the backup is running.
< Incremental backup of the transaction logs
A backup of the transaction logs.
A full database backup is still required on a periodic basis. The usual arrangement is; a
full backup on the weekend and incremental backups during the week.
Advantages:
 Much faster than a full database backup. Because of the smaller backup window,
there is less impact to the users.
Disadvantages:
 A full backup is needed, as a starting point to restore the database.
 To restore the database takes significantly longer and is more complicated than
restoring a full backup. The last full database backup must be restored, then all log
backups since the full backup. This can be many logs if for example the system
crashed on Friday, then the logs from Monday through Friday have to be applied.
 If one log cannot be restored, all the logs after that point cannot be restored.
< Differential backup
Depending on your database and operating system, you may (or may not) have a third
option. A differential backup is a backup of only what has changed since the last full
backup. A full database backup is still required on a periodic basis. The usual
arrangement is; a full backup on the weekend and differential backups during the week.
Differential backup is not supported from within R/3 using DB13, you must use other
tools to perform a differential backup.
 Microsoft SQL Server; to do a differential backup you must execute the differential
backup using Microsoft SQL Server tools.
Advantages:
 The exposure to a corrupt log backup is reduced. Each differential backup is backing
up all the changes to the database since the last full backup.
Disadvantages:
 Like the incremental log backup, a full backup is needed as the starting point.

System Administration Made Easy

3–7
Chapter 3: Backup and Recovery
Backup

 The backup window for a differential is longer than a transaction log backup. It
starts as being short (just after the full backup) and gets longer as more data is
changed.
+RZWKH%DFNXS,V7DNHQ
< Offline
An offline backup is taken with the database and R/3 System down.
Advantages:
 An offline backup is faster than an online backup.
 During the backup, there is no issue with data changing in the database.
 If the files are backed up at the same time, the related operating system files will be
in sync with the R/3 database.
Disadvantages:
 R/3 is unavailable during an offline backup.
 Buffers for R/3 and the database are flushed.
This process will impact performance until the buffers are populated.
< Online
An online backup is taken with the database and R/3 running.
Advantages:
 R/3 is available to users during a backup.
This is needed where the system is running and used 24 hours a day and seven days
a week.
 The buffers are not flushed.
Since buffers are not flushed, once the backup is complete, there is no impact on
performance.
Disadvantages:
 An online backup is slower than an offline backup (a longer backup time).
 Backup time is increased because processes such as R/3 are running and competing
for system resources.
 Online performance is degraded while the backup is running.
 Data may change in the database while it is being backed up.
Therefore, the transaction logs become critical to a successful recovery.
 Related operating system level files may be out of sync with the R/3 database.

If you are using online backups, the transaction logs are critical to successfully
recovering the database.

Release 4.6A/B
3–8
 Chapter 3: Backup and Recovery
Backup

:KHQWKH%DFNXS,V0DGH
< Scheduled
Scheduled backups are those that are run on a regular schedule, such as daily or weekly.
For normal operations, configure a scheduled backup. Automated backups should use
the DBA Planning Calendar (transaction DB13). This calendar provides the ability to set
up and review backup cycles. It also has the ability to process essential database checks
and update statistics. You can also set up CCMS to process the backup of transaction
logs.
Depending on the operating platform, backups and other processes configured here can
be viewed in the Batch Processing Monitors (transaction SM37). In general, the status of
the backups can be viewed using Backup Logs overview (transaction DB12).
< On-demand
On-demand backup is done on an ad hoc basis. It is done before a major change to the
system, such as for an R/3 upgrade. Backups that are controlled directly by an operator,
or on-demand, can be performed either by the DBA Planning Calendar (transaction
DB13), at the database, or at operating system level.
Although the DBA Planning Calendar can schedule backups for periodic use, it can also
be used to perform an immediate backup. For an on-demand backup, it is more common
to use tools at the database level such as Enterprise Manager (Microsoft SQL Server) or
SAPDBA (Oracle and Informix).
Regardless of the chosen backup method, you should achieve the following goals:
< Provide a reliable backup that can be restored.
< Keep the backup simple.
< Reduce the number of dependencies required for operation.
< Provide the above items with little or no impact to business units.

%DFNXS6WUDWHJ\'HVLJQ
SAP provides tools under CCMS-DB Administration in R/3 to assist in implementing your
strategy. The DBA Planning Calendar (transaction DB13) is designed for scheduling backups.
The other tool, the CCMS Monitoring tool (transaction DB12), provides historical
information to review backup statistics and tape management information. At the operating
system or database level, there are additional tools you can use to administer backup and
restores. These tools include SQL Enterprise Manager (Microsoft SQL Server) and SAPDBA
(Oracle and Informix).
To design your backup procedures:
1. Determine the recovery requirements based on an acceptable outage.
It is difficult to define the concept of acceptable outage, because “acceptable” is
subjective and will vary from company to company. The cost of what is an outage
includes productivity loss, time, money, etc. spent on recovery. This cost should be
evaluated in a manner similar to insurance. (The more coverage you want, the more the

System Administration Made Easy

3–9
Chapter 3: Backup and Recovery
Backup

insurance will cost.) Therefore, the faster the recovery time requirements, the more
expensive the solution.
2. Determine what hardware, software and process combinations can deliver the desired
solution.
Review the section on performance to decide which method is best. Follow the “Keep It
Simple” (KISS) rule, but more importantly, make sure your method is reliable.
3. Test your backup procedures by implementing the hardware and reviewing the actual
run times and test results.
Ensure that you get results from all types of backup that could be used in your
environment, not just the ones you think might be used. This information will aid
further evaluation and capacity planning decisions and provide useful comparison
information as needed.
4. Test your recovery procedures by creating various failure situations.
Document all aspects of the recovery including the process, who should perform various
tasks, who should be notified, etc. Remember that a recovery will be needed when you
least expect it so be prepared. Testing is not a one-time event. It should occur regularly,
with additional tests as hardware or software components change.
6XSSOHPHQWDU\%DFNXSV
Supplementary backups are made on special days (month-end, year-end), so that you can
restore the database to a previous state.

*HQHUDO3URFHGXUHV
%DFNXS
The unattended backup is performed based on the backup frequency table. The scheduling
functionality of the R/3 CCMS is used to schedule the backup. In CCMS, the required tapes
can be listed by choosing theVolumes Needed button on the backup scheduling screen. Extra
backups, such as the monthly and yearly backup, should be performed offline.
7UDQVDFWLRQ/RJ%DFNXS
If transaction log backup is performed during normal system operation, there is no user
impact. You can also find the tapes needed by choosing Volumes Needed.
No special archiving is required for offline backup. (Since the backup is performed offline,
the database remains in a consistent state.)
9HULI\LQJ%DFNXSV
Backups must be verified following a regular schedule. Transaction DB13 and other backup
utilities provide buttons such as Verify Backup to perform this task. Unless the backup is
verified, you will not know that you have properly backed up everything onto tape.

Release 4.6A/B
3–10
 Chapter 3: Backup and Recovery
Backup

([DPSOH
A backup of several files was done, but the “append” switch was not properly set for
second and later files. Consequently, rather than appending the files one after the other,
for each file, the tape was rewound and the backed up. The end result was that only the
last backed up file was on the tape.

File verify has to be done after all files have been backed up. If it was done after each file, it
would not detect that the previous file was erased.

0RQLWRULQJ&RQWUROOLQJ
For each system, after backing up the database and finishing the archives, all logs must be
printed and placed in the folder.
'DWDEDVH,QWHJULW\
An integrity check of the database must be performed in one retention period to ensure that
no corrupted blocks exist in the database. These blocks may go unrecognized during backup
(see the chapter written for your database for more information).
To avoid backing up a hidden, inconsistent database, the database must be checked at least
once during a retention period.

System Frequency of DB Checks

DEV Every 2 weeks
QAS Every 2 weeks
PRD Every week

5ROHVDQG5HVSRQVLELOLWLHV

Task Role
Backup Database Operator
Backup Archives Operator
Verifying Backups Operator/DBA
Monitoring/Controlling Operator/DBA
Database check DBA

System Administration Made Easy

3–11
Chapter 3: Backup and Recovery
Backup

'HVLJQ5HFRPPHQGDWLRQV
< Database
Assuming the size of your database and backup window permits it, we recommend a
full database backup be taken every day. For databases that are too large for daily full
database backup, a full backup should be taken weekly.
< Transaction Logs
Backing up the transaction logs is critical. If the filespace is used up, the database will
stop, which stops R/3.
Between 6:00 a.m. and 9:00 p.m., we recommend that you back up these logs at least
every three hours. A company with high transaction volume carries higher risk and
would increase the frequency accordingly, perhaps to every hour. Similarly, if you have
a Shipping department that opens at 3:00 a.m. and a Finance department that closes at
10:00 p.m., you would need to extend the start and end times.
< Operating System Level Files
The frequency of the operating system level backup depends on the application. If these
files must be kept in sync with R/3, they must be backed up with the same frequency
and at the same time as the database and log backups. An option for a non-sync-critical
situation is to back up these operating system level files once a day.
$6WUDWHJ\&KHFNOLVW
It is important to set up a proper procedure to back up the valuable system information.
Procedures should be defined as early as possible to prevent possible data loss. Resolve the
following list of backup issues before you go live:
< Decide how often to perform complete database backups
< Decide whether partial or differential backups are necessary
< Decide when to perform transaction log backups
< Have the ability to save a day’s worth of logs on the server.
< Provide ample disk space for the transaction log directory
< Consider using DBA Planning Calendar (DB13) to schedule transaction log backups
< Set the appropriate R/3, operating system, and database authorizations
< Create a volume labeling scheme to ensure smooth operations
< Decide on a backup retention period
< Determine tape pool size (tapes needed per day × retention + 20 percent)
Allow for growth and special needs.
< Initialize tapes
< Determine physical tape storage strategy
< Decide whether to use unattended operations
If using unattended operations, decide where (in CCMS or elsewhere).
< Document backup procedures in operations manual
< Train operators in backup procedures

Release 4.6A/B
3–12
 Chapter 3: Backup and Recovery
Tape Management

< Implement a backup strategy

< Perform a test restore and recovery
< Define an emergency plan and determine who to contact in case of an emergency
%DFNXS3URFHGXUHVDQG3ROLFLHV
Backup policies and procedures should be defined as early as possible to prepare for
potential data loss during an implementation.
Some examples of policies and procedures are included below:
< System Environment
In the three-system landscape, CCMS backs up and restores the software components.
(In the three-system landscape in this guidebook, DEV is a development system, QAS is
a quality assurance system, and PRD is a production system.)
< Hardware Components
The hardware listed in the table below is to backup and restore the database and
transaction logs:

System Name Backup Hardware

DEV 1 x DLT 7000 35/70 GB, 1 DDS-3 12/24
QAS 1 x DLT 7000 35/70 GB, 1 DDS-3 12/24
PRD 2 x DLT 7000 35/70 GB, 2 DDS-3 12/24

7DSH0DQDJHPHQW

7UDFNLQJDQG'RFXPHQWLQJ
To easily retrieve tapes from storage, you need to track and document them.
The issues are:
< Labeling
< Tracking
< Handling
< Retention requirement
/DEHOLQJ
Tapes should be clearly labeled using one of many labeling methods. Three simple methods
are described in the examples below. Two of these methods are used by R/3 and are
important if you use DB13 to schedule your backups. Third-party backup management
software may assign their own tracking number for the labels. In this case, you must use the
label specified by the software.

System Administration Made Easy

3–13
Chapter 3: Backup and Recovery
Tape Management

([DPSOH
This five-character naming convention is used by DB13 on Microsoft SQL Server 7.0. (see
SAP note 141118). Microsoft SQL server 6.5 had a different naming convention.
Each label has the following data:
< What is backed up:
R = R/3 database or transaction log
M = msdb database
S = master database
C = combination
< Type of backup:
L = transaction log
D = database
F = file
G = file group
+ = differential
< Day of the month (01-31)
< Parallel or Sequential backup (P or S)

Sample Label: RD06S

R (R/3) + D (database) + 06 (6th day of the month) + S (sequential)

([DPSOH

This six-character naming convention is used by SAPDBA and BRBACKUP (Oracle).

Each label has the following data:
< System ID <SID>
< What is backed up
B = database
A = log
O = operating system files
< Sequence number of the tape
(This number is a sequential tape number, starting from 1 and is unrelated to the date.)
Sample Label:
PRDB25
PRD (Production db) + B (Brbackup/Database) + 25 (tape number 25)

Release 4.6A/B
3–14
 Chapter 3: Backup and Recovery
Tape Management

([DPSOH

This method is more visual, where the length of the label name is less of a limitation.
Each label has the following data:
< System ID <SID>
< What is backed up
db = database
tl = transaction log
os = operating system files
< Day of the month
< Multiple tape indicator for a single day (can be omitted if only one tape is used)
Sample Label:
PRD-db-06-a
PRD (Production database) + db (database) + 06 (6th day of the month) + a
(tape “a”, the first tape)

If DB13 is not used, for all of above naming conventions, additional codes can be used to
indicate additional types of files that are backed up.
In addition to the naming schemes, use a different color label for each system. A color
scheme is one more indicator to help identify the tape and reduce confusion.
An example of a color scheme is:
< PRD = orange
< QAS = green
< DEV = white
7UDFNLQJ
Tapes should be logged to track where they are stored, so you can locate them when you
need them.
In addition to tracking and documenting tapes when tape locations change, tapes should be
tracked and documented when they are:
< Used
< Sent to offsite storage
< Returned from offsite storage
< Moved to a new location
To help you track and retrieve the offsite backup, log the:
< Date of backup
< Database

System Administration Made Easy

3–15
Chapter 3: Backup and Recovery
Tape Management

< Tape number

< Tape storage company’s number
Some storage companies label the cartridges with their own tracking label, so that they
can track them internally to their system and facility.
< OS level backup tape number
< Date sent offsite
< Date returned
The table below is an example:

Date Volume Purpose Notes Storage Out Back

Label Company
Label

7/15/98 PRDB01 Data Base X7563 7/15/98 7/30/98

7/15/98 PRDO23 Operating Sys X7564 7/15/98 8/15/98

+DQGOLQJ
When you transport tape cartridges, carry them in a protected box to minimize damage and
potential data loss if they are accidentally dropped. The box should have foam cutouts for
each tape cartridge you use.

For a small company, an ideal tape collection device is a small or medium-sized plastic tool
box with a foam insert that has cutouts for each tape cartridge. Plastic is used because it is
nonmagnetic.

We recommend that you use two boxes. One box should collect the tapes to be sent offsite,
and a second box should contain the new backup tapes. The second box should be empty
when you finish changing tapes.

When changing tapes, to avoid confusion:

< Handle one tape cartridge at a time
< Follow the same procedure each time

To change tapes:
1. Remove the tape cartridge from the tape drive.
2. Insert it in the collection box.
3. Remove the next tape.
4. After all tapes have been removed, insert the new tapes in the drive in the same manner.
If you are using preinitialized tapes, you must use the correct tape for that day, or the
backup program will reject the tape. The backup program reads the tape header for the

Release 4.6A/B
3–16
 Chapter 3: Backup and Recovery
Tape Management

initialization information (which includes the tape label name) and compares it to the next
label in the sequence.
Keep track which tape cartridges:
< Have been used
< Are to be sent offsite
< Are to be loaded in the drives
It is easy to accidentally put the wrong tape cartridge in a drive and destroy the recent
backup or cause the next backup to fail.

When you initialize a tape, some programs write an expiration date on the tape. The tape
cannot be overwritten by that same program before the expiration date. However, it might
be overwritten by another program that ignores the tape header.
The next section discusses the importance of retention requirements.

5HWHQWLRQ5HTXLUHPHQWV
There are legal requirements that determine data retention. Check with your company’s
legal department on complying with federal, state, and local data retention requirements.
Complying with these requirements should be discussed with your legal and finance
departments, external auditors, and consultants. The retention requirement should then be
documented.
The practical side of data retention is that you may be unable to realistically restore an old
backup. If the operating system, database, and the R/3 System have each been upgraded
twice since the backup, it is unlikely that the backup can be restored without excessive
cost—if at all.
Retention is related to your backup cycle. It is important to have several generations of full
backups and all their logs because:
< If the database is corrupted, you will have to return to the last full backup before the
database corruption.
< If the last full backup is corrupted, you will have to return to the previous full backup
before the corruption or disaster and roll forward using the backup of the logs from that
backup until the corruption.
How far back you go depends on the level of corruption.
< Since R/3 is an online real-time system, to recover the database from a full database
backup, you must apply all the logs since that backup. If this is a significant amount of
time, the number of logs could be tremendous. Therefore, the number of logs you may
need to apply is a practical constraint to how far back you can recover.

System Administration Made Easy

3–17
Chapter 3: Backup and Recovery
Tape Management

5HFRPPHQGDWLRQV
< If a full database backup is taken each day, we recommend that you keep at least two
weeks of backups and all the logs for these weeks.
< If a full database backup is taken weekly, you should go back at least three generations.
The traditional three generations of backup are:
 Grandfather
 Father
 Son
< Store selected backup sets (month-end, quarter-end, year-end, etc.) for extended periods,
as defined by your legal department and auditors.
Tape Retention Period
Even if one tape (backup/archive) is damaged or lost, the tape retention period assures the
ability to recover the database.

System Name Regular Month-End Quarter-End Year-End Archives

Backup Backup Backup Backup
DEV 14 days 31 days
QAS 14 days 31 days
PRD 31 days 24 months 2 years 4 years 31 days

System administrators cannot determine tape retention periods on their own.

To determine the retention period, administrators must consult the departments that are
impacted, such as accounting and legal. There is room for some negotiation, but the
administrator must comply with the final decision. As a policy, this decision must be
written down.

6WRUDJH
2IIVLWH

:KDW

The offsite storage site is a separate facility (building or campus) from the R/3 data center.

:K\

An offsite storage safeguards the backups if your facility is destroyed.

:KHUH

The magnitude of the disaster will determine what is considered adequate protection:
< Sending tapes to a separate location in the building or another building in the campus
will be sufficient.
If the disaster is confined to the building where the data center is located.

Release 4.6A/B
3–18
 Chapter 3: Backup and Recovery
Tape Management

< If the disaster is local or regional (for example, a flood or earthquake) adequate
protection means sending tapes to a distant location several hundred miles away.
Offsite data storage can be at a separate company facility or a commercial data storage
company.
The offsite data storage facility or vendor should have a certified data storage site. Data
tapes have different handling and storage requirements than paper.

Once the backup is complete, send the tapes offsite immediately. If there is a data center
disaster and the backup tapes are destroyed, you can only recover to the last full backup
that you have offsite. For log backups, it is critical to send the tapes offsite immediately. If
not, everything since this backup is lost.
2QVLWH

:KDW

Onsite storage means storing your data in the same facility as your data center.

+RZ

Tape cartridges should be properly stored, following the tape manufacturer’s storage
requirements.
The most difficult requirement to comply with is magnetic fields. The problem is
determining if there is a strong magnetic field near the tape storage location. A vacuum
cleaner motor or a large electric motor on the opposite side of the wall from where the data
tapes are stored can generate a magnetic field strong enough to damage tapes.

When storing tape cartridges, keep all related tape cartridges together. All the tapes used in
a daily backup should be considered as a set, comprising backups for:
< Database
< Logs
< Operating system files
Tapes and files in a set need to be restored as a set. For example, if operating system files are
not restored with database and log files, the operating system files will not be in sync with
the database and critical information will be missing.

System Administration Made Easy

3–19
Chapter 3: Backup and Recovery
Performance

3HUIRUPDQFH

The most important performance target is the time required to restore the database. This
determines how long the R/3 system will be down and not available for use. With R/3
down, certain company operations may not occur.
Backup performance is important, especially if the system is global or used 24 hours a day.
When doing a backup, it is important to minimize the impact on users. The key is to reduce
backup time, which in turn reduces the impact on the users.
To increase performance:
1. Identify the bottleneck or device that is limiting the throughput.
2. Eliminate the bottleneck.
Repeat steps 1 and 2 until the performance is adequate or the additional cost is no longer
justified.
This iterative process is subject to cost considerations. Additional performance can always
be purchased, which is almost always a business cost justification exercise.

%DFNXS
All of the backup performance items that follow also apply to restoring the database.
There are three major variables that affect performance:
< Database size
The larger the database, the longer it will take to back up.
< Backup window
The backup window is the time allocated for you to take the regular backups of the
system. This window is driven by the need to minimize the impact on users.
 An online backup
The backup window for this backup type is defined as the time when there are the
fewest users on the system and is usually done early in the morning.
 An offline backup
The backup window for this backup type is defined by when and for how long R/3
can be brought down and is usually done during the weekend.
< Hardware throughput
This variable limits how fast the backup can run and is defined by the slowest link in the
backup chain such as:
 Database drive array
 I/O channel that is used
 Tape drive

Release 4.6A/B
3–20
 Chapter 3: Backup and Recovery
Performance

%DFNXS2SWLRQV
Our backup options assume that the backup device is local to the database server. A backup
performed over a network will be affected by network topology, overhead, and traffic.
Rarely is the full capacity of the network available. If a backup is done over the network, it
will decrease performance for other network users. Although technically possible,
performing a backup over a network is beyond the scope of this guidebook.
%DFN8SWR)DVWHU'HYLFHV
All of the backup options attempt to eliminate the bottleneck at the backup device. The
backup device, usually a tape drive, is the throughput-limiting device.
The table below contains capacity and throughput values to help you plan tape drive
selection:

Type Capacity (GB) Rate (GB/hr)

(native/compressed) (native/compressed)

DAT (DDS-2) 4 / 6.8 1.8 / 3.1

DAT (DDS-3) 12 / 20.4 3.6 / 6.1
DLT 4000 20 / 34 5.4 / 9.2
DLT 7000 35 / 60 18 / 30.6
DLT 8000 40/68 21.6/36.7

The compressed capacity values in this table assume the use of hardware compression and
use a more conservative 1.7x ratio, as opposed to the typical 2x compression ratio. The
actual compression ratio and rate depends on the nature of the file and how much it can be
compressed.
A 20 GB database with only 9 GB of data will only require 9 GB of tape space. As the
volume of data in the database increases, so will the tape space requirement. However, if
you are backing up at the operating system level, the entire file is being backed up.
Therefore, you will need to provide tape space for the entire 20 GB database.
As technology advances, and the capacity and throughput of tape drives increases, these
values will become obsolete. We recommend that you investigate what is currently available
at the time of your purchase.
Advantages:
Faster and larger capacity tape drives allow you to back up an entire database on a single
tape cartridge in a reasonable period of time (for example, a two-hour backup of a 60 GB
database to a DLT7000).

System Administration Made Easy

3–21
Chapter 3: Backup and Recovery
Performance

Disadvantages:
< A backup to a single tape drive is the slowest option.
< Unless an automated changer or library is used, without manually changing the
cartridge, you are limited to the maximum capacity of the tape cartridge.

Not all databases and backup tools support tape changers or libraries; make certain that
these tools are compatible before purchasing them. For example, SAPDBA supports tape
changers, but Microsoft SQL Server Enterprise Manager and NT Backup do not.

3DUDOOHO%DFNXS
Backing up to multiple tape drives uses a RAID-0 (stripe) array, in which several tape drives
are written to in parallel. In certain environments, like Oracle, individual tablespaces or files
are simultaneously backed up to separate tape drives. Because you are writing to multiple
tape drives in parallel, total performance is significantly faster than if you were using a
single tape drive.
With sufficient tape drives in parallel, the bottleneck can be shifted from the tape drives to
another component. You must consider the performance of each subsystem when using tape
drives in parallel. This subsystem includes the tape drive(s), controller(s), CPU, and I/O
bus. In many configurations, a controller or bus is the limiting factor.

To restore a parallel backup, all the tapes in the set must be readable. If one tape is bad, the
entire backup set will not be usable. The more tapes you have in a set, the greater the chance
that one tape will be bad.

%DFNLQJ8SWR'LVNV7KHQWR7DSH
Advantages:
< For the database, this option is the fastest.
Under most situations, you can back up to disk faster than to tape.
< This option allows you to make several identical backup copies (for example, one for
onsite storage and one for offsite storage).
< Once the backup has been made to disk, R/3 System performance is minimally affected.
Because the tape backup is made from the disk copy, and not the live database, the
backup to tape is not competing with database activity for significant system resources.
< During an onsite disaster recovery to the same equipment, the recovery can be done
from the on-disk backup.
Disadvantages:
< Significant additional disk space, up to the same amount of space as the database, is
required.
This additional space makes this option the most expensive, especially for a large
database.
< Until the backup to tape is completed, you are vulnerable to a data center disaster.

Release 4.6A/B
3–22
 Chapter 3: Backup and Recovery
Performance

< In a major disaster recovery, you have to first restore the files to disk, then execute the
database recovery from the files on disk.
This process increases the time to recover the system.
There are other options available for a faster backup, such as the various High Availability
options, but these options are beyond the scope of this guidebook.

5HFRYHU\
The performance requirement for a recovery is more critical than for backup. Recovery
performance determines how quickly the system will be available for use and how soon
business can continue. The goal is to restore the database and related files to make the
system quickly available for general use. The longer this restore takes, the greater the impact
on your business.

5HVWRUH2SWLRQV
To increase database restore performance, all of the above database backup options are
valid. The option also exists to restore to a faster disk array with a higher data-write
throughput.
There are different ways to restore to a faster disk array:
< Dedicated drives
In conjunction with parallel backups, restoring files and tablespaces to individually
dedicated disk drives makes the process faster. Because at any one time, only one
tablespace or file is written to the drive, you do not have head contention writing
another tablespace to the same drive.
< RAID type
Mirrored stripe (RAID 0+1) is faster than RAID5, but this speed depends on the specific
hardware. In most cases, the task of computing the parity data for the parity drive
(RAID5) takes more time than it would to write all the data twice (RAID 0+1). This
option is expensive because the usable capacity is 50 percent of the total raw capacity—
significantly less than RAID5:
 RAID 0+1 = [single_drive_capacity × (number_of_drives/2)]
 RAID5 = [single_drive_capacity × (number of drives – 1)]
< Drives with faster write performance
< Drive array “system” with faster write performance

System Administration Made Easy

3–23
Chapter 3: Backup and Recovery
Useful SAP Notes

8VHIXO6$31RWHV

SAPNet – R/3 Description

Frontend
Note #

0LFURVRIW64/6HUYHU

141118 New Scheduling calendar in the CCMS (DB13) SQL Server 7

102467 Online documentation for SQL Server with SAP
50990 DB-Backup/Restore of Microsoft SQL Server
142731 DBCC checks for SQL Server 7
28667 Microsoft SQL Specific Profile Parameters
128126 Database Connect for external tools
111372 Standby Database for Microsoft SQL 7.0
126808 Configuration Parameter for Microsoft SQL 7.0
25$&/(

68059 SAPDBA - option -next with tablespace list

43499 All collective notes concerning DBA Tools
43491 Collective note: SAPDBA – Command line options
43486 Collective note: General SAPDBA
43484 Collective note: General DBA
42293 SAPDBA - new command line option –analyze
34432 ORA-00020: max number of processes exceeded
31073 SAPDBA - new command lines -next, -analyze
21568 SAPDBA: Warning: only one member of online redo
16513 File system is full—what do I do?
15465 SAPDBA - shrinking a tablespace
04754 Buffer synchronization in centralized systems
03807 Tablespace PSAPROLL, rollback segments too small
02425 Function of tablespaces/DBspaces on the database
01042 ORACLE TWO_TASK connect failed

Release 4.6A/B
3–24