Spring World 2015

Conference & Exhibit

Attend The #1 BC/DR Event!

Summer Journal

Volume 27, Issue 3

Full Contents Now Available!

October 26, 2007

Logically or Physically Restored Data?

Written by  Walter Horodyski
Rate this item
(0 votes)

Restoring lost packs, minidisks, and data files is a critical component of any disaster recovery plan. The occurrences that precipitate the need to restore data are many and diverse, and contingency planners need to be aware that a number of backup and restore approaches are available. The exact approach taken in any given situation will depend on both the extent of the loss as well as the extent to which lost data needs to be restored.

Even so, some companies have not completely explored the various backup and restore techniques available that will let them minimize the time to recover their business operations after a disaster--or even after the smaller data losses that can occur on a daily basis. This is particularly the case in the VM operating environment.

VM has become increasingly popular in recent years because it offers end-users a flexible operating environment, allowing them a high degree of control over file creation and manipulation. However, what IBM did not provide with this system is an efficient way for operations to back up and restore inadvertently destroyed minidisks or corrupted files. The IBM restore utility called DASD Dump Restore (DDR) included with VM is not only slow--requiring about 30 minutes to backup or restore a single 3380/D pack--but also requires technical support staff involvement, particularly if trying to restore a user minidisk or file.

A number of products have evolved to fill the operations need to easily back up and restore lost packs, minidisks and files. But before making a product selection, contingency planners need to understand the various conditions which could lead to a restore requirement. Only then will they be able to know how best to respond to each of these situations and select the backup and restore product that meets their specific requirements.

There are two different ways to back up and restore data--logically or physically. Logical restores assume a “logical” view of the storage media which reflects the existence of the CMS file system in minidisks on that media. Physical restores, in contrast, make no such assumptions and view the media as unformatted with no internal data structure. In practice, logical restores are done on a minidisk by minidisk basis, while physical restores are done cylinder by cylinder.

Logical restores are the method of choice when, through human error, a file or minidisk is corrupted or erroneously deleted. With a backup and restore product, these situations are easily rectified by an interactive full-screen search for the name of the lost file or mindisk in an online catalog, and then by a function key request to direct a software restore.

A logical restore should also be favored if a head crashes. This may happen, for example, in conjunction with a head drive assembly failure--a hardware error that renders a volume on the disk unreadable. Since that volume may contain a number of end-user minidisks, restoring the user pack swiftly and efficiently is crucial to business operations. Again, with a logical restore, the name of the pack is entered from a front-end screen, a function key is pressed, and the volume is automatically restored to its most current status.

Logical restores are recommended in these three situations (file, minidisk, and user packs) because in each case the operating system and backup product capabilities are available. However, if the system pack fails, placing the operation in a standalone mode, a more complex restoration is required. This situation may also occur in the event of a disaster which renders the entire system inoperative.

In either of these cases, since the backup product and operating systems are unavailable, an initial program load (IPL) must be executed from a standalone tape. A physical restore can then be completed after mounting the backup tape and entering a single command. By comparison, a logical backup would require the systematic restoration of each minidisk individually by manually entering separate restore commands for each minidisk from a hard copy file listing.

Recovering from a disaster with logical restores requires significantly more time and steps to complete than physical restores. Pack names must be input before the restore can begin, and all volumes have to be labelled and formatted--a process that can take anywhere from three to 12 additional hours, depending on the expertise of the support staff. Additional time and human involvement may be required to format special system areas.

Under the stresses of a disaster recovery operation, it may not be wise to depend on human efficiency for business critical operations. For this reason, when operating from a hot-site after a disaster in a standalone mode, it is better to conduct physical backups.

Only when DASD capacity is limited at the hot-site backup facility is it better to include logical restores in an overall data recovery operation. In this case, complete a physical restore for business critical packs, and then do logical restores for individual minidisks and/or files on an as-needed basis.

Product performance factors are vitally important to contingency planners--but only in the context of their individual recovery requirements. If recovery windows are large, time may not be critical. But in most cases, disaster recovery plans exist for one reason: to ensure swift resumption of business operations.

To ensure that business recovery can be completed as fast as possible, planners should develop a data restoration plan that reflects their specific needs for logical or physical restores. Only then should they systematically review available backup and restore products and select the one that meets these specified requirements.


Walter Horodyski is the Software Development Manager with Syncsort, Inc.

This article adapted from Vol. 3 No. 4, p. 56.

Read 1817 times Last modified on October 11, 2012