Backup Verify

Use

When making database backups, you must regularly perform a verify.

If you fail to verify backups, you might find that a backup cannot be used in the event of a database restore. Even if a backup is reported as successfully completed, this does not mean that it is always error-free.

There are the following types of verify:

• Backup tape readability

This verify checks the backup media (that is, usually tape). It checks the size of the backup files and whether the data can be read. In some cases, it also compares the backed-up data with the contents of the database byte-by-byte.

• Database block consistency

This verify checks the database itself block-by-block.

At least once in every backup cycle, you must perform both types of verify. If possible, perform verify once a week, or even for every backup.

Integration

• You can perform verify at the command level of the
BRBACKUP, BRARCHIVE, and BRRESTORE tools, as described below.
• You can also perform verify using the
action patterns of the DBA Planning Calendar.

Prerequisites

• Verify adds considerably to backup run times.
• Verify is always performed on complete backup volumes. A volume is first written and then verified.

Features

Verify of Backups with BRBACKUP

This type of verify only checks the backup tape readability. The method and extent of a BRBACKUP verify differs according to whether the backup is online or offline:

• Offline backup

After the backup the files are copied back to a temporary directory, compress_dir, and the contents are compared to the original data in the database byte by byte.

• Online backup

After the backup the files are copied back to a temporary directory, compress_dir, but only the readability file sizes are compared. The byte-by-byte compare used in an offline backup is not possible with an online backup because the database is constantly changing as updates continue.

Independent Verify of Backups with BRRESTORE

This type of verify with BRRESTORE only checks the backup tape readability, separately from the backup, at a later time if you want. You can also perform this type of verify on another computer.

BRRESTORE only checks whether the backup can be read and its size, not the contents. The files are only read, not restored.

Verify of Backups with BRARCHIVE

This type of verify with BRARCHIVE only checks the backup tape readability. The extent of the check on archived offline redo log files depends on the type of BRARCHIVE backup:

• brarchive -s|-sc|-ss|-cs

The backed-up files are restored and compared with the originals byte by byte.

• brarchive -sd|-scd|-ssd|-cds

The file sizes of the archived offline redo log files are checked. Since the originals were deleted, a check on the contents is not possible.

Verify of Backups with Oracle DBVERIFY

The Oracle DBVERIFY tool is available for both types of verify, that is, backup tape readability (but without a byte-by-byte comparison) and database block consistency. This means you can recognize errors early (for example, ORA-1578), before they lead to the termination of a program in an application that accesses the blocks.

You can use DBVERIFY as follows:

• Database backup with subsequent restore to a temporary directory (
compress_dir) and check on the Oracle block structure:

brbackup -w use_dbv

• Online check of block structure on the database files without backup:

brbackup -w only_dbv

Any number of these verify processes can run in parallel, using parameter exec_parallel, option -e.

• Temporary restore of a database backup (
compress_dir) and verify of the database block consistency:

brrestore -w use_dbv

The restore implicitly checks the readability of the backup.

Verify of BACKINT Backups

You can verify third-party backups using the BACKINT interface. This function confirms that backups are known to the external backup tool (that is, confirmation) and they are accepted when restoring. In this case there is no physical data check on the backup medium. Only an internal catalog of BACKINT backups of the backup tool is checked (that is, logical verification). Verifications using Oracle DBVERIFY are no longer supported in this context.

If you want to include verification of the internal Oracle block
consistency with DBVERIFY, you can check the database directly without
starting the backup. To do this, call BRBACKUP as follows:

brbackup -w only_dbv

From Release 4.5A, the external backup tool – that is, backup_dev_type = rman_util – can also be accessed using the Oracle Recovery Manager (RMAN). This gives you a complete range of functions for verification:

• The RMAN validate function is used for verifying backups. In this case, data is physically read by the backup medium and checked by RMAN for consistency.
• The verification with DBVERIFY is no longer required because for each backup all saved database files are checked by RMAN for internal Oracle block consistency.

You can also use BR programs from Release 4.5 for RMAN backups for lower SAP releases. Oracle 8.0 is required in this case. For more information, see Note 12741.

Of course, you can perform BACKINT backup verification directly using the backup tool (if supported). Some backup tools offer special parameters in the BACKINT parameter file, init.utl, that you can use to activate the verification independent of the BR option -w|-verify. For additional information, consult your BACKINT provider.

BRBACKUP and BRARCHIVE Backups in One Run

Use

You can execute the database backup using BRBACKUP and the backup of the offline redo log files using BRARCHIVE in a single run. You can use this option to make more effective use of the increasing capacity of storage devices, such as tapes and disks. It also makes an unattended backup easier, since after a backup with BRBACKUP, the BRARCHIVE run is started automatically. You can now perform this procedure in the DBA Planning Calendar of the Computing Center Management System (CCMS)

There are the following options for performing the backup in one run:

• BRBACKUP starts BRARCHIVE, using
brbackup -a. For tape backups, the tapes are managed by BRBACKUP. For more information, see -a|-archive.
• BRARCHIVE starts BRBACKUP, using
brarchive -b. For tape backups, the tapes are managed by BRARCHIVE. For more information, see -b|-backup.

We recommend the first option (brbackup -a). For tape backups, BRBACKUP uses the tapes defined in volume_backup. To execute the backup, BRBACKUP:

• Checks the volume label
• Backs up the tape header files (
.tape.hdr0, init_ora, init_sap)
• Backs up the database files (but does not save logs)
• Calls BRARCHIVE

Then BRARCHIVE:

• Writes the offline redo log files to tape after the backed-up database files (without checking the label and without header files)
• Backs up all logs (that is, for BRBACKUP and BRARCHIVE)

This is an example of a BRBACKUP command for unattended online backup with two tape devices. The database files are backed up first and then the offline redo log files are copied to the same tapes.

brbackup -m all -t online -c -a -ssd -c

For more information, see BRBACKUP command -a|-archive.

If you run the tape administration using brarchive -b, the tapes defined in volume_archive are used. The only change to the backup is the sequence in which the data files and the offline redo log files are written to tape. In this case the logs are backed up by BRBACKUP at the end.

This is an example of a BRARCHIVE command for offline backup with one tape device. The offline redo log files are backed up on tape first and then the database files are copied to the same tape.

brarchive -sd -c -b -t offline -c

For more information, see BRARCHIVE command -b|-backup.

You can also perform a combined BRBACKUP and BRARCHIVE run to several tape devices in parallel. For more information, see Parallel Backup.

Starting BRBACKUP and BRARCHIVE in sequence with BACKINT, or to disk, only means that BRBACKUP and BRARCHIVE run together. It does not automatically mean that the backup is made to the same volume. If you are using BACKINT, you can do this with BACKINT tools in some situations.

Unattended Backup

Use

With BRBACKUP and BRARCHIVE, you can back up your Oracle database without monitoring or operator intervention. How you do this depends on your operating system. For more information on backup with Microsoft Windows, see BRBACKUP/BRARCHIVE.

Features

Unattended Parallel Backup

You can make unattended backups if you have enough backup devices. This means that you need as many backup devices as volumes are required for the backup. BRBACKUP can then back up to these devices in parallel, without operator intervention to change the volumes. For more information, see Parallel Backup.

Automatic Tape Changers

If you want to use automatic tape changers, you must define the rewind_offline parameter appropriately and set backup_dev_type to tape_auto or pipe_auto. For more information, see Backup with Automatic Tape Changers.

Serial Backup

Unattended backup is also possible if fewer parallel copy processes than connected backup devices are possible (for example, due to the impact on performance). To do this, set the parameter exec_parallel to 1. If you need several volumes for a backup, the backup devices are not used in parallel. In this case they are used in accordance with the number of copy processes set.

To make a parallel or serial backup on several tape devices, you must define the addresses of the backup devices in the following init.sap parameters:

• 
  
tape_address
• 
  
tape_address_rew
• 
  
backup_root_dir for a local disk backup
• 
  
stage_root_dir for a remote disk backup

Here is an example of these parameters:

tape_address = (dev/rmt/0mn, /dev/rmt/1mn)
tape_address_rew = (dev/rmt/0m, /dev/rmt/1m)

Backups with BRBACKUP or BRARCHIVE in One Run

The complete backup of the database files and the offline redo log files can be executed with a single start of BRBACKUP, using command option -a|-archive.

For more information, see BRBACKUP and BRARCHIVE Backups in One Run.

Backup with CRON

For a successful unattended backup using CRON, you must meet the following requirements:

• The parameters in
init.sap must be set correctly.
• The Crontab entries must be defined under user
root.
• BRBACKUP or BRARCHIVE must run under database user
ora or the operating system user adm. The advantage of the adm user is that no password is needed, due to the OPS$ mechanism. This means that no password can be seen in a script.
• Enough volumes (for example, tape or disk volumes) must be available, as well as a sufficient number of backup devices (if you want to perform a parallel backup).
• The correct tapes must be mounted in the backup devices. The operator cannot change the tapes during the backup run.

If automatic tape management is active, first determine the tape names by entering the commands brbackup|brarchive -q.

Use brbackup|brarchive -q check to verify that the required volumes were actually mounted.

For more information, see brbackup -q and brarchive -q.

If automatic tape management is not active, mount tapes for which the expiration period has passed.

Examples

Online backup of the complete database

Unattended operation

Daily, Monday through Friday

Backup to start at 22:00

#Min(0-59) Hrs (0-23) Day (1-31) Mon(1-12) WD (0-Sun,...,6-Sat)

00 22 * * 1-5

su - ora -c "brbackup -t online -c force -u"%system/

or under adm:

su - adm -c "brbackup -t online -c force -u /"

Offline backup of the complete database

Unattended operation

Daily, Monday through Friday

Backup to start at 22:00

R/3 System shut down

#Min(0-59) Hrs (0-23) Day (1-31) Mon(1-12) WD (0-Sun,...,6-Sat)

00 22 * * 1-5

/backup1.sh

The script backup1.sh in the root directory might look as follows:

su - adm -c "stopsap R3"

su - ora -c "brbackup -t offline -c force -u" <

system/

END

su - adm -c startsap

Offline backup of the complete database

Unattended operation

Daily, Monday through Friday

Backup to start at 22:00

No R/3 System shut down

#Min(0-59) Hrs (0-23) Day (1-31) Mon(1-12) WD (0-Sun,...,6-Sat)

00 22 * * 1-5

/backup2.sh

The script backup2.sh in the root directory might look as follows:

su - ora -c "brbackup -t offline_force -c force -u" <

system/

END

Archiving the offline redo log files

Unattended operation

Daily, Monday through Friday

Backup to start at 08:00

Parallel archiving to two backup devices.

#Min(0-59) Hrs (0-23) Day (1-31) Mon(1-12) WD (0-Sun,...,6-Sat)

00 8 * * 1-5

su - ora -c "brarchive -ssd -c force -u"%system/

Parallel Backup

Use

You can use BRBACKUP and BRARCHIVE to back up your Oracle database to several backup devices in parallel. The backup devices can be tape or disk drives. Parallel backup reduces the backup time and allows unattended operation (that is, backup in unattended mode).

Parallel backup is especially useful for large databases. For more information, see Parallel Backup of Large Databases to Disk with BRBACKUP.

Features

• Parallel backup is possible to local or remote backup devices.

• If the backup devices used support hardware compression, use this by setting the
init.sap parameter compress = hardware. You can also make parallel backups with software compression, using compress = yes. For more information, see compress.
• When you perform parallel backups to several backup devices, BRBACKUP attempts to optimize the distribution of the database files among the backup volumes using load balancing, as follows:

• BRBACKUP attempts to balance the load equally among all the backup devices, which is called time optimization. If this is not possible, it attempts to divide the dataset equally among the individual backup devices, which is called size optimization.
• Whenever possible, BRBACKUP saves files from one disk on one volume in one backup device, in order to minimize drive head movement during the backup.

• BRARCHIVE only uses the parallel backup option to tape when you start archiving with
brarchive -ss or brarchive -ssd. In this case, the offline redo log files for archiving are saved to both volumes in parallel (or saved and then deleted). For more information, see -s|-sc|-ds|-dc|-sd|-scd|-ss|-ssd|-cs|-cds.

• The addresses of the tape devices are defined in the following
init.sap parameters:

• 
  
tape_address
• 
  
tape_address_rew
• 
  
tape_address_arch
• 
  
tape_address_rew_arch

• If the
-ss or -ssd option is used, BRARCHIVE only uses the first two tape devices in the list. The addresses of the directories on disk are defined in the init.sap parameter backup_root_dir or stage_root_dir.

This is an example of the entries required in the init.sap initialization profile for parallel backup:

• Device type:
  
backup_dev_type = tape|disk|pipe|stage
• Addresses for tape devices:
  
tape_address = (/dev/rmt/0hnc, /dev/rmt/1hnc)
tape_address_rew = (/dev/rmt/0hc, /dev/rmt/1hc)
• Addresses for directories on hard disk:
  
backup_root_dir = (/backup/dir1, /backup/dir2)
• Compression parameters:
  
compress = no|software|hardware
• Tape size:
  
tape_size = 18G|16G

• The number of parallel copy processes normally corresponds to the number of backup devices available. You can change this setting with the
init.sap parameter exec_parallel or the command option -e|-execute.

Parallel Backup

Use

You can use BRBACKUP and BRARCHIVE to back up your Oracle database to several backup devices in parallel. The backup devices can be tape or disk drives. Parallel backup reduces the backup time and allows unattended operation (that is, backup in unattended mode).

Parallel backup is especially useful for large databases. For more information, see Parallel Backup of Large Databases to Disk with BRBACKUP.

Features

• Parallel backup is possible to local or remote backup devices.

• If the backup devices used support hardware compression, use this by setting the
init.sap parameter compress = hardware. You can also make parallel backups with software compression, using compress = yes. For more information, see compress.
• When you perform parallel backups to several backup devices, BRBACKUP attempts to optimize the distribution of the database files among the backup volumes using load balancing, as follows:

• BRBACKUP attempts to balance the load equally among all the backup devices, which is called time optimization. If this is not possible, it attempts to divide the dataset equally among the individual backup devices, which is called size optimization.
• Whenever possible, BRBACKUP saves files from one disk on one volume in one backup device, in order to minimize drive head movement during the backup.

• BRARCHIVE only uses the parallel backup option to tape when you start archiving with
brarchive -ss or brarchive -ssd. In this case, the offline redo log files for archiving are saved to both volumes in parallel (or saved and then deleted). For more information, see -s|-sc|-ds|-dc|-sd|-scd|-ss|-ssd|-cs|-cds.

• The addresses of the tape devices are defined in the following
init.sap parameters:

• 
  
tape_address
• 
  
tape_address_rew
• 
  
tape_address_arch
• 
  
tape_address_rew_arch

• If the
-ss or -ssd option is used, BRARCHIVE only uses the first two tape devices in the list. The addresses of the directories on disk are defined in the init.sap parameter backup_root_dir or stage_root_dir.

This is an example of the entries required in the init.sap initialization profile for parallel backup:

• Device type:
  
backup_dev_type = tape|disk|pipe|stage
• Addresses for tape devices:
  
tape_address = (/dev/rmt/0hnc, /dev/rmt/1hnc)
tape_address_rew = (/dev/rmt/0hc, /dev/rmt/1hc)
• Addresses for directories on hard disk:
  
backup_root_dir = (/backup/dir1, /backup/dir2)
• Compression parameters:
  
compress = no|software|hardware
• Tape size:
  
tape_size = 18G|16G

• The number of parallel copy processes normally corresponds to the number of backup devices available. You can change this setting with the
init.sap parameter exec_parallel or the command option -e|-execute.

Structure-Retaining Database Copy

Use

With BRBACKUP you can make a copy of the Oracle database files with exactly the same directory structure. You can use this type of database copy to:

• Generate a test system from a production system
• Set up a
Standby Database.
• Have a database backup available that saves you the restore during a recovery. In this case the Oracle Home directory is renamed as the new Oracle Home directory of the database copy. The copied files are then the current files and you can apply the offline redo log files directly.
• Change the location of the database files. Database copy is the only way of moving database files between the file system and raw devices using BRBACKUP.

Prerequisites

You must create the following directories on the target database:

• sapdata
directories
• sapbackup
directory
• origlogA
, origlogB, mirrlogA, mirrlogB directories of the online redo log files

The corresponding subdirectories are created automatically during copying.

/oracle/C11/sapdata2/stabd_1/stabd.data1 is copied to
/oracle/C12/sapdata2/stabd_1/stabd.data1

Since this is a one-to-one copy, software compression is not possible.

Activities

To copy the database, you have to define the name of the new database home directory (of the database copy) in the init.sap profile parameter new_db_home (for local disks) or stage_db_home (for remote disks). Also set the parameter backup_dev_type to disk_copy|disk_standby|stage_copy|stage_standby or call up BRBACKUP with the relevant command option, for example, brbackup -d|-device disk_copy.

Under Windows, the sapdata directories can be distributed across several drives. When you make the copy, you can retain this distribution by specifying the appropriate target drives. For more information, see the BRBACKUP parameter m|-mode.

Two-Phase Backup

As an alternative to a direct Oracle backup to tape you can perform a two-phase backup with full support from BRBACKUP or BRARCHIVE. This backup strategy enables you to easily make a disk backup, as well as having several copies of this and previous backups available. For a recovery, SAPDBA can, in this case, access the disk backup directly. If a restore from tape is required, the files are directly copied to the original directories by BRRESTORE.

You can also perform the second phase of the two-phase backup with external tools – that is, backup programs, operating system tools, and so on. In this case, you have full responsibility for the complete and correct execution of this phase.

You can not use the BACKINT interface to copy backups from raw devices or compressed disk files to tape. If you use raw devices or compressed disk files, you must save directly to tape.

Features

Two-Phase Database Backup with BRBACKUP

• Phase 1

BRBACKUP backup to disk

• Phase 2

BRBACKUP backup from disk to tape

• Restore phase

BRESTORE restore from tape directly to the original directories or BRRESTORE from the disk to the original directories

To back up to tape (phase 2), start BRBACKUP with the relevant command option. For more information, see -b|-backup.

Features of Two-Phase Database Backup with BRBACKUP

Advantages

Disadvantages

The first phase can be much shorter than a direct backup to tape. In the case of a recovery the restore phase is shortened, if the backup is directly available on disk. When restoring from tape, BBRESTORE can write the backed up files directly to the original directories. Volume management and all other automatic actions of BRBRACKUP can be fully used in the second phase.

The hardware requirements (that is, disk storage and storage tapes) must be fulfilled. Additional disk storage space is required, compared to a direct tape backup. You must start BRBACKUP twice for a two-phase backup. The backup type – that is, offline or online – and the extent of the backup – that is, complete or partial – must be identical in the first and second phases. In an offline backup the database remains open in the second phase.

Two-Phase Backup of Offline Redo Log Files with BRARCHIVE

Two-phase backup of the offline redo log files using BRARCHIVE runs analog to the BRBACKUP backup. However, you can only make a maximum of two copies to tape. We strongly recommend you to back up the offline redo log files to tape, in addition to a disk backup.

• Phase 1

BRARCHIVE backup to disk

• Phase 2

BRARCHIVE backup from disk to tape

• Restore phase

BRRESTORE restore from tape directly into the original directories or direct import of offline redo log files in an SAPDBA recovery from disk (no restore).

To perform the BRARCHIVE backup of the offline redo log files to a volume start BRARCHIVE with the appropriate command option. For more information, see -a|-archive.

Features of Two-Phase Backup of Offline Redo Log Files with BRARCHIVE

Advantages

Disadvantages

The first phase can be much shorter than direct backup to tape, so that the SAPARCH directory is emptied more quickly. In a recovery, the restore phase can be much shorter, if the backup of the offline redo log files is directly available on disk. In this case SAPDBA uses the offline redo log files directly from the disk. There is no restore. When restoring from tape, BBRESTORE can write the backed-up offline redo log files directly to the SAPARCH directories. The volume management of BRARCHIVE can be fully used in the second phase of the backup.

A maximum of two copies of the offline redo log files can be backed up to tape, regardless of the way in which the offline redo log files are backed up: directly to tape or with a disk backup. Additional storage space and storage tapes are required. You must start BRARCHIVE twice for a two-phase backup.

Backup to a Remote Tape Device

With BRBACKUP and BRARCHIVE you can back up files of the Oracle database to a remote tape device that is connected to a UNIX host in the network. You can use several tape devices on the remote host for backup and these are used in parallel.

The UNIX versions of the local and remote hosts need not be identical. For example, if the database runs on an HP-UX host, you can perform the backup on an AIX host.

We only recommend remote backup when your network is very fast and stable. Therefore, we do not recommend this procedure for production systems in most cases. However, you can use it to back up test systems.

Prerequisites

• Make sure that no additional messages (that is, not belonging to command output) are issued on remote login (for example, from
.login or .cshrc). Test the command remsh|rsh date.: only one line with the output of the date command should be displayed.

• For a successful remote shell call, check that there is an entry as follows in the
.rhosts file, which is in the HOME directory of the remote operating system user on the remote host:

where:

is the host where the database runs

is the operating system user who starts the backup

For more information, see your operating system documentation.

Activities

The individual database files are transferred to the remote host using a remote shell call, called a "pipe." You define the remote host with the init.sap parameter remote_host and the user with the remote_user parameter.

On the remote host the files are written to tape using the UNIX dd command. You define the dd command in the profile init.sap, as in the following example:

copy_in_cmd = "dd bs=64k if=$"

copy_out_cmd = "dd bs=64k of=$"

The number of parallel copy processes normally corresponds to the number of backup devices available. You can change this setting with the init.sap parameter exec_parallel or the command option -e|-execute.

Backup to a Remote Disk

You can perform an Oracle backup to a remote disk directly with BRBACKUP or BRARCHIVE, or as part of an incremental backup using the Oracle Recovery Manager (RMAN).

We only recommend remote backup when your network is very fast and stable. Therefore, we do not recommend this procedure for production systems in most cases. However, you can use it to back up test systems.

Prerequisites

• The target directories for the backup defined in the parameter
stage_root_dir and archive_stage_dir must exist on the remote host.
• The name of the remote host and the relevant user must be specified in the initialization profile with the parameters
remote_host and remote_user.
• If you use FTP as the transmission program, a password is needed for the remote host. Do one of the following for this:

• Specify the password in the
remote_user parameter.

remote_user = " "

• Use the password of the BRBACKUP database user, which happens if you do not explicitly specify a password. Make sure that the password of the operating system user is the same.

• No password is needed if you use the RCP command for the remote disk backup. A prerequisite for a successful RCP call is, for example, the following entry in the
.rhosts file, which is in the HOME directory of the remote user on the remote host:

For more information, see your operating system documentation.

Features

Remote Disk Backup with BRBACKUP

A remote disk backup removes the need for a Network File System (NFS) disk mount, if the backup is across the network. The NFS protocol is relatively insecure, which means that the backup must be verified. In contrast, RCP and FTP are relatively secure ways of transferring data over the network, which means that you do not have to verify the backup.

You need to meet the prerequisites above and make the following entries in the initialization profile init.sap:

backup_dev_type = stage|stage_copy|stage_standby
stage_copy_cmd = rcp|ftp

A remote backup to disk is particularly useful with the standby database and hierarchical storage management systems.

Incremental Remote Backup with RMAN

You can use RMAN to perform an incremental disk backup of a remote host.

You need to meet the prerequisites above and make the following entries in the initialization profile init.sap:

backup_dev_type = stage
backup_mode = incr

FTP is always used automatically as the transmission program for incremental backup to remote disk.

Backup to Multiple Disks

You can use BRBACKUP for Oracle backup to multiple disks if the space available on one disk or logical volume is not sufficient.

To do this, you use the init.sap profile parameter backup_root_dir to specify the directories on the different disks where you want to save your database files.

This is an example of the entries required in the init.sap initialization profile for parallel backup:

• Device type:
  
backup_dev_type = disk

• Backup directories:
  
backup_root_dir = (/backup/dir1, /backup/dir2)

• Compression parameters:
  
compress = no|yes

BRBACKUP normally uses all the directories specified in backup_root_dir in parallel to back up the database files. The number of copy processes corresponds to the number of disks. Since BRBACKUP attempts to optimize the speed of the backup, all the hard disks specified in backup_root_dir are written to, except if the number of files you want to back up is smaller than the number of disks. You can change this setting with the init.sap parameter exec_parallel or the command option -e|-execute.