Storage network backup: Next generation

Storage network backup offers new possibilities for getting around performance bottlenecks. This excerpt from Storage Networks Explained describes your options and what to consider when deciding which one best suits your clients' system.

Storage networks open up new possibilities for getting around the performance bottlenecks of network backup described above. They connect servers and storage devices, so that during backup production data can be copied directly from the source hard disk to the backup media, without passing it through a server (server-free backup, Section 7.8.1). LAN-free backup (Section 7.8.2) and LAN-free backup with shared disk file systems (Section 7.8.3) are two further alternative methods of accelerating backup using storage networks. The introduction of storage networks also has the side-effect that several backup servers can share a tape library (Section 7.8.4). The use of instant copies (Section 7.8.5) and remote mirroring (Section 7.8.6) provide further possibilities for accelerating backup and restore operations.

7.8.1 Server-free backup

The ultimate goal of backup over a storage network is so-called server-free backup (Figure 7.7). In backup, the backup client initially determines which data has to be backed up and then sends only the appropriate metadata (file name, access rights, etc.) over the LAN to the backup server. The file contents, which make up the majority of the data quantity to be transferred, are then written directly from the source hard disk to the backup medium (disk, tape, optical) over the storage network, without a server being connected in between. The network backup system co-ordinates the communication between source hard disk and backup medium. A shorter transport route for the backup of data is not yet in sight with current storage techniques.

Figure 7.7 In server-free backup, backup server and backup client exchange lightweight metadata via the LAN (1). After it has been determined which data blocks have to be backed up, the network backup system can configure the storage devices for the data transfer via the storage network (2). The heavyweight file contents are then copied directly from the source hard disk to the backup medium via the storage network (3)

The performance of server-free backup is predominantly determined by the performance of the underlying storage systems and the connection in the storage network. Shifting the transport route for the majority of the data from the LAN to the storage network without a server being involved in the transfer itself means that the internal buses and the I/O buses are freed up on both the backup client and the backup server. The cost of co-ordinating the data traffic between source hard disk and backup medium is comparatively low.

A major problem in the implementation of server-free backup is that the SCSI commands have to be converted en route from the source hard disk to the backup medium. For example, different blocks are generally addressed on source medium and backup medium. Or, during the restoration of a deleted file in a file system, this file has to be restored to a different area if the space that was freed up is now occupied by other files.

In the backup from hard disk to tape, even the SCSI command sets are slightly different. Therefore, software called 3rd-Party SCSI Copy Command is necessary for the protocol conversion. It can be realized at various points: in a SAN switch, in a box specially connected to the storage network that is exclusively responsible for the protocol conversion, or in one of the two participating storage systems themselves.

7.8.2 LAN-free backup

LAN-free backup dispenses with the necessity for the 3rd-Party SCSI Copy Command by realizing comparable functions within the backup client (Figure 7.8). As in server-free backup, metadata is sent via the LAN. File contents, however, no longer go through the backup server: for backup the backup client loads the data from the hard disk into the main memory via the appropriate buses and from there writes it directly to the backup medium via the buses and the storage network. To this end, the backup client must be able to access the backup server's backup medium over the storage network. Furthermore, backup server and backup client must synchronize their access to common devices. This is easier to realize than server-free backup and thus well proven in production environments.

Figure 7.8 In LAN-free backup, too, backup servers and backup clients exchange lightweight metadata over the LAN (1). The backup server prepares its storage devices for the data transfer over the storage network and then hands control of the storage devices over to the backup client (2). This then copies heavyweight file contents directly to the backup medium via the storage network (3)

In LAN-free backup the load on the buses of the backup server is reduced but not the load on those of the backup client. This can impact upon other applications (databases, file and web servers) that run on the backup client at the same time as the backup.

LAN-free backup is already being used in production environments. However, the manufacturers of network backup systems only support LAN-free backup for certain applications (databases, file systems, e-mail systems), with not every application being supported on every operating system. Anyone wanting to use LAN-free backup at the moment must take note of the manufacturer's support matrix (see Section 3.4.6). It can be assumed that in the course of the next one to two years the number of the applications and operating systems supported will increase significantly.

7.8.3 LAN-free backup with shared disk file systems

Anyone wishing to back up a file system now for which LAN-free backup is not supported can sometimes use shared disk file systems to rectify this situation (Figure 7.9). Shared disk file systems are installed upon several computers. Access to data is synchronized over the LAN; the individual file accesses, on the other hand, take place directly over the storage network (Section 4.3). For backup the shared disk file system is installed on the file server and the backup server. The prerequisite for this is that a shared disk file system is available that supports the operating systems of backup client and backup server. The backup client is then started on the same computer on which the backup server runs, so that backup client and backup server can exchange the data via Shared Memory (Unix) or Named Pipe or TCP/IP Loopback (Windows).

In LAN-free backup using a shared disk file system, the performance of the backup server must be critically examined. All data still has to be passed through the buses of the backup server; in addition, the backup client and the shared disk file system run on this machine. LAN data traffic is no longer necessary within the network backup system; however, the shared disk file system now requires LAN data traffic for the synchronization of simultaneous data accesses. The data traffic for the synchronization of the shared disk file system is, however, comparatively light. At the end of the day, you have to measure whether backup with a shared disk file system increases performance for each individual case.

Although the performance of LAN-free backup with the aid of a shared disk file system is not as good as the performance of pure LAN-free backup, it can be significantly better than that of backup over the LAN. Therefore, this approach has proved its worth in production environments, so that it can be viewed as an interesting transitional solution until LAN-free (or even server-free) backup becomes available.

Figure 7.9 When backing up using shared disk file systems, backup server and backup client run on the same computer (1). Production data and backup media are accessed on the backup server (2), which means that the backup can take place over the storage network (3). The shared disk file system requires a LAN connection for the lightweight synchronization of parallel data accesses (4)

7.8.4 Tape library sharing

Server-free backup and LAN-free backup can significantly reduce the load upon the backup server. However, the problem remains that a large number of objects to be backed up can break the metadata database. The only effective remedy is to distribute the load amongst several backup servers (Section 7.7.2). All backup servers can share a large tape library via the storage network by means of tape library sharing (Section 6.2.2). An alternative would be to purchase each backup server its own smaller tape library. However, many small tape libraries are more expensive to purchase and more difficult to manage than one large one.

Figure 7.10 shows the use of tape library sharing for network backup: one backup server acts as library master, all others as library clients. If a backup client backs up data to a backup server that is configured as a library client, then this first of all requests a free tape from the library master. The library master selects the tape from its pool of free tapes and places it in a free drive. Then it notes in its metadata database that this tape is now being used by the library client and it informs the library client of the drive that the tape is in. Finally, the backup client can send the data to be backed up via the LAN to the backup server, which is configured as the library client. This then writes the data directly to tape via the storage network.

Figure 7.10 In tape library sharing two backup servers share a large tape library. If a client wants to back data up directly to tape with the second backup server (library client) (1) then this initially requests a tape and a drive from the library master (2). The library master places a free tape in a free drive (3) and returns the information in question to the library client (4). The library client now informs the backup client (5) that it can back the data up (6)

7.8.5 Backup using instant copies

Instant copies can practically copy even terabyte-sized data sets in a few seconds, and thus freeze the current state of the production data and make it available via a second access path. The production data can still be read and changed over the first access path, so that the operation of the actual application can be continued, whilst at the same time the frozen state of the data can be backed up via the second access path.

Instant copies can be realized on three different levels:

  1. Instant copy in the block layer (disk subsystem or block-based virtualization) Instant copy in the disk subsystem was discussed in detail in Section 2.7.1: intelligent disk subsystems can practically copy all data of a hard disk onto a second hard disk within a few seconds. The frozen data state can be accessed and backed up via the second hard disk.
  2. Instant copy in the file layer (local file system, NAS server or file-based virtualization) Many file systems also offer the possibility of creating instant copies. Instant copies on file system level are generally called snapshots (Section 4.1.3). In contrast to instant copies in the disk subsystem the snapshot can be accessed via a special directory path.
  3. Instant copy in the application

Finally, databases in particular offer the possibility of freezing the data set internally for backup, whilst the user continues to access it (hot backup, online backup). Instant copies in the local file system and in the application have the advantage that they can be realized with any hardware. Instant copies in the application can utilize the internal data structure of the application and thus work more efficiently than file systems. On the other hand, applications do not require these functions if the underlying file system already provides them. Both approaches consume system resources on the application server that one would sometimes prefer to make available to the actual application. This is the advantage of instant copies in external devices (e.g., disk subsystem, NAS Server, network-based virtualization instance): although it requires special hardware, application server tasks are moved to the external device thus freeing up the application server.

Backup using instant copy must be synchronized with the applications to be backed up. Databases and file systems buffer write accesses in the main memory in order to increase their performance. As a result, the data on the hard disk is not always in a consistent state. Data consistency is the prerequisite for restarting the application with this data set and being able to continue operation. For backup it should therefore be ensured that an instant copy with consistent data is first generated. The procedure looks something like this:

  1. Shut down the application.
  2. Perform the instant copy.
  3. Start up the application again.
  4. Back up the data of the instant copy.

Despite the shutting down and restarting of the application the production system is back in operation very quickly.

Data protection with instant copies is even more attractive if the instant copy is controlled by the application itself: in this case the application must ensure that the data on disk is consistent and then initiate the copying operation. The application can then continue operation after a few seconds. It is no longer necessary to stop and restart the application.

Instant copies thus make it possible to backup business-critical applications every hour with only very slight interruptions. This also accelerates the restoring of data after application errors ('accidental deletion of a table space'). Instead of the time-consuming restore of data from tapes, the frozen copy that is present in the storage system can simply be put back.

With the aid of instant copies in the disk subsystem it is possible to realize so-called application server-free backup. In this, the application server is put at the side of a second server that serves exclusively for backup (Figure 7.11). Both servers are directly connected to the disk subsystem via SCSI; a storage network is not absolutely necessary. For backup the instant copy is first of all generated as described above: (1) shut down application; (2) generate instant copy; and (3) restart application. The instant copy can then be accessed from the second computer and the data is backed up from there without placing a load on the application server. If the instant copy is not deleted in the disk subsystem, the data can be restored using this copy in a few seconds in the event of an error.

Figure 7.11 Application server-free backup utilizes the functions of an intelligent disk subsystem. To perform a backup the application is operated for a short period in such a manner as to create a consistent data state on the hard disks, so that data can be copied by means of instant copy (1). The application can immediately switch back to normal operation; in parallel to this the data is backed up using the instant copy (2)

7.8.6 Data protection using remote mirroring

Instant copies help to quickly restore data in the event of application or operating errors; however, they are ineffective in the event of a catastrophe: after a fire the fact that there are several copies of the data on a storage device does not help. Even a power failure can become a problem for a 24 × 7 operation.

The only thing that helps here is to mirror the data by means of remote mirroring on two disk subsystems, which are at least separated by a fire protection barrier. The protection of applications by means of remote mirroring has already been discussed in detail in Sections 6.3.3 and 6.3.5.

Nevertheless, the data still has to be backed up: in remote mirroring the source disk and copy are always identical. This means that if data is destroyed by an application or operating error then it is also immediately destroyed on the copy. The data can be backed up to hard disk by means of instant copy or by means of classical network backup to tapes. Since storage capacity on hard disks is more expensive than storage capacity on tapes, only the most important data is backed up using instant copy and remote mirroring. For most data, backup to tapes is still the most cost effective.

Use the following table of contents to navigate to chapter excerpts or click here to view Network Backup in its entirety.

Storage Networks Explained
  Home: Introduction
  1: Storage network backup: General conditions for backup
  2: Storage network backup services
  3: Storage network backup: Server components
  4: Storage network back-up clients
  5: Storage network back-up performance gains
  6: Storage network backup performance bottlenecks
  7: Storage network backup: Limited opportunities for increasing performance
  8: Storage network backup: Next generation
  9: Storage network backup of file servers
  10: Storage network backup of databases
  11:Storage network backup: Organizational aspects
Storage networks will become a basic technology like databases or local area networks. According to market research, 70% of external storage devices will be connected via storage networks in 2003. The authors have hands-on experience of network storage hardware and software, they teach customers about concrete network storage products, they understand the concepts behind storage networks, and show customers how storage networks address their business needs. This book explains how to use storage networks to fix malfunctioning business processes, covering the technologies as well as applications -- a hot topic that will become increasingly important in the coming years.Purchase the book from Wiley Publishing
Authors Ulf Troppens and Rainer Erkens are both employed at IBM TotalStorage Interoperability Center in Mainz, Germany a testing, development and demonstration laboratory for storage products and storage networks. Both authors work at the interface between technology and customers. Wolfgang Müller is currently working as a software architect in the Storage Software Development Department at IBM in Mainz, Germany, where the focus is on software development projects supporting open standards such as SMI-S/CIM/WBEM and IEEE 1244.

Dig Deeper on Primary and secondary storage