UPSTREAMSOS - SAN Express Passthru

Introduction

FDRSOS and UPSTREAM SOS are designed to backup Open Systems data stored on EMC2 Symmetrix, DMX or VMAX series Storage Subsystems and IBM DS8700 and DS8800 series systems which are attached to both Open Systems and z/OS. The backups are directed to the UPSTREAM Storage Server that are then stored on Storage Server disk or tape.

This product suite has been made possible through a teaming agreement among BMC Software and EMC and IBM Corporations. Under this agreement, EMC has produced the Symmetrix, DMX, and VMAX series ICDA (Integrated Cached Disk Array) Storage Subsystems and the Enterprise Storage Platform (ESP) option now called EMC z/SOS. This combination allows access to Open Systems data on the Symmetrix from both SCSI or fiber and IBMZ channels.

For IBM, a new co-cost feature of the DS8700 or DS8800 storage arrays called z/OS Distributed Data Backup (zDDB) is required to be installed on the DS8700 or DS8800 to allow FDRSOS to access the Open System volumes.

Normal z/OS access methods cannot read or write data on the Open Systems volumes via the IBMZ channel. However, under its part of the teaming agreement, BMC has produced FDRSOS and UPSTREAM SOS to use special I/O techniques to read the Open Systems volumes in the EMC and IBM arrays and transmit backup data across the IBMZ channel for storage at the Storage Server. The IBMZ channel is used in preference to slower network links like TCP/IP with much lower CPU overhead.

If you are using the UPSTREAM Reservoir, the exact same technology and UPSTREAM Client software is used as for UPSTREAM SOS and named the UPSTREAM SAN Express Passthru. The UPSTREAM SAN Express Passthru is not limited to EMC or IBM disk - any vendors disk array can be used - even stand-alone drives. Formatting of the disk is done using the UPSTREAM Director. Otherwise, all other client and Director features for UPSTREAM SOS are valid for the SAN Express Passthru. Throughout this chapter the term UPSTREAM SOS is used, but it always applies to the SAN Express Passthru as well. Note that FDRSOS is a z⁄OS only product. To achieve the same results with the Reservoir, use the Physical Disk backup features of the Client.

At the end of this chapter are FDRSOS and physical disk notes specific to a number of different operating systems including:

• Windows (see FDRSOS Windows Considerations)
• AIX (see FDRSOS AIX Considerations)
• HPUX (see FDRSOS HP-UX Considerations)
• Solaris (see FDRSOS Solaris Considerations)
• Linux x86 (see Linux x86 Local Backup Support and Linux OS on IBMZ Local Backup Support)

Why Use FDRSOS and UPSTREAM SOS or the SAN Express Passthru

An Open System workstation/server, with data on the EMC or IBM storage array, and which has a network connection to the UPSTREAM Storage Server, could of course use a standard LAN backup package (like UPSTREAM) to do its backups to the Storage Server.

Data would be read from the EMC or IBM storage array and transmitted over to the UPSTREAM Storage Server across the TCP/IP network link. Performance would greatly depend on the bandwidth of the network connection, as well as other elements making up the network link (CPU loading, network loading etc., etc.).

FDRSOS and UPSTREAM SOS use the network connection only for the synchronization between the software running at both ends of the link. The backup data goes across the IBMZ channel connecting the EMC or IBM storage array to the Storage Server. This channel may be FICON or ESCON.

The advantage of FDRSOS and UPSTREAM SOS, when compared with regular UPSTREAM, is speed and reduced CPU utilization. The bandwidth of a IBMZ channel far exceeds that of most TCP/IP network connections.

Introducing FDRSOS

Let us first take a look at the FDRSOS component of the suite. FDRSOS is an z⁄OS component and is not needed for the SAN Express Passthru

Running under z⁄OS, FDRSOS can be used to backup and restore logical disk volumes in the EMC or IBM storage array, which are being used as SCSI or fiber disks by a Unix, PC/LAN Server, or PC/Workstation.

As described in the introduction, the backups and restores of this Open Systems data are transmitted at high speeds by FDRSOS across the EMC or IBM storage array’s IBMZ channel (FICON, or ESCON) to the Storage Server. FDRSOS backups can be output directly to z⁄OS TAPE or DASD.

FDRSOS uses the Data Management strengths of IBM’s IBMZ hardware and z⁄OS software to provide high-speed, well-managed backups of Open System’s data.

For FDRSOS to be able to read the Open System logical disk volumes in the EMC or IBM storage array via the IBMZ channel, the following tasks need to have been performed:

• The Enterprise Storage Platform (ESP) option now called EMC z/SOS installed on the Symmetrix. For the DS8700 and DS8800 you must have connectivity to the same storage array to both FICON and Fibre channel and the no cost zDDB option installed.
• The IBMZ channel connection (FICON, or ESCON) made to the z⁄OS host.
• The Open Systems Logical Disk Volumes ‘defined’ to z⁄OS.

Normally (but not always) the physical disk drives in the EMC or IBM storage array are sub-divided into smaller Logical Volumes for use by the Open Systems. Volumes of 2-4Gb in size are often created and it is these Logical Volumes that FDRSOS is able to backup and restore.

Each separate Logical Volume must first be defined to the z⁄OS I/O configuration (IOGEN). This is a simple one time task. The Logical Volume is given a standard z⁄OS address and it can be generated as either a 3380 or 3390 (it is not important to FDRSOS). The OFFLINE keyword is specified so that the volume remains OFFLINE to z⁄OS during an IPL.

z⁄OS itself cannot recognize an Open System Logical Volume and any attempt to bring one ONLINE produces various z⁄OS error messages. However, once a Logical Volume has been generated into the z⁄OS I/O Configuration, FDRSOS is then able to access it (by its z⁄OS address) using the special I/O techniques mentioned in the Introduction. FDRSOS is able to access the volume - even though it remains OFFLINE to z⁄OS.

FDRSOS is then able to write a label (volser), with a “LABEL” command, to a reserved area on the Logical Volume. The “LABEL” command also places the label (volser) into the z⁄OS UCB for the Logical Volume. The label, which is a standard z⁄OS 6-character volser, is not used or recognized by the Open System. However, the presence of the volser in the UCB allows FDRSOS (through JCL) to access the offline volume referencing the volser instead of the z⁄OS device address.

After an z⁄OS IPL, the volser is removed from the UCB (which is recreated at each IPL), so FDRSOS also provides a “VARYON” command (not to be confused with z⁄OS Vary On) that re-reads the volser from the Logical Volume and places it back into the UCB.

In summary, a Logical Volume must have a LABEL before it can be accessed for backup or restore by FDRSOS. Then, after each IPL (or before each backup or restore), the FDRSOS ‘VARYON’ command must be run to ensure that the volser has been placed into the z⁄OS UCB.

Once these functions have been completed, FDRSOS can back up and restore either the whole Logical Volume or selected tracks (not data sets – see UPSTREAM SOS later). FDRSOS can also ERASE and PRINT the data on the volume.

FDRSOS Summary

To summarize FDRSOS’s benefits:

• FDRSOS backups and restores can be taken at high-speed – without suffering from traditional network connection bottlenecks. And, often more importantly, FDRSOS backups/restores can be taken without themselves further adding to network utilization and congestion.
• The Logical Volume backups, which are taken by FDRSOS, are ideal for Disaster Recovery protection. FDRSOS provides a truly viable Disaster Recovery solution for Open Systems data stored on the EMC or IBM storage array.
• FDRSOS backups can be written to z⁄OS DASD or Tape. If on tape, the backups can be controlled by the z⁄OS Tape Management System (TMS) that can optionally control off-site vaulting and retention requirements for these backups.

The FDRSOS backups of Open Systems data effectively become integrated into the corporate Disaster Recovery plan, along with existing z⁄OS DASD backups. This allows for a consolidated and controlled Disaster Recovery Plan – the Open Systems data can be restored at the same time (and with the same well-documented procedures) as the z⁄OS data.

Introducing UPSTREAM SOS and the SAN Express Passthru

UPSTREAM SOS provides FILE LEVEL support to the suite. It introduces an Incremental Backup scheme in addition to the Logical Volume backups taken by FDRSOS.

Like FDRSOS, UPSTREAM SOS uses the IBMZ channel between the EMC or IBM storage array and the z⁄OS host for its data transfer. This differentiates it from other z⁄OS-based LAN backup systems (like UPSTREAM) that use slower TCP/IP network connections for their data transfer.

The following diagram summarizes UPSTREAM SOS operations:

As you can see from the diagram, UPSTREAM SOS consists of the following two components:

• UPSTREAM SOS (z⁄OS), which resides on the z⁄OS host
• UPSTREAM SOS (Open System), which resides on the workstation/server that owns the data on the EMC or IBM storage array

The z⁄OS component controls the creation, retention, and expiration of UPSTREAM SOS backups that reside on z⁄OS Tape or DASD. The recording mechanism used by UPSTREAM SOS for its backups is also resident on the z⁄OS host and is controlled by the z⁄OS component.

The Workstation/Server component, running under the Open System, carries out the incremental selection (and subsequent handling of Archive bits etc) of the Open System data stored on the EMC or IBM storage array. It uses the specialized file handling services inherent in the various Open Systems to select and process the files for daily incremental backup.

Once it has selected the relevant files for backup, the Workstation/Server component writes its backup data across a SCSI or fiber connection to a specially formatted ‘FDRSOS Local Backup Disk’ in the EMC or IBM storage array. You can see an example of this Local Backup Disk in the previous diagram. It is created by an FDRSOS job using the ‘LOCALBACKUP TYPE=INIT’ command.

While the Workstation/Server component is writing to the Local Backup disk, the z⁄OS Component “follows behind” and reads the backup data from the Local Backup disk via the IBMZ channel. It does this using the same special I/O techniques employed by FDRSOS. It then writes the backup to z⁄OS tape or DASD, as required.

When the backup begins, the UPSTREAM host allocates the space on the local backup disk for the backup to be stored. Since each backup has its own space, multiple backups can be stored in the local backup disk. Multiple backups can be run simultaneously and can even come from different machines that have access to that disk.

Space for the backup is allocated based on:

• The estimated size of the backup.
• The maximum size specified for that profile (a default is used if there is no specific profile definition).
• If space is short, then the size can be reduced based on a specified percentage.

 UPSTREAM SOS wraps through the space allocated, reusing the space after the host has written the data to host disk or tape, if the amount of space allocated is insufficient for the backup (and you do not disallow it). There are some performance disadvantages in wrapping (generally two seconds in each wrap); wrapping allows you to backup data which is much larger than the local backup disk. If your backup wraps, the backup is deleted from the local backup disk when the backup has completed.

Space on the local backup disk is freed when:

• The backup is complete if you specified that backups not be retained.
• The restore is complete. Restores are never retained.
• You have exceeded the specified number of backups to store on the local backup disk (by profile).
• If you are short on space and have allowed UPSTREAM SOS to delete prior backups (oldest first).

Restores work somewhat differently than backups. If the data exists on the local backup volume, it is restored directly from it without having to come from host disk or tape resulting in the fastest possible performance. If the data is no longer on the local backup volume, the process is reversed with the data transiting from host disk or tape through the local backup volume.

You can specify the UPSTREAM SOS parameter defaults when you format the UPSTREAM SOS volume (using FDRSOS). You can later manage and maintain values for individual backup profiles and system defaults using UPSTREAM on the workstation/server.

UPSTREAM SOS Summary

To summarize UPSTREAM SOS:

• The use of the FDRSOS Local Backup Disk and the IBMZ channel means that it is truly viable to take regular (daily) incremental backups of large Open Systems Volumes in the EMC or IBM storage array and store them on the z⁄OS host.
• The UPSTREAM SOS incremental backups can be used to complement the weekly Full FDRSOS backups – allowing both Volume Restores and File Restores at the home site, as required.
• UPSTREAM SOS backups can also be included, along with FDRSOS backups, in the corporate Disaster Recovery plan. This allows for a more comprehensive (i.e. up-to-date) recovery of Open Systems data in the event of a disaster.
• UPSTREAM SOS offers performance and feature advantages that may make it the viable solution for all your full and incremental backup needs.

UPSTREAMSOS Setup describes the setup of UPSTREAM SOS using both FDRSOS and UPSTREAM. Subsequent sections describe the use of UPSTREAM SOS for backups and its integration with FDRSOS for fulls and incremental backups.

UPSTREAM SOS Setup

There are a number of steps in the setup of UPSTREAM SOS.

• Get UPSTREAM installed and operational on both the host and workstation/server platform. This is described earlier in this manual (in the platform chapters) and the UPSTREAM Storage Server User Guide.
• Planning the Local Backup disk.
• Identify, from both the host and open systems side the disk you wish to use as your local backup disk.
• Use FDRSOS to format that disk.
• Identify the workstation/server name for the disk.
• Identify the local backup disk.
• Test and automate your backups.

Planning the Local Backup Disk

Planning the number of local backup disks and their sizes can be a somewhat complex matter which can be affected by the type and size of backups you perform, the availability of resources, etc.

In a perfect world with no monetary or resource constraints and for maximum performance we would recommend that:

• Each concurrently operating copy of UPSTREAM would have its own local backup disk on separate controller. This reduces controller and head contention when you have multiple simultaneous backups running.
• The local backup disk be large enough so that it never needs to wrap during a backup and that it can be large enough to hold an entire cycle (full and all incremental backups).

However, since this perfect scenario is often not possible, some reasonable compromises include:

• When possible, multiple concurrently running copies of UPSTREAM have their own local backup disk. Head contention is the largest offender in performance degradation with UPSTREAM SOS.
• Allow wrapping in all cases where recovery times are not critical. We generally recommend that a single backup allocation be at least 100MB, and 500MB to 1000MB is better for large backups.

When in doubt about sizing and disk allocation questions feel free to contact BMC Support

Generally the biggest performance bottleneck with UPSTREAM SOS is reading the data from the disk. Thus we recommend that whenever possible that UPSTREAM be run on the machine that is physically attached to the disk. Also, UNC names degrade performance on PC backups; use the drive letter for best performance.

. If you are going to convert a disk which currently has a file system on it, you must remove the file system in such a way so that the operating system does not step on the local backup data. Contact BMC Support. The local backup disk does not have an open systems file system on it; it has a file system proprietary to BMC if you have questions.

For the Reservoir, any disk type can be used as a local backup disk including SATA, Thumb Drives, iSCSI drives, etc. But the same issues that affect performance for file access on disk, is true with a local backup disk. In other words, high speed storage arrays with lots of RAM are preferred as local backup disks to local SATA or IDE disks or even iSCSI disks unless the LAN speed is seriously high (10GB or higher).

Identify and Label the Local Backup Disk

It is important to identify the disk you wish to use for local backups correctly from both the host and open systems side to ensure that you are not overwriting any existing data. Your EMC or IBM representative should be able to help identify the disk on both sides.

Note that on the open systems side you need to know the disk number (for Windows), the location in the /dev directory for UNIX; for Novell, the volume can only be determined after it has been formatted.

The local backup disk can not be a member of a metavolume. Metavolumes are seen by FDRSOS and the UPSTREAM host as multiple volumes and are not suitable for use as local backup disks. Metavolumes can however be used by the SAN Express Passthru.

You do not need to label the disk if you are using the SAN Express Passthru.

The FDRSOS LABEL command includes an option, PRINT=STATUS, which can help in identifying the type of existing data on the disk. We recommend that this option be used before labeling and strongly recommend its use before formatting.

Use the FDRSOS LABEL command (TYPE=SOS) label the disk. The following information is from the FDRSOS manual and describes the LABEL command, we recommend that you see the FDRSOS manual for any updates.

LABEL Statement Syntax

This statement requests a volume labeling operation. It must be the first statement in the input; only one LABEL statement is allowed per execution. LABEL must be followed by one or more MOUNT statements with the UNIT= and SETVOL= operands to specify the Open System volumes to be labeled.

The LABEL function must be executed against each Open System volume before it can be used by other FDRSOS functions. It assigns a volume serial to a volume and records that serial in an area of the volume reserved by EMC or IBM for FDRSOS use. You only need to execute LABEL against each Open System volume when:

• The Open System volume has not previously been used by FDRSOS
• You need to change an Open System volume serial
• The EMC or IBM hardware has been reconfigured changing the size or location of the Open System volumes so that the original volume serials have been lost
• A new EMC or IBM storage array subsystem is replacing the original system (such as a replacement subsystem at a disaster site).

LABEL also stores the volser in the UCB of the Open System device so that it can be used in a DISKx DD statement in other FDRSOS steps. However, that volser is lost when your z⁄OS system is re-IPLed; after an IPL, the FDRSOS VARYON function must be executed before any FDRSOS backup, restore or print is performed.

The LABEL function is also useful as a diagnostic tool, to verify that your hardware and software configuration is correct so that the Open System volume can successfully be accessed by FDRSOS. Compared to other FDRSOS functions, LABEL gives additional diagnostic messages if it cannot access the volume. In fact, if a LABEL statement is used with a MOUNT statement with only UNIT= on it (no SETVOL= operand), it validates access to the volume but does not change its volume serial.

LABEL Statement Operands:

TYPE=SOS

Must be specified on the LABEL statement.

BCV=IGNORE

Normally, FDRSOS identifies all EMC or IBM storage array devices that are Business Continuance Volumes (BCVs) or FlashCopy volumes. Since their usual purpose is to act as a mirror of another standard volume which can be detached for backup, they usually do not have their own volume serials and LABEL has no effect if executed against them. However, BCVs can be used as spare primary volumes.

BCV=IGNORE allows BCVs to be labeled with a volume serial you specify and used as a normal Open System volume.

PRINT=

STATUS

Requests that FDRSOS attempt to identify the type of Open System volume being labeled. If possible, it displays the type of Open System which created it, and other pertinent information about the format and contents of the volume.

(STATUS,DIR)

In addition to the PRINT=STATUS displays, for some Open System platforms, it displays the files and subdirectory names in the root directory of each volume or logical volume.

UCB

Prints the z⁄OS Unit Control Block (UCB) and associated control blocks for each unit address specified. This is a diagnostic tool, used primarily to investigate disk access problems.

Format the Local Backup Disk

After you have identified the disk it must be formatted for use by FDRSOS using the FDRSOS LOCALBACKUP statement.

If you are using the SAN Express Passthru, see the UPSTREAM Reservoir manual for instructions on formatting the disk.

We highly recommend the use of the FDRSOS LABEL PRINT=STATUS command to verify that it is the correct disk.

The following description of the LOCALBACKUP FDRSOS statement is from the FDRSOS manual. See the FDRSOS manual for updates and additional information.

LOCALBACKUP Statement Syntax

This statement is used to initialize EMC or IBM storage array disk volumes for use with UPSTREAM as FDRSOS local backup volumes, or to update default parameters on an existing FDRSOS local backup volume.

The disk(s) to be processed are identified by one or more MOUNT statements which follow. These disks must have been previous labeled by a FDRSOS LABEL statement. You must not change the volume serial of a local backup volume once it is in use; if you do so, all existing backups on the volume are lost.

The operands on the LOCALBACKUP statement set options stored on the FDRSOS local backup volume that control UPSTREAM use of the local backup volume. For TYPE=INIT, all the operands (or their defaults) are used to set the options on the new local backup volume; TYPE=UPDATE updates options on an existing local backup volume and only those operands that appear on the LOCALBACKUP statement are modified (other options keep their previous values).

Except for DYNADDPROF= and MAX#PROF=, all the LOCALBACKUP operands provide defaults for processing the UPSTREAM profiles which have backups on the FDRSOS local backup volume. Any profile newly added to the local backup volume gets these defaults. Facilities are provided with UPSTREAM on the Open System to add and delete profiles, change the values associated with any profile, and change the defaults.

TYPE=INIT normally initializes the entire volume for FDRSOS local backup use, but you can specify a SIZE= operand on each MOUNT statement to limit the space used to less than the physical size of the volume. The volume is initialized as a DOS disk partition with additional data used by local backup; SIZE= causes only the first part of the volume to be formatted as a DOS partition; the remainder of the disk can be defined from the Open System as additional partitions for other uses.

To avoid overlaying valid data, TYPE=INIT fails if the disk currently has any file system format that is recognized by FDRSOS, including local backup data. If you want to take a volume which previously held data and use it for FDRSOS local backups, you need to ERASE at least the first 1000 blocks of data (see ERASE in Section 210.05).

TYPE=UPDATE does not normally change the size of the existing FDRSOS local backup volume. However, if you specify a SIZE= operand on a MOUNT statement, and the value is larger than the SIZE= used to initialize the volume, the local backup volume is updated to use the new size for local backups. Note that there is no checking to be sure that the additional space is not already used for other data. TYPE=UPDATE fails if the disk is not already formatted for local backups.

SUN SPARC SYSTEMS:

• When the local backup disk is attached to a SUN Solaris system running on a SUN SPARC processor, there are special procedures (they do not apply to SUN Solaris on an INTEL-type system):
• Unless the disk is brand new, never before used, you should erase the disk completely with the FDRSOS ERASE function.
• Use the “format” command to format the disk. “format” lists the disks available to the system; selects the disk to be used for local backups. The following bullets use subcommands of the “format” command.
• Use the “volname” subcommand to assign a volume name of “FDRSOS” to the volume.
• Use the “partition” subcommand to delete all partitions on the volume except the “backup” partition, which must be partition 2. For every partition whose “tag” is other than “unassigned”, you must modify that partition to mark it “unassigned” and change its starting and ending cylinders to 0 (zero). You must delete the partitions in reverse numeric order (highest numbered partition first).
• Use the “label” subcommand to write the new format to the disk.
• When done you can use the “verify” subcommand to verify that the volume is correctly initialized. The output looks something like this:
  
  format> verify
  Primary label contents:
  Volume name = < FDRSOS>
  ascii name = <EMC-SYMMETRIX-5264 cyl 1103 alt 2 hd 15 sec 64>
  pcyl = 1105
  ncyl = 1103
  acyl = 2
  nhead = 15
  nsect = 64
  Part Tag Flag Cylinders Size Blocks
  0 unassigned wm 0 0 (0/0/0) 0
  1 unassigned wm 0 0 (0/0/0) 0
  2 backup wu 0 - 1102 517.03MB (1103/0/0) 1058880
  3 unassigned wm 0 0 (0/0/0) 0
  4 unassigned wm 0 0 (0/0/0) 0
  5 unassigned wm 0 0 (0/0/0) 0
  6 unassigned wm 0 0 (0/0/0) 0
  7 unassigned wm 0 0 (0/0/0) 0

• Use the FDRSOS LOCALBACKUP function to make the formatted disk as a FDRSOS local backup.

LOCALBACKUP Operands

Operands include:

TYPE=

Identifies the type of operation and must be specified on the LOCALBACKUP statement.

INIT

Performs a full initialization of a new FDRSOS local backup volume. The operands on this statement, or their defaults, are used to set defaults on the local backup volume for use with new UPSTREAM profiles.

UPDATE

Updates an existing FDRSOS local backup volume with new default values. Only values for the operands you specify are changed; omitted operands retain their previous values.

BCV=IGNORE

If the volume you are trying to initialize is defined as a Business Continuance Volume (BCV) or FlashCopy volume in the EMC or IBM storage array configuration, even if it is not currently ESTABLISHed as a copy of any primary volume, FDRSOS normally rejects any attempt to initialize the BCV for local backups. If you are sure that you want to use the BCV for local backups, and never ESTABLISH that BCV as a copy of another volume, specify BCV=IGNORE to bypass the check and initialize it for local backups.

DELMIGRATED=

If UPSTREAM SOS is unable to find sufficient space on the FDRSOS local backup volume for a new backup, this controls what action it takes.

YES

Delete backups on the volume for the current profile which have been copied (migrated) to z⁄OS tape or disk by UPSTREAM, then try the allocation again.

NO

Migrated backups are not automatically deleted. If there is insufficient free space on the local backup volume you may need to manually delete backups.

Default: NO.

DYNADDPROF=

YES

If you do a backup to this FDRSOS local backup volume under an UPSTREAM SOS profile that has not previously been used on this volume, it is automatically added to the control records on the volume. The backup characteristics of the profile are initially set to the values specified by other operands on the LOCALBACKUP statement, but they can be modified by UPSTREAM on the Open System in the FDRSOS Local Backup Admin panel.

NO

Only UPSTREAM SOS profile names which have been manually added to the control records on this FDRSOS local backup volume can do backups to the volume. Profile names are added by UPSTREAM SOS on the Open System in the FDRSOS Local Backup Admin panel.

Default: YES.

MINALLOC%=

When UPSTREAM SOS allocates space for a backup on a FDRSOS local backup volume, the space required is not known since compression reduces the requirement but cannot be predicted. If available, the uncompressed size is allocated and any unused space released at the end. But if that much space is not available, it may allocate a smaller backup file anticipating that the backup may fit. This operand controls the minimum percentage of the uncompressed size which can be allocated. You may need to adjust it depending on your results with the UPSTREAM compression.

nnn

Specifies the minimum percentage of the total uncompressed size that must be allocated for the backup to the local backup volume. Valid values are 10 to 100.

Default: 50.

MAX#BACKUPS=

This controls the maximum number of backups which may be retained on the FDRSOS local backup volume for a given UPSTREAM SOS profile. Under a given UPSTREAM SOS profile, backups older than the maximum are automatically deleted to reclaim space when a new backup is created.

nnn

Specifies the number of backups per profile allowed. Valid values are 1 to 255.

Default: 10, unless RETAINLB=NO then 0.

MAX#PROF=

This controls the maximum number of UPSTREAM profiles which may have backups recorded on this FDRSOS local backup volume. Profiles are added automatically the first time that they do a backup to this local backup volume if DYNADDPROF=YES was specified or defaulted; profile names can also be added manually using UPSTREAM on the Open System.

nnn

Specifies the number of backups per profile allowed. Valid values are 1 to 100.

Default: 100.

MAXBACKUPSIZE=

This specifies the maximum size in megabytes (MB) of a backup that is allowed on this FDRSOS local backup volume. If the total uncompressed size of the backup exceeds this size, UPSTREAM allocates the maximum size on the local disk. If WRAP=YES is specified or defaulted, UPSTREAM reuses the backup internally to send all the remaining files through the local disk to z⁄OS. If WRAP=NO is specified, the remaining files are sent over the network.

nnnn

The maximum backup size in megabytes (MB). The value must be from 1 to 4095.

Default: 100 MB.

MAXFILESIZE=

This specifies the maximum size in megabytes (MB) of an individual Open System file that is allowed on this FDRSOS local backup volume. Files that exceed the size are transmitted to UPSTREAM over your network instead, although smaller files may be written to the local backup.

nnnn

The maximum file size in megabytes. The value must be from 0 to 4096. A value of zero indicates no limit.

Default: 0 MB (unlimited).

RETAINLB=

Specifies whether the local backup is to be retained after the backup completes. As a default, the local copy is retained if the backup was not restarted and it was large enough to contain all the files written (did not wrap).

YES

Specifies to keep the local backup.

NO

Specifies that the local backup is to be deleted after a successful backup. If the backup fails and is re-startable, the local backup is retained for the first restart.

Default: YES.

WRAP=

Specifies whether UPSTREAM on the PC/Open System can re-use the backup file on the local disk if there is insufficient space to contain the entire backup.

YES

UPSTREAM can re-use the backup. The backup is deleted at the end of the backup if it wraps.

NO

UPSTREAM cannot re-use the backup. If the backup fills up, all the remaining files are sent through the network.

Default: YES.

Identify the Local Backup Disk

When requesting backups or restores, the local backup disk can be specified on either the host or the workstation by the UPSTREAM SOS local backup disk name. You can specify the local backup disk on the host either by the local backup disk name or by the host VOLSER. For UNIX systems we discourage the use of the VOLSER as it may hang UPSTREAM for a long time if a disk has a reserve on it.

The local backup disk name can be specified and selected in many of the Director screens by selecting a target system, and then pressing the Options button and pressing the Local Backup tab:

Select the FDRSOS physical disk local backup radio button. If you do not have a target system selected, the Director is not able to display the list of disks and it warns you that you need to select a target system first.

The Select Disk list shows all the disks on the system. You can press the Show only SOS disks to limit the list to only local backup disks.

Highlight the disk in the list you wish to use. When you highlight a disk, information about the disk is displayed in the fields to the right of the list.

You can check the Use volume serial # check-box to force UPSTREAM to use the disk’s host VOLSER rather than the operating system name for the disk. If you check this, UPSTREAM is able to find the local backup disk even if disks are reorganized on your system, but there is a slight delay in starting the backup or restore and there may be extra error messages displayed.

You can manually add disks to the list by pressing the Add button and then highlighting the disk. You can add disks by their mainframe VOLSER, using the “*” to indicate first disk found, “!” to indicate the first empty disk found or “&” to indicate the most empty disk found. Press the OK button to save your selection.

Test and Automate Your Backups

We always recommend that your first local backup test be performed from the UPSTREAM workstation/server rather than from the host as this reduces the number of steps to the process.

In the prior step you selected the local backup disk to be used. You can press the OK button to return to the backup dialog and select a few files to be included in the backup. You know that the backup worked correctly and that the local backup disk was used based on the UPSTREAM log file entry. If it gives you a number of files and bytes stored in the local backup file then you have been using it correctly.

If you are host initiating the backup, you can now take the local backup disk name and enter it in the USTBATCH, Backup, More dialog in the Disk Name field (note that you must also select the FDRSOS Physical Disk Local Backup option).

Restores

The speed and the reduced network overhead of UPSTREAM SOS is also available for restores as well as backups. By specifying the local backup disk for your restore in the same way that you do for your backups, the local backup disk is automatically used as a transfer device for your restores.

If you do not specify local backup and the disk to be used, the entire restore is performed through the network.

You can force the restore to use the network for data not already stored on the local backup disk if you wish by specifying the parameter LOCALRESTORE N. This parameter is also available in the Local UPSTREAM local backup restore dialog as a check-box UPSTREAM SOS restore and in the Director in the Local Backup dialog as Use disk for restore to transfer data. In both cases the default is checked to use the local backup disk.

UPSTREAM allocates a data area on the local backup disk using the smaller of the mainframe estimate of the size of the restore or the MAXBACKUPSIZE defined for the backup profile on the local backup disk in the same way as for backups. If this estimate is too small (and it is for a number of UPSTREAM database agent restores including IBM DB2 and Oracle), there are excessive wraps through this area and thus a reduction in performance. You can use the DASDOVERRIDE to increase the size of the transfer area and thus reduce the number of wraps. As for backups, the upstream.log file logs the space allocated for the local backup and the number of wraps that were used.

UPSTREAM allocates a new “backup” for the restore. If you are currently retaining backups on your local backup disk to speed your restores, this causes an extra backup to roll-off if you exceed the MAXBACKUPS value specified for your backup profile on the local backup disk. You may need to account for this and update the MAXBACKUPS value or specify LOCALRESTORE N to not create a new transfer area on the local backup disk.

Performance Tuning

There are only a limited number of things you can tune for UPSTREAM SOS. Some of these include:

• Reducing the number of wraps. The UPSTREAM log displays the number of times that a backup wrapped through the data. Note that each wrap costs around 2 seconds of time. Thus a 5 minute backup that wrapped 20 times could be made significantly faster by increasing the amount of space available in the local backup disk.
• Reducing head contention. Try to run only one backup through the local backup disk at a time.
• Differing levels of compression. High compression may speed up backups or it may slow them down. You should try testing with None, Fast, and High3 (High1 and High2 perform at almost the same speeds as High3).
•  Get close to the data. UPSTREAM SOS performance is most frequently bottle-necked by disk access. It is often better to run regular UPSTREAM on LAN attached disks than use UNC names or shares to access them with UPSTREAM SOS.

Your best tool for performance tuning is the UPSTREAM log. At the end of a backup or restore it reports:

• Bytes per second. This is bytes from the source disk transported to the host. Our experience has shown that good performance is 2-3 MB/sec for PCs and 2-5 MB/sec for UNIX systems. As always, your performance varies based on the type of the data, average file size, contention for disk, and CPU resources, etc.
• Number of wraps. Each wrap costs a minimum of 2 seconds. Whenever possible try to reduce the number of wraps.
• Number of files and data bytes. Bytes divided by files results in the average file size.

See Performance for other useful suggestions for optimizing performance.

UPSTREAM Director Local Backup Disk Management

Introduction

For those who have licensed UPSTREAM SOS, a feature that uses EMC or IBM disks shared between a server and the host to transmit/store backup data, this tab panel manages the FDRSOS initialization information, default profile, profiles and backups on these UPSTREAM SOS disks. To use FDRSOS Management in the Director you must have v1.0.25 of the Director (or higher) and be connecting to v3.1.4e of UPSTREAM (or higher).

All disk drives on the server can be viewed and listed, but only the FDRSOS initialized disks are managed and operated on. So, what exactly do we need to manage and control on an FDRSOS disk? The following figure shows three areas that we are interested in: Initialization/control and default (profile) information, Defined/generated profiles and the backups themselves:

Using the FDRSOS Management panels you can list your physical disks and see which ones are initialized for FDRSOS Local Backup, display all the above information about an FDRSOS disk, update the profile defaults for un-defined (generated from these defaults) backup profiles, display, add, delete, and update the parameters of any backup profile, display and delete (without deleting the backup in the repository) the backups by profile.

First Look

FDRSOS Management consists of two panels that work together to present the information on an FDRSOS disk. The first panel is used to list the physical disks, FDRSOS disks and the information on an FDRSOS disk including the initialization information, default profile values, and some diagnostics.

Selecting an particular FDRSOS disk from this panel retrieves and displays the profiles and backups for that disk in the second panel:

Setting Target - Get the List of Physical Disks

First set a target server for FDRSOS Management from the list of physical disks and manage the FDRSOS disks:

Select the system you wish to manage these local backup disks from the list of available systems.

The two FDRSOS Management panels are designed to get and display information in stages from the target server after setting a target. Information is gathered by doing read operations against the physical disks installed at the target server. Before selecting the target system, be aware of the two preliminary operations this initiates automatically.

The first operation performed after the target is set is to get the list of physical disks itself - with this list the drop down combination box labeled “Disks” on the top left side of the FDRSOS Management panel is filled in and becomes available for selecting a particular disk to interrogate and display information about. A summary of the number of disks found is displayed in a message window displaying the results of this operation:

Once the combination box is filled in, the first entry or disk is automatically selected; so information about that disk is retrieved from the server next. The results of this are seen after this message window is dismissed by clicking OK. Another message window displays showing the results of the selected disk (the first entry in the “Disks” drop down combination box). This disk is interrogated (read) to determine if it is an FDRSOS disk or not and if so the FDRSOS information is gathered. The message window that pops up informs you which is the case.

Once this last message window is dismissed, if the first disk is not an FDRSOS Disk (almost always the case), the drive letter or name (depending on the OS type of the target server) is filled in next to the disk number in the drop down combination box.

Disk Selection, Finding and Displaying FDRSOS Information

Remembering that the FDRSOS Management panels are designed to get and display information in stages, after the target has been set, the only information available is the list of physical disks at the target server. Only the first one has been interrogated and this is probably not an FDRSOS disk and therefore no FDRSOS disk information is displayed.

Next, we might follow one of the two suggestions of the message box displaying the physical disk count that were either: to select Find All SOS Disks or use Find to search for an FDRSOS disk by volume serial name. Either of these may be appropriate but there is yet another alternative, that is to merely use the Disks drop down combination box list to select a particular physical disk that is interrogated. This was done automatically to the first disk in the list when the target was set. This selection results in reading the particular physical drive to discover whether it is or is not an FDRSOS disk and if so, the FDRSOS information is read and displayed. So there are three different ways to discover what physical disks are FDRSOS disks and to display the FDRSOS information on them.

Let’s look at this last method, which is to just select one of the disks from the Disks drop down combination box list. This is useful when we know which physical addresses are SOS Disks and we only want to interrogate that particular disk. Selecting a disk results in discovering if the physical address is an SOS Disk or not and then displays SOS information if it is:

Depending on the target system operating type, additional information is added when possible; in this case the target was a Windows system so the drive letter was filled in. If the disk we select is in fact an FDRSOS disk we would get the message box reporting this and the disk is added to the list below:

The third physical disk selected is an FDRSOS disk and is reported as such. It is added to the FDRSOS Initialized Disks drop down combination box list and added to the display list below. Notice how in the display list the FDRSOS information is not yet filled in, this is because as stated earlier, information is interrogated from the disk at the target in stages. When the message box is dismissed by pressing OK, the FDRSOS Information is gathered and filled in:

As we see, whenever we find an FDRSOS disk to put in the list, the detailed FDRSOS information is not filled in unless the disk is selected using either of the combo boxes or by clicking on the header line “Information/SOS Disks” along the top. This line is a row of buttons that can be selected by clicking once on them.

Next lets look at the second and most convenient method which is to just find all the FDRSOS disks in one operation. Pressing Find All SOS Disks causes all the drives to be interrogated to discover which ones are indeed FDRSOS initialized disks. This operation ONLY builds the list of FDRSOS Disks but does not yet read and display FDRSOS information for any disk but the first (selected) one at this point. The progress of interrogating all the drives at the target server is shown in a status line at the bottom of the panel:

When finished, a message box is displayed giving the results (count of FDRSOS disks):

After dismissing this message by pressing OK, the list of FDRSOS disks is shown and the FDRSOS disk information for the first FDRSOS disk is displayed:

As noted before, the row header titled “Information / SOS Disk” contains a set of buttons for each FDRSOS disk to select. Once selected, the FDRSOS detail information is filled in:

Whenever an FDRSOS disk is selected, the FDRSOS information is filled in. Also, the corresponding Profiles and backups are displayed in the partner panel “SOS Backup Profiles”. Instead of selecting each FDRSOS disk to fill in the information, you can have all the information for every disk filled in by pressing the Get All SOS Disk Init/Profile Info button:

This causes all the information to be gathered from every disk and filled in:

The last method we have for displaying FDRSOS disk information is to search for it by the z⁄OS Volume Serial name given to a disk when it was initialized as an FDRSOS disk. We most often know the FDRSOS disk by its initialized volume serial name and so we can search for it by this name:

Once you type in a name to search for, the Find button is enabled for you to click it and start the search:

If found, the FDRSOS disk information is displayed.

Default Profile Settings, Profile and Backup Display and Management

The default profile control and settings are displayed in the rows following the row titled “Default Profile Settings” and are shown outlined below.

Whenever the control setting “Dynamically Add Profile(s)” is “Yes” and an FDRSOS backup is performed with an undefined profile, a new profile is created with these settings. You can update the control settings and these default parameter settings by selecting an SOS Disk and clicking the Update Default Profile button; the following dialogue is displayed:

You can click Update to make the changes or Cancel to abort and changes.

Whenever a FDRSOS disk is selected with either the “Disks” or “SOS Initialized Disks” drop down combination boxes or by clicking the header button for the FDRSOS disk, the current defined profiles and profiles dynamically added are displayed in the partner panel “SOS Backup Profiles” for that selected disk:

This panel also uses a drop down combination box (labeled “Profiles”) and a header row of buttons for profile selection. The backups done with the selected profile are displayed in a list below. In this case there are none and so the Delete Profile button is enabled for you if you care to delete the selected profile. You may update the profile selected (Update Profile button) or you may define a new profile (Add Profile button):

To update a profile, make the desired changes and click the Update button or click the Cancel button to abort any changes.

To add a new profile, you must first type in a name (1-8 characters) that enables the Add button that you can press after you have set all the profile settings you desire. The Cancel button aborts any profile creation.

Any backups taken with the selected profile are listed in the table in the lower half of the panel. In the following case there was one backup taken (and kept) with the profile “BAHNT”:

Any backup displayed may then be selected by clicking on the row to highlight it and then press the Delete Backup button.

UPSTREAM and FDRSOS

Introduction

UPSTREAM can be used in concert with FDRSOS to use FDRSOS’ ability to provide high speed backups and restores of complete EMC or IBM attached disk drives with UPSTREAM’s ability to provide incremental backups and restores.

In the recommended scenario, FDRSOS or the physical disk backup facility in the UPSTREAM Client is used regularly (generally weekly) to provide a backup of your EMC or IBM drives. UPSTREAM incremental backups are run daily to provide recovery to a given point.

Whenever possible, we recommend the regular use of UPSTREAM full merge backups so that selective file restores as well as FDRSOS high speed disaster recovery restores can be performed. However, if tape drive or time issues force it, you can use UPSTREAM incremental merges exclusively.

When a disaster occurs, you restore, using FDRSOS, the entire drive. Using UPSTREAM, you then restore the files modified since the FDRSOS backup.

Two options in UPSTREAM have been added to facilitate this feature:

• A backup option in the File Spec More dialog allows you to create a “FDRSOS Timestamp File”.
• A restore option allows you to specify a restore back to this Timestamp file.

To complement the FDRSOS facility, UPSTREAM can be used to:

• Create physical disk backups for later physical disk restore.
• Restore FDRSOS backups over the network.

FDRSOS Timestamp File

There is an option in the Backup, File Spec, More dialog: Write FDRSOS Timestamp. If checked, UPSTREAM places a FDRSOS Timestamp file in the directory specified for the backup spec, or in any user specified directory.

A FDRSOS Timestamp file is zero length, has standard system attributes, and is of the form:

here <Backup Profile> is the specified backup profile name.

If you do not specify a FDRSOS Timestamp directory, the file is placed in the directory specified for the backup. For example, if you specify C:\*.*, the FDRSOS Timestamp file is placed in C:\. For UNIX systems the Timestamp file is placed in the top level of each file spec as well as in the top level any file systems mounted below each file spec.

For restores, UPSTREAM searches for the FDRSOS Timestamp file in the directory specified for the restore, and works its way upwards until it reaches the root. For example, if you wish to restore 

C:\Dir1\Dir2\Dir3\File.DAT, UPSTREAM searches for the FDRSOS Timestamp file in 

C:\Dir1\Dir2\Dir3, then C:\Dir1\Dir2, then C:\Dir1, and finally C:\ until the file is found. If you specify a particular directory, that directory is used exclusively.

The important information stored in a FDRSOS Timestamp file is its modification date/time. The date of the file is the host defined version date of the backup and it is used during a restore as the date/time of the last UPSTREAM backup before the disaster recovery FDRSOS restore.

You should check this box for all disks which are included in both UPSTREAM and FDRSOS backups. The user specified path can be left blank in most cases except those where security or other reasons make it difficult to store files in the directory specified for the backup. In this case, you need to verify that this directory is properly specified for both the backup and the restore.

Highlighted Back to FDRSOS Full

There is a radio button option in the restore parameters dialog, Highlighted Back to FDRSOS Full. If selected, the workstation/server software extracts the modification date/time of the FDRSOS Timestamp file and the host software transmits files in backups that were performed since that date.

Thus, the FDRSOS Timestamp file is a signature on the disk of the last UPSTREAM backup. When FDRSOS is run, it places this signature back as part of its normal processing and UPSTREAM uses it to determine the date/time of its last backup.

Note that the FDRSOS Timestamp file should not be removed. UPSTREAM does not include these files in normal backups. If you perform a non-UPSTREAM restore of files which would include the FDRSOS Timestamp file, you should either specifically exclude it or recognize that you are placing the FDRSOS state of the disk for UPSTREAM at an earlier date.

There is a personalization option to disallow FDRSOS features.

UPSTREAM and Physical Disks

UPSTREAM can be used to restore FDRSOS created backups as well as create its own physical disk backups. See Physical Disk for more information about these features.

FDRSOS Windows Considerations

Introduction

FDRSOS includes a facility where a Windows attached EMC or IBM drive (one or more) can be locked throughout an FDRSOS backup or restore. This facility also assures that if the operating system definition of the drive is changed because you have restored a different drive to it, the operating system information about the drive is refreshed.

This facility is useful when implementing FDRSOS during:

• A backup when you wish to assure that the drive(s) are not being accessed and you wish to guarantee the integrity of the data.
• A restore when you wish to assure that no users are going to be affected during the restore process.
• A restore when you are restoring an older version of an entire drive (or drives) or when you are moving the backed up contents of a drive to a different drive and wish the operating system to be notified without having to shut down the operating system.

The drive can remain locked until:

• A user presses a key.
• A predefined timeout occurs.
• Another program is run that tells the first program to unlock the drive.

Note that the drives must be of the same size when restoring a drive to a different location.

There are two programs in this facility: UNMOUNT and REMOUNT.

Installation

The FDRSOS disk consists of only a few files. Merely create a directory and copy the files into them:

md \soscopy a:\nt\*.* c:\sos\*.*

or for a DVD installation:

md\soscopy d:\sos\nt\*.* c:\sos\*.*

The files are (relative to the root of the diskette or the \SOS directory on the DVD):

GENDATA.EXE

A test data generation program provided to help you generate a large amount of data quickly.

NT\REMOUNT.EXE

Allows you to, from a separate program at a later time, unlock a previously locked set of drives.

NT\UNMOUNT.EXE

Allows you to lock and dismount one or more drives.

NT\UNMOUNTX.EXE

An internal program, not to be called directly.

The newest version of all BMC workstation/server software is available on the FDRSOS diskette, UPSTREAM DVD or by request from your sales representative.

UNMOUNT.EXE

This is the program that can lock one or more drives and then forces an operating system refresh of the drive information when it is unlocked. It is a 32-bit Console program. Contact BMC Support for more information to run this program as a service.

Unless the /p option is specified, UNMOUNT must be left running during the backup or restore to assure that the drive is locked. During testing, verify that the drive is locked during SOS operations by attempting an access to the drive on the Windows machine (with a DIR command for example) and you should get an “Access is denied” error.

This program fails if ANY programs are accessing the drive. You must assure that all users and programs have closed all open files on the drive to be locked before running the program. The program writes an error to the screen and return a non-zero program return code if there are any errors.

Run this program from an MS-DOS prompt or a batch file. Its format is:

Where:

<drive letter:>

Is a list of one or more space separated drives to be locked. For example: C: or E: F: G:. At least one drive letter must be specified.

/n<name>

Is an optional parameter that allows you to specify the semaphore name used when running REMOUNT. You only need to specify this parameter if you are running REMOUNT and you wish to run, simultaneously, more than one copy of UNMOUNT.EXE at a time. For example: /nREMOUNT2.

/k

Is an optional parameter that locks the drive until the user presses a key.

/w<time>

Is an optional parameter that locks the drive for a given number of seconds. For example, for 5 minutes, specify /w300.

/p[<pgm>]

Is an optional parameter that causes UNMOUNT to terminate when the drive is locked. The drive remains locked until REMOUNT is run. The optional program parameter <pgm> allows you to specify a different program name than UNMOUNTX; for example, to specify UNMOUNTX on the D: drive, specify /pD:\UNMOUNTX.EXE. Most users do not use the optional <pgm> parameter and specify /p alone.

The /p option is particularly useful, as UNMOUNT returns a program return code that can indicate to you whether the drive was successfully locked.

/f

Is an optional parameter that has UNMOUNT merely open the drives specified, flush all the buffers to disk and return. This is useful if you know that you can not unmount the drive but wish to get all the integrity you can.

If you wish to lock the drives D, E, and F until REMOUNT is run, specify:

If you wish to lock the drive D: until a user presses a key, specify:

If you wish to lock D and E, but unlock them with REMOUNT at separate times, specify:

UNMOUNT D: /nDDRIVEUNMOUNT E: /nEDRIVE

If you wish to create a batch file that unmounts the C: drive, checks the return code and returns, it might look like:

REMOUNT.EXE

Run this program when you have run UNMOUNT and wish UNMOUNT to unlock the drive and refresh the operating system’s view of it. It must be run in a separate MS-DOS prompt session as UNMOUNT.

Its form is:

Where:

Is an optional parameter and is the same name specified when UNMOUNT was run.

In the example above, where UNMOUNT was run to lock D: E: F:, to unlock the drive, run:

If the example above where you wish to unmount the drives separately run:

REMOUNT /nDDRIVEREMOUNT /nEDRIVE

Both UNMOUNT and REMOUNT return 1 if they fail and 0 if they succeed.

Non Disruptive Backups Using BCVs or FlashCopy

TimeFinder is an EMC feature that supports a fast point in time copy of volume onto a mirrored disk. The IBM feature that provides similar function is named FlashCopy. In TimeFinder or FlashCopy there is a standard volume which contains the data to be backed up.

The examples below are for EMC BCVs. Similar functions exist for IBM FlashCopy.

A Business Continuance Volume (BCV) is a mirror of the standard volume which is set “not ready” while it is an active mirror. A TimeFinder command can cause the volume to be split, at which point it becomes addressable as a separate volume.

This section discusses using a BCV to perform a file level backup on Windows using basic disks. See the EMC documentation for a description of the techniques for dynamic disks. All the BCV operations can be performed using batch files, thus making the entire operation automated.

Before beginning:

• You must have EMC Control Center and Solutions Enabler with the TimeFinder component installed on your system. You also need the EMC ResourcePak for Windows that includes the System Integration Utilities. The TimeFinder component must also be installed on the EMC storage array as well. See your EMC representative for details concerning its configuration.

You need to add the EMC CLI and Utilities directories to the your PATH environment variable. Assuming you installed EMC Control Center and Solutions Enabler on the C: drive:

C:\Program Files\EMC\SYMCLI\binaries

C:\Program Files\EMC\Utilities for Windows

• 93_List1_Bullet_1113944 • You also must have certain information about your EMC disks. You must know which disks are configured as ‘standard data volumes’, and which are configured as BCVs. Your EMC CE generally configures the EMC storage array and can give you this information.

The commands discussed below are detailed in the following EMC manuals.

• EMC Solutions Enabler, SYMCLI Base Component Product Guide

• EMC Solutions Enabler, SYMCLI TimeFinder Component Product Guide

• EMC Control Center, Symmetrix Manager for Windows NT Product Guide

• EMC ResourcePak for Windows Product Guide

Setup Procedures

You need to create a device group and associate the disks you’ll be using to that group, once after you’ve chosen the disks you’ll be using.

• Prepare the disks. Using the information from your CE determine, by physical disk and SYM number, which disk you are using as standard volume and which one is the BCV. Both disks must be the same size. Using the Disk Administrator verify that the BCV disk has assigned a drive letter. If it does not, create a single large partition for the disk, format it and assign it a drive letter to the volume.
• Create a device group. An EMC Device Group is simply one or more logical disks, which you then operate on using a single command. Many of the EMC commands require that the disks be in a device group. The procedure is to create the device group and then associate the standard volume and the BCV with the device group name.

Device groups are created at a command prompt using the EMC symdg program. Its syntax is:

For example, to create the device group labtest, enter from a command prompt:

You can verify the group was created using the command symdg list.

• Add the standard volume to the device group. After creating the device group, add the standard volume to it using its Windows device name.

The Windows device name uses the format:

<number> is the Disk Administrator number for the disk. Optionally a logical name can be added to the disk; one is created for you if you do not. Use the symld program. Its syntax is:

symld –g groupname add pd physical_disk_name logical_name

For example, to add the physical disk #3 as the standard volume to the device group labtest with the logical name real_data:

• Associate the BCV volume to the device group. In similar fashion to adding a standard volume, associate the BCV volume to the device group. Optionally a logical name can be added to the disk. One is created for you if you do not.

Use the program symbcv, which has the following syntax:

For example, to associate physical drive #9 to the device group labtest with the logical name bcv_data:

• Verify the device group. The disks that make up the device group as well as the status of the group can be verified with the following commands:

The above procedures only need to be done once, unless the disks are changed or the group configuration becomes corrupt.

Performing Backups

The following procedures need to be performed for each backup.

• Save the Windows disk signature. Before synchronizing the disks, it is necessary to save the Windows disk signature. Once the establish command is performed, the BCV is an exact replica of the standard volume, including the disk signature. Windows was not designed to have two disks with the same signature therefore, the signature must be saved so you can later restore it before bringing the volume back on line. In fact, saving and restoring the disk signature must be part every “Split-establish” operation.

The EMC command line program symntctl is used to save the signature. Its syntax is:

For example, to save the signature for disk #9.

• Unmount the BCV disk. Before synchronizing the disks, unmount the BCV volume. At this point, the disk is not addressable from the operating system. Again, use the symntctl command line program. For the unmount command, use the drive letter rather than the physical disk number. The syntax is:

For example, to unmount the h: drive:

• Establish the disks as a “BCV Pair”. At this point, the disks are ready to be synchronized, making the BCV an off-line mirror of the standard volume. The first time a “BCV Pair” is synchronized, it must be done with the symmir establish command, using the –full option, which causes all the data on the standard volume to be written to the BCV. You can also use the Control Center GUI.

Subsequent establish actions do not need the –full option as long as the symmir split command uses the –diff option, which causes a differential split. When the –diff option is used during a split, and the -full option is NOT used during the subsequent establish command, only the changed tracks are synchronized, thus making the operation faster.

The syntax of the symmir command line program is:

For example, to perform the establish on the group labtest:

• Split the BCV Pair. At this point you have a fully functioning BCV Pair. The BCV volume is not addressable from the NT system. The Windows explorer program does not see the disk, and the Windows Disk Administrator lists it as “off-line, no configuration information available”. To back up the data on the BCV volume, it must be made addressable to the operating system.

This is performed using the split command with the symmir program. This breaks the “mirror”, which is the first step in making the disk addressable to the operating system. Use the –diff option to perform a differential split, which makes subsequent establish and split operations more efficient by only updating the changed tracks. The syntax of this command is:

For example, to split the volume group labtest:

• Restore the Disk Signature. You must restore the original disk signature, as Windows was not designed to handle two disks with the same signature. Use the signature command with the symntctl program. Its syntax is:

For example, to restore the signature of disk #9 saved previously:

• Mount the BCV Volume. This is the last step to make the BCV volume addressable to the operating system. Mount the disk and associate it with a Windows drive letter. Use the mount command with the symntctl program. The syntax is:

For example, to mount the h: drive on disk #9:

At this point the disk is fully addressable from the operating system. The disk can be seen in the Windows Explorer program and the Disk Administrator. The data can now be backed up using UPSTREAM or UPSTREAM SOS on this disk by targeting the NT drive letter used to mount the disk.

The archive bit can not be used as a reliable technique to determine changed files as the archive bits along with all other data is constantly being refreshed from the primary. So we recommend using the MODIFYFILE technique (the incremental determination technique used by UPSTREAM in UNIX) rather than archive bits and we recommend that you disable resetting archive bits in your backup. Thus in your parameter files, in the overall specs, specify:

To disable resetting archive bits, in each file spec, specify:

After the backup is complete, you can re-establish the disks as a “BCV Pair”

Samples

This process can be automated by putting the commands in a batch job and using UPSTREAM’s PREJOB and POSTJOB options. The following are sample batch jobs to do this. This assumes that there are no databases being backed up. Database backups require additional handling; see the EMC documentation for more information. These samples also assume that the disks have been fully established at least once using the -full option and generally remain established except while being backed up.

UPSTREAM pre- and post- processing jobs require that the program name to execute be fully qualified. The examples below assume the default directory for the EMC programs.

Sample Pre-process Job

This batch job splits the BCV Pair, restores the NT disk signature to its original value and mounts the volume to a NT drive letter. This is done before performing the backup.

Note that this job assumes that the disk signature from the BCV has been saved, the BCV unmounted, and the disks established. In other words, that the steps above and those in the post-process job have been done previously. Thus, if you are running this for the first time, you should independently run the post-process job before running the backup (with its embedded pre-process job).

Sample post process job. This batch job saves the NT disk signature, un-mounts the volume and re-establishes the disks as a “BCV Pair”.

Restores

Assuming that you used UPSTREAM to perform file-level backups of the data, you’ll similarly use UPSTREAM to perform restores. Files should be restored to the source volume rather than the BCV. Note that the drive letter as stored in UPSTREAM is likely different than the destination.

FDRSOS AIX Considerations

Introduction

To use FDRSOS to back up or restore AIX attached EMC drives there are recommended procedures that help to guarantee that the data is complete and correct and that the operating system is properly notified.

Recommended procedures are provided for:

• Backup.
• Restoring disks to their original locations.
• Restoring one or more physical disks to different locations and scratching the original disks.
• Restoring a single volume “volume group” as a copy on the same system.
• Restoring a multiple volume “volume group” as a copy on the same system.

Note that coordination for the sequencing of host and workstation/server automated procedures is provided by UPSTREAM. UPSTREAM's USTBATCH host facility allows you to integrate workstation/server batch jobs into your host scheduling facilities. And UPSTREAM's host job execution facility allows host batch jobs to be executed from workstation/server automation. This allows you to coordinate the workstation/server procedures below with the execution of FDRSOS on the host. See z/OS Initiation with USTBATCH and Advanced UPSTREAM for more information.

Recommended Backup Procedure

•  Unmount ALL active file systems in the volume group and/or shutdown any applications using the physical disk(s) or logical volume(s) on the physical disk(s) in RAW mode. You can use smit umountfs or the umount command to unmount file systems.

If the file systems can not be dismounted, you should insure that all cached I/O has been flushed out to the disk. Also, you should insure that no one is writing to the file system during the backup.

• If the physical disk(s) are in a volume group, deactivate the volume group. You can use smit varyoffvg or the varyoffvg command to deactivate a volume group. Again, if you can not deactivate the volume group, flush all I/Os to disk and verify that no users are writing to the file system.
• Run the SOS backups.
• Activate the volume group if the physical disk(s) are in a volume group. You can use smit varyonvg or the varyonvg command to activate a volume group.
• Remount the file systems. You can use smit mountfs, smit mountg (if the file systems have been assigned to a group), or the mount command to mount a file system.
• Restart the applications (if any) that were using the physical disk(s) or logical volume(s) in RAW mode.

Restoring One or More Physical Disks to Original Locations

• Unmount ALL active file systems in the volume group and/or shutdown any applications using the physical disk(s) or logical volume(s) on the physical disk(s) in RAW mode that are to be used for the restore. You can use smit umountfs or the umount command to unmount file systems.

• If the physical disk(s) are in a volume group, deactivate the volume group. You can use smit varyoffvg or the varyoffvg command to deactivate a volume group.
• Run the SOS restore. If you are restoring a multiple volume “volume group”, you MUST restore all the volumes in the volume group.
• Activate the volume group if the physical disk(s) are in a volume group. You can use smit varyonvg or the varyonvg command to activate a volume group.
• Remount the file systems. You can use smit mountfs, smit mountg (if the file systems have been assigned to a group), or the mount command to mount a file system.
• Restart the applications (if any) that were using the physical disk(s) or logical volume(s) in RAW mode.

Restoring One or More Physical Disks to Different Locations and Scratching the Original Disks

• Unmount ALL active file systems in the volume group and/or shutdown any applications using the physical disk(s) or logical volume(s) on the physical disk(s) in RAW mode. You can use smit umountfs or the umount command to unmount file systems.

•  If the physical disk(s) are in a volume group, deactivate the volume group. You can use smit varyoffvg or the varyoffvg command to deactivate a volume group.
• If the physical disk(s) are in a volume group, export the volume group. You can use smit exportvg or the exportvg command to export a volume group.
• Clear the physical volume id’s (PVID’s) from both the original and target physical disk(s) BEFORE running the restore. This is VERY important. AIX does not tolerate duplicate physical volume id’s. To clear a PVID, use the following form of the chdev command:

hdisk# represents the name of the physical volume such as hdisk5.

• Run the SOS restore. If you are restoring a multiple volume “volume group”, you MUST restore all the volumes in the volume group.
• If the physical volume(s) are in a volume group, you must assign the physical volume id’s of the restored physical volume(s). Note that physical volume id’s are the physical volume id’s of the original volumes. Use smit chgdsk for EACH target volume. Make sure you change ASSIGN physical volume identifier to yes. AIX uses the physical volume identifier found on the restored volume.
• If the physical volume(s) are in a volume group, import the volume group. You can use smit importvg or the importvg command to import a volume group.
• Remount the file systems. You can use smit mountfs, smit mountg (if the file systems have been assigned to a group), or the mount command to mount a file system.
• Restart the applications (if any) that were using the physical disk(s) or logical volume(s) in RAW mode.

Restoring a Single Volume “Volume Group” as a Copy on the Same System

• Ensure that target volume has been assigned a physical volume id BEFORE running the restore. Use smit chgdsk to display the physical volume id of the target volume. If it already has one, then cancel out of this smit screen. If not, change ASSIGN physical volume identifier to yes and perform the change.
• Run the SOS restore using the VOLRESET=NO option. SOS preserves the physical volume id. To allow you mount the file systems on the copy at the same time as the originals, SOS changes the mount points of all file systems during the restore by appending _sos to the original mount point.
• For example, if the original volume group had a file system with a mount point of /myfilesys, SOS changes it to /myfilesys_sos. This change is picked up by AIX when the volume group is imported.
• Import the volume group. You can use smit importvg or the importvg command to import a volume group. Note that you can not use the name of the original volume group. You must assign a new name.
• You can now mount the file systems on the new volume group. Remember that the mount points need _sos appended to the original mount point.

Restoring a Multiple Volume “Volume Group” as a Copy on the Same System

• Clear the physical volume id’s (PVID’s) from target physical disk(s) BEFORE running the restore. To clear a PVID, use the following form of the chdev command:

hdisk# represents the name of the physical volume such as hdisk5.

• Run the SOS restore using the VOLRESET=NO option. You MUST restore all the volumes in the volume group. SOS assigns new physical volume id’s to all the volumes in the volume group. To allow you to mount the file systems on the copy at the same time as the originals, SOS changes the mount points of all file systems during the restore by appending _sos to the original mount point.

For example, if the original volume group had a file system with a mount point of /myfilesys, SOS changes it to /myfilesys_sos.

This change is picked up by AIX when the volume group is imported.

• You must assign the physical volume id’s of the restored physical volume(s). Note that physical volume id’s are the physical volume id’s set by SOS. Use smit chgdsk for EACH target volume. Make sure you change ASSIGN physical volume identifier to yes. AIX uses the physical volume identifier found on the restored volumes.
• Import the volume group. You can use smit importvg or the importvg command to import a volume group. Note that you can not use the name of the original volume group. You must assign a new name.
• You can now mount the file systems on the new volume group. Remember that the mount points have _sos appended to the original mount point.

Problems with Failed Backups Caused by Reserves

There are known problems with the EMC Control Center program on AIX, where it periodically sets a reserve on all disks. This causes UPSTREAM SOS backups to fail.

To address this, you can set the UPSTREAM environment variable USAIXRESERVEDISK to any value, which causes UPSTREAM itself to put a SCSI reserve on the UPSTREAM SOS local backup disk. If you are running AIX 5.2 or above, you may also need to set the environment variable USAIXLOCKDISK to any value as well. If you set this option, UPSTREAM locks out any other systems from being able to use the disk during the operation. This option is never recommended when a local backup disk is shared by any other system besides AIX as most operating systems do not properly support SCSI reserves.

FDRSOS HP-UX Considerations

Introduction

To use FDRSOS to back up or restore HP-UX attached EMC drives, there are recommended procedures which help to guarantee that the data is complete, correct and the operating system is properly notified.

Recommended procedures are provided for:

• Backup.
• Restoring disks to their original locations.
• Restoring one of more physical disks to different locations or as a copy on the same system.

Recommended Backup Procedure

• Unmount ALL active file systems in the volume group and/or shutdown any applications using the physical disk(s) or logical volumes(s) on the physical disk(s) in RAW mode. You can use SAM utilities or umount command to unmount the file systems.

If the file systems cannot be dismounted, you should insure that all cached I/O has been flushed out to the disk. Also, you should insure that no one is writing to the file system during the backup.

• If the physical disk(s) are in a volume group, deactivate the volume group. You can use SAM utilities or the vgchange command to deactivate a volume group. Again, if you cannot deactivate the volume group, flush all I/Os to disk and verify that no users are writing to the file system.
• Run the SOS backups.
• Activate the volume group if the physical disk(s) are in a volume group. You can use SAM utilities or the vgchange command to activate a volume group.
• Perform ‘file check’ on the unmounted file systems to insure integrity. For example:

• Remount the file systems. You can use SAM utilities or the mount command to mount a file system.
• Restart the applications (if any) that were using the physical disk(s) or logical volume(s) in RAW mode.

Restoring One or More Physical Disks to Original Locations

• Unmount ALL active file systems in the volume group and/or shutdown any applications using the physical disk(s) or logical volume(s) on the physical disk(s) in RAW mode that are to be used for the restore. You can use SAM utilities or the umount command to unmount file systems.

• If the physical disk(s) are in a volume group, deactivate the volume group. You can use SAM utilities or the vgchange command to deactivate the volume group.
• Run the SOS restore. If you are restoring a multiple volume “volume group”, you MUST restore all the volumes in the volume group.
• Activate the volume group if the physical disk(s) are in a volume group. You can use SAM utilities or the vgchange command to activate a volume group.
• Perform file check on the unmounted file systems to insure integrity. For example:

• Remount the file systems. You can use SAM utilities or the mount command to mount a file system.
• Restart the applications (if any) that were using the physical disk(s) or logical volume(s) in RAW mode.

Restoring One or More Physical Disks to Different Locations

• Unmount ALL active file systems in the volume group and/or shutdown any applications using the physical disk(s) or logical volume(s) on the physical disk(s) in RAW mode that are to be used for the restore. You can use SAM utilities or the umount command to unmount file systems.

• If the physical disk(s) are in a volume group, deactivate the volume group. You can use SAM utilities or the vgchange command to deactivate the volume group.
• If the physical disk(s) are in a volume group, export the volume group. You can use SAM utilities or the vgexport command to remove the volume group. The use of the vgexport mapfile parameter is recommended to retain the logical volume names for the vgimport. Otherwise the system creates default logical volume names of ‘lvol1, lvol2, etc.’.

• Run the SOS restore. If you are restoring a multiple volume “volume group”, you MUST restore all the volumes in the volume group.
• Recreate the target volume group directory and target group file using the following commands:

mknod /dev/vg_xxxx/group c 64 0xNN0000
NN is unique ‘minor number’ relating to volume group #

• Import volume group using SAM or the following command:

• Activate the volume group if the physical disk(s) are in a volume group. You can use SAM utilities or the vgchange command to activate a volume group.
• Perform file check on the unmounted file systems to insure integrity. For example:

fsck -F vxfs -o full …

fsck …

• Remount the file systems. You can use SAM utilities or the mount command to mount a file system.
• Restart the applications (if any) that were using the physical disk(s) or logical volume(s) in RAW mode.

FDRSOS Solaris Considerations

This is required to “harden” the data and insure that all data is written to the disk, as described in Section 220.11 in the FDRSOS manual. If a backup is done with a file system then a restore of that backup may result in down-level data or other errors.

Restoring to an Alternate Volume

If you wish to restore backups of SUN Volume Manager disks to spare disk volumes (as described in Section 220.14 of the FDRSOS manual), use this procedure:

1. If the spare volumes are currently known to the SUN volume manager, usually because you have previously used them as the target of a FDRSOS restore, you must unmount the file systems on those volumes and deport the volumes before doing the restore.
2. Do the FDRSOS restore, to the spare disk volumes, with the VOLRESET=NO parameter. FDRSOS changes the internal volume name and volume group ID to make them unique. It also makes the volume group name unique by overlaying the first character of the volume group name with an underscore; for example, if the group name was “testgroup”, VOLRESET=NO changes it to “_estgroup”.
   If the underscore is not acceptable or does not result in a unique group name, you can specify the FDRSOS parameter “SUNGROUPID=xxx” on the MOUNT statement for the output volume. “xxx” is 1 to 3 characters; these characters are made lower case (even if entered in upper case) and used to overlay the beginning of the group name. For example, SUNGROUPID=TMP changes “testgroup” to “tmptgroup”. You must use the same SUNGROUPID value while restoring all volumes in the group.If you specify PRINT=STATUS on the RESTORE statement, FDRSOS displays the group and volume names before and after the restore; the after display shows the modifications described above.
3. If the spare volumes were not previously managed by the SUN volume manager, you must refresh the volume manager so that it recognizes the new volumes. From the root user, issue:
   vxdctl enable
4. Import the volume group using the new group name set by FDRSOS (step 2 above). You can use the GUI interface of the volume manager (vxva), the menu interface (vxdiskadm), or the vxdg command. For the latter, issue from the root user:
   vxdg import _estgroup

5.  Start the volumes in the group you just imported. You can either start specific volumes or all the volumes. You can use the GUI or menu interfaces of the volume manager, or the vxvol command. For the latter, issue from the root user:
   vxvol -g _estgroup volume_name (for a specific volume)

   vxvol -g _estgroup startall (for all volumes)
6. Mount the file system(s) on the started volume(s). You can use either the GUI interface of the volume manager, or the mount command.

To use the mount command, you should refer to /etc/vfstab for the options used to mount the original file system. You need to create a new mount point and use the new device name and new mount point to mount the file system. Volume manager device names for a given volume are:

To mount a SUN (Veritas) file system on a volume named “vol01” that is in the disk group restored as _estgroup at mount point /test, issue this command:

At this point the files on the restored volumes should be accessible.

Warning on Use of RESERVE=YES

We have found that the use of RESERVE=YES on DUMP statements may cause problems if the Open System using the volumes you are backing up is sensitive to a long term RESERVE on the volume. If the volume may still be in use on the Open System during the FDRSOS backup, you may need to omit RESERVE=YES (or specify RESERVE=NO). This is most likely to be a problem if the Open System volume involved is a system volume to the Open System (e.g., the boot volume).

In particular we have found that Sun Solaris systems fail if their system volumes are reserved for long periods of time.

However, this may also be true for other Open System or for application-type volumes (such as data bases).

Certainly it is true that doing a long-term RESERVE on a system or application volume probably causes that system or application to hang until the backup is complete.

The default on a DUMP is RESERVE=NO.

Initializing the Local Backup Disk on Sun SPARC

To use FDRSOS local backup volumes with UPSTREAM SOS on a SUN Solaris system running on a SUN SPARC platform, a special procedure must be followed. This does not apply to Solaris running on an Intel-type platform.

1. The disk is brand new, never before used, you should erase the disk completely with the FDRSOS ERASE TYPE=FULL function. This step is not required with the SAN Express Passthru.

2.  From the SUN system, you must format the disk volume and specify a volume name of “FDRSOS”. To do so:

   1. Use the “format” command to format the disk. “format” lists the disks available to the system; selects the disk to be used for local backups.
   2. Use the “volname” subcommand to assign a volume name of “FDRSOS” to the volume. The volume must be named FDRSOS; using any other name results in UPSTREAM SOS being unable to initialize the volume.
   3. Use the “partition” subcommand to delete all partitions on the volume except the “backup” partition which must be partition 2. For every partition whose “tag” is other than “unassigned”, you must modify that partition to mark it “unassigned” and change its starting and ending cylinders to 0 (zero).
   4. When done you can use the “verify” subcommand to verify that the volume is correctly initialized. The output looks something like this:

   format> verify
   
   Primary label contents:
   

3. Use the FDRSOS LOCALBACKUP function to make the formatted disk as a FDRSOS local backup or if you are using the SAN Express Passthru use the Director to format the disk.

Linux x86 Local Backup Support

You can now use UPSTREAM’s UPSTREAM SOS local backup disks on most x86 Linux systems. Previous versions of UPSTREAM required the raw interface. The current version does not. All disks can be addressed as character devices, eliminating the need for raw support. While still supported, new users are able to identify disks without using it.

Thus identification of local backup disks is as simple as letting the Director find all formatted disks.

Linux OS on IBMZ Local Backup Support

Once a fibre FBA disk that has been labeled and formatted with FDRSOS (or for the Reservoir is formatted in the Director) has been made visible to Linux OS on IBMZ UPSTREAM is automatically detect it. The key is the set of steps necessary to make a disk visible to the Linux OS on IBMZ device tree.

This process is described in the IBM redbook Fibre Channel Protocol for Linux and z⁄VM on IBM IBMZ available at:

• http://www.redbooks.ibm.com/abstracts/sg247266.html?Open&pdfbookmark

Some notes from our local installers here include:

1. The VM directory for the guest machine needs to be updated to point to what SuSE calls a “Channel Number”. In our case the Fiber devices begin at F000. I'm using F004 for Hitachi disks, and F006 for EMC. It appears you don't need to use different numbers, but we recommend doing so to try and keep things somewhat isolated, and to try and avoid potential problems.
2. The Linux OS on IBMZ system needs to be re-booted after the VM directory entry is updated.
3. The new devices need to be defined to Linux OS on IBMZ. Using Yast2, after it starts, select Hardware > Zfcp. Enter the Channel Number, WWPN, and the zfcp-LUN. All the disks for each Channel No. have the same WWPN, the LUNs start at 0 and increment by 1 for each disk.
4. Be careful entering the WWPN, once you have entered information and pressed the NEXT key, there is no easy way to delete or change a mistake.
5. After you are done and have exited Yast2, you can issue a “cat /proc/scsi/scsi” and the new disks show up.
6.  Reboot Linux OS on IBMZ. Linux assigns names in the order it finds the disks. Starting out with 4 fiber disks, 1 tape, and then adding 8 disks (shown by a cat /proc/scsi/scsi command). After rebooting, the order changed. cat /proc/scsi/scsi listed 12 disks and 1 tape. Apparently all the disks are listed first, and then any tapes. This can be important for the UPSTREAM Reservoir because Reservoir uses the number visible in the /proc/scsi/scsi file for tape drives and libraries. Adding disks may affect tape and library names that may require re-association.