Why Back Up the Database

Split-Mirror Backup

Why Back Up the #SAP's Database?

For large global organizations spanning operations in many countries, a robust Information Technology Infrastructure supporting 24x7 365 days a year has become absolutely necessarily. Non-availability of Information Systems for however short time would cause these organization losses in Millions. The loss of Data due to system failures would even result in closure of these organizations. In such a scenario it is become absolutely necessary to not only have a mechanism to efficiently take Backup of the systems but also to be able to do it without any downtime and performance degradation.

The Split-Mirror technology helps in achieving High Availability of Database, by letting a system quickly take backup, typically in seconds, and it also helps in eliminating the use of System Resources of the Database Server for backing up the database, thus efficiently avoids System degradation (often experienced) while Backups are running.


The Split-Mirror, as the name suggests, is achieved by splitting the Mirror at the Storage (SAN) Subsystem level. Typically this is possible if RAID 10 is configured for storing Data of the Database Server. The tape Backup can be initiated from secondary disks by an agent running in a separate Backup Server. The mirrored disks are resynchronized after the Backup is completed.

In the split mirror configuration, the disks of the production database host are mirrored, that is, synchronized. BRBACKUP runs on a backup database host, where the backup is performed after the mirror disks have been split and mounted. On the production host, this saves processing power otherwise required for the backup, so that the production SAP System is unaffected by the backup.

BRBACKUP can be used to control the splitting and later synchronization of the disks. If you want to open the database on the backup host and use it as a "reporting server" you can perform the synchronization yourself later. The actual splitting and later synchronization of disks is executed by a script or program supplied and supported by the manufacturer of the operating system, disk subsystem, or backup software.

If the split disks do not have to be resynchronized immediately after the backup you can use the backup server along with the mirror disks to operate an independent SAP system on the backup server. For this you must install the entire Oracle server software on the backup server.

Typically the steps are like.

Backup Steps:

1. BRBACKUP connects to the production database on the R/3-Server to set the tablespaces to backup mode (ALTER TABLESPACE ... BEGIN BACKUP). Thus the database is only consistent with the offline redo log files which were created during the begin backup – end backup period.
2. BRBACKUP invokes a script to split the mirrored disks identified by the split_cmd parameter.
3. The split-script includes all actions necessary to access the disks (secondary volumes) with read/write-option set on the Backup-Server (e.g. file system check and mount).
4. BRBACKUP connects to the production database on the R/3-Server to take the tablespaces out of backup mode (ALTER TABLESPACE ... END BACKUP).
5. BRBACKUP does the backup of the tablespaces/data files defined by the parameter backup_mode (e.g. backup_mode=all for a full database backup) directly on the Backup-Server.
6. Optionally, BRBACKUP invokes a script to resynchronize the mirrored disks identified by the resync_cmd parameter

---

Reblogged from MySAPinkPot

More info:

• Split-Mirror Backup and Restore
• Split Mirror Backup
• BRBACKUP
• Common Features of BRBACKUP and BRARCHIVE