Created: August 11, 1997
Last Updated June 5, 1998
Version 3.0

1.1  EMC/Symmetrix ICDA

The EMC/Symmetrix Integrated Cached Disk Array (ICDA) is a complex disk array device, combining a set of industry-standard physical disks, a number of Fast/Wide SCSI channels, a certain amount of internal cache memory and sophisticated control and diagnostic software executing inside the ICDA – commonly referred to as the microcode.

All data flow between the SCSI channels (through which the client host computers are connected to the ICDA) and the physical disks inside the ICDA is routed through the internal ICDA cache and controlled by the microcode. This allows the ICDA to implement the notion of logical devices (further: Symmetrix logical devices, SLDs) which are internally mapped to a whole or only a portion of a physical disk by the ICDA microcode and cache.

Each configured Symmetrix logical device (SLD), possibly referring to a partition of a physical disk inside the ICDA, is ‘exported to’ (made accessible through) one Fast/Wide SCSI port, and is presented by the ICDA to the host computer as a physical volume. The host computer thus never sees the actual physical disks inside the Symmetrix – it believes that the SLDs are actually physical volumes! The ICDA maps (routes) all host computers' read/write requests to a SLD to the proper physical disk transparently at run-time, at virtually no performance degradation.

This concept of logical devices (SLDs) enables the Symmetrix ICDA to achieve high performance and reliability by implementing RAID-1 and EMC’s version of RAID-5 (called RAID-S). All Symmetrix features and operations described in this document (i.e. SRDF, TimeFinder, BCVs, split/establish of mirrors, etc.) are based on and operate on Symmetrix logical devices.

As already mentioned, an SLD is exported (by the ICDA) to a certain Fast/Wide SCSI port, and thus has a certain SCSI target ID and LUN. This SLD is detected by the host computer sharing the same SCSI bus, and is believed to be a physical volume (disk). The possibility of an SLD mapping to a partition of a physical disk inside the ICDA is not visible and has no significance to the host computer.

The customer can decide to configure and export several different SLDs – and connect them to the same or to different host computers. On the other hand, the ICDA can export the same SLD to more than one SCSI port, which means that two different host computers (or even the same) can be connected to the same SLD and potentially share it. As a matter of fact, up to 32 connections can be established this way.

The configuration of the Symmetrix ICDA – mapping partitions of physical disks to SLDs inside the ICDA, exporting SLDs to SCSI ports, and how different SLDs are connected to different host computers can obviously become quite complex, and is thus necessarily customer- and application specific.

An additional layer of complexity is added through the introduction of the HP-UX Logical Volume Manager (further: LVM). Since SLDs are viewed by the host computer as physical volumes, it is quite possible (and very probable) that they would be used to build a hierarchy of LVM logical volumes and LVM volume groups. On top of this LVM structure, the customer could build filesystems or databases to support mission-critical applications.

1.1.1  EMC/Symmetrix SRDF

The Symmetrix Remote Data Facility (SRDF) is a business continuation process that enables effective, real-time data replication between dislocated processing environments. These environments could be situated within the same computer room or separated by long distances. Essentially, two EMC/Symmetrix ICDA boxes are connected with multiple ESCON connections and configured to replicate (mirror) the contents of selected SLDs in real-time.

In an uni-directional configuration, selected SLDs in a designated primary (source) ICDA are mirrored to equivalent SLDs in the secondary (target) ICDA. The mirrors are maintained in a synchronized state by the SRDF protocol between the two Symmetrix ICDAs – transparent and unknown to the host computer operating on the primary SLDs, and with very limited performance degradation. The two Symmetrix ICDAs can be physically dislocated – the current ESCON implementation allows distances of up to 60km. However, connecting Symmetrix boxes using E-3 or T-3 lines, distances can be extended to any required extent.

This configuration provides excellent disaster recovery benefits – should the primary Symmetrix ICDA fail for any reason (i.e. earthquake, flood), a stand-by host computer connected to the secondary Symmetrix ICDA can resume operation almost instantaneously, since all critical data is already available on the SLDs in the secondary ICDA.

Please note that not all SLDs existing in the primary ICDA have to be mirrored via SRDF – it is up to the customer to decide which SLDs should be replicated. If a primary SLD is SRDF-mirrored to a secondary SLD, and the SRDF is operational, then the secondary SLD is forced into a read-only mode – its contents cannot be modified directly through an attached host, and it is essentially a read-only mirror of the primary SLD. However, suspending the SRDF link between the primary and secondary SLD will make it possible to switch the secondary SLD to read/write mode.

In a bi-directional configuration, both Symmetrix ICDAs contain primary as well as secondary SLDs. Some SLDs are mirrored from ICDA #1 to ICDA #2 and some vice versa. Both ICDAs are thus primary and secondary at the same time, on an SLD-to-SLD basis.

The SRDF logical connection (ongoing synchronization) between a primary SLD and its mirror (the secondary SLD) can be temporarily suspended and resumed under software control. If a link between a primary SLD and its mirror remains suspended for a certain period of time, the SRDF protocol is not able to maintain the synchronization of the two SLDs. However, as soon as the logical link is resumed, the SRDF mechanism automatically re-synchronizes both SLDs, either by updating the secondary SLD with incremental data from the primary SLD (thus preserving any changes on the primary SLD) or the other way around, thus discarding any changes which occurred on the primary side while the logical SRDF link was suspended. Both Symmetrix ICDAs executes this process transparently, without the knowledge of attached host computers and with minimal performance impact.

Please note that suspending/resuming logical SRDF links operates on a per-SLD basis – logical SRDF links between selected SLDs can be suspended/resumed without affecting existing logical SRDF links between other SLD pairs on the primary and secondary side.

The commands that are used to control logical SRDF connections are part of the SymmScript SRDF package provided by EMC. Exactly these SymmScript commands are used by OmniBack II to interface with the Symmetrix ICDA and control the SRDF mechanism.

1.1.2  EMC/Symmetrix TimeFinder

The Symmetric Multi-Mirror Facility (TimeFinder) is a business continuation process that creates an instant copy of a single or multiple Symmetrix logical devices, but inside a single Symmetrix ICDA. The instant copy is created on local SLDs called Business Continuation Volumes (BCVs) and is accessible to the host computer(s) via separate SCSI ports when it is detached from the original SLD.

Essentially, certain SLDs are pre-configured to serve as BCVs – as dynamically attachable mirrors of other SLDs in the same Symmetrix ICDA. ‘Dynamically attachable’ indicates that a BCV can be attached to a selected SLD (thus effectively operating as its mirror inside the same ICDA), or it can be detached and

attached to another SLD under software control. It is straightforward that a BCV can serve as a mirror only for SLDs that are of equal size.



A BCV maintains the profile of the most recent SLD to which it was attached. If it is re-attached to the same SLD after a certain period of time, it will automatically re-synchronize its contents with the SLD by copying incremental information either from the SLD to the BCV (thus preserving the SLD’s data) or vice versa, discarding the SLD’s contents. This synchronization process is executed by the ICDA internally, without the knowledge of the host computer operating on the SLD and with minimal performance impact.

If a BCV is attached to a completely new SLD, a complete replication (as opposed to the incremental described above) of either disk will be performed – with some performance penalties in terms of Symmetrix ICDA response time.

Please note that, while attached, a BCV is not accessible through the SCSI port it is exported to, not even for read-only access. It becomes accessible as soon as it is detached from its SLD.

Attaching/detaching BCVs to SLDs within a single Symmetrix ICDA can be performed on a per-BCV basis, and under software control. Again, the SymmScript package mentioned in the SRDF section provides the necessary commands to interface with the ICDA and control the BCVs from OmniBack II.

 

1.2  HP Openview OmniBack II

The HP OpenView OmniBack II product is a reliable, high-performance data management solution used for powerful backup and restore of mission-critical applications and data resources in large, distributed heterogeneous enterprise environments. OmniBack II uses the concept of backup environments. Each backup environment consists of a central backup manager, multiple distributed backup device servers, backup agents and application agents. Typically such a backup environment with its specific policies is adapted to a logical part of an organizational structure in the enterprise.

This document assumes that the reader is familiar with OmniBack II architecture and functionality to a certain level. For a deeper understanding and a more detailed level of OmniBack II features and architecture, please refer to the regular OmniBack II product documentation.

1.2.1  Mixed backup environment

Typically, one backup environment consists of multiple backup device servers and agents, one media management and one backup information database and various devices, which can be shared among systems. This entire backup environment is managed effectively by one backup manager.

1.2.2  Manager of Manger (MoM)

For central management of multiple backup environments, OmniBack II allows to consolidate the various individual environments to be centrally managed from one single point through the Enterprise Backup Console with its new Manager-of-Manager feature. This concept allows for a transparent central management of thousands of nodes, and enables easy implementation of a consistent enterprise-wide backup strategy. This strategy can be adapted to the organizational needs while still allowing for flexible management of the individual site.

This powerful and unique multi-cell management feature enables users to administer a group of cells as one homogenous entity from one single point, thus being able to handle largest environments efficiently, and to be able to better adopt to organizational needs. The MoM concept allows for central management and control for one group of cells via LAN or WAN, also providing for a homogenous view on datalists and schedules, multi-cell reporting, centralized licensing, and support of central media management for up to twenty cells.

Utilizing the MoM feature, one cell acts as the manager cell that is capable of handling additional tasks, and the other cells run as "client" cells. Thus, policies can be defined centrally and downloaded to individual backup environments, while at the same time corporate standards are established. Furthermore, administrators can offer end-user restore capabilities, which will result in empowered end users and in a reduction on the administrator load.

Users will also be able to take advantage of effective and powerful centralized device and media management. All media of multiple backup environments can be tracked and managed with a single, central media management database. This allows for restore of data from one backup environment into another backup environment, sharing of large tape silos, e.g., StoreageTek silos, across multiple OmniBack II backup cells (multi host connectivity), easy and efficient move of media from one backup environment to another (for example remote site), and vaulting and disaster recovery procedure support.

1.2.3  Backup and Restore

OmniBack II offers automated and reliable network backup and restore, allowing for different backup strategies, such as backup on the host level as a full or incremental backup, or backup of single disks or logical volumes, while backup operations can be customized according to the specific needs. For backup, datalists need to be defined which group the objects to be backed up (see chapter 1.4.2 for further information), and the backup sessions will then be started upon user request or by the scheduler. Multiple systems can be backed up simultaneously onto one or multiple backup devices. This parallelism is also available for restore operations. However, for restore the objects to be restored need to be defined for each session and can not be predefined. Depending on the type of backup that was performed, OmniBack II offers filesystem restore, restore of a raw backup or single file restore from a raw backup.

OmniBack II implements three different backup/restore paradigms – RawDisk, FileSystem and DataBase backup/restore. The integration with EMC’s SRDF and TimeFinder technologies adds an additional dimension, offering powerful new point-in-time backup opportunities for mission-critical data processing environments.

 

 

1.2.3.1  RawDisk Backup/Restore

To configure a rawdisk backup object in an OmniBack II datalist, it is necessary to specify the hostname of the computer where this disk is connected and its character device file. OmniBack II allows the user to specify both character device files of physical volumes (i.e. /dev/rdsk/c0t0d0) and those of logical volumes (i.e. /dev/vg00/rlvol1) – it is up to the customer to decide which interface to use.

If a raw logical volume (further: RLV) is configured, it will be backed up as a stream of bytes, without the specific information how this logical volume maps to physical volumes at backup time. At restore time, this backup image can be restored either to its original location, or to any other host or volume in the OmniBack II backup cell, providing that the capacity of the target volume matches the size of the backup image. Please note that a rawdisk (physical or logical) is always backed up completely by OmniBack II.

It is important to realize that any LVM related information has to be recreated manually before the image is restored, as OmniBack II does not record the layout and mapping of logical volumes at backup time. Also, if a specific rawdisk is formatted and mounted as a filesystem (but the storage administrator still wishes to back it up as a rawdisk), then it is the responsibility of the administrator to ensure that the rawdisk is in a consistent state – (not in use, i.e. mounted) at backup time. For this specific case (a rawdisk containing a mounted filesystem), OmniBack II will issue a warning, but still proceed with the backup.

1.2.3.2  FileSystem Backup/Restore

To configure a filesystem backup object in an OmniBack II datalist, it is necessary to specify the hostname of the computer where this filesystem exists, and its UNIX mountpoint. OmniBack II does not care if this filesystem is built on a physical or logical volume – it uses the standard POSIX filesystem API to traverse the filesystem and backup files and directories. Though the backup object is called a filesystem and defined in OmniBack II through its mountpoint, it is possible to specify which areas of the filesystem (i.e. directories, files) should be included or excluded from the backup.

As opposed to rawdisk backup objects, filesystems can be backed up incrementally. OmniBack II offers a sophisticated scheme of incremental backup levels, which allows the administrator to define incremental backup policies. The backup level (full, incremental) is defined as part of the scheduling information for a complete datalist and inherited by each individual filesystem object within it. However, incremental backup does not apply to rawdisk backup objects – they are always backed up completely.

A backup image created by backing up a filesystem backup object thus contains files and directories – which can be restored individually, either to the original or to a new location anywhere in OmniBack II cell. OmniBack II uses an embedded database to maintain a certain amount of metadata about each single file or directory backed up, along with the exact position of each object on tape. This enables OmniBack II to quickly restore any single file or directory on demand – a feature that is not available if a filesystem is backed up via its rawdisk interface as described above.

1.2.3.3  Database Backup/Restore

With OmniBack II, databases can be backed up in more than one way. The classic approach is to shutdown the database (can be any commercial database), perform a backup of all disks occupied by the database, either using rawdisk or filesystem backup objects, and subsequently restart the database. This approach, although quite simple and robust, has several disadvantages – a long database downtime while the backup operation is in progress, and no partial backup/restore of database objects (i.e. tables and tablespaces). However, with the integration of Symmetrix SRDF and/or TimeFinder and OmniBack II, these disadvantages will be powerfully resolved.

OmniBack II provides this functionality through the mechanism of session (datalist) pre- & post-processing commands, which can be used to shutdown and restart the database. Since these commands are database- and environment-specific, they have to be created and maintained by the backup administrator. The configuration of such a backup environment is simple, however – the backup administrator creates a datalist containing rawdisk or filesystem objects (on which the database resides), adds pre- & post-processing commands to shutdown/restart the database, and schedules the datalist for later execution.

However, this simple solution is not an option if an extended downtime of the database is not acceptable, or if a partial backup/restore of database entities is desired. For such more sophisticated online backup solutions, OmniBack II offers an online backup integration with backup tools for specific databases, i.e. Oracle/EBU. Informix/OnBar, and SAP R3/brbackup, MS Exchange, MS SQL, and with EMC SRDF and TimeFinder.

These integrations are based on OmniBack's ability to accept formatted data from the databases’ backup tools via a well-defined API. The database backup tools, well aware of the internal complexity of the particular database and capable of performing backup while the database is online and processing transactions, traverse the database’s internal data structures and send all data to be backed up to OmniBack II, which stores the data received on normal OmniBack II backup media.

On the OmniBack II side, these more sophisticated online database backup solutions are configured and executed using OmniBack’s barlist mechanism – which largely parallels the datalist functionality already described. A barlist, just like a datalist, is an OmniBack II configuration file which contains a generic client statement instead of standard rawdisk and filesystem backup objects, and a set of OmniBack II logical devices (backup target devices, i.e. tape drives) which are to be used for backup.

The barlist describes which command on which host computer in the network should be started in order to initiate the online database backup, i.e. ‘obackup’ for Oracle databases. Just like datalists, barlists can also be scheduled and executed - the major difference is that an application-specific command is invoked to perform the backup, rather than a set of OmniBack’s Disk Agents, as for the datalist’s rawdisk and filesystem backup objects. However, the decisions, which database backup mechanism to use, are left to each customer individually.

Based on an easy to use GUI, OmniBack II offers an sophisticated GUI for database integration , enabling users to easily configure backup, schedule and restore all databases in the entire enterprise from one single point.

1.2.4  OmniBack II Datalists

OmniBack II uses the notion of a "datalist" to configure and execute repeatable backup jobs. A datalist is a configuration file, which contains descriptions of backup objects, which need to be backed up and target backup devices, which should be used for backup. Target backup devices (i.e. tape drives) are called OmniBack II logical devices in OmniBack II terminology (further: OB2LD) – not to be confused with Symmetrix logical devices (SLDs) already introduced.

Besides datalists, OmniBack II also uses so-called "barlists", which are equivalent, but used to configure and execute backups of applications and databases whose data format is not known to OmniBack II. The barlist mechanism is described in section 1.2.4 "DataBase Backup/Restore".

A single datalist may contain two types of backup objects – rawdisk or filesystem entries. Their character device file references Rawdisk objects, and filesystem objects are referenced by their mountpoint. The execution of a datalist results in an OmniBack II backup session, which is managed by a single OmniBack II Backup Session Manager (further: BSM) process.

The OmniBack II datalist is a powerful tool – multiple datalists can be configured and processed in parallel or scheduled for regular periodic execution. It is the responsibility of the backup administrator to create and schedule a set of datalists, which correspond to the specific backup requirements of his/her environment. Though OmniBack II does not restrict the use of rawdisk and filesystem objects in a single datalist, it is probably a good idea to define separate datalists for backup of different types of data – i.e. a datalist containing filesystem objects for user home directories, and another datalist containing rawdisk objects for the company’s transactional database. Datalists can be scheduled individually, but specific objects within a datalist cannot – they are always backed up together, as part of the same backup session.

Each OmniBack II datalist can contain certain session pre- & post-processing commands, which are executed before the session is started and after it is completed. These commands are user-defined and can be used to shutdown and restart applications (i.e. databases) during backup time. They can also be used for other user-specific purposes, i.e. to notify the operator that a backup session has been completed. These session pre- and post commands can be started remotely on any host within the OmniBack II cell.

Additionally, instead of associating each datalist object to a specific logical device, OmniBack II supports dynamical allocation of logical devices. This datalist layout will allow for a dynamic binding of backup objects and available devices based on a load-balancing algorithm when backup is performed. Basically, with this concept, the datalist definition will describe a set of logical devices and a set of backup objects without implying any relationships between them, thus dynamically mapping the backup objects to logical devices. Integrated with SAP R/3, OmniBack II additionally offers load balancing either by file size or by time.

Taking advantage of load balancing, total backup execution time can be reduced and backup performance can be continuously improved with each backup session.

Furthermore, OmniBack II is also capable of host backup support. At this, instead of specifying single filesystem objects, the host entry will be supported. Thus, when performing backup, OmniBack II will silently expand the host into a set of transient filesystem objects, one for each filesystem mounted locally on the specified host. Afterwards, for each transient filesystem object, a dedicated backup disk agent will be spawned to perform its backup.

1.2.5  Media Management

OmniBack II offers a full set of media management capabilities that allows the user to easily track the largest number of backup media, and to retain a backup/restore history. The media is organized into media pools, a logical collection of media of the identical type with the same common media or data properties. When configuring a logical device, a default media pool must be specified, which can either be a standard pool, a magazine pool or an exchanger pool. In addition, when configuring the pool, the properties OmniBack II uses to manage the media and media pools need to be set to define the media class, media usage- and media allocation policies, and media condition factors. Thus, the administrator is given the ability to create media

pools which fit the various needs of the different user requirements and to collect media with common properties in a logical group.

OmniBack II media management is a powerful functionality – allowing for efficient handling of media in a broad range of standalone backup devices, autochangers, library systems and silos, spanning from single-drive to up

to high-end multi-tape devices. Furthermore, besides tracking and managing media in large exchangers and optimizing the space available in the exchangers, OmniBack II also permits notification of bad or worn media, and the protection against accidental overwrites.

2.1  Integration Benefits

The integration of EMC/Symmetrix SRDF/TimeFinder technologies with the HP OmniBack II storage management software offers a number of valuable benefits for the customer:

• No Performance Impact on Business Applications
• Minimal Downtime of Mission-Critical Business Applications
• Ease of Use
• Automated, Lights-Out Operations
• Rawdisk, Filesystem & Database Backup/Restore
• Online Application (SAP) and Databases (Oracle) Backup/Restore
• Point-In-Time (Snapshot) Backup
• Minimal Backupmode for Applications/Databases
• Sophisticated Library & Media Management
• High-Performance Parallel Backup
• Strong Vision of Next-Generation Backup Solutions

2.2  Integration Concepts

The existing pre- & post-execution mechanism is enhanced to allow the OmniBack II Backup Session Manager (BSM) to interface with SymmAPI at session startup and session end time. This allows the customer to create a backup datalist with backup objects (i.e. rawdisks) which reside on a Symmetrix ICDA and let OmniBack II automatically take advantage of the SRDF and TimeFinder facilities.

The classic user-configurable pre- & post-execution facility is not affected by this parallel integration mechanism – the user is still able to define and execute specific pre- & post-exec commands. However, enabling Symmetrix SRDF or TimeFinder processing for a selected datalist instructs the OmniBack II BSM process to additionally (and transparently to the user) execute internal session pre- & post-exec commands which suspend/resume SRDF links or attach/detach TimeFinder links – naturally, for backup objects defined in the datalist.

Next to the classic pre- & post-execution does OmniBack II allow the customer with this integration to execute an additionally set of pre- & post-executions. These scripts are executed just before and right after the physical split of the mirrors. They are typically used to shutdown and startup the application or database on the application host.

Just like datalists, barlists can also have user-defined pre- & post-processing commands. And just like for the datalist mechanism, this barlist feature is expanded to allow the OmniBack II BSM to interface with SymmAPI commands and control the Symmetrix SRDF and TimeFinder facilities.

The set commands that the BSM calls in order to interface with the Symmetrix SymmAPI is called the "OmniBack II/EMC² SRDF and TimeFinder Integration Module" and provided as an additional package. It is described in detail in OmniBack II technical documentation.

It is important to realize that the customer always defines the original instance of a backup object in a datalist. If SRDF or TimeFinder processing is enabled for this individual datalist (and thus for all backup objects within it), OmniBack II will detect existing SRDF or TimeFinder links, temporarily suspend them, perform the backup of mirrored instances and resume SRDF or TimeFinder links as the backup completes – with minimal interference with the primary instance of each individual backup object.

In order to present the solution transparently to the user the backup on the backup host has to be done on the same object level as the backup is defined (file f.e.) though the communication to the Symmetrix ICDA is done on disk level. This requires an identification of the disks before SRDF and TimeFinder facilities can be used as well as a preparation of the backup host (activate volume groups or mount files systems). These tasks are triggered by the BSM when they are needed.

As the backup object activated on the backup host might be of use for other purposes (decision support) after the backup the resume of the links at the end of the backup is optional.

2.3  OmniBack II/Symmetrix Backup Configurations

Regardless of the selected OmniBack II backup paradigm, a number of physical Symmetrix backup configurations are possible, depending on the Symmetrix SRDF and/or TimeFinder facility available. Since all backup configurations have a ‘source’ and a ‘target’ side, we will standardize on the use of the following terminology for clarity and consistency:

R1 Synonymous with the term ‘primary side’ or ‘source side’. This term can occur in different contexts, with different meanings.

R1 Symmetrix The Symmetrix ICDA on which the primary set of SLDs resides.

R1 Host The computer connected to the R1 Symmetrix, usually running a production application or database and therefore also called application host.

R1 SLDs The primary set of SLDs on which production data resides, SLDs residing in the R1 Symmetrix and connected to the R1 Host.

R1 BCVs A set of SLDs residing in the R1 Symmetrix, and used for local detachable mirroring of the (production) R1 SLDs.

R2 Synonymous with the terms ‘secondary side’ or ‘target side’. This term too can occur in different contexts.

R2 Symmetrix The Symmetrix ICDA on which the secondary (mirrored) set of SLDs resides.

R2 Host The computer connected to the R2 Symmetrix, usually in stand-by mode, ready to take over processing in case the R1 Host fails, or used for backup purposes. Therefore it is also called backup host. In a single-Symmetrix configuration, this term can also refer to a second host connected to the R1 Symmetrix and used for running backups.

R2 SLDs The secondary (mirrored) set of SLDs, usually used for backup.

R2 BCVs A set of SLDs residing in the R2 Symmetrix, and used for local mirroring (TimeFinder) of a set of R2 SLDs which already are SRDF-mirrors of a set of R1 SLDs.

2.3.1  SRDF

The SRDF configuration is primarily used for disaster-recovery purposes, but can also be used for point-in-time backup with OmniBack II. The first (primary, R1) Symmetrix is connected to the R1 Host running a production application or database. A set of R1 SLDs is SRDF-mirrored to a secondary (and possibly dislocated) R2 Symmetrix, which exports its R2 SLDs to a R2 Host. The R2 SLDs are read-only while the SRDF link is established, and the R2 Host is in a stand-by mode and used for running the OmniBack II backup process only.

IMAGE 1

At backup time, the OmniBack II backup process executes on the R2 Host and performs the following steps:

• The BSM executing the backup datalist (or barlist) invokes an OmniBack II command on the R1 Host and R2 Host resolving the file or logical volumes down to the disk, in order to build up a list of disks which needs to be suspended.

• With the list of the first step the next command on the R2 Host is suspending SRDF links between R1 and R2 SLDs and enabling read/write access to relevant R2 SLDs.

• R2 SLDs are now backed up using one of OmniBack's backup paradigms (rawdisk, filesystem or database). In the meantime, R1-side access to the R1 set of SLDs can continue without interference to the backup process or any performance impact.

• As the backup of R2 SLDs completes, the BSM executes an OmniBack II command on the R2 Host, resuming SRDF links between R1 and R2 SLDs and resynchronizing the contents of the R2 SLDs with the R1 SLDs, without affecting any applications using the R1 SLDs at that moment. (this step is optional)

Using OmniBack's the new split pre- & post-execution facility, the customer can add an initial step to disable any processing on the R1 side before the SRDF links are suspended and resume processing on the R1 side as soon as the SRDF split is complete.

The backup process executing on the R2 side is completely separated from the mission-critical application or database running on the R1 side – apart from the fact that a short time is necessary during the SRDF split in order to ensure data consistency (could be downtime or backup mode time).

Also, this solution has no performance impact on the R1 side. Neither on the Host CPU running the database or application nor on the Symmetrix ICDA. This configuration can also be used to provide a central backup/vaulting solution for multiple R1 Symmetix sites – if they all share the same dislocated R2 Symmetrix. As the SRDF link is suspended for the time of the backup it is not recommended to use this copy of the data as high availability or disaster recovery copy. In order to address the disaster recovery need a combination of SRDF and TimeFinder (explained later) should be considered.

2.3.2  Single-host TimeFinder

The single-host TimeFinder configuration is interesting for customers looking to implement a local point-in-time backup solution, with no special considerations regarding backup performance and performance impact on the application/environment backed up. A primary set of R1 SLDs is TimeFinder-mirrored to a set of BCVs inside the same Symmetrix. These BCVs are exported as R2 SLDs to the same host computer (in this case R1 Host and R2 Host are the same machine).

Both the application as well as OmniBack’s backup process runs on the same machine. However, at backup start time, the set of BCVs is detached from their corresponding R1 SLDs, and backed up by OmniBack II:

• The BSM executing the backup datalist (or barlist) invokes an OmniBack II command on the R1 Host resolving the file or logical volumes down to the disk, in order to build up a list of disks which needs to be detached.

• Using the list of the first step a command is executed on the R2 Host, detaching BCVs from their corresponding R1 SLDs, and enabling read/write access to them.

• The BCVs are backed up using one of OmniBack’s backup paradigms (rawdisk, filesystem, and database). In the meantime, the application can continue accessing the R1 SLDs without interference with the backup process or any disk I/O performance impact. However, since the OmniBack II backup process executes on the same machine, certain CPU performance degradation should be expected. Additionally it needs to be mentioned that the backup Objects needs to be mounted for the backup which might conflict with the mounted Object for the running application.

• As the backup of the BCVs completes, the BCVs are re-attached to their corresponding R1 SLDs, thus resynchronizing their contents with the R1 SLDs. This occurs without affecting any applications using the R1 SLDs at that moment.

Using OmniBack’s user-configurable split pre- & post-execution facility, the customer can add an initial step to disable any processing on the R1 SLDs immediately before, and resume R1 processing as soon as the BCVs are detached.

2.3.3  Dual-Host TimeFinder

This configuration is similar to the single-host TimeFinder configuration described in 2.2.3. However, it has clear performance benefits, since the OmniBack II backup process effectively executes on the R2 Host and does not affect the performance of the R1 side.

At backup start time, the set of BCVs is detached from their corresponding R1 SLDs and exported to the R2 Host. As the R2 Host has to see the SLDs for a potential Service Guard configuration the BCVs need to be accessed through a different path or at the time of a fail over situation a decision on a running backup has to be made. (abort or halt the package until the backup is finished)

The procedure for the backup is exactly the same as for the single host TimeFinder integration.

2.3.4  SRDF + TimeFinder

This solution assumes that a set of SLDs inside the R1 Symmetrix is SRDF-mirrored to a set of SLDs inside the R2 Symmetrix, which are then TimeFinder-mirrored to a third set of BCVs inside the R2 Symmetrix.

Both the R2-side SLDs and their R2-side BCVs are connected to the same R2 host computer. At backup time, OmniBack II detaches the R2 BCVs from the R2 SLDs, leaving the SRDF links between the R1 and R2 SLDs intact. This ensures point-in-time backup while maintaining full SRDF disaster-recovery protection of the R1 SLDs.

In an automated fail over setup configured with Service Guard for example a startup of a application/database would conflict with a running backup as described for the dual host TimeFinder solution.

By connecting the R2 SLD to a dedicated standby machine the backup and the failover would have been separated again.

2.4  OmniBack II / SAP R/3 Integration

Combining the features of the OmniBack II/Symmetrix integration with the well-known backup functionality of the SAP utility brbackup, a SAP R/3 database running on Symmetrix configuration like mentioned above, could be easily backed up. New functionality introduced with brbackup 4.0 plus OmniBack II integration in SAP and SRDF/TimeFinder supports this kind of setup.



Brbackup takes over the control of the database and uses OmniBack II as a service to communicate with the Symmetrix and to perform the backup. The brbackup process actually running on the R2 Host queries the production database on the R1 host for the files/raw partitions the database is built on. This information is transferred to OmniBack II to perform the actual split. Like for the normal Datalist backup the BSM is now coordinating the tasks which needs to be performed.

As the database has to be in a consistent state before the split can be executed brbackup puts the database in backup mode or offline before it calls the BSM. This depends on the selected backup mode (online_split or offline_split). After the split is executed the control is transferred back to brbackup that now takes immediately the database out of the backup mode or online.

Brbackup follows the normal flow of backup by calling the storage vendor API backint. Before the actual backup can be performed the R2 host needs to be prepared in terms of activating volume groups or mounting filesystems. Therefore the control is once more transferred to the BSM before several sapbackp processes are started to write the data to tape.

The current status of the backup and brbackup log is stored in the standard sapbackup directory that is shared between the R1 and R2 Host as this information is needed on the R1 host for restore purposes. At the end of the backup the BSM takes care of handling the SRDF and TimeFinder link as configured by the customer.

To ensure a consistent backup a backup of the archive log files is still required. This backup has to be taken through the R1 host as a consistent information of a filesystem on the disk can only be guaranteed by unmounting the filesystem. The saparch directory needs to be available all the time to copy current redo log files in the archive log directory. If the copy of the redo log would fail the database would stop.

2.5  OmniBack II / Oracle8 Integration

To provide the full advantage of a split mirror backup to Oracle user without SAP OmniBack II and Oracle provide together an integrated backup solution. The OmniBack II command (ob2rman.exe) takes over the tasks of querying the database, putting the database in backup mode, calling OmniBack II to split the links and release the again the backup mode. Until this point the Oracle integration looks very similar to the SAP one and in fact is using the same Oracle technology to communicate with the primary database (SQL-NET V2).

After the R2 host is prepared with the right init<SID>.ora file and the right backup control file the database can be mounted. It is important to mentioned that ob2rman.exe only mounts the database and not opens it as a open of a database would change the checkpoint numbers of the tablespaces. If the checkpoint numbers are changed before the backup is taken a recovery would be impossible as the checkpoint number in the redo log files located on the R1 host would not match anymore.

The database needs to be mounted in order to be able to start the Oracle Recovery Manager (RMAN). RMAN is used to perform the actual backup and uses the Oracle recovery database located on a third machine to track the status of the backup. OmniBack II transfers automatically the required information to the RMAN in order to perform an unattended backup.

At the end of the backup the BSM takes care again of the cleanup of the R2 Host. For more information on the Oracle integration please refer to the OmniBack II / EMC² / Oracle whitepaper.

2.6  Restore

By nature of the backup the restore can be performed in two ways.

To the R1 Host, which is not at all different to a normal OmniBack II restore with the limitation that most often the network is involved as the device is locally connected to the R2 Host.



The restore to the R2 Host would mean a restore to the mirror that includes a SRDF or TimeFinder restore to activate the restore on the source disk. Before this restore can be started at all the mirror needs to be detached from the source. Therefore the same configuration information as for a backup needs to be defined in the restore settings.

As the restore action of SRDF or TimeFinder affects always a complete disk a single portion of the disk which have not been restored will be reset to the status of the beginning of the restore and all information added after the split of the disk will be lost.

As the restore activation on the source side is done through a HW method (SRDF/TimeFinder restore) a mounted directory on R1 would not directly recognize the new HW structure. If during this time data is written to the filesystem the data could be lost as well. To avoid these two potential data loss OmniBack II tries to unmount filesystems and deactivate volume groups before disks are split.

2.7  Terminology

ICDA EMC’s Symmetrix Integrated Cached Disk Arrays - complex disk array devices, combining a set of industry-standard physical disks, a number of Fast/Wide SCSI channels which are used to connect the ICDA to one or more host computers, a certain amount of internal cache memory and sophisticated control and diagnostic software executing inside the ICDA – commonly referred to as the microcode.

SLD Symmetrix Logical Device – a logical disk drive, possibly mapped to a partition of a physical disk drive inside the ICDA. The SLD is visible to the host computer as a single physical volume. All Symmetrix operations (see SRDF, TimeFinder) operate on the SLD level of granulation.

BCV Business Continuation Volumes, or BCV devices, are dedicated Symmetrix SLDs which are pre-configured in the Symmetrix unit on which the business continuation operation will run. The BCV devices are assigned separate SCSI addresses; different from the addresses used by SLDs they mirror. The BCV devices are used as splittable mirrors of source Symmetrix SLDs which need to be protected.

SRDF The Symmetrix Remote Data Facility is a business continuation process that enables effective, real-time data replication of SLDs between dislocated processing environments. These environments could be situated within the same computer root or separated by long distances.

TimeFinder The TimeFinder Facility is a business continuation process that creates an instant copy of single or multiple SLDs. The instant copy is created on specially preconfigured SLDs called BCVs and is accessible via a separate device address to the host(s).

SymmAPI A set of integrated API calls providing an interface to Symmetrix ICDA’s SRDF and TimeFinder related operations, i.e. suspend/resume, attach/detach. Used by OmniBack II to interface with the ICDA.

Datalist An OmniBack II configuration file which contains a description of backup objects (rawdisks and filesystem) which need to be backed up, and target backup devices which should be used for backup. A datalist can be scheduled or executed manually. The execution of a datalist results in an OmniBack II backup session.

Barlist An OmniBack II configuration file which contains a description of an external backup command which initiates application- or database-specific backup and target backup devices which should be used for backup. Barlists are used for online database backup integrations and can be scheduled or executed manually. The execution of a barlist results in an OmniBack II backup session.

BSM The execution of a datalist is managed and supervised by an OmniBack II process called ‘Backup Session Manager’. The BSM is responsible for spawning and controlling any additional agents required to complete the backup session as described in the datalist. Additionally, the BSM may execute user-defined commands at the start of the session (before the actual backup process is started) and at the end of the session (after all backup processing has completed). This mechanism is called session (datalist) pre- & post-execution.