Businesses, governmental organizations and other entities are increasingly saving large volumes of data necessary for daily operations. This data represents a significant asset for these entities. Consequently, data loss, whether accidental or caused by malicious activity, can be costly in terms of wasted manpower, loss of goodwill from customers, loss of time and potential legal liability. To ensure proper protection of data for business and legal purposes (e.g., to ensure quick recovery of data in the event of a disaster, to comply with document retention requirements, etc.), these entities often back up data to a physical media, such as magnetic tapes or optical disks on a regular basis.
Traditional backup systems placed an application server, backup server, source device, destination device and a local area network (“LAN”) in the data path of backup operations. Under these systems, the LANs were becoming overburdened by the amount of data being copied. Often, the backup window (the period in which data is unavailable for normal operations in order to permit backup) was too short to achieve a complete backup of data. Accordingly, many entities implemented Storage Area Networks (“SAN”) to relieve the burden of mass data storage and backup from the LAN, freeing the LAN for more immediate data storage and manipulation operations. In SANs data from multiple machines on a network may be backed up to a remote media library. Centralized data backup allows storage problems to be identified at one location and has the advantage of increased efficiency.
One example of a media library commonly used in enterprise backup systems is a magnetic tape library. In a typical magnetic tape library, tapes are contained in cartridges and the tape library contains multiple cartridge slots in which tape cartridges can be stored. The tape cartridges are physically moved between cartridge slots and tape drives by a robot. The robot is controlled by access commands received from the host devices on the network. When specific data is required, the host device determines which cartridge slot contains the tape cartridge that holds the desired data. The host device then transmits a move-element command to the robot and the robot moves the tape cartridge.
In a SCSI tape library, for example, devices that are part of the library are typically addressed by target number and logical unit numbers (“LUN”). Thus, each drive and robot of a tape library typically has a target number and LUN. Cartridge slots, on the other hand, are addressed by element numbers that are used by the robot to locate the slots. Because the robot also places tape cartridges in the drives, each drive is also associated with an element number. If multiple tape libraries are connected to a single device (e.g., a fibre channel to SCSI router, etc.), the tape libraries may be further addressed by bus number.
In current tape library systems, each tape library may present itself as an independent entity on the network. Each host in these systems maintains a view (i.e., a table of target numbers, LUNs and element numbers) of each of the tape libraries. Using this address information a host can format commands to the tape library to perform read/write, backup and other operations. In order to coordinate activities, hosts must cooperate with each other in issuing these commands.
Enabling cooperation, however, requires some form of application to arbitrate between the various hosts or applications that are accessing the tape library. Thus, it may be necessary to employ some form of application (such as a backup application, like Symantec Netbackup) to read and write tapes in a tape library.
Additionally, many of these issues may only be dealt with in software if the hosts use the same application or at least compatible applications. For example, if two hosts use the same backup application to store their data to tape, the application can coordinate the access requests of the two hosts so that both are backed up to the tape library. If, on the other hand, the two hosts use different backup applications, the applications will most likely not be able to coordinate their actions to ensure that both of the hosts are properly backed up, since they were probably independently designed and are consequently incompatible. Thus, to prevent conflicts between hosts, each host must typically use the same application to access a shared tape library. This can be inefficient as individual tape libraries cannot store data from multiple applications. Moreover, the files written on a tape by a backup application are written in a format proprietary to that backup application. Thus, to restore or otherwise access files on those tapes, the same backup application is required.
Recently, however, the Ultrium Linear Tape Open (LTO)-5 specification for tapes (hereby incorporated by reference in its entirety for all purposes) has included support for partitioning. The Linear or Long Term File System (LTFS) Format Specification by IBM and Ultrium (also hereby fully incorporated by reference in its entirety for all purposes) makes use of this partitioning support to define a tape format. The LTFS tape format defines a file system for LTO-5 tapes using an eXtensible Markup Language (XML) schema architecture and was utilized in conjunction with the IBM LTO Gen5 Drive. This file system support allows the use of an LTFS-formatted tape as if it were a file system. Files and directories may appear in a directory listing, files may be dragged and dropped from tape, data may be accessed at the file level, etc. With LTFS, tape media can be used like other storage media (e.g. flash drive, hard disk drives, etc.).
Consequently, while it previously was necessary to make use of a backup application to write and read tapes, the introduction of LTFS has simplified the storing and retrieval of files on tape by reducing such operations to a copy. Furthermore, any operating system that includes LTFS support can mount an LTFS formatted tape and read and write the files thereon.
Although LTFS makes the use of a single tape much simpler, it does, however, have limitations. As defined in the current specification the LTFS file system may be limited to a single tape. If it is desired to use multiple LTFS tapes these tapes are mounted one at a time or additional support is provided. While the capacity of an LTO-5 tape is relatively high (e.g., around 1500 GB to 3.0 TB or greater) in the realm of business data and backup applications this is a major restriction.
It is thus desired to effectively leverage tape libraries to provide storage in conjunction with a networked based file system and, particularly, to provide a networked based file system utilizing tape libraries that employ LTFS. In view of current limitations of the LTFS specification, there remains room for improvement.