Computer data storage backup with tape overflow control of disk caching of backup data stream

[0002] The present invention relates generally to computer data storage backup, and more particularly, to a data storage system that performs a backup of data from primary storage to tape in response to a backup command.

[0003] Due to advances in computer technology, there has been an ever-increasing need for data storage in data processing networks. In a typical data processing network, there has been an increase in the number of volumes of data storage and an increase in the number of hosts needing access to the volumes. This has been especially true for networks of workstations. Not only have a greater number of workstations been added to the typical network, but also the increase in data processing capabilities of a typical workstation has required more data storage per workstation for enhanced graphics and video applications.

[0004] Fortunately for computer users, the cost of data storage has continued to decrease at a rate approximating the increase in need for storage. For example, economical and reliable data storage in a data network can be provided by a storage subsystem including a Redundant Array of Independent Disks (RAID). Presently it is practical to provide a single data storage subsystem with up to 20 terabytes (TB) of storage, or approximately 4000 logical volumes, using magnetic disk drives each having a storage capacity of 46 gigabytes.

[0005] Unfortunately for network administrators, the development of services for storage management has lagged behind the increase in storage to be managed. Consequently, the cost of storage management has become relatively more significant. More troubling is the difficulty of maintaining the same level of management service as the amount of storage increases. For example, users are accustomed to being provided with backup and restore services for their data that is stored on the network. Users are encouraged to store their data on the network so that it can be shared by other authorized users and maintained in a cost-effective manner in accordance with corporate document retention policies. However, data stored on the network is always subject to some chance of loss due to a severe failure of the data storage system. Backup and restore services are a conventional way of reducing the impact of data loss from the network storage. To be effective, however, the data should be backed up frequently, and the data should be restored rapidly from backup after the storage system failure. As the amount of storage on the network increases, it is more difficult to maintain the frequency of the data backups, and to restore the data rapidly after a storage system failure.

[0006] In the data storage industry, an open standard network backup protocol has been defined to provide centrally managed, enterprise-wide data protection for the user in a heterogeneous environment. The standard is called the Network Data Management Protocol (NDMP). NDMP facilitates the partitioning of the backup problem between backup software vendors, server vendors, and network-attached storage vendors in such a way as to minimize the amount of host software for backup.

[0007] The current state of development of NDMP can be found at www.ndmp.org/info. The NDMP server must implement a number of interfaces, including a CONNECT interface, a CONFIG interface, an SCSI interface, a TAPE interface, and a DATA interface. The CONNECT interface is used when a client opens the communication to a NDMP server. This interface allows the NDMP server to authenticate the client and negotiate the version of protocol used.

[0008] The CONFIG interface allows backup software to discover the configuration of the NDMP server. It can be used to discover tape drives and jukeboxes as well as file systems and databases. Backup software will use this interface to build request and.media server databases automatically.

[0009] The SCSI interface simply passes SCSI commands (known as CDBs) through to the SCSI device and returns the SCSI status. The backup software will use this interface to control a locally attached jukebox. Software on the backup software host will construct SCSI CDBs and will interpret the returned status and data. This interface can also be used to exploit special features of SCSI tape drives.

[0010] The TAPE interface will support both tape positioning and tape read/write operations. The backup software will use this interface to control the labeling and format of the tape. The backup software will also use this interface for positioning of the tape during backups and restores.

[0011] The DATA interface actually deals with the format of the backup data. The backup software will initiate backups and restores using this interface. The backup software provides all of the parameters that may affect the backup or restore using this interface. The backup software does not place any constraints on the format of the backup data other than it must be a stream of data that can be written to the tape device.

[0012] The NDMP server may send a number of messages to the backup software host. All of the messages that the backup software host accepts are asynchronous. None of these messages will generate a reply message. These messages include a NOTIFY message, a FILE HISTORY message, and a LOGGING message. The NDMP uses the NOTIFY message to notify the backup software that the NDMP server requires attention.

[0013] The FILE HISTORY message allows the NDMP server to make entries in the file history for the current backup. The backup software uses this message to select files for retrieval.

[0014] The LOGGING message allows the NDMP server to make entries in the backup log. The operator uses this message to monitor the progress and successful completion of the backup. It is also used to diagnose problems.

[0015] It will be assumed that the reader is familiar with the details of NDMP, for example, as set out in the Internet Draft Document by R. Stager and D. Hitz entitled “Network Data Management Protocol” document version 2.1.7 (last update Oct. 12, 1999), incorporated herein by reference. Therefore, the following disclosure will deal primarily with certain backup and restore operations in a data storage system, with the understanding that such a data storage system may provide other functions as known to a person of ordinary skill in the art familiar with the details of NDMP.

[0016] Since backup software need not place any constraints on the format of backup data other than it must be a stream of data that can be written to the tape device, the inventor has discovered that the performance of the storage system can be improved by the addition of certain facilities which may cause the tracks of a storage volume to become non-sequential as they are written to the tape device. In particular, it is desirable to continue host read-write access to a storage volume that is being backed up. If a host has read-write access to a storage volume, then the storage volume will be referred to as a “production volume.” When a production volume in a primary storage subsystem is being backed up, it is desirable to receive the backup data from the primary storage subsystem as quickly as the primary storage subsystem delivers the backup data. Otherwise, when the host writes to the production volume, the maintenance of a snapshot copy of the backup data in the primary storage subsystem will increase the storage load and may also increase the processing load on the primary storage subsystem. Often, however, the tape storage device cannot write the backup data to tape as fast as the storage subsystem delivers the backup data. One solution to this problem is for the primary storage subsystem to write the backup data to intermediate disk storage in a secondary data storage subsystem and then write the backup data from the intermediate disk storage to tape storage. However, if the tracks of backup data from the snapshot copy of the production volume can be written to tape in a non-sequential fashion, then the required storage and data processing resources for the intermediate disk storage can be minimized by selectively bypassing-the intermediate disk storage whenever possible.

[0017] Accordingly, in accordance with a first aspect, the invention provides a method of selective buffering of the backup data from primary data storage before the backup data is written to the tape. The method includes transferring a portion of the backup data to be written on the tape from the primary data storage to intermediate disk storage when the tape storage device is not ready to receive the backup data to be written on the tape from the primary data storage, and later transferring the portion of the backup data to be written on the tape from the intermediate disk storage to the tape storage device. In addition, when the tape storage device is ready to receive the backup data to be written on the tape and the backup data is being transmitted from the primary data storage device and the portion of the backup data is contained in the intermediate disk storage and has not yet been written to-the tape storage device, the intermediate disk storage is bypassed to transfer to the tape storage device the backup data being transmitted from the primary data storage device.

[0018] In accordance with another aspect, the invention provides a method of transferring a first portion of the backup data from the primary data storage to a memory buffer and from the memory buffer to the tape. When the backup data is delivered from the primary data storage to the memory buffer at a faster rate than the backup data is written from the memory buffer to the tape, overflow of the memory buffer is prevented by transferring a second portion of the backup data from the primary data storage to intermediate disk storage, and at a later time transferring the second portion of the backup data from the intermediate disk storage to the tape.

[0019] In accordance with another aspect, the invention provides a method of selective buffering of backup data in a data storage system including at least one data mover computer receiving a stream of the backup data from a data storage device, a cached disk storage subsystem coupled to the data mover computer for intermediate data storage, and a tape library unit coupled to the data mover computer for storage of the backup data onto a tape. The backup data from the data storage device is selectively buffered before the backup data is written to the tape. The method includes transferring a first portion of the backup data from the data storage device to a random access memory buffer in the data mover computer and from the random access memory buffer to the tape. When the backup data is delivered from the data storage device to the random access memory buffer at a faster rate than the backup data is written from the random access memory buffer to the tape, overflow of the random access memory buffer is prevented by transferring a second portion of the backup data from the data mover computer to the cached disk storage subsystem, and at a later time transferring the second portion of the backup data from the cached disk storage subsystem to the tape.

[0020] In accordance with yet another aspect, the invention provides a data processing system including primary data storage adapted for coupling to a host processor for read/write access, a tape storage device for providing backup storage on a tape and coupled to the primary data storage for transfer of backup data from the primary data storage to the tape in response to a backup request. The data processing system further includes a memory buffer coupled to the primary data storage and the tape storage device for buffering of the backup data from the primary data storage before the backup data is written to the tape, and intermediate disk storage coupled to the primary data storage and the tape storage device for buffering of the backup data from the primary data storage before the backup data is written to the tape. Moreover, the data processing system includes flow control logic coupled to the memory buffer and to the intermediate disk storage for controlling a flow of the backup data to the memory buffer and to the intermediate disk storage so that when the backup data is delivered from the primary data storage to the memory buffer at a faster rate than the backup data is written from the memory buffer to the tape, overflow of the memory buffer is prevented by buffering a portion of the backup data in the intermediate disk storage for writing to the tape at a later time.

[0021] In accordance with still another aspect, the invention provides a data storage system including a tape library unit including at least one tape, at least one data mover computer adapted for receiving a stream of backup data from a data storage device and coupled to the tape library unit for transferring the backup data to the tape library unit for writing the backup data onto the tape; and a cached disk storage subsystem coupled to the data mover computer for receiving data from the data mover computer, and coupled to the tape library unit for writing data from the cached disk storage subsystem to the tape library unit. The data mover computer includes a random access buffer memory, and the data mover computer is programmed to control a flow of the backup data to the random access memory buffer and to the cached disk storage subsystem so that when the backup data is delivered to the random access memory buffer at a faster rate than the backup data is transferred from the random access memory buffer to the tape library unit, overflow of the random access memory buffer is prevented by buffering a portion of the backup data in the cached disk storage subsystem for transfer to the tape library unit at a later time.

[0022] In accordance with a final aspect, the invention provides a program storage device containing a program executable by a data processor for selectively buffering a stream of data from a data source to a data sink by buffering the data in a buffer memory or in disk storage. The program is executable by the data processor for buffering the data in the memory buffer unless the memory buffer becomes substantially full, and when the memory buffer becomes substantially full, buffering a portion of the data from the data source in the disk storage. The program is also executable by the data processor for supplying data to the data sink from the buffer memory unless the memory buffer becomes substantially empty, and when the memory buffer becomes substantially empty, supplying the portion of the data from the disk storage to the data sink.

[0023] Additional features and advantages of the invention will be described below with reference to the drawings, in which:

[0024] FIG. 1 is a block diagram of a data processing system in which the invention can be used;

[0025] FIG. 2 is a block diagram of a more complex data processing system in which the invention can be used;

[0026] FIG. 3 is a block diagram of a preferred construction for the primary data storage subsystem in the data processing system of FIG. 2;

[0027] FIG. 4 is a block diagram of a preferred construction for the secondary data storage subsystem in the data processing system of FIG. 2;

[0028] FIG. 5 is a block diagram of data structures which are included in a snapshot copy facility of the primary data storage subsystem of FIG. 1;

[0029] FIG. 6 is a schematic diagram of a preferred construction for a list of pointers to tracks in snapshot disks for the snapshot copy facility as shown in FIG. 5;

[0030] FIG. 7A is a flow chart of programming of the port adapters in the primary data storage subsystem of FIG. 3 for creating a snapshot of a production volume extent;

[0031] FIG. 7B is a flow chart of programming of the port adapters in the primary data storage subsystem of FIG. 3 for access to a production volume that is in a snapshot mode;

[0032] FIG. 8A is a flow chart of programming of the remote link adapters in the primary data storage subsystem of FIG. 3 for a preferred implementation of the snapshot copy facility as introduced in FIG. 5;

[0033] FIG. 8B is a flow chart of programming in the link adapter for responding to confirmation from the secondary storage that a remote copy has been made and a specified production volume extent can therefore be deallocated;

[0034] FIG. 8C is a flow chart of programming of the remote link adapters in the primary data storage subsystem of FIG. 3 for an alternative implementation of the snapshot copy facility as introduced in FIG. 5;

[0035] FIG. 9 is a schematic diagram of a format for backup data as written to tape;

[0036] FIG. 10 is a block diagram of components in a data mover of the secondary data storage subsystem of FIG. 4 as they are used for selective disk caching of backup data written to tape;

[0037] FIG. 11 is a schematic diagram showing backup data flow from a primary data storage subsystem for the selective disk caching of backup data written to tape;

[0038] FIG. 12 is a schematic diagram showing control flow in the form of records of track pointers transferred between a free record queue and an allocated record queue for the selective disk caching of backup data written to tape in accordance with a preferred implementation;

[0039] FIG. 13 is a schematic diagram showing a preferred construction of a record containing track pointers to tracks of backup data cached on disk storage of the secondary data storage subsystem;

[0040] FIG. 14 is a schematic diagram showing a preferred construction of a record containing track pointers to tracks of backup data cached in random access memory of a data mover in the secondary data storage subsystem;

[0041] FIG. 15 is a flow chart of a front-end program module introduced in FIG. 10 for the selective caching of backup data to be written to tape;

[0042] FIG. 16 is a flow chart of a back-end program module introduced in FIG. 10 for the selective caching of backup data to be written to tape.

[0043] While the invention is susceptible to various modifications and alternative forms, specific embodiments thereof have been shown in the drawings and will be described in detail. It should be understood, however, that it is not intended to limit the invention to the particular forms shown, but on the contrary, the intention is to cover all modifications, equivalents, and alternatives falling within the scope of the invention as defined by the appended claims.

[0044] With reference to FIG. 1 of the drawings, there is shown a data processing system in which the present invention can be used. The data processing system includes a host computer 20, a primary data storage subsystem 21, and a secondary data storage subsystem 22. A user 23 operates the host computer 20, and during typical operation the host computer reads and writes to primary storage 27 in the primary data storage subsystem 21. In order to recover from a failure causing a loss of data in the primary storage 27, a backup copy of data in the primary storage 27 is kept in secondary storage 29 of the secondary data storage subsystem 22.

[0045] In the data processing system of FIG. 1, the backup data in the, secondary storage 29 is not updated every time that the host 20 writes new data to the primary data storage subsystem. Instead, specified data in the primary storage 27 is copied to the secondary storage 29 when the primary data storage subsystem 21 receives a backup command from the host 20. The host 20 may issue such a backup command at the request of the user 23 or at the request of an application program being executed by the host. In either case, the host has backup software 24, which the user or the application program can invoke to cause the host to issue a backup command. The backup software 24, for example, translates requests to backup logical data structures, such as files, to backup commands that operate upon units of data storage specified in the backup commands transmitted by the host 20 to the primary data storage subsystem 21. For example, the units of data storage specified in the backup commands may include data storage volumes or devices, cylinders, and tracks.

[0046] In the context of this patent application, the term “physical storage unit” will refer to a storage unit specified by the backup commands received by the primary data storage subsystem 21. There may or may not be a one-to-one correspondence between such a physical storage unit specified in a backup command and a data storage device in the primary data storage subsystem. In the case where there is not such a one-to-one correspondence, the primary data storage subsystem will perform a mapping between the physical storage unit specified in the backup request and at least one address of a data, storage device providing the primary storage .27 in the primary data storage subsystem 21.

[0047] In response to a backup command from the host 20, the primary data storage subsystem 21 accesses a primary directory 26 to find data of the physical storage unit specified by the backup command in order to initiate a process of copying the data from the primary storage 27 to the secondary storage 29 of the secondary data storage subsystem 22. Preferably, the primary directory 26 is constructed in such a way that the host can continue to access the primary storage 27 concurrently with the copying process. For example, in response to the backup command from the host 20, the primary data storage subsystem creates an “instant snapshot copy” of the specified physical storage unit, and this instant snapshot copy is protected from modification by the host 20 while the instant snapshot copy is being written to the secondary storage 29. There are a number of ways that such an instant snapshot copy can be created, depending on the way that the primary directory is organized.

[0048] One way of organizing the primary directory 26 is to associate a set of flags and mapping information with each physical storage unit, for example as described in Yanai et al., U.S. Pat. No. 5,206,939, issued Apr. 27, 1993, and incorporated herein by reference. In order to create an instant snapshot copy, a remote copy pending flag is associated with each physical storage unit. When the primary data storage subsystem 21 receives a backup command from the host 20, the primary data storage subsystem sets the remote copy pending flag, and thereafter the host can concurrently access the primary storage 27 while data is being copied from the physical storage unit to the secondary storage 29. However, before the primary data storage subsystem accesses the primary storage 27 to modify any data in response to a request from the host 20, the primary data storage subsystem first inspects the remote copy pending flag of the physical storage unit to be, modified, and if the remote copy pending flag is set, the primary data storage subsystem must copy the data of the physical storage unit from the primary storage 27 to the secondary storage 29 and reset the remote copy flag, before modifying the data in the primary data storage subsystem. Unless there is such a request from the host for modification of data marked as “remote copy pending,” the copying of data from the primary storage 27 to the secondary storage 29 is performed as a background process relative to host requests.

[0049] Another way of organizing the primary directory 26 is to maintain lists of pointers to primary storage locations of old and new versions of physical storage units. Whenever data in the primary storage is modified, the data is read from the primary storage locations containing the most current version, modified, and written to a different set of primary storage locations. This is known in the art as a “log structured file” approach. See, for example, Douglis et al. “Log Structured File Systems,” COMPCON 89 Proceedings, Feb. 27-Mar. 3, 1989, IEEE Computer Society, p. 124-129, incorporated herein by reference, and Rosenblum et al., “The Design and Implementation of a Log-Structured File System,” ACM Transactions on Computer Systems, Vol. 1, February 1992, p. 26-52, incorporated herein by reference. In order to create an instant snapshot copy, the primary directory 26 includes a respective remote copy pending flag associated with the pointer to each version of each physical storage unit. In response to a backup command from the host 20, the primary data storage subsystem sets the remote copy flag. Thereafter, the primary data storage subsystem can modify the data of the physical storage unit in the primary storage in the usual fashion concurrently with the copying of a snapshotted version of the data to the secondary storage, because the new version and the snapshotted version of the physical storage unit are stored in a different set of primary storage locations. Instead of being used to temporarily delay any modification access to a physical storage unit, the remote copy flag is used to indicate whether or not the set of primary storage locations associated with an old version of a physical storage unit can be de-allocated after a modification access.

[0050] After a modification access to a physical storage unit, the primary data storage subsystem 21 inspects the remote copy flag associated with the physical storage unit, and if the remote copy flag is not set, then the set of primary storage locations associated with the old version of the physical storage unit is de-allocated, for example, by placing a pointer to the set of the primary storage locations on a “free list.” The de-allocated primary storage locations therefore become available for storing modified versions of physical storage units. If the remote copy flag is set, then the set of primary storage locations cannot be de-allocated until the data in the set of primary storage locations has been copied to the secondary storage 29. For example, when the remote copy flag of a set of primary storage locations is set, the pointer to the set of primary storage locations is placed on a remote copy list that is serviced as a background process relative to servicing host requests. After the data for the set of primary storage locations indicated by the pointer at the head of the remote copy list has been copied to the secondary storage 29, the set of primary storage locations is de-allocated and the pointer is removed from the head of the remote copy list.

[0051] In the preferred implementation of the data processing system of FIG. 1, the primary data storage subsystem 21 includes a snapshot copy facility 69. The snapshot copy facility 69 includes a stored program that is executed by data processors in the primary data storage subsystem as described below with reference to FIGS. 5 to 8. This stored program is a component of what is known as microcode for the primary data storage subsystem. The microcode can be down-loaded into program memory of the primary data storage subsystem from a conventional program storage device such as a floppy disk.

[0052] Regardless of how the primary directory 26 is organized and how the instant snapshot process is performed, it is possible for the secondary storage 29 to contain more than one version of backup data for the same physical storage unit. In order to distinguish between different versions of backup data for the same physical storage unit, the primary data storage subsystem 21 appends an identification tag to the backup data transmitted from the primary data storage subsystem to the secondary data storage subsystem 22. The tag, for example, is supplied by the host 20 in the backup command transmitted by the host to the primary data storage subsystem 21. The tag could also include a date-time stamp generated by the primary data storage subsystem. In the secondary data storage subsystem 22, the tag associated with each version of backup data is stored in a secondary directory 28, which further includes a record of a set of locations of the secondary storage 29 in which the version of backup data is stored.

[0053] The tag associated with each version of backup data in the secondary storage 29 is used in a restore operation initiated by the backup software 24 in response to the user 23 or in response to a call from an application program executed by the host 20. The backup software 24 issues a restore command to the primary data storage subsystem 21, and the restore command contains the tag of a backup version to be restored. The primary data storage subsystem forwards the restore command to the secondary data storage subsystem 22. In response to the restore command, the secondary data storage subsystem accesses the secondary directory 28 to find the secondary storage locations containing the version of backup data identified by the tag, and then copies the version of backup data from the secondary storage 29 to the primary storage 27. Therefore, the version of the backup data identified by the tag becomes the current version in the primary storage 27. The primary data storage subsystem then transmits an acknowledgment of completion of the restore operation to the backup software 24 of the host 20.

[0054] The primary storage 27 and the secondary storage 29 may contain various kinds of data storage devices such as dynamic or static random access memory, magnetic or optical disk data storage, and magnetic or optical tape data storage. As will be further described below with reference to FIG. 3, the primary data storage subsystem 21, for example, is a cached disk data storage subsystem including a random access cache memory and magnetic disk data storage. As further described below with reference to FIG. 4, the secondary data storage subsystem 22, for example, includes a tape library unit containing a multiplicity of magnetic tape cassettes providing the secondary storage 29, and the secondary data storage subsystem 22 may also include a random access cache memory and magnetic disk memory for buffering backup data transferred between the primary data storage subsystem 21 and the secondary data storage subsystem 22, and for storing the information contained in the secondary directory 28. In the preferred implementation, the secondary data storage subsystem includes a disk caching facility 66 for selectively buffering the backup data to be written to tape, as described below with reference to FIGS. 9 to 16.

[0055] Although the data processing system of FIG. 1 is shown to include a single user 23, a single host 20, a single primary data storage subsystem 21, and a single secondary data storage subsystem 22, it should be appreciated that economies of scale in the construction of the data storage subsystems provide an incentive for a multiplicity of hosts to share a primary data storage subsystem, and for a multiplicity of primary data storage subsystems to share a secondary data storage subsystem. Such a data processing system is shown in FIG. 2.

[0056] With reference to FIG. 2, a data network 30 such as a Fibre Channel loop links a multiplicity of hosts 31, 32, 33 to a number of primary data storage subsystems 41, 42. The hosts 31, 32, 33, for example, are workstations of respective users 34, 35, 36. The user 35 is a system manager responsible for configuring the data storage subsystems 41, 42 and ensuring that the data storage and backup needs of the users are satisfied. Each of the hosts has a copy of backup software 37, 38, 39 similar to the backup software 24 described above with reference to FIG. 1. The primary data storage subsystems 41,42 each have a respective primary directory 44, 46, respective primary storage 45, 47, and respective snapshot copy facilities 67, 68. The primary data storage subsystems 41, 42 are each similar to the primary data storage subsystem 21 of FIG. 1. The primary data storage subsystems 41, 42 share a secondary data storage subsystem 43. The secondary data storage subsystem 43 has a secondary directory 48, secondary storage 49, and a disk caching facility 69. The secondary data storage subsystem 43 is similar to the secondary data storage subsystem 22 of FIG. 1, but it further includes independent, dedicated data links 93 and 94 to each of the primary data storage subsystems 41 and 42 and a data link 92 to the data network 30. The dedicated links 93, 94 are used for transferring backup data between the respective primary data storage subsystems 41, 42 and the secondary data storage subsystem 43. The data link 92 permits the system manager 35 to access the secondary data storage subsystem 43 for data storage management and diagnostic purposes.

[0057] In a preferred implementation, most of the intelligence for backup functions is programmed into the secondary data storage subsystem 43 so as not to significantly reduce the data processing resources of the primary data storage subsystems 41, 42 that are available for processing host read/write operations to production volumes. For example, in the preferred implementation using NDMP compliant backup software 31, 32, 33, the NDMP commands from the backup software pass through a primary data storage subsystem and are received and executed by the secondary data storage subsystem with the exception of a backup or restore command. A backup or restore command is recognized by a port adapter of a primary data storage subsystem upon receipt in order to maintain synchronization with any immediately following read/write operation upon a production volume being backed up or restored. In other words, if a command to backup a production volume is immediately followed by a read/write command upon the production volume, then the backup command should be performed upon the production volume version existing prior to any modification performed in response to the read/write command. In a similar fashion, if a command to restore a production volume is immediately followed by a read/write command upon a production volume, then the read/write operation should be performed upon the version of the production volume having been restored from the secondary storage.

[0058] In a preferred implementation, NDMP commands that pass through a primary data storage subsystem to the secondary storage subsystem are received by one of the data movers (72, 73, 74, 75) and are passed over the internal bus 79 to the active control station server 76, 77 for execution. In this fashion, the active control station can function as an NDMP server. For protection against failure of the secondary storage subsystem, the control station servers 76, 77 could be connected via the data network link 92 to a remote server (not shown) that would receive the NDMP commands, control station backup related commands, and secondary directory information from the active controller server, in order to permit the remote server to maintain a duplicate secondary directory. In this fashion, the remote server could function as a redundant NDMP server that could respond to requests for secondary directory information and could help recover from a failure of the secondary storage subsystem.

[0059] With reference to FIG. 3, there is shown a preferred construction for the primary data storage subsystems in the data processing system of FIG. 2. The primary data storage subsystem 41 is a cached disk data storage subsystem including a disk array 50 and a data storage controller 51 for controlling access of the hosts to the disk array. The disk array includes a multiplicity of magnetic disk drives 59, 60, 61, 62. Using current technology, each of the disk drives has a data storage capacity of at least 47 gigabytes, and the primary data storage subsystem provides at least 20 terabytes (TB) of data storage.

[0060] The data storage controller 51 includes a dual port cache memory 52, a number of port adapters 55, a number of remote link adapters 56, and a plurality of storage adapters 57, 58. The cache memory 52 is accessed via any one of two back-plane busses 53, 54. Each port adapter 55 links the hosts, via the network 30 in FIG. 2, to each of the two back-plane busses 53, 54. Each remote link adapter 56 links the secondary data storage subsystem to each of the two back-plane busses. Each of the storage adapters 57, 58 links a respective set of the disk drives 59, 60, 61, 62 to each of the two back-plane busses 53, 54. For example, the cached disk data storage subsystem includes up to eight storage adapters, and a total of up to eight port or remote link adapters. Each port adapter provides two independent data ports to the data network, and each remote link adapter provides two independent data ports to one or two secondary data storage subsystems.

[0061] When a port adapter 55 receives a data storage access request from one of the hosts (31, 32, 33 in FIG. 2), the port adapter accesses the primary directory 44 in the cache memory 52 to determine whether or not the data to be accessed resides in the cache memory. If the data to be accessed resides in the cache memory, then the port adapter accesses the data in the cache memory. If the data to be accessed does not reside in the cache memory, then the port adapter forwards a data storage access request to the storage adapters 57, 58. One of the storage adapters 57, 58 responds to the data storage access request by performing a mapping to determine where the data to be accessed resides on the data storage devices, and reads the data from the data storage devices and writes the data to the cache memory, for access by the port adapter. The storage adapters 57, 58 also perform a write-back operation to ensure that data written to the cache memory 52 by the port adapters eventually becomes written to the disk array 50.

[0062] The cache memory 52 ensures that data frequently accessed by the hosts is likely to be found in cache in order to avoid the data access time of the disk drives and in order to minimize loading on the storage adapters and the port adapters. Consolidation of network data storage into a large cached data storage subsystem provides a benefit that cache resources are consolidated into one large cache, which is more efficient than a number of smaller caches having in total the same cache memory capacity. A large cache is more likely to contain the most recently accessed data than the combined cache memory of the smaller caches.

[0063] The data storage subsystem 41 is constructed for high data availability so that a single high-capacity data storage subsystem is at least as fault-tolerant as a local collection of conventional network data storage servers. Fault tolerance is ensured by dual redundant components and busses in the path from each port adapter 55 to any one of the disk drives 59, 60, 61, 62. Mirroring or RAID (redundant array of inexpensive disks) techniques ensure that the storage adapters 57, 58 can recover data in the event of failure of any one of the disk drives. See, for example, Patterson et al., “Introduction to Redundant Arrays of Inexpensive Disks (RAID),” COMPCON 89 Proceedings, Feb. 27-Mar. 3, 1989, IEEE Computer Society, p. 112-117, incorporated herein by reference. In a similar fashion, the data network (30 in FIG. 2) can be made fault tolerant by ensuring that each of the hosts (31, 32, 33) has more than one independent path through the data network 30 to each of two port adapters in the data storage subsystem 41. For example, the data network 30 in FIG. 2 could have dual redundant Fibre-Channel loops, only one being shown in FIG. 2.

[0064] In a preferred form of construction, the cache memory 52 is composed of dynamic RAM memory cards mounted in a card-cage or main-frame, and the port adapters and storage adapters are programmed micro-processor cards that are also mounted in the card-cage or main-frame. Each port adapter 55 has one or more processors for handling the communication protocol of the data network (30 in FIG. 2) and communicating with the cache memory busses 53, 54. Each remote link adapter 56 has one or more processors for handling a communications protocol with the secondary data storage subsystem. Each storage adapter 57, 58 has one or more processors for handling the communication protocol of the disk drives and for communicating with the cache memory busses 53, 54. For example, the links between the storage adapters 57, 58 and the disk drives are FWD (fast, wide, differential) SCSI or Fibre Channel fiber-optic loops, the port adapters 55 are programmed to communicate with the .network and hosts via Bus and Tag CKD, ESCON, or SCSI protocols, and the remote link adapters 56 are programmed to communicate with the secondary data storage subsystem using the ESCON protocol.

[0065] Further details regarding the preferred construction and operation of the cached disk data storage subsystem 41 are disclosed in Yanai et al., U.S. Pat. No. 5,206,939, issued Apr. 27, 1993; Yanai et al. U.S. Pat. No. 5,335,352, issued Aug. 2, 1994; and Yanai et al. U.S. Pat. No. 5,381,539, issued Jan. 10, 1995; all incorporated herein by reference. The operation of the remote link adapter 56 is further described in Yanai et al., U.S. Pat. No. 5,544,347 issued Aug. 6, 1996, incorporated herein by reference, and in Yanai et al., U.S. Pat. No. 5,742,792 issued Apr. 21, 1998 (Ser. No. 08/654,511 filed May 28, 1996), incorporated herein by reference. Yanai et al. U.S. Pat. Nos. 5,544,347 and 5,742,792 describe the use of the remote link adapter for automatic remote mirroring of data. The use of the remote link adapter for backup of data is similar to the use of the remote link adapter for automatic remote mirroring of data with the exception that automatic remote mirroring of data need not maintain multiple versions of data in the secondary storage and therefore need not use a tag for identifying any particular version of the mirrored data.

[0066] Referring to FIG. 4, there is shown a block diagram of a preferred construction of the secondary data storage subsystem 43 in FIG. 2. As shown in FIG. 4, the secondary data storage subsystem includes a tape library unit 70, a cached disk data storage subsystem 71, a plurality of data mover computers 72, 73, 74, 75, dual redundant control station server computers 76, 77, and a control station display and keyboard 78. The data mover computers 72-75 and the control station server computers 76-77 are linked for transfer of control and status information by a dual redundant 10-Base-T bus 79.

[0067] The tape library unit 70 has a plurality of read-write stations 81, 82, 83, 84 and a robotic mechanism (not shown) for mounting and unmounting magnetic tape cartridges onto the read-write stations and removing or inserting the tape cartridges from slots in data storage shelves. The robotic mechanism operates automatically in response to mount, unmount, read, and write commands received by the read/write stations. The tape library unit 70, for example, is an ATL (Trademark) brand of tape library unit.

[0068] The cached disk data storage subsystem 71 includes a cache memory 86 providing a secondary directory 48 for the secondary data storage subsystem 43, a disk array 87, and a plurality of port adapters 88, 89, 90, and 91. The cached disk data storage subsystem 71 is similar to the data storage subsystem shown in FIG. 3, except that it need not have a remote link adapter. The cached disk data storage subsystem 71, for example, is a SYMMETRIX (Trademark) brand of data storage subsystem, sold by EMC Corporation, 171 South Street, Hopkinton, Mass., 01748.

[0069] The data mover computers 72-75 and the control station servers 76-77 are commodity personal computers. The data mover computers 74, 75 provide a front-end for the secondary data storage subsystem 43, and they are programmed to respond to backup and restore commands from the primary data storage subsystems. In response to a backup request, a front-end data mover computer 74, 75 moves the backup data to the cached disk data storage subsystem 71, updates the secondary directory 48, and initiates the transfer of the backup data from the cached disk data storage subsystem 71 to the tape library unit 70. The actual transfer of the backup data from the cached disk data storage subsystem 71 to the tape library unit 70 is performed by one of the back-end data mover computers 72, 73. In response to a restore request, a front-end data mover computer 74, 75 accesses the secondary directory 48 to determine the most accessible source of the backup data (cache memory 86, disk array 87, or tape cassettes 85), and accesses the backup data from the cache memory 86 or the disk array 87, or if the backup data is not accessible from the cache memory 86 or the disk array 87, the front end data mover sends a command over the 10-Base-T bus 79 to one of the back-end data mover computers 72, 73 to read the backup data from the tape cassettes and transfer the data from the tape cassettes to the cache memory 86 in the cached disk data storage subsystem 71. Once at least a portion of the backup data has been transferred from tape 85 to the cache memory 86, the front-end data mover computer 74, 75 transfers the backup data from the cache memory 86 to the primary data storage subsystem having issued the restore request.

[0070] The operation of the secondary storage subsystem is similar to that described in Vikshlitzky et al., U.S. Pat. No. 5,737,747 issued Apr. 7, 1998, incorporated herein by reference, except that the use of the cached disk data storage subsystem 71 for buffering data to be written to the tape library unit 70 has been modified. In particular, backup data from a primary storage subsystem is received by a data mover 72, 73, 74, 75, 76 and is transmitted directly to a read/write station 81, 82, 83, 84 unless the data mover receives the backup data at a rate faster than the rate at which the data can be accepted by the read/write station and random-access buffer memory (RAM) in the data mover becomes full. If the RAM buffer of the data mover becomes full, then the backup data is cached in the cached disk storage subsystem 71. When the RAM buffer of the data mover becomes depleted of backup data, then the data mover transfers the backup data cached in the cached disk storage subsystem 71 to the read/write station for writing to tape.

[0071] As described above with reference to FIGS. 1 to 4, a primary data storage subsystem and a secondary data storage subsystem have been constructed to rapidly respond to a backup request. The primary data storage subsystem responds by performing a snapshot copy, and transferring backup data from the snapshot copy to the secondary storage subsystem.

[0072] With reference to FIG. 5, there are shown a number of data structures that are located in the primary data storage subsystem and are used by the snapshot copy facility (69 in FIG. 1) of the primary data storage subsystem. In the example of FIG. 5, snapshot copies have been made of two production volumes 101 and 102. The snapshot copies are shown as they would exist some time after the primary storage subsystem has received a first backup command for backing up an “extent” of the production volume 101, and some time after the primary data storage subsystem has received a second backup command for backing up an extent of the production volume 102. An “extent” of a production volume is a set of contiguous tracks of the production volume, as specified, for example, by a beginning track number and an ending track number. Since receipt of the first backup command, a host has modified tracks A and B of the production volume 101, and since receipt of the second backup command, a host has modified tracks G and H of the production volume 102. Before the first modification of each track in the snapshotted production volume 101 or 102, however, the primary data storage subsystem copies the original contents of the production volume (i.e., the contents existing at the time of the snapshot) to a track in a snapshot volume 103, 104. For example, before the primary data storage subsystem modifies track A of the production volume 101, the original contents of track A are copied to track 0 of the snapshot volume 103. In a similar fashion, track 1 of the snapshot volume 103 contains the original contents of track B of the production volume 101, track 2 of the snapshot volume 103 contains the original contents of track G of the production volume 102, and track 3 of the snapshot volume 103 contains the original contents of track H of the production volume 102.

[0073] The data structures in FIG. 5 include, for each snapshotted production volume extent, a bit map 105, 107 indicating the modified tracks in the extent. The bit map is a set of bits, such as a list, table, or array, including a respective bit for each track in the extent. For example, the first bit in the bit map indicates the modified state of the first track in the extent, the second bit in the bit map indicates the modified state of the second track in the extent, etc.

[0074] The data structures in FIG. 5 also include, for each snapshotted production volume extent, a list of pointers 106, 108 to tracks in the snapshot volumes that contain original data of the snapshot. The data structures also include, for each snapshot volume, a list of pointers 109, 110 to free tracks. When a track is copied from an extent of a production volume to a snapshot volume, a pointer to the track is taken from the list of pointers to free tracks in the snapshot volume and added to the list of pointers for the extent.

[0075] When a snapshot copy of a production volume is first created, the directory to the production volume is locked to host access while the bit map and list of pointers to snapshot tracks are allocated and initialized for the snapshot copy, and then the directory is unlocked.

[0076] The data structures for the snapshot copy facility as shown in FIG. 5 permit the production volumes to be configured and indexed in the usual fashion. The tracks of the snapshot copy for an extent can be obtained by scanning the bit map for the extent and accessing the production volume for a track having its respective bit not set in the bit map, and otherwise accessing the track in the snapshot volume using a pointer from the list of pointers for the extent if the respective bit for the track is set. The data structures used by the snapshot copy facility include information associating the tracks for the extent with their respective pointers in the list.

[0077] Although not necessary for making backup copies, the data structures associated with the snapshot copy facility may include an index to the snapshot tracks for each snapshot copy of a production volume. Such an index, for example, would be desirable if the snapshot copy facility were used for providing specified snapshot data to a distributed transaction processing system. It could also be useful if it were desired to transmit snapshot copy data from the primary storage subsystem in sequential track order, or to de-allocate specified snapshot tracks. As shown in FIG. 5, for example, an index 111 is provided to locate, in the list of pointers 106, the pointer to any snapshot track containing original data from a specified track in the production volume 101. Also, an index 112 is provided to locate, in the list of pointers 108, the pointer to any snapshot track containing original data from a specified track in the production volume 102. In other words, each index 111, 112 functions as a kind of translation table, to translate a production volume track number to a corresponding snapshot volume number and snapshot volume track number.

[0078] Although the indices 111 and 112 can be constructed in various ways, in many applications only a small fraction of the production volume tracks will have corresponding snapshot volume tracks. In this situation, a conventional hash table index is an efficient implementation for the indices 111, 112. For the index 111, for example, such a conventional hash table index includes, for each possible hashing of the production volume track number, a list of pointers to corresponding entries in the list 106. Therefore, given a specified production volume track number, any corresponding snapshot track is found by hashing the production volume track number (i.e., obtaining the remainder of the division of the production volume track number by a predetermined number of possible hashings), and then searching the corresponding entries in the list 106 to locate an entry for the specified production volume track number.

[0079] As shown in FIG. 6, the list of pointers 106 includes heading information that specifies the list's production volume extent. This heading information includes a logical device number (DEVICE_NUM), a first track number for the extent (FIRST_TRACK), and a last track number for the extent (LAST_TRACK). Each entry in the list includes a snapshot volume number (X), a production track number (A, B), and a snapshot track number (0, 1). In this example, the list is maintained as a singly-linked list, so that the header information includes a pointer to a first entry in the list (or has a value of zero if the list is empty), and each entry in the list includes a pointer to a next entry in the list (and this pointer has a value of zero for the last entry in the list).

[0080] When the snapshot copy facility is used to facilitate backup operations, it is desirable to use a singly-linked list of pointers 106 instead of simply a list in the form of an array in order to conserve memory for the list because the length of the list is highly variable and it is possible that multiple snapshot copies may be in existence simultaneously. For example, the tape library unit has multiple read/write stations (81, 82, 83, 84 in FIG. 4) which may be writing backup data simultaneously to different respective tape cassettes, and each production volume extent is written to a respective tape cassette.

[0081] Referring to FIG. 7A, there is shown a flow chart of a software procedure programmed in the port adapters of a primary data storage subsystem for creating a snapshot copy of a production volume. The procedure of FIG. 7A is invoked, for example, when the port adapter receives a command from a host requesting backup of a specified production volume extent. In the first step 120 of FIG. 7A, the port adapter allocates the snapshot data structures, including a bit map and a list of pointers to snapshot tracks for the extent. An index to the pointers may also be allocated. Then in step 121, the port adapter inserts, into the volume directory entry for the production volume, a pointer to the snapshot data structures. This pointer, for example, is zero in the volume directory entry for any volume which does not have a snapshot copy. The volume directory entry could also have a field specifying a minimum track number for the production volume extent to be snapshotted, and a maximum track number for the production volume extent to be snapshotted. After step 121, the snapshot creation procedure is finished.

[0082] Referring to FIG. 7B, there is shown a flowchart of a software procedure programmed into the port adapters for accessing a production volume in a snapshot mode. This procedure is invoked whenever a host processor requests a write operation to a production volume for which a snapshot could have been created. In the first step 122 the port adapter checks the volume director entry to determine whether a snapshot currently exists for the production volume, and if so whether the write operation is upon a track within the production volume extent of the snapshot. If the access to the production volume is not a write to a track within the production volume extent of the snapshot, then execution branches to step 123 to access the track in the production volume, and then the procedure of FIG. 7B is finished. Otherwise, if the access to the production volume is a write to a track within the production volume extent of the snapshot, then execution continues from step 122 to step 124. In step 124, the port adapter inspects the bit for the track in the bit map for the extent. If the bit is set, then execution branches to step 123 to access the track in the production volume extent, and then the procedure of FIG. 7B is finished. Otherwise, if the bit for the track is not set in the bit map, then execution continues from step 124 to step 125. In step 125 the port adapter obtains a pointer to a free track in one of the snapshot volumes. For example, the port adapter first checks whether the list of pointers 109 for a first volume 103 is empty, and if so, it then checks the list of pointers for other snapshot volumes such as the volume 104 in FIG. 5.

[0083] Once the port adapter finds a non-empty list of pointers to free tracks of a snapshot volume, it removes a pointer from the list. In step 126 the port adapter copies the track to be modified from the production volume to the snapshot volume track specified by the pointer that was taken from the list of pointers to free tracks in the snapshot volume. In step 127 the port adapter inserts the pointer into the list of snapshot track pointers for the extent, and also inserts into this list entry an identifier for the snapshot volume and an identifier for the track in the production volume extent. Then in step 128 the port adapter sets the bit in the bit map to indicate that the track is being modified. Finally, in step 129 the port adapter writes new data to the track in the production volume. After step 129, the procedure of FIG. 7B is finished.

[0084] With reference to FIG. 8A, there is shown a flow chart of a software procedure programmed in a remote link adapter of a primary storage subsystem for implementation of the snapshot copy facility. This procedure is invoked in response to a message from a port adapter when the port adapter receives a backup command from a host. In a first step 131, the remote link adapter sets a track copy pointer to point to the first track in the production volume extent. Then in step 132 the remote link adapter checks whether the bit for the track is set in the bit map for the production volume extent. If not, then in step 133 the remote link adapter copies the track from the production volume to secondary storage. Execution continues from step 133 to step 134. Execution also branches from step 132 to step 134 when the remote link adapter finds in step 132 that the bit for the track has been set in the bit map. In step 134, the remote link adapter checks whether the track copy pointer is pointing to the end of the production volume extent. If not, execution continues from step 134 to step 135. In step 135 the track copy pointer is incremented to point to the next track in the extent, and execution loops back to step 132.

[0085] If in step 134 the remote link adapter finds that the track copy pointer is pointing to the end of the production volume extent, then execution branches to step 136 In step 136, the remote link adapter deallocates the bit map. Then in step 137, for each entry in the list of pointers to snapshot tracks, the remote link adapter copies the track from the snapshot volume to secondary storage, and removes the entry from the list. Finally, in step 138, the remote link adapter deallocates the list of pointers to snapshot tracks for the extent, and the backup operation is finished.

[0086] The remote link adapter routine of FIG. 8A may copy the tracks of snapshot data in either a synchronous fashion or an asynchronous fashion from the primary data storage subsystem to the secondary storage subsystem. If the copying is done in a synchronous fashion, the procedure in FIG. 8A would not proceed from step 133 to step 134 until the remote link adapter would receive confirmation from the secondary storage that the track has in fact been written to the secondary storage. Preferably, however, the copying is done in an asynchronous fashion, in which the track is transmitted from the production volume to secondary storage in step 133 and execution then continues to step 134 without waiting for confirmation that the that the track has been written to the secondary storage. Once the remote link adapter receives confirmation that a track has been written from the production volume to secondary storage, the bit for the track in the bit map can be set to avoid any delay if and when the host makes any write access to the production volume track before the entire production volume extent has been copied to secondary storage. Also, if a backup copy is made in an asynchronous fashion, the bit map is not deallocated in step 136 until after receipt of confirmation that all of the tracks sent from the production volume to secondary storage in step 133 have actually been written to secondary storage.

[0087] To facilitate backup copying to secondary storage in an asynchronous fashion, the remote link adapter can be programmed as shown in FIG. 8B to respond to a command from the secondary data storage system indicating that a range of specified tracks have been in fact copied to secondary storage and therefore the specified tracks can be deallocated from the snapshot copy. The range of specified tracks, for example, is a small subset of the tracks in the production volume extent being backed up. In this case, the command from the secondary storage is a request to “partially free” the snapshot copy. The deallocation of the specified range of tracks will prevent copying of production volume tracks in the specified range to snapshot tracks if a host subsequently writes to the tracks for the first time after the creation of the snapshot copy, and will free any snapshot volume tracks that have been allocated to production volume tracks within the specified range.

[0088] In a first step 221 of FIG. 8B, the remote link adapter sets a deallocation track pointer to the first track in the specified range of tracks. Then in step 222, execution branches depending on the state of the bit for the track in the bit map. If the bit for the track is set in the bit map, then execution branches from step 222 to step 223. In step 223, any snapshot volume track allocated for the production volume track is deallocated by removing the snapshot track pointer from the list for the snapshot volume and returning the snapshot track pointer to the free list for the snapshot volume. If in step 222 the bit for the track is not set in the bit map, then execution continues from step 222 to step 224. In step 224, the bit for the track is set in the bit map. Therefore, if a host subsequently writes to the track, a copy of the original contents of the track will not be copied to a snapshot volume track. After step 223 or 224, execution continues to step 225. In step 225, the deallocation track pointer is compared to the end of the specified range. If the deallocation track pointer is at the end of the specified range, then the procedure is finished. If not, execution continues to step 226. In step 226, the deallocation track pointer is incremented, and execution loops back to step 222.

[0089] The remote copy routine of FIG. 8A may result in a stream of tracks of backup data that is non-sequential with respect to track number. However, for a backup operation, it is not necessary for the tracks of a production volume extent to be written in sequential order to tape. In fact, as noted above, the NDMP protocol places no restriction on the format of the backup data written to tape. In the preferred embodiment of the invention, the format of the backup data on the tape is not necessarily sequential in terms of the tracks of the extent. Nevertheless, when restoring the backup data, the track numbers are determined for each track of data read from the backup tape in order to write each track of data in its proper location in the restored production volume extent.

[0090] Alternatively, the tracks can be copied from a snapshot to secondary storage in a sequential fashion. In an example of such an alternative procedure, as shown in the flow chart of FIG. 8C, the link adapter is programmed to respond to a backup request by sequentially incrementing a track copy pointer from the beginning track in a production volume extent to an ending track in the production volume extent. In a first step 241, the link adapter sets the track copy pointer to point to the first track in the production volume extent. Then, in step 242, for the track pointed to by the track copy pointer, the link adapter indexes the bit map for the snapshot. If the bit for the track is set in the bitmap for the snapshot, then execution continues from step 242 to step 243. In step 243, the link adapter accesses the index to the snapshot tracks to translate the track number specified by the track copy pointer to a snapshot volume number and a snapshot track number. Then in step 244, the link adapter reads the snapshot track from the snapshot volume and transmits this track of backup data from the snapshot track to the secondary storage subsystem.

[0091] If the bit for the track is not set in the bit map for the snapshot, then execution branches from step 242 to step 245. In step 245, the link adapter reads the track specified by the track copy pointer from the production volume and transmits this track of backup data to the secondary storage subsystem. After step 244 or 245, execution continues to step 246. In step 246, if the track copy pointer has not reached the end of the production volume extent, then execution branches to step 247. In step 247, the track copy pointer is incremented, and execution loops back to step 242. Once the track copy pointer reaches the end of the production volume extent in step 246, the procedure of FIG. 8C is finished.

[0092] With reference to FIG. 9, there is shown a format of a data record on the backup tape. In accordance with a conventional tape record, the record shown in FIG. 9 includes, after an inter-record gap 141, a synchronization code 142, a record number 143, record data (fields 144, 145, and 146), and finally an error correction code 147 preceding another inter-record gap 148. Since the records on the backup tape are not necessarily sequential by track number, it is desirable for each record to include a track number 145 in the record data. Also, it is assumed that each tape cassette will include data from only one production volume extent. It is possible, however, that a tape cassette could be used, at various times, to store more than one version of data from the same production volume extent. Therefore, it is also desirable for the data of the record on tape to include a version identifier 144, such as a date/time stamp when the snapshot copy was made. As shown in FIG. 9, the data portion of the record on the backup tape includes the version identifier 144 followed by the track number 145 and track data 146.

[0093] It is also possible to use a record format on the backup tape that does not include a track number in each data record. For example, a correspondence table of track numbers and record numbers could be written at the beginning and/or the end of the tape.

[0094] With reference to FIG. 10, there is shown a schematic diagram of the flow of backup data through a data mover 72. Backup data from the primary storage subsystem for a production volume extent is received by a front end module 152 in the data mover 72 and either passed directly to a back-end module 151 or cached in the cache disk storage subsystem 71 for transfer at a later time to the back end module 151. The back end module 151 then writes the data to a read/write station 81 of the tape library unit 70. The front-end module 152 and the back-end module 151 share random access memory 153 of the data mover 72 including a track buffer pool 154 and pointer queues 155. The pointer queues point to track buffers in the track buffer pool 154 or tracks of data stored in the cache disk storage subsystem 71. The front-end module 152 and back-end module 151 are implemented as software programs resident in a program storage device, such as a hard magnetic disk drive, of the data mover computer 72. During operation of the data mover computer 72, these software programs are loaded into the random access memory 153 of the data mover.computer 72 for execution by the data mover computer.

[0095] With reference to the data flow diagram of FIG. 11, the front-end module selectively stores the incoming backup data on disk 161 in the cache disk storage subsystem (71 in FIG. 10) or in random access memory 162 in the shared random access memory (153 in FIG. 10) of the data mover (72 in FIG. 10). The front-end module stores the incoming tracks from the primary storage subsystem in random access memory so long as a RAM track buffer for the extent is not full of backup data, and otherwise stores the tracks on disk. The back end control writes the tracks 161 from disk and the tracks 162 cached in RAM to the tape library unit. The back end module obtains the tracks from the random access memory 162 and if no tracks are cached in RAM then the back end module obtains any tracks 161 cached on disk.

[0096] FIG. 12 shows a preferred implementation and use of the pointer queues 155 for the disk caching facility. The pointer queues 155 include a free record queue 171 and an allocated record queue 172. The records in the queues 171, 172 are flagged as either pointing to RAM or pointing to disk. Initially, a predefined set of records pointing to random access memory 173 are inserted at the head of the free record queue 171, and a predefined set of records pointing to disk 174 are inserted at the tail of the free record queue. For example, the track size is 32 kilobytes, and each record points to up to one hundred tracks, and there are about a hundred and sixty records pointing to RAM (up to about ½ gigabyte), and there are enough records pointing to disk to store nearly a full production volume.

[0097] The allocated record queue 172 has a structure similar to the structure of the free record queue 171. If the allocated record queue 172 has records pointing to RAM 175, they appear towards the head of the allocated record queue. If the allocated record queue 172 includes records pointing to disk, they appear toward the tail of the allocated record queue. Each data mover may include a free record queue and an allocated record queue for each read/write station under its control, and at any given time the allocated record queue may include pointers to tracks for data of only a single production volume extent being backed up. Upon receipt of a command to back up an extent, the data mover allocates a read/write station under its control and its associated free record queue and allocated record queue to the backup request. The front-end of the data mover removes the record at the head of the free record queue and uses the record for determining where to store tracks from the primary data storage subsystem. The front end module stores a track in either the random access memory of the data mover if the record points to random access memory or to disk in the cached disk array of the secondary data storage subsystem if the record points to disk. The front-end module transfers the RAM records to the head of the allocated record queue, and transfers the disk records to the tail of the allocated record queue. The back-end module of the data mover removes records from the head of the allocated record queue and uses the records to determine where to obtain tracks of backup data. The back-end module obtains the tracks of data from either the random access memory of the data mover or from disk in the cached disk array of the secondary data storage subsystem, and then writes the tracks to tape. Then the back-end module returns the RAM records to the head of the free record queue 171, and the disk records to the tail of the free record queue. In this fashion, priority is given to the storage and retrieval of track data from random access memory, and intermediate disk storage is used for caching backup data to be written to tape only when free random access buffer memory is unavailable.

[0098] With reference to FIG. 13, there is shown a preferred format of a disk record 181. The disk record identifies the physical location where tracks of the backup data are to be stored in the disk memory of the cached disk storage subsystem of the secondary data storage subsystem. Each track of backup data includes a track identifier followed by the track data. The tracks of backup data are stripped across at least four disk drive devices. The disk record 181 specifies a drive identifier for each disk drive device. The record 181 also specifies the first track and the last track where the backup data is stored in each device.

[0099] With reference to FIG. 14, there is shown a preferred construction for a record pointing to random access memory. The record is organized as a queue of track buffer pointers. When a record pointing to RAM is in the free record queue, the track buffer pointer queue is empty. As tracks of data are-received from the primary data storage subsystem and stored in the RAM of the data mover, pointers to the tracks of data in the RAM are inserted at the tail of the queue of track buffer pointers. As tracks are written from the RAM of the data mover to the tape library unit, corresponding track buffer pointers are removed from the head of the track buffer pointer queue. In general, for any individual record pointing to RAM or disk, the tracks are read from RAM or disk in the same sequence that they were written to RAM or disk.

[0100] With reference to FIG. 15, there is shown a flow chart of the software procedure programmed in the front-end module of a data mover. The procedure of FIG. 15 is invoked when the data mover receives a backup request from a primary data storage subsystem. In a first step 191, the data mover gets a record from the head of the free record queue. Then in step 192 the data mover receives a track of backup data from the primary storage subsystem. In step 193 the data mover puts the track in the next random access memory or disk location indicated by the record. In step 194, execution branches from step 194 to step 196 if the RAM or disk locations pointed to by the record have been filled with backup data. If the record is not full in this fashion, then execution continues from step 194 to step 195. In step 195, execution branches to step 196 if the data mover has received the last track for the extent. (Step 195, for example, tests a flag that is set when the front-end receives the last track of the extent.) Otherwise, execution loops back from step 195 to step 192.

[0101] In step 196, execution branches to step 197 if the record is a disk record. In step 197, the data mover inserts the record at the tail of the allocated record queue. If in step 196 the record is not a disk record, then it is a RAM record and execution continues from step 196 to step 198. In step 198, the data mover inserts the RAM record at the head of the allocated record queue. After steps 197 or 198, execution continues to step 199. In step 199, if the front-end has not received the last track for the extent, then execution loops back to step 191 to receive and store more tracks of backup data from the primary storage subsystem. If in step 199 the data mover has received the last track for the extent, then the procedure of FIG. 15 is finished for the extent.

[0102] With reference to FIG. 16, there is shown a flow chart of a software procedure programmed in the data mover for implementing the back-end module. The procedure of FIG. 16 is invoked when the data mover receives a backup request from a primary data storage subsystem. Execution continues from a first step 211 to a second step 212 when the allocated record queue is no longer empty. In step 212 the data mover removes the record from the head of the allocated record queue. Then in step 213 execution continues to step 214 when the read/write station allocated to the extent is ready to receive data. In step 214 the data mover transmits a next track of data from either disk or RAM as indicated by the record. Then in step 215 execution branches depending on whether there are more tracks of data indicated by the record. If so, execution loops back to step 213. When there are no more tracks indicated by the record, then execution continues from step 215 to 216. In step 216, execution branches to step 217 if the record is a disk record. In step 217 the data mover inserts the record at the tail of the free record queue. Otherwise, if the record is a RAM record, execution continues from step 216 to step 218. In step 218 the data mover inserts the RAM record at the head of the free record queue. After steps 217 or 218, execution loops back to step 211. Additional tracks are sent to the read/write station until the allocated record queue 211 is empty and the end of the extent is reached in step 219. (The front end module, for example, sets a flag upon exiting from step 199 to signal to the back-end that the end of the extent has been reached, and in step 219 the back-end tests this flag.) Once the end of the extent is reached, the back-end procedure of FIG. 16 is finished.

[0103] In view of the above, there has been described a data storage system and method providing backup and restore services with minimal host involvement and with an insubstantial reduction in storage access performance and data availability. The backup data transmitted from the primary storage to tape is buffered in a memory buffer unless the memory buffer would overflow, and the overflow is stored in intermediate disk storage. This permits high data transfer rates through the memory buffer, and minimizes disk storage resources.

[0104] It should be apparent that the buffer control program could be useful for various applications were it is permissible to re-order the sequence of data in a data stream. Therefore, the buffer control program could be useful for data migration, in which the data source would be still be primary storage, but the data sink would be a remote data storage system in lieu of the tape library unit.