14.2 Introduction to backup and restore

Companies establish backup and restore procedures against loss of data if:

• Users unintentionally delete or damage data.^[31]

  ^[31] Loss of data due to erroneously hitting a key is also known as a "finger check." In an early version of the S/360 Time Sharing Option (TSO), the command for editing a file was the single character E, while the command for deleting a file was a D. A glance at your keyboard will tell you why this short command for deletion was soon abandoned for the three-character command DEL.

• An operating system or application crashes.

• Hardware fails (for example, a disk head crash).

Linux on the mainframe allows for the usual schemes, including tape libraries and dual copy facilities, that are used for backup, restore, and disaster recovery. z/VM's data management tools can help you to physically isolate critical data on particular disks that can then be handled by z/VM disk copy tools.

The standard backup method is to copy data to tape at regular intervals. Tape allows you to recover an earlier version of data that have been lost by accidental deletion or damaged by a failing application. However, with this method, you lose all changes that have occurred since the time the last backup was made.

Maintaining two synchronized copies of current data (for example, by dual copy) is a backup method that always assures a current copy of your data. This protects you against a head crash, but not against accidental deletion or damage through a malfunctioning application.

Because backup activities can be disruptive and consume processing power, communication, and media resources, backup rarely covers all of a company's data. Backup is often limited to important data, which cannot readily be recreated. Generally, the more critical and dynamic the data, the more frequent the backups.

For a selection of tools to handle your backup and restore procedures, your choices range from developing your own solution, to leveraging the Open Source community or buying a solution. Amanda is one of the better-known examples of Open Source tools.

tar and ftp from Linux can supplement the formal backup and restore process for smaller amounts of data that are controlled by single or small groups of individuals.

14.2.1 Tape versus disks

In the past, backup meant tape. With disk space becoming cheaper, backups on disk are becoming a viable alternative to tape for some types of data.

Backups on disk can be restored with less latency than backups on tape. In addition, the mainframe allows you to connect an enormous number of storage devices, so that disk as a backup medium becomes an option.

Tape prevails where backups must be taken off-site and where floor space is limited.

14.2.2 Layout of backup infrastructure

Most backups are still written to tape. Because highly reliable tape devices can be costly, the typical server farm approach is to have a LAN-attached backup server with an attached tape device or library (Figure 14-4).

Figure 14-4. Backup server in a distributed server farm environment

If you have consolidated a server farm using Linux on the mainframe, you can continue to use the backup server on the LAN with its tape library (Figure 14-5).

Figure 14-5. Consolidated server farm with the backup server on the LAN

However, a LAN-attached backup server has disadvantages, including:

• Backup activities can overload a LAN and sometimes necessitate a separate LAN.^[32]

  ^[32] With Gigabit Ethernet, you are less likely to experience LAN overloads from the backup data.

• Moving backup data across the LAN is a potential security exposure.

With a consolidated server farm on a zSeries machine, you can also have directly attached tape devices (Figure 14-6). You can move data to the backup server through HiperSockets, which are secure, provide high bandwidth, and, being virtual, require no cabling.

Figure 14-6. Backup server on the mainframe

You can attach multiple tape devices to the same zSeries machine and perform multiple backup operations concurrently.

14.2.3 Restore

An important decision point for selecting a backup/restore tool is whether it satisfies your security requirements (for example, to control who can retrieve backed-up data). Before buying a tool, be sure that it can be integrated with your security checks.

Restoring a single file usually takes longer than backing it up, especially when the restore medium is a tape. The tape must be mounted, and the required data must be located by winding the tape to the correct position. The greater the tape capacity, the longer is the expected response time.

You can have faster response times by keeping the backed-up files on disk. By keeping the disk available to a Linux guest image or by making it accessible through z/VM, you can provide rapid access to a backed-up file system.

14.2.4 Disaster recovery

Disaster recovery is a business survival scheme that is used in the event that an installation is partially or totally destroyed. Disaster recovery includes contingency plans for a range of possible disaster scenarios. These plans involve physical aspects, such as the location from where to operate and the machines and devices to be used.

z/VM tools and hardware facilities such as FlashCopy for Enterprise Storage Server allow rapid copying at the device level. If you ensure that all critical applications keep their data on a specific set of physical devices, you can create your data copies for disaster recovery at the physical level and take advantage of these facilities.

For most disaster scenarios you must keep data copies off-site, usually on tape. If the initial copy is on disk at the primary site, a slower but non-disruptive secondary copy to tape should follow the initial fast copy. If you are using a remote dual copy, you might not need to go to tape. ESS, for example, provides the remote dual copy features Peer-to-Peer Remote Copy (PPRC) and eXtended Remote Copy (XRC).

This section and the disaster recovery examples of our hypothetical companies are not a full discussion of disaster recovery. Our view is limited to aspects of data management in which special considerations apply to Linux or to the mainframe.

With z/OS Parallel Sysplex,^[33] the mainframe offers an unsurpassed availability scheme for z/OS images. You cannot build sysplexes with Linux images; but if you already run a Parallel Sysplex, you might be able to exploit the sysplex capabilities to protect critical data.

^[33] A Parallel Sysplex is a mainframe clustering technology that can also involve geographically distant systems. One or more Coupling Facilities assure integrity as data are shared among constituent systems. If a shared storage device fails, the data can be reconstructed from the Coupling Facilities' log streams in conjunction with the application and the middleware that owns the data.

At StoreCompany, for example, Linux works with data that are copied from z/OS. The z/OS copy is the master copy (see 14.4.2, "StoreCompany data management") and is included in the disaster recovery scheme. No additional precaution is required to safeguard the survival of data on the Linux side of its operations.

14.2.5 Backup tools summary

Table 14-2 summarizes some of the tool options you have when taking backups:

Table 14-2. Entities to be backed up

Backup level	Tool
Disk	DASD dump restore
Minidisks	DASD dump restore
CMS files	CMS copy command
Linux files	Tivoli Storage Manager
Incremental database backups	Database utility
Cross-resource increments	Application that owns the resources

z/VM can take care of entities that it knows, for example, the physical disks. Where the entities are of a more logical nature, such as a Linux file system, you need tools that operate at the same abstraction level as the entities to be backed up. See also 25.2, "Data management tools."