Data Storage Volume Recovery Management

Abstract

A computer program product, system, and method are provided for restoring a volume of data in a data storage system. A virtual restore of the volume of data stored in storage is performed using a target volume. In one embodiment, the virtual restore includes configuring metadata associated with the target volume to map the target volume to the recovery volume as a virtual restore of the recovery volume. In response to a request by a host for data stored on the recovery volume, a physical restore of the data of the recovery volume is performed using the target volume. In one embodiment, the physical restore includes transferring data from the recovery volume to which the target volume is mapped by the virtual restore to the target volume. Additionally, the transferred data is relabeled as target volume data instead of recovery volume data.

Description

[Technical field]

[0001] The present invention relates to a computer program product, a system, and a method for managing recovery of volumes in a data storage system. [Background technology]

[0002] For long-term storage of data, various storage devices are utilized. For example, data may be stored on magnetic tape. A collection of such tapes is often referred to as a tape library, and data is written to and read from the tape using a tape drive. The magnetic tapes may, for example, be carried in cartridges and mounted in a tape drive by a robot when needed. When mounted in the tape drive, the tape of the cartridge is carried past the read / write heads of the tape drive, allowing data to be written to and read from the tape of the cartridge.

[0003] Mainframe hosts and storage controllers communicate with long-term storage devices using tape protocols. In virtual tape, a Virtual Tape Server (VTS) emulates a tape device. The International Business Machines Corporation TS7700 is one such VTS that emulates a tape library containing tape drives. The mainframe host sees the TS7700 as a tape library. Thus, a Virtual Tape Server such as the TS7700 appears to and communicates with the mainframe host as if it were a tape library. However, instead of dealing with physical tape cartridges, the Virtual Tape Server operates on logical volumes, which can be thought of as virtual tape volumes. In the same way as tape cartridges, each logical volume is assigned a VOLSER (volume serial number) and a version number that identifies the specific version of that VOLSER.

[0004] A tape library in a tape storage device typically contains a set of blank tape cartridges ready to store data. The mainframe host categorizes these tape volumes by VOLSER and records which tape volumes are available for use, which tape volumes contain data, and what the content of the data is. As a result, when a particular data set is needed, the mainframe knows which tape volume, identified by the VOLSER, to mount from the tape library to retrieve the particular data set from storage. After the data stored on a tape volume is no longer needed, the tape volume may be placed in the "scratch" category in order to reuse the tape volume and its associated VOLSER.

[0005] In known tape storage devices, a storage manager also categorizes and manages these tape volumes by VOLSER. Unlike a mainframe host, the storage manager logic of a tape storage device does not know the contents of a tape volume identified by a VOLSER, but it does record where a particular tape volume with that VOLSER is stored in a tape library and how a tape volume with that VOLSER should be managed (e.g., how long to retain a tape volume after it is deleted, how many copies to maintain, where to make those copies, etc.).

[0006] A single tape cartridge (VOLSER) can store a large amount of data, so hosts typically bundle large amounts of data together before writing it to tape. A VOLSER can contain multiple data sets, potentially thousands of data sets. A virtual tape server such as the TS7700 may retain a VOLSER for a period of time specified by the host user after the mainframe host has salvaged the active data and marked the VOLSER as deleted. This practice is used in case of accidental or malicious activity within the host where someone prematurely marks a VOLSER for deletion. In the TS7700, this practice is called category retention. Users can set a retention period for any volume that contains data, anywhere from a few hours to a few years. However, the data contained in a VOLSER is eventually deleted.

[0007] The need to restore or recover a volume may arise, whether it is a physical tape volume or a logical volume on a virtual tape server. For example, an older version of a volume may be deleted, but it may be discovered later that a particular version of the volume is still needed. For this reason, it may be desirable to retain the older version of the data. A change in the version of a logical volume occurs when, due to a reclaim process, all of the data on the logical volume is no longer valid, or any active data is moved to another logical volume. These volumes are scratched and taken out again to be reused for writing new data. A logical volume's version may also change when data is added. In this case, the same VOLSER continues to be used, but the version level changes. In any of these cases, the older version of the data may be retained for a period of time based on the needs of the user, in case an older version of the logical volume needs to be restored or recovered.

[0008] One known recovery process (also called restore process) restores an older version of a logical volume to a volume with the same VOLSER identification (ID) as the deleted volume. However, if the volume at that VOLSER contains the most recent valid data and has also been assigned the "hold" property by a retention policy, restoring the volume to the same VOLSER would violate the hold property that requires the volume to be held unchanged for the required hold period. Similarly, if the VOLSER of the volume being restored is classified as LWORM (Logical Write Once, Read Many), allowing this older version to be restored to the same VOLSER would violate these strict protection rules.

[0009] Another known technique restores an older version of a volume to a different scratch VOLSER. However, these known restore methods require that the volume be physically copied or moved to a scratch volume before the volume can be considered "restored." Such a physical copy or data movement typically requires that the volume be read from storage, the data read modified, and then written back to the storage device. For example, data read from the volume being restored is typically relabeled by updating its metadata to match the destination VOLSER. Thus, any metadata representing or contained within a file that references a VOLSER is updated to specify the new VOLSER instead of the old VOLSER. However, modifying data on a volume being restored may violate legal restrictions on the volume that prohibit data from being modified or replaced. Also, data on a volume marked as read-only, such as WROM (Write Once, Read Many), cannot be modified or replaced without violating read-only restrictions. Summary of the Invention

[0010] A computer program product, system, and method are provided for restoring a volume of data in a storage. A virtual restore of a first volume of data stored in the storage is performed using a second volume. In one embodiment, metadata associated with the second volume is configured to map the second volume to the first volume as a virtual restore of the first volume. In another aspect, a physical restore of the data of the first volume is performed using the second volume in response to a request by a host for the data stored in the first volume. In one embodiment, the physical restore includes transferring data from the first volume to which the second volume is mapped by the virtual restore to the second volume. Additionally, the transferred data is relabeled as the second volume data instead of the first volume data.

[0011] In the above embodiment, access to the data of the first volume is postponed until access to the data is requested by the host. As a result, a quick and low-cost restoration in virtual restoration is facilitated. Furthermore, during the virtual and physical restoration of the first volume, modification of the data on the first volume related to the restoration of the first volume may be avoided. Thus, restoration may be realized despite any restrictions on modification of the data of the first volume.

[0012] In another embodiment, transferring data from the first volume to the second volume includes receiving a request by the host to mount the second volume on a storage drive, and in response to the request, mounting the second volume on the storage drive, mounting the first volume on the storage drive, and copying data of the first volume mapped by metadata of the second volume to the second volume.

[0013] In the above embodiment, mounting the first volume to access the data of the first volume is deferred until mounting the second volume is requested by the host. As a result, the virtual restore facilitates a quick, low-cost restore of the first volume until the first volume is mounted for the requested physical restore. Furthermore, during the physical restore, data modification on the first volume associated with the restore of the first volume may be avoided during the virtual and physical restore of the first volume because the data is relabeled on the second volume instead of on the first volume. Thus, the restore may be realized despite any restrictions on modifying the data of the first volume.

[0014] In a further embodiment, relabeling the transferred data as second volume data instead of first volume data includes modifying header data read from the first volume when the data is stored to the second volume to identify the data copied from the first volume as being data of the second volume instead of the first volume, such that modifying the header data read from the first volume is deferred until access to the data is requested by the host.

[0015] In the above embodiment, relabeling the data is deferred until mounting of the second volume is requested by the host. As a result, the virtual restore facilitates a quick, low-cost restore of the first volume until the data is relabeled for the requested physical restore. In addition, during the virtual and physical restore of the first volume, modification of header data on the first volume associated with the restore of the first volume may be avoided. Instead, during the physical restore, the header data on the second volume is modified to relabel the user data transferred to the second volume, and the header data on the first volume is not modified.

[0016] In a further embodiment, the first volume has a first volume serial number and the second volume has a second serial number different from the first volume serial number, and when the user data is read from the first volume and the read data is copied to the second volume, modifying the header data for storage on the second volume during a physical restore of the first volume includes replacing the first serial number of the first volume in the header data with the second volume serial number of the second volume as the header data.

[0017] In the above embodiment, relabeling the data with the serial number of the second volume is deferred until mounting of the second volume is requested by the host to request the data of the first volume. As a result, the virtual restore facilitates a quick, low-cost restore of the first volume until the data is relabeled with a different serial number for the requested physical restore. In addition, during the virtual and physical restore of the first volume, changes to the serial numbers in the header data on the first volume associated with the restore of the first volume may be avoided. Instead, during the physical restore, the serial number header data on the second volume is changed to relabel the user data transferred to the second volume, and the serial number header data on the first volume is not changed.

[0018] In another embodiment, the first volume is classified as a read-only volume prior to mounting the first volume to prevent modification of the first volume due to the restoration of the first volume during both the virtual and physical restoration of the first volume.

[0019] In the above embodiment, the second volume may be classified as read-only to ensure compliance with legal or policy restrictions on the second volume, since both virtual and physical restorations may be performed without any modification to the data of the second volume. Thus, restoration may be achieved despite any restrictions on modification of the data of the first volume.

[0020] In yet another embodiment, prior to initiation of the virtual restore of the first volume, the first volume is classified into a retention category in which the volume is retained for a period of time after designated deletion. The virtual restore of the first volume further includes reclassifying the first volume into a hold category in which the volume is prevented from being modified. In response to completion of the transfer of data from the first volume to the second volume during the physical restore of the first volume, the first volume is reclassified from the hold category into the retention category.

[0021] In the above embodiment, modification of the first volume due to the restore of the first volume may be avoided during both the virtual and physical restore of the first volume. Thus, the first volume may be reclassified into a hold category to ensure that modification of the first volume is prevented. Thus, the restore may be accomplished despite any restrictions on modification of the data of the first volume.

[0022] In yet another embodiment, at least one policy is assigned to the second volume, the policy defining parameters regarding at least one of a period for which the volume is to be maintained and a permitted number of versions of the volume. In this embodiment, virtual restoration may be facilitated.

[0023] In another embodiment, a third volume is imported into the storage, the importing including performing a virtual restore of the third volume using a fourth volume having a volume serial number that conforms to a volume serial numbering convention of the storage, and the virtual restore of the third volume includes configuring metadata associated with the fourth volume to map the fourth volume to the third volume as a virtual restore of the third volume.

[0024] In the above embodiment, access to the data of the third volume during the import is deferred until access to the data is requested by the host. As a result, a quick, low-cost import is facilitated. Furthermore, modification of the data on the third volume may be avoided in connection with the import of the third volume. Thus, the import may be accomplished despite any restrictions on modification of the data of the third volume.

[0025] In yet another embodiment, the second volume is deleted and a second virtual restoration of the first volume is performed using the third volume, the second virtual restoration including configuring metadata associated with the third volume to map the third volume to the first volume as a second virtual restoration of the first volume.

[0026] In the above embodiment, the first volume remains immutable across the first and second virtual reconstructions of the first volume, so that the first volume may be recursively reconstructed multiple times as necessary, remaining immutable in each reconstruction.

[0027] In another embodiment, the first volume is stored in a secondary storage coupled to a storage server containing the primary storage, and the first volume remains unmounted in the secondary storage throughout the virtual restore of the first volume.

[0028] In the above embodiment, mounting the first volume to access its data is deferred until mounting of the second volume is requested by the host, so that the first volume remains unaccessed in the secondary storage during the virtual restore, avoiding the expense of transferring data from the first volume in the secondary storage in connection with the virtual restore. [Brief description of the drawings]

[0029] [Figure 1A] 1 illustrates an embodiment of a storage environment employing data storage volume recovery management in accordance with the present description. [Figure 1B] 1 illustrates an embodiment of a host, such as a storage controller, that employs data storage volume recovery management in accordance with the present description. [Diagram 2] FIG. 1 illustrates an embodiment of a policy pool for defining retention policies. [Diagram 3] FIG. 13 illustrates an embodiment of a version object that contains actual data about a version of an object. [Figure 4] FIG. 1 illustrates an embodiment of version metadata that includes metadata about a version object. [Figure 5A] 1 illustrates an embodiment of the operation of a virtual restore or recovery process employing data storage volume recovery management in accordance with the present description. [Figure 5B] 1 illustrates an embodiment of the operation of a physical restore or recovery process employing data storage volume recovery management in accordance with the present description. [Figure 6A] 5B illustrates a more detailed embodiment of the operation of the virtual recovery process of FIG. 5A. [Figure 6B] 5C illustrates a more detailed embodiment of the operation of the physical recovery process of FIG. 5B. [Figure 7A] 6A-6B illustrate embodiments of catalog entries for a tape library of a VTS at various stages of the virtual and physical recovery processes. [Figure 7B] 6A-6B illustrate embodiments of catalog entries for a tape library of a VTS at various stages of the virtual and physical recovery processes. [Figure 7C] 6A-6B illustrate embodiments of catalog entries for a tape library of a VTS at various stages of the virtual and physical recovery processes. [Figure 7D] 6A-6B illustrate embodiments of catalog entries for a tape library of a VTS at various stages of the virtual and physical recovery processes. [Figure 7E] 6A-6B illustrate embodiments of catalog entries for a tape library of a VTS at various stages of the virtual and physical recovery processes. [Figure 7F] 6A-6B illustrate embodiments of catalog entries for a tape library of a VTS at various stages of the virtual and physical recovery processes. [Figure 7G] 6A-6B illustrate embodiments of catalog entries for a tape library of a VTS at various stages of the virtual and physical recovery processes of FIGS. [Figure 8A] FIG. 7 is an embodiment of a catalog entry in a VTS showing a mapping of a target scratch volume to a recovery volume for the virtual recovery process of FIGS. 5A and 6. [Figure 8B] FIG. 7 is a diagram of an embodiment of a host catalog entry showing the mapping of target scratch volumes to recovery volumes for the virtual recovery process of FIGS. 5A and 6. [Figure 9A]FIG. 13 illustrates an embodiment of data read from a recovery volume. [Figure 9B] FIG. 1 illustrates an embodiment of data stored in a target private volume. [Figure 10] FIG. 1 illustrates a computing environment in which the illustrated components may be implemented. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0030] Data storage volume recovery management according to the present description provides a significant improvement to the computer art. In one aspect of data storage recovery management according to the present description, recovery of a data storage volume includes a virtual recovery or restoration that configures metadata associated with the volume to map a target scratch volume to the recovery volume. In this manner, virtual recovery may be completed without copying data from the recovery volume to the target scratch volume or performing any other transfer. While configuring the metadata may be accomplished in some instances in a fraction of a second, copying several gigabytes of data can often take approximately an hour or more. As a result, virtual recovery may be completed significantly faster, using significantly less computational or human resources, as compared to various known recovery methods. Furthermore, virtual recovery may be completed without modifying the recovery volume itself in any way, and therefore without mounting the recovery volume at all. As a result, the recovery volume may remain unmodifiable, satisfying various retention policies or legal requirements that the recovery volume remain unmodified. Furthermore, unless the data is actually required for purposes other than recovery, virtual recovery often allows for the avoidance of significant costs associated with copying or moving data.

[0031] It is understood herein that access to the data of the recovery volume is often not required immediately or even for a long period of time. As a result, as described herein, virtual recovery can often satisfy the immediate or even long-term needs related to volume recovery, and the need for actual access to the data of the recovery volume does not arise or has not yet arisen. However, in those cases where the need for access to the data of the recovery volume should become apparent at some point after the virtual recovery of the volume is completed, the data recovery management according to the present description also provides a second recovery process, i.e., a physical restore or recovery process, which provides ready access to the data of the recovery volume that has already completed the virtual recovery process.

[0032] In one embodiment, the physical recovery process includes copying data from a recovery volume to a target volume, which may be referred to as a private volume instead of a scratch volume at this stage. Thus, to provide a substantially "on demand" data transfer and obviate data transfer during the virtual recovery process, all mounts of the recovery volume to copy data from the recovery volume to the target private volume are deferred until an actual need for the data arises. As previously mentioned, eliminating data transfers for virtual recovery facilitates quick completion of the virtual recovery process. Thus, time consuming, resource consuming data transfers are deferred until an actual need for the data arises and physical recovery is performed.

[0033] In another aspect of the physical recovery process according to the present description, when data is copied from the recovery volume to the target private volume in connection with the physical recovery process, the copied data is relabeled in the target private volume to indicate that the copied data now belongs to the VOLSER of the target private volume instead of the VOLSER of the recovery volume from which the copied data was read. This relabeling of the data is therefore also deferred until after the virtual recovery process, when a need arises to access the data, and when physical recovery is performed. In this way, the relabeling of the copied data is effectively an "on demand" relabeling of the data of the physical recovery process, obviating any need for relabeling of the data during the virtual recovery process. Again, the physical recovery may be completed without modifying the recovery volume in any way. As a result, the recovery volume may remain unmodifiable, satisfying various retention policies or legal requirements that the recovery volume remain unmodified.

[0034] In another aspect of data storage recovery management according to the present description, a virtual recovery process may be used to quickly and efficiently import volumes from another source that may have different or conflicting volume serial numbering schemes or conventions. In one embodiment, the imported volume may be mapped or remapped to a new VOLSER that conforms to the existing volume serial number conventions of the target data storage system, for example. Thus, the imported volume may be mapped or remapped to a new VOLSER of the target data storage system that does not match or otherwise conflicts with an existing active VOLSER of, for example, a host or VTS. Additionally, the imported volume may be mapped or remapped to a VOLSER that conforms to the existing volume serial number range conventions, thereby preserving the existing volume serial number range conventions.

[0035] For example, it is understood that the volumes imported into a target VTS may number in the hundreds, thousands, millions, or more, depending on the particular application. The virtual recovery process of the example embodiment allows a large number of volumes to be quickly imported into a target VTS without mounting any of the volumes being imported using the virtual recovery process or otherwise accessing the volumes. As a result, the volumes being imported may be made robust to maintain the validity of their contents, knowing that each imported volume may remain immutable and will only be relabeled on-demand as part of any future mount requests for subsequent physical recovery. For example, legal reasons may require that the state of the data at the time of import remain immutable in order to maintain a consistent position for workload capture. The virtual recovery process of the example embodiment allows for the import of volumes without volume serial number (VOLSER) conflicts, without the need to access each instance, and without the need to modify the source instance. If a need arises to access the data of the imported volumes, an on-demand physical recovery of the imported volumes may be performed as described above.

[0036] FIG. 1A illustrates an embodiment of a data storage environment including one or more host systems and / or storage controllers 100 that provide object or volume data to a storage server 104 in the form of a volume retrieval or addition to an object via a first network 102. An “object,” as the term is used herein, may include a volume, a data set, a database, a logical drive, a file system, and any other grouping of data. The storage server 104 may generate objects such as backup volumes or tape volumes for backup to one or more of cloud storage 106 (which may be onsite or offsite with respect to the storage server 104) via a second network 108, a tape library 110 for storage on physical tape cartridges, and a primary storage of the storage server 104. Additionally, version backup objects may be transferred to cloud or tape storage in addition to being stored persistently or temporarily in the primary storage 112. The storage server 104 may generate version objects 300 for the various versions of the backup objects, each having a unique serial number, such as a VOLSER, and including standard tape marks and data blocks.

[0037] The storage server 104 includes a processor 114 and a memory 116 containing programs executed by the processor 114 to create and store version objects 300 of objects, such as in tape format, in one or more of the tape library 110, the cloud storage 106, and the primary storage 112. The memory 116 includes an operating system 118 for managing the operation of the storage server 104, and a version manager 120 for creating and managing object versions 300, such as tape volumes, in one or more of the tape library 110, the remote storage 106, and the primary storage 112. A recovery manager 123 manages the recovery of volumes in a virtual recovery process and an on-demand physical recovery process, as described in more detail below.

[0038] Referring to FIG. 1B, the host 100 includes a processor 114h (FIG. 1B) and a memory 116h containing programs executed by the processor 114h to provide object or volume data to the storage server 104. The memory 116h includes an operating system 118h for managing the operation of the host 100 and a version manager 120h for providing object or volume data to the storage server 104. In addition, the version manager 120h issues commands to the storage server 104 for management of object versions 300, such as tape volumes, stored in one or more of the tape library 110, the remote storage 106, and the primary storage 112. The version manager 120h maintains metadata identifying various characteristics of objects stored in or by the storage server 104 in the form of a catalog 121h. The recovery manager 123h issues commands to the storage server 104 for recovery of object versions 300, such as tape volumes, stored in one or more of the tape library 110, the remote storage 106, and the primary storage 112.

[0039] Referring again to FIG. 1A, the storage server 104 (FIG. 1A) may obtain a serial number, such as a volume serial number (VOLSER), from the scratch pool 122 and use it for the object version 300 to create and store the object version 300 in one or more of the tape library 110, the remote storage 106, and the primary storage 112. All versions of the object / volume use the same serial number or VOLSER. The tape volume serial number or VOLSER is used to uniquely identify a tape volume. For tape storage, the VOLSER is specified in the tape label, which is the first set of information contained on a tape. In addition to the tape label, other metadata stored inside the tape volume also identifies the VOLSER of the volume.

[0040] The version manager 120 may further generate version metadata 400 including metadata regarding the version object 300, which may be used to restore data of the version object 300 from a higher version numbered version object 300. Additionally, the version manager 120 processes commands from the host 100 for management of the object versions 300 stored in one or more of the tape library 110, the remote storage 106, and the primary storage 112, such as tape volumes. The version manager 120 of the storage server 104 also maintains metadata identifying various characteristics of the objects stored in or by the storage server 104 in the form of a catalog 121b.

[0041] Serial numbers or VOLSERs obtained from the scratch pool 122 may be assigned to policy pools 200, with different policy pools 200 maintaining different data retention policies. Upon creation of an instance of object version 300i for writing to storage such as 106, 112, or 110, the version manager 120 may add an instruction for object version 300i to the export queue 124 for exporting object version 300i to storage 112, 110, 106.

[0042] In one embodiment, the storage server 104 may comprise a virtual tape server, such as, by way of example, an International Business Machines Corporation (IBM) TS700 virtual tape server, for managing the creation of versions of objects and offloading them to the storage 110, 112. The virtual server emulates a tape library including tape drives to the attached host / storage controller 100. The storage server 104 may provide an archive of objects for storage in one or more of the low-cost physical tape library 110, the cloud storage 106, and the primary storage 112.

[0043] 1A as program code that is loaded into memory 116 and executed by processor 114. Similarly, program components in memory 116h, including 118, 120, and 123, are shown in FIG. 1B as program code that is loaded into memory 116h and executed by processor 114h. Alternatively, some or all of the functionality of the components may be implemented in hardware devices such as Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), or the like, or performed by separate dedicated processors.

[0044] The memory 116, 116h may comprise one or more memory devices, volatile or non-volatile, such as dynamic random access memory (DRAM), phase change memory (PCM), magnetoresistive random-access memory (MRAM), spin transfer torque (STT)-MRAM, SRAM storage devices, DRAM, ferroelectric random-access memory (FeTRAM), nanowire-based non-volatile memory, and non-volatile Direct In-Line Memory Modules (DIMMs), NAND storage (e.g., flash memory), solid state drive (SSD) storage, non-volatile RAM, etc.

[0045] The version manager 120 may export the object versions 300 to one or more of the tape library 110, the remote storage 106, and the primary storage 112 via a network. For example, FIG. 1A illustrates a storage server 104 coupled to a remote cloud storage 106 via a second network 108. In an alternative embodiment, the cloud storage 106 may be local, e.g., in the same building as the storage server 104. The cloud storage 106 may comprise a cloud storage system provided by a cloud storage service provider. Examples of cloud storage 106 service providers include DropBox®, Google® Drive, Amazon Cloud Drive®, Amazon® S3, IBM® Cloud Object Storage System™, etc. (Dropbox is a registered trademark of Dropbox Inc., Google is a registered trademark of Google Inc., Amazon and Amazon Cloud Drive are trademarks of Amazon Technologies Inc., and IBM and Cloud Object Storage System are trademarks of IBM worldwide).

[0046] The version manager 120 uses the primary storage 112 as a virtual tape cache to store object versions 300 as they are created before they are added to the export queue 124 for migration to storages 106, 110, 112. In a further embodiment, the primary storage 112 may be used to store object versions 300 when no storages 106, 110, 112 are available.

[0047] The primary storage 112 may comprise various types or classes of storage devices, such as magnetic hard disk drives, solid state storage devices (SSDs) made of solid state electronics (such as Electrically Erasable Programmable Read-Only Memory (EEPROM), flash memory, flash disks, Random Access Memory (RAM) drives, storage-class memory (SCM)), phase change memory (PCM), resistive random access memory (RRAM), spin transfer torque memory (STM-RAM), conductive bridging RAM (CBRAM), magnetic hard disk drives, optical disks, tapes, etc. The volumes in the primary storage 112 may further comprise arrays of devices, such as Just a Bunch of Disks (JBOD), Direct Access Storage Devices (DASD), Redundant Array of Independent Disks (RAID) arrays, virtualization devices, etc. Additionally, the storage 112 may comprise different types of storage devices, such as heterogeneous storage devices from different vendors, and a first type of storage device (e.g., hard disk drive) having a slower data transfer rate than a second type of storage device (e.g., SSD). The cloud storage 106 and the tape library 110 may be considered secondary storage in comparison to the primary storage 112.

[0048] The first network 102 used by the host / storage controller 100 to communicate volume data to the storage server 104 may include storage networks, such as one or more interconnected local area networks (LANs), storage area networks (SANs), wide area networks (WANs), peer-to-peer networks, wireless networks, etc. The second network 108 may include a network, such as the Internet, a wide area network (WAN), etc., through which remote storage, such as the cloud storage 106, may be accessible. In an alternative embodiment, the first network 102 and the second network 108 may be the same network, and one or more of the primary storage 112 and the tape library 110 may be remote storage accessible via the network.

[0049] FIG. 2 shows an embodiment of an instance 200i of a policy pool 200, where the instance 200i is assigned the object serial numbers (e.g., VOLSERs) of the objects or volumes to be written, and includes a pool identifier 202 that identifies the pool, assigned object serial numbers (VOLSERs) 204 assigned to the pool, object versions 206 contained in the pool with respect to the object serial numbers 204, and one or more retention policies 208 for determining how long object versions are retained within the policy pool 200.

[0050] Examples of retention policies include:

[0051] -Version metadata for version 400 i and version object 300 i The maximum number of previous versions to keep, including data from

[0052] -Object version metadata 400 i and version object 300 i The maximum number of days to retain previous version information, including data from

[0053] - Version Object 300 i The maximum number of previous versions of data that will be retained.

[0054] - Version Object 300 i If the version number of an object is a multiple of k plus 1 (e.g., the version number of an object = 1 + x * k, where x is an integer greater than zero), then the version object 300 i We keep one version for every k versions of an object, such that the kth version of the data is kept.

[0055] FIG. 3 shows an instance 300 of a version object that is created from object data or volume data sent from the host / storage controller 100. i The object version 300 includes the object serial number (e.g., VOLSER) assigned to the object / volume for which the version is being created, the creation timestamp 304 when the object version was created, the object version number 306, and the most recently added data. i Host / Storage Controller 100 from version V 1 ~V n Object version data for each version of object data 308 1 ~308 nand host trailing metadata 312 that is added to the end of the object version by the host / storage controller 100 that created the object version sent to the storage server 104. The host trailing metadata 312 may include information about the structure and format of the object, as well as information about the host / storage controller 100 that generated the data for the object.

[0056] Figure 4 shows the version object 300. i Instance 400 of version metadata 400 that contains metadata about i Instance 400 i Version object 300 i The version object 300 of the previous version may be kept separately to save space. i The version metadata may be retained if the instance is deleted. i The assigned object serial number (e.g., VOLSER) 402, the policy pool 404 that contains the assigned object and serial number 402, the version number 406 of the version object, and the version number of the version object 300. i One or more version objects 300 of higher version contain the creation timestamp 408 and the version number 406 of when the j Indicates version location 410 and version metadata 400 i Object 300 represented by i The object size is 412, the data of the version object is 300. j4, the version object 300 includes an end offset 414 indicating where the version object ends if the version object 300 is included in the version number 406 (where the appended data of the version number 406 ends), and information added by the host / storage controller 100 providing the object data. i The host trailing metadata 312 may include host trailing metadata 416 located at the end of the version metadata 400 as 416, since the host trailing metadata 312 of the version number 406 may be overwritten as new data and changes are added. i This saves the version object 300 i be restored using the original host trailing metadata 312.

[0057] Version Metadata 400 i maintains any other information needed to identify the beginning and end of a version of the data.

[0058] In addition to maintaining the version metadata 400, the version manager 120 also maintains the version object 300, which contains the actual data of the object, until the retention policy determines the end of the version retention period, at which point the version metadata 400 expires and the version manager 120 deletes the version metadata 400. The version metadata 400 may be used to identify and access for restoration either the current version number or a version identified in the version metadata 400 from a higher version numbered object 300. Thus, if a particular version of a volume is marked for deletion by a user, the data of that volume version may nevertheless be accessed for restoration to a private volume by a physical recovery process, as long as the retention period defined by the retention policy assigned to that version of the deleted volume has not expired, as described herein. Thus, the data of a deleted volume may be accessed for restoration to a new volume by a physical recovery process, if the version metadata 400 identifying that volume version, and the version object 300 containing the actual data of the object still exist. However, a deleted volume cannot be recovered after the version metadata 400 identifying that volume version, and the version object 300 containing the object's actual data, have been destroyed in accordance with the applicable retention policy.

[0059] Although volume recovery management has been described herein in connection with volumes stored as objects 300 with associated metadata 400 achieving improved efficiency in the use of storage space, it is understood that volume recovery management in accordance with this description may be utilized in data storage systems utilizing other data and metadata storage techniques. For example, volume recovery management in accordance with this description may be utilized in a data storage system in which each version of a volume is stored and retained collectively as a separate unit until discarded due to expiration of a policy retention period.

[0060] As indicated above, volume recovery management according to the present disclosure provides a virtual recovery process that provides for the restoration of a volume without requiring the recovery volume to be mounted and without requiring any modification of the recovery volume. In addition, the physical recovery process provides for "on-demand" relabeling of data copied to a target private volume until the data on the recovery volume is actually accessed.

[0061] FIG. 5A illustrates one embodiment of a virtual recovery process with recovery volume VolR being virtually recovered to a target scratch volume VolP in this example. The virtual recovery process of FIG. 5A is also referred to herein as a virtual restore process. FIG. 6A illustrates a more detailed embodiment of the operation of the virtual recovery process illustrated in FIG. 5A. As described in more detail in connection with FIG. 5A and FIG. 6A, the virtual recovery process of FIG. 5A includes a mapping process 504 (FIG. 5A) that maps the target scratch volume VolP to the recovery volume VolR. In one aspect of volume recovery according to the present description, upon completion of the virtual recovery illustrated in FIG. 5A, recovery of volume VolR may be considered complete as long as host 100 does not need to access data in recovery volume VolR.

[0062] On the other hand, FIG. 5B illustrates an example of a physical recovery process according to the present description when host 100 actually needs to access data in recovery volume VolR for purposes other than recovery. The physical recovery process of FIG. 5B is also referred to herein as a physical restore process. As described in more detail below, in response to a request by host 100 for user data stored in recovery volume VolR, a physical restore (FIG. 5B) of recovery volume VolR is performed using a target scratch volume VolP that has been mapped to recovery volume VolR by the virtual restore process of FIG. 5A. The physical restore includes copying data upon request (represented by arrow 514) from recovery volume VolR to a target private volume VolP to which target scratch volume VolP has been mapped by the virtual restore of FIG. 5A, and also includes modifying data headers upon request (represented by arrow 518) to relabel the copied data as VolP data instead of VolR data. In this way, accessing and copying the data in the recovery volume VolR is deferred until on demand, i.e., until access to the data is requested by the host. Furthermore, relabeling of the data is also an on demand process, and the modification of the header is also deferred until access to the data is requested by the host. In addition to the tape label, other metadata stored inside the tape volume identifies the VOLSER of the volume. Therefore, to relabel the data on a tape volume due to a change in VOLSER, all file names and metadata within the files that refer to this VOLSER are also updated as part of the relabeling process. As a result, all known metadata read from the recovery volume VolR for storage in the target private volume VolP, inside the volume that directly references the source volume serial number (VOLSER), is updated for storage in the target volume as part of the physical restore.

[0063] In one embodiment, the mapping process 504 of the virtual recovery process of Figure 5A is accomplished by configuring the metadata maintained by the host and associated with the target private volume VolP such that the host 100 treats the target private volume VolP as if it were recovery volume VolR. In addition, the storage system's VTS configures the metadata maintained by the VTS and associated with the target scratch volume VolP to point to the recovery volume VolR in case the host 100 later needs to access data in the recovery volume VolR once the virtual recovery process of Figure 5A is complete.

[0064] In accordance with one aspect of volume recovery according to the present description, it will be appreciated that unless host 100 needs to access data in recovery volume VolR, the virtual recovery process illustrated in FIG. 5A obviates the need to actually transfer data from recovery volume VolR to scratch volume VolP until host 100 actually needs to access data in recovery volume VolR for application purposes rather than merely recovery purposes. Thus, for the virtual recovery process of FIG. 5A, target scratch volume VolP and recovery volume VolR are shown as unmounted in FIG. 5A because no actual data transfer is required. Because the virtual recovery process of FIG. 5A focuses on configuring metadata associated with target scratch volume VolP instead of copying data from recovery volume VolR to target scratch volume VolP, the virtual recovery process of FIG. 5A may be completed quickly compared to an actual data transfer from volume VolR to volume VolP.

[0065] On the other hand, recovery methods are already known that require volumes to be recovered and physically copied or moved to a scratch volume before they are considered "restored". Having to move (copy) data has multiple disadvantages: Moving (copying) data can be time consuming because tape volumes can be very large (typically 4GB or more in size). Also, if the data is archival data that may never be accessed except under extreme circumstances, copying the data and storing it on a new VOLSER takes time. Typically, users will also monitor the process to ensure it is completed, so if it takes an hour to process a single large volume, someone will be monitoring the process to completion. Moving (copying) data also requires system resources such as memory, CPU, and disk utilization. Moving (copying) data also requires the use of tape devices if performed by a VTS or physical tape library. These tape devices are tied up doing this work instead of more important production work. Having to read data can be expensive if the data only resides in a system (such as a cloud storage system) that incurs additional costs when it is read.

[0066] Additionally, in some environments, archived instances may be considered to be on legal hold, such that modification or replacement is not legally permitted and they are treated as "read only." Other examples of environments that may prevent known recovery methods include volumes with strict retention or media policies, such as WROM (write once read many).

[0067] On the other hand, virtual recovery according to the present description provides a user with the ability to restore an older version of a volume to a scratch volume without any physical data movement. Instead of moving the actual data, it is only necessary to modify the metadata that maps the new scratch volume to the older version of the volume. Modifying the volume's metadata typically requires less than a second to complete and may require a negligible amount of resources compared to the amount of resources typically used for an actual data copy of a large volume. Furthermore, when the recovery volume is stored in a system such as a cloud system that charges by read operation, virtual recovery according to the present description can eliminate additional costs. Since physical recovery, in which data is physically copied and volume header data is modified, is deferred until the host actually needs the data and therefore may be deferred until the host mounts the volume, cloud charges for reading data may be completely avoided in the recovery process if the host does not always need to actually read the data.

[0068] Blocks 602-622 of Figure 6A show a more detailed example of the virtual recovery process of Figure 5A from the perspective of host 100. Blocks 630-650 of Figure 6B show a more detailed example of the physical recovery process of Figure 5B from the perspective of host 100.

[0069] In the example of FIG. 6A, the recovery manager 123h of the host 100 initiates a virtual recovery (FIG. 5A) by issuing (block 602 of FIG. 6A) a command (represented by arrow 604 labeled “Command”) to the tape library of the VTS storage system, which command requests the restoration of volumes. In one embodiment, the command indicates the number of volumes that the host 100 requires to be recovered and from which scratch category the target volumes may be selected. Such a command or request may be issued manually or automatically via an appropriate interface, such as a management interface. In one embodiment, the request may be in the form of: LIBRARY REQUEST, library-name, RECOVER, NUM, N, C Here, the name of the command is "LIBRARY REQUEST", the parameter "library-name" identifies the target library that the command is directed to, the parameter "RECOVER" identifies the operation to be performed, the parameters "NUM, N" identify the number of volumes to be recovered, and the parameter "C" identifies the scratch category from which the target scratch volumes are to be selected. Thus, the request LIBRARY REQUEST, library-name, RECOVER, NUM, 1, 0002 Requests a restore of a single logical volume using scratch category 0002 as the target category. It is understood that other command or request format names, and parameters may be used, depending on the particular application.

[0070] In an example embodiment, blocks 702-726 of FIG. 6A illustrate one example of the virtual recovery process of FIG. 5A from the perspective of a tape library of a storage server 104, such as a VTS (Virtual Tape Server) 104, and blocks 738-760 of FIG. 6B illustrate one example of the physical recovery process of FIG. 5B from the perspective of a tape library of a VTS storage server 104 of a storage system. In the example of FIG. 6A, in response to command 604 of block 602 (FIG. 6A) requesting initiation of a virtual recovery process for a specified number of volumes taken from a specified scratch category, recovery manager 123 of VTS 104 receives the command (block 702 of FIG. 6A) and selects a particular volume or volumes from the identified scratch category (block 702 of FIG. 6A) and places them in a special hold category.

[0071] Figure 7A illustrates in tabular form the metadata maintained by the storage device's VTS 104 tape library in a suitable database, referred to herein as a tape library catalog. The example of Figure 7A illustrates three entries for three volumes: volume serial number L00000, version V1, volume serial number L00000, version V2, and scratch volume S99999, which is classified as being in scratch category 0002. For simplicity, the VTS catalog is illustrated as including three entries, but it is understood that a VTS tape library catalog may include several thousand or more entries depending on the particular application.

[0072] Commands from the host LIBRARY REQUEST, library-name, RECOVER, NUM, 1, 0002 In response, the recovery manager 123 of the VTS 104 may select, for example, scratch volume S99999 (FIG. 7A) in the general scratch category 0002 for the virtual recovery process shown in FIG. 5A (block 702 of FIG. 6A). In that case, the VTS 104 selects scratch volume S99999 from the general scratch category 0002 and temporarily places the volume in a special hold category, such as category Y000 as shown in FIG. 7B (block 710 of FIG. 6A). In addition, the recovery manager 123 of the VTS 104 issues a response to the host, as represented by arrow 712, informing the recovery manager 123h of the host 100 that the scratch volume having volume serial number S99999 has been retrieved from the specified scratch category 0002 in response to the request issued by the host.

[0073] When the recovery manager 123h of the host 100 receives the identification of the requested scratch volume as having volume serial number S99999 (block 606 of FIG. 6A), it issues another command to the VTS 104 requesting that the target scratch volume having volume serial number S99999 be placed in the private category (block 610 of FIG. 6A), as indicated by arrow 612, to ensure that the target scratch volume having volume serial number S99999 is not used for other purposes by other hosts or processes on other hosts. As described below, the scratch volume having volume serial number S99999 is used as the target scratch volume represented by volume VolP (FIG. 5A) for the virtual recovery process illustrated in FIG. 5A. In response to command 612, recovery manager 123 of VTS 104 places the scratch volume having volume serial number S99999 in a private category, such as category C000 shown in FIG. 7C (block 718 of FIG. 6A).

[0074] When recovery manager 123h of host 100 reserves scratch volume having volume serial number S99999 for its own private use, it issues a command to VTS 104 (block 614 of FIG. 6A) to assign one or more retention policies to scratch volume having volume serial number S99999, as represented by arrow 616. These policies define, for example, how long a volume is to be retained before it can be discarded.

[0075] For example, Host 100 may use a known command, such as the existing MVS LIBRARY LMPOLICY command, to assign a policy to the "n" requested volumes (which are now private) used in the recovery (block 614 of FIG. 6A). In this example, to assign a retention policy to scratch volume S99999, the LIBRARY LMPOLICY command is used with the following parameters: LIBRARY LMPOLICY, S99999, SG=SGRECOVER, MC=MCRECOVER, SC=SCRECOVER, DC=DCRECOVER The policies established in the VTS104 tape library can be existing policies used for other data or can be new policies for recovery purposes. In response to receiving the policy assignment command 616, the VTS 104 assigns the policy or policies indicated by the command 616 to the scratch volume having volume serial number S99999 (block 718). The assignment of the policy to the scratch volume having volume serial number S99999 is represented in Figure 7D as the scratch volume having volume serial number S99999 being assigned to volume category C000. In this manner, the policy actions are associated with the policy name specified in the tape library of the VTS (block 718 of Figure 6A).

[0076] When recovery manager 123h of host 100 has reserved scratch volume having volume serial number S99999 for its own private use and assigned the appropriate retention policy to the scratch volume, it issues a recovery command to VTS 104 (block 618 of FIG. 6A), as represented by arrow 620. The recovery command, referred to herein as MVS LIBRARY RECOVER, identifies the volumes selected to be recovered and the volumes selected to be the target scratch volumes. For example, the MVS LIBRARY RECOVER command may be parameterized as follows: LIBRARY REQUEST, library-name, RECOVER, S99999, L00000, V2

[0077] Thus, the example restore command 620 identifies the private scratch volume S99999, which in this example is represented in the third entry in the VTS catalog (FIG. 7D), as the target scratch volume. Thus, in this example, private scratch volume S99999 is selected by the restore command 620 to be the target scratch volume VolP in the virtual restore process of FIG. 5A.

[0078] In this example, the recovery command 620 also identifies the recovery volume as having volume serial number L00000, version V2, and classified as volume category C000, as represented by the second entry in the VTS tape library catalog of Figure 7D. Thus, in this example, recovery volume L00000, version V2 is selected to be recovery volume VolR in the virtual recovery process of Figure 5A.

[0079] In some embodiments, the virtual recovery process of Figure 5A may be initiated by a user via an appropriate user interface. After the virtual recovery process is initiated, the host 100, in one embodiment, may automatically issue the commands of Figure 6A. In other embodiments, one or more of the commands described in connection with Figure 6A may be manually issued by a user from the host 100 via an appropriate user interface of the host.

[0080] In response to a recovery command 620 issued by the host 100 identifying recovery volume VolR and target scratch volume VolP for the virtual recovery process (FIG. 5A), the recovery manager 123 of the VTS 104 performs the virtual recovery process shown in FIG. 5A (block 720 of FIG. 6A) to virtually recover volume VolR using the target scratch volume VolP. In one embodiment of the virtual recovery process, the VTS 104 changes the state of recovery volume VolR (volume L00000, V2 in this example) from a previous hold state shown in FIG. 7C with respect to the VTS tape library catalog to a hold state shown in FIG. 7D with respect to the VTS tape library catalog (block 722 of FIG. 6A).

[0081] In this example, in the hold state, recovery volume VolR is marked as read-only (block 722 of FIG. 6A) to ensure that all previous properties are maintained and that recovery volume VolR is not modified by the recovery process, i.e., recovery volume VolR is immutable. The target scratch volume VolP (volume S99999 in this example) may also be treated as immutable or as a read / write volume, depending on the client's preference.

[0082] Thus, as part of the virtual recovery of Figure 5A, host 100 may completely avoid any monitoring of either recovery volume VolR or private target scratch volume VolP for the virtual recovery process, leaving the storage server's tape drives or other storage drives free for other uses during the virtual recovery process. Both recovery volume VolR and target scratch volume VolP may remain unmounted unless host 100 has an actual need to access data in recovery volume VolR. However, if a need arises to access data in recovery volume VolR, then the physical recovery of Figure 5B may be performed, as described below.

[0083] In another aspect of the virtual recovery process, further responsive to receiving recovery command 620 (block 722 of FIG. 6A), recovery manager 123 of VTS 104 associates recovery volume VolR (in this example, volume L00000, V2) with target scratch volume VolP (in this example, volume S99999, version V1) for the virtual recovery process (block 726 of FIG. 6A). In one embodiment, VTS 104 associating recovery volume VolR and target scratch volume VolP includes mapping target scratch volume VolP to recovery volume VolR, as represented by arrow 504 labeled "Mapping" in FIG. 5A. In the case of the example embodiment, this mapping may be accomplished by modifying metadata of target scratch volume VolP (in this example, S99999) to point to data stored in recovery volume VolR (in this example, L00000, V2). For example, metadata in the form of a tape library catalog entry in VTS 104 may be configured to map a target scratch volume VolP to a recovery volume VolR, as shown in the mapping catalog entry represented by the table of FIG. 8A, such that the metadata associated with the target scratch volume VolP, as represented by the VTS mapping catalog entry of FIG. 8A, points to the recovery volume VolR.

[0084] As described in further detail in connection with physical recovery such as the physical recovery shown in FIG. 5B, the mapping of the target scratch volume VolP to the recovery volume VolR as shown in FIG. 5A and FIG. 8A may be utilized in a subsequent physical recovery to locate and read the data of the recovery volume VolR if the host 100 needs to access the data of the recovery volume VolR after the virtual recovery is completed. However, the virtual recovery of the example embodiment does not itself require either the recovery volume VolR or the target scratch volume VolP to be mounted for reading or writing. Instead, the mapping as represented by the arrow 504 in FIG. 5A and the VTS catalog entry in FIG. 8A (FIG. 5A) is accomplished by configuring metadata associated with the volumes VolR and VolP without requiring mounting either of the volumes. Thus, the virtual recovery may be accomplished without reading from any back-end storage device, such as a physical tape drive or cloud. Also, no header information within the data stored in the volumes needs to be modified to complete the virtual recovery.

[0085] In contrast, in various known recovery methods, recovery requires that the recovery volume be read from an external storage device and the data read be modified to point to a different VOLSER and written back to the storage device, whereas, as previously described, in the virtual recovery of Figures 5A, 6A, and 8A, the data stored in recovery volume VolR (in this example, L00000 V2) can remain unaccessed and therefore unmounted and unread and unwritten throughout the virtual recovery.

[0086] The host 100 issues a recovery command to the VTS 104 (block 618 of FIG. 6A), as represented by arrow 620, identifying the volume VolR selected to be recovered and the volume VolP selected to be the target scratch volume, and the recovery manager 123h of the host 100 associates the recovery volume VolR (volume L00000, v2 in this example) with the target scratch volume VolP (volume S99999, version V1 in this example) for the virtual recovery process (block 622 of FIG. 6A). In one embodiment, the host 100 associating the recovery volume VolR and the target scratch volume VolP includes mapping the target scratch volume VolP to the recovery volume VolR. The host 100 mapping the target scratch volume VolP to the recovery volume VolR is also a component of the mapping represented by the arrow 504 labeled "Mapping" in FIG. 5A.

[0087] In an example embodiment, the mapping by host 100 may be accomplished by modifying the metadata of target scratch volume VolP (S99999 in this example) to reference target scratch volume VolP as if it were recovery volume VolR (L00000, V2 in this example). For example, metadata in the form of a mapping catalog entry at host 100 may be configured to reference target scratch volume VolP as if it already contains the data currently stored in recovery volume VolR, as shown in the host catalog entry represented by the table in FIG. 8A. In one embodiment, the reference to the VOLSER of recovery volume VolR (volume L00000 in this example) is replaced with the VOLSER of target scratch volume VolP (S99999 in this example). Thus, if a host needs to identify a data set currently stored in, for example, recovery volume VolR, the reference to recovery volume VolR is replaced with a reference to target scratch volume VolP, as shown in Figure 8B. Although the example embodiment describes the mapping metadata as catalog entries, it will be appreciated that such mapping metadata may be in other forms, such as, for example, data structures within the application, depending on the particular application.

[0088] As described in further detail in connection with physical recoveries such as the physical recoveries shown in FIG. 5B, the mapping of the target scratch volume VolP to the recovery volume VolR as shown in FIG. 5A, FIG. 8A, and FIG. 8B may be utilized in subsequent physical recoveries such that the host 100 mounts the target scratch volume VolP if the host 100 needs to access the data in the recovery volume VolR after the virtual recovery is completed. However, as previously described, the virtual recovery of the example embodiment does not itself require that either the recovery volume VolR or the target scratch volume VolP be mounted, read, or written. Instead, the mapping as represented by arrow 504 in FIG. 5A and by the VTS mapping catalog entry in FIG. 8A and the host mapping catalog entry in FIG. 8B (FIG. 5A) is accomplished by the VTS 104 and the host 100 configuring metadata associated with volumes VolR and VolP, respectively, without requiring mounting either of the volumes. Therefore, virtual recovery can be achieved without reading from any back-end storage device, such as a physical tape drive or cloud, and there is no need to modify any header information inside the data stored on the volume to complete the virtual recovery.

[0089] In contrast, in various known recovery methods, recovery requires that the recovery volume be read from an external storage device, the data read modified to indicate a different VOLSER, and then written back to the storage device. In contrast, as previously described, in the virtual recovery of Figures 5A, 6A, 8A, and 8B, the data stored in recovery volume VolR (in this example, L00000 V2) can remain unaccessed and therefore unreadable and unwritten (unmodifiable) throughout the entire virtual recovery.

[0090] As previously discussed, FIG. 5B illustrates an example of a physical recovery process according to the present description when host 100 actually needs to access data in recovery volume VolR for purposes other than recovery. FIG. 6B illustrates a more detailed example of the operation of the physical recovery process of FIG. 5A. In this embodiment, when host 100 determines that it actually needs to access data in recovery volume VolR that has been mapped by the virtual recovery process to target scratch volume VolP (FIG. 8B) as if it were contained in target volume VolP, as previously described (block 630 of FIG. 6B), recovery manager 123h of host 100 issues a command to VTS 104 to mount target scratch volume VolP that has been mapped by host 100 to recovery VolR (block 634 of FIG. 6B). At this point, target scratch volume VolP is referred to as target private volume VolP instead of scratch volume. In this manner, Host 100 treats target private volume VolP (S99999 in this example) as if it were recovery volume VolR (L00000, V2 in this example), as previously described. A command to VTS 104 to mount target private volume VolP is represented in Figure 6B by arrow 636 labeled "COMMAND," initiating the physical recovery process of Figure 5B using target private volume VolP for recovery volume VolR.

[0091] In response to the Host 100 command 636 to mount the target private volume VolP, the recovery manager 123 of the VTS 104 mounts (block 738 of FIG. 6B) the target private volume VolP (S99999 in this example) but also mounts (block 738 of FIG. 6B) the recovery volume VolR (L00000, V2 in this example) to which the target scratch volume VolP was mapped by the VTS 104 in the virtual recovery process described above. In this example, the VTS 104 configures the metadata associated with the target private volume VolP to point to the recovery volume VolR to which the target scratch volume VolP was mapped. The VTS 104 also updates the VTS tape library catalog to indicate a "mounted" state for the target private volume VolP, as depicted in FIG. 7E.

[0092] Using the mapping of target private volume VolP (S99999 in this example) to recovery volume VolR (L00000, V2 in this example), the data of the mounted recovery volume VolR is accessed by the recovery manager 123 and copied to the target private volume VolP (block 742), as represented by arrow 514 (FIG. 5B) labeled "Copy Data." FIG. 9A illustrates in schematic form an example of data read from a mounted recovery volume VolR, including a header portion 902 that contains metadata identifying the source of the data as recovery volume VolR. The header portion 902 may contain other metadata that describes other characteristics of the data read from the recovery volume VolR, depending on the particular application.

[0093] The remainder of the data read from recovery volume VolR (in this example, L00000, V2), referred to in Figure 9A as non-header data 904, includes user data stored in recovery volume VolR and may include other types of data, depending on the particular application. The non-header data 904 is accessed from the mounted recovery volume VolR and copied (block 742 in Figure 6B) to the target private volume VolP (in this example, S99999) as shown in Figure 9B and represented by arrow 514 (Figure 5B) labeled "Copy Data."

[0094] As shown in FIG. 9B and represented by arrow 518 (FIG. 5B) labeled "Modify Header" in FIG. 5B, when the non-header data 904 is copied to the target private volume VolP (S99999 in this example), the header data 902 read from the recovery volume VolR is replaced with a replacement header 906 (FIG. 9B) that is stored in the target private volume VolP along with the data 904 (block 746 in FIG. 6B). In this way, the data read from the recovery volume VolR is relabeled when stored in the target private volume VolP to indicate the source of the data as the target private volume VolP (S99999 in this example) in any subsequent reads of that data from volume VolP. The recovered volume may now be accessed as volume serial number S99999 for all uses.

[0095] Further, accessing and copying the data of the recovery volume VolR is deferred until access to the data is requested by the host. Furthermore, relabeling of the data source is also an on-demand process, and header modification for copy operations targeting the target private volume VolP is also deferred until access to the data of the recovery volume VolR is requested by the host 100 by requesting mounting of the target private volume VolP. In this embodiment, as previously described, the recovery volume VolR can remain immutable, i.e., unchanged, during the virtual recovery as well as the physical recovery (block 748 of FIG. 6B). Thus, the recovery volume VolR can still be used as a source in the future when a read from the cloud or tape of the external storage device is requested.

[0096] Upon completion of copying and relabeling of data from recovery volume VolR to target volume VolP (block 752 in FIG. 6B), the recovery manager 123 of the VTS 104 reports to the host 100 that the physical recovery of recovery volume VolR to target volume VolP (S99999 in this example) is complete (block 754 in FIG. 6B), as represented by arrow 756 (FIG. 6B) labeled "REPORT." Completion of the data copying and relabeling is sometimes referred to as "mount complete." In addition, the VTS 104 updates the VTS tape library catalog to indicate an active status for the target private volume VolP, as represented in FIG. 7F.

[0097] In response, in this embodiment, recovery manager 123h of host 100 verifies the data in target volume VolP (block 644 of FIG. 6B) and issues a command to VTS 104 to release the hold state on recovery volume VolR (block 648 of FIG. 6B), as represented by arrow 650 labeled "COMMAND." In response, VTS 104 updates the state of recovery volume VolR in the VTS tape library catalog to release the "hold" state and restore the "held" state, as shown in FIG. 7G.

[0098] In the example embodiment, after the virtual recovery of data from recovery volume VolR (in this example, L00000 V2) to target private volume VolP (in this example, S99999, V1) is complete, the host does not need to record the mapping of private volume VolP to recovery volume VolR. As far as the host knows, the data is fully recovered to S99999. At this point, if the host wants to read the data, it simply performs a standard library mount (referred to as a "LUM" in the example embodiment) of target private volume VolP and reads the recovered data just as it would read any other volume. If physical recovery has not yet occurred, the VTS 104, which maintains the mapping information, begins copying data and modifying headers for physical recovery from recovery volume VolR to target private volume VolP, as described in connection with FIG. 5B.

[0099] In another aspect of data storage recovery management according to the present description, the virtual recovery process of Figures 5A and 6A may be used to quickly and efficiently import volumes from another source that may have different or conflicting volume serial numbering schemes or conventions. In one embodiment, each of the imported volumes, such as volume VolR (Figure 5A), may be mapped or remapped (as represented by arrow 504 in Figure 6A) to a new target private volume VolP, e.g., each such volume VolP having a VOLSER that conforms to the existing volume serial number convention of the host 100 or storage server 104 of the target data storage system. Thus, each of the imported volumes VolR (Figure 5A) may be mapped or remapped to a new VOLSER of the target data storage system that, e.g., does not match or otherwise conflicts with an existing active VOLSER of the host or storage server. In addition, the imported volume VolR may be mapped or remapped to the VOLSER of the target private volume VolP according to the existing volume serial number range rules, thereby preserving the existing volume serial number range rules.

[0100] For example, it is understood that the volumes imported into a target VTS may number in the hundreds, thousands, millions, or more, depending on the particular application. The virtual recovery process of the example embodiment allows a large number of volumes to be quickly imported into a target VTS without mounting or separately accessing any of the volumes being imported using the virtual recovery process. As a result, the imported volumes may be made robust to maintain the validity of their contents, knowing that each imported volume may remain immutable and will only be relabeled on-demand as part of a future recall request for a subsequent physical recovery. For example, legal reasons may require that the state of the data at the time of import remain immutable in order to maintain a consistent position for workload capture. The virtual recovery process of the example embodiment allows for the import of volumes without volume serial number (VOLSER) conflicts, without the need to access each instance, and without the need to change the source instance. If a need arises to access the data of the imported volumes, an on-demand physical recovery of the imported volumes may be performed, as described above in connection with Figures 5B and 6B.

[0101] In yet another aspect, because the recovery volume can remain immutable and therefore unmodified by the recovery process of the example embodiment, storage volume recovery according to the present description may be applied recursively to recover the volume as many times as required. Thus, as described above, if recovery volume VolR is restored to target private volume VolP, and then VolP is deleted, and the host subsequently requests recovery of volume VolP or recovery volume VolR again, the virtual recovery process described above may be repeated, recovering recovery volume VolR to a new target scratch volume, such as target volume VolP1. In this example, because recovery volume VolR is immutable and therefore still contains recovery data during the second virtual recovery, the new target volume VolP1 may be directly mapped to recovery volume VolR in the virtual recovery instead of the deleted volume VolP. If necessary, a physical recovery may then be performed to transfer and relabel data from the recovery volume VolR to the new target volume VolP1, as described above in relation to the first target volume VolP.

[0102] If target volume VolP1 is then deleted and the host subsequently requests recovery of volume VolP1 or recovery volume VolR again, the virtual recovery process described above in relation to target volumes VolP and VolP1 may be repeated again, recovering recovery volume VolR to yet another new target scratch volume, such as target volume VolP2. Thus, in this example, new target volume VolP2 may be directly mapped to recovery volume VolR in place of the deleted volume VolP in the virtual recovery, since recovery volume VolR is immutable and therefore still contains recovery data during the third virtual recovery. A physical recovery may be performed, transferring and relabeling data from recovery volume VolR to the latest target volume VolP2, as required, as described above in relation to previous target volumes VolP and VolP1. Volume recovery management according to the present description thus allows volumes to be recovered indefinitely and to remain immutable indefinitely.

[0103] The present invention may be a system, a method, or a computer program product, or a combination thereof. The computer program product may include a computer readable storage medium including computer readable program instructions for causing a processor to perform aspects of the present invention.

[0104] A computer readable storage medium may be any tangible device capable of holding and storing instructions for use by an instruction execution device. A computer readable storage medium may be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. A non-exhaustive list of more specific examples of computer readable storage media includes portable floppy disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital versatile disk (DVD), memory stick, floppy disk, mechanically encoded devices such as punch cards or ridge structures in a groove on which the instructions are recorded, and any suitable combination thereof. As used herein, a computer-readable storage medium should not itself be construed as a transitory signal, such as an electric wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., a light pulse passing through a fiber optic cable), or an electrical signal transmitted over a wire.

[0105] The computer readable program instructions described herein may be downloaded from a computer readable storage medium to each computing device / processing device or to an external computer or storage device over a network (e.g., the Internet, a local area network, a wide area network, or a wireless network, or a combination thereof) that may include copper transmission cables, optical transmission fiber, wireless transmission, routers, firewalls, switches, gateway computers, or edge servers, or a combination thereof. A network adapter card or network interface within each computing device / processing device receives the computer readable program instructions from the network and transfers the computer readable program instructions for storage on a computer readable storage medium within each computing device / processing device.

[0106] The computer readable program instructions for carrying out the operations of the present invention may be source or object code written in any combination of assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or one or more programming languages, including object-oriented programming languages ​​such as Java, Smalltalk, C++, and traditional procedural programming languages ​​such as the "C" programming language or similar programming languages. The computer readable program instructions may execute entirely on the user's computer, partially on the user's computer as a standalone software package, partially on the user's computer and on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be to an external computer (e.g., via the Internet using an Internet Service Provider). In some embodiments, to carry out aspects of the invention, electronic circuitry including, for example, programmable logic circuitry, field programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), may execute computer readable program instructions to customize the electronic circuitry by utilizing state information of the computer readable program instructions.

[0107] Aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks included in the flowchart illustrations and / or block diagrams, can be implemented by computer readable program instructions.

[0108] These computer readable program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, where the instructions, executed by the processor of the computer or other programmable data processing apparatus, produce means for performing the functions / operations specified in one or more blocks of the flowcharts and / or block diagrams. These computer readable program instructions may be stored on a computer readable storage medium and capable of directing a computer, programmable data processing apparatus, or other device, or combination thereof, to function in a particular manner, such that the computer readable storage medium on which the instructions are stored comprises an article of manufacture containing instructions for performing aspects of the functions / operations specified in one or more blocks of the flowcharts and / or block diagrams.

[0109] The computer readable program instructions may be loaded into a computer, other programmable data processing apparatus, or other device to cause a series of operable steps to be performed on the computer, other programmable apparatus, or other device to generate a computer-implemented process such that the instructions, which execute on the computer, other programmable apparatus, or other device, perform the functions / acts specified in the flowchart and / or block diagram blocks.

[0110] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagram may represent a module, segment, or portion of instructions, comprising one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions shown in the blocks may occur in a different order than that shown in the figures. For example, two blocks shown in succession may in fact be executed substantially simultaneously or in reverse order, depending on the functionality involved. It is also noted that each block of the block diagrams and / or flowchart illustrations, as well as combinations of blocks included in the block diagrams and / or flowchart illustrations, may be implemented by a dedicated hardware-based system that executes the specified functions or operations or executes a combination of dedicated hardware and computer instructions.

[0111] Each of the diagrams may be implemented in one or more computer systems, such as the computer system 1002 shown in FIG. 10. The computer system / server 1002 may be described in the general context of computer system executable instructions, such as program modules being executed by the computer system. Typically, program modules may include routines, programs, objects, components, logic, data structures, etc. that perform particular tasks or implement particular abstract data types. The computer system / server 1002 may be executed in a distributed cloud computing environment, where tasks are performed by remote processing devices linked through a communications network. In a distributed cloud computing environment, program modules may be located in both local and remote computer system storage media, including memory storage devices.

[0112] As shown in FIG. 10, a computer system / server 1002 is shown in the form of a general-purpose computing device. The components of the computer system / server 1002 may include, but are not limited to, one or more processors or processing units 1004, a system memory 1006, and a bus 1008 that couples various system components including the system memory 1006 to the processor 1004. The bus 1008 represents one or more of any of several types of bus structures including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures. Examples of such architectures include, but are not limited to, an Industry Standard Architecture (ISA) bus, a Micro Channel Architecture (MCA) bus, an Enhanced ISA (EISA) bus, a Video Electronics Standards Association (VESA) local bus, and a Peripheral Component Interconnects (PCI) bus.

[0113] The computer system / server 1002 typically includes a variety of computer system readable media. Such media can be any available media that can be accessed by the computer system / server 1002 and includes both volatile and nonvolatile media, removable and non-removable media.

[0114] The system memory 1006 may include computer system readable media in the form of volatile memory, such as random access memory (RAM) 1010 and / or cache memory 1012. The computer system / server 1002 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, a storage system 1013 may be provided for reading from and writing to a non-removable, non-volatile magnetic medium (not shown, and typically referred to as a "hard drive"). Although not shown, a magnetic disk drive may be provided for reading from and writing to a removable, non-volatile magnetic disk (e.g., a "floppy disk"), and an optical disk drive may be provided for reading from and writing to a removable, non-volatile optical disk, such as a CD-ROM, DVD-ROM, or other optical medium. In such an example, each may be connected to the bus 1008 by one or more data media interfaces. As shown and described in detail below, memory 1006 may include at least one program product comprising a series of (e.g., at least one) program modules configured to perform functions of embodiments of the present invention.

[0115] For example, a program / utility 1014 including a set of (at least one) program modules 1016 may be stored in the memory 1006, including, but not limited to, an operating system, one or more application programs, other program modules, and program data. Each of the operating system, one or more application programs, other program modules, and program data, or combinations thereof, may include implementations of a network environment. The components of the computer 1002 may be generally implemented as program modules 1016 that perform the functions and / or methods of embodiments of the invention described herein. The system of FIG. 1A may be implemented in one or more computer systems 1002, and when the system is implemented in multiple computer systems 1002, the computer systems may communicate over a network.

[0116] The computer system / server 1002 may communicate with one or more external devices 1018, such as a keyboard, a pointing device, a display 1020, one or more devices that allow a user to interact with the computer system / server 1002, or any device that allows the computer system / server 1002 to communicate with one or more other computing devices (e.g., a network card, a modem, etc.), or a combination thereof. Such communication may occur through an input / output (I / O) interface 1022. Additionally, the computer system / server 1002 may communicate with one or more networks, such as a local area network (LAN), a general wide area network (WAN), or a public network (e.g., the Internet), or a combination thereof, through a network adapter 1024. As shown, the network adapter 1024 communicates with other components of the computer system / server 1002 through a bus 1008. Although not shown, it should be understood that other hardware and / or software components may be used with computer system / server 1002, including, but not limited to, microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archive storage systems.

[0117] The terms "an embodiment," "embodiment," "embodiments," "the embodiment," "the embodiment," "one or more embodiments," "some embodiments," and "one embodiment" mean "one or more (but not all) embodiments of the present invention," unless expressly specified otherwise.

[0118] The terms "including," "comprising," "having," and variations thereof mean "including but not limited to," unless expressly specified otherwise.

[0119] An enumerated list of items does not imply that any or all of the items are mutually exclusive, unless expressly specified otherwise.

[0120] The terms "a," "an," and "the" mean "one or more," unless expressly specified otherwise.

[0121] Devices that are in communication with each other need not be in continuous communication with each other unless explicitly specified otherwise In addition, devices that are in communication with each other may communicate directly or indirectly through one or more intermediaries.

[0122] A description of an embodiment including multiple components in communication with each other does not imply that all such components are required. On the contrary, a variety of optional components are described to illustrate the wide variety of possible embodiments of the present invention.

[0123] Where a single device or item is described herein, it will be readily apparent that two or more devices / items (whether cooperating or not) may be used in place of the single device / item. Similarly, where two or more devices or items are described herein (whether cooperating or not), it will be readily apparent that a single device / item may be used in place of two or more devices or items, or a different number of devices / items may be used in place of the number of devices or programs shown. The functionality or features or both of a device may alternatively be embodied by one or more other devices not explicitly described as having such functionality / features. Thus, other embodiments of the invention need not include the device itself.

[0124] The foregoing description of various embodiments of the invention has been provided for purposes of illustration and description. It is not intended that these descriptions be exhaustive or to limit the invention to the precise forms disclosed. Many modifications and variations are possible in light of the above. It is intended that the scope of the invention be limited not by this Detailed Description, but by the claims appended hereto. The above specification, examples, and data provide a complete description of the manufacture and use of the composition of the invention. Because many embodiments of the invention can be made without departing from the spirit and scope of the invention, the invention resides in the claims hereinafter appended.

Claims

1. 1. A system for restoring a volume of data stored in a storage device, the system comprising: performing a first virtual restoration of the first volume of data stored on the storage using the second volume, the first virtual restoration including configuring metadata associated with the second volume to map the second volume to the first volume as a virtual restoration of the first volume; and performing a physical restore of the data of the first volume using the second volume, including, in response to a request by a host for data stored on the first volume, transferring data from the first volume to which the second volume is mapped by the virtual restore to the second volume and relabeling the transferred data as second volume data instead of first volume data, such that access to the data of the first volume is deferred until access to the data is requested by the host, and modification of data on the first volume associated with the restore of the first volume is avoided during the virtual and physical restore of the first volume. and execute the system.

2. The transferring of data from the first volume to the second volume is in response to receiving a request by the host to mount the second volume on a storage drive, and in response to the request: mounting the second volume on a storage drive; mounting the first volume on a storage drive; copying data of the first volume that is mapped to the second volume by the metadata of the second volume, such that copying of data from the first volume that is related to a restore of the first volume using the second volume is deferred until the physical restore of the second volume; The system of claim 1 , comprising:

3. 3. The system of claim 2, wherein relabeling the transferred data as second volume data instead of first volume data includes modifying header data read from the first volume when the data is stored to the second volume to identify data copied from the first volume as being data of the second volume instead of the first volume, such that modifying the header data read from the first volume is deferred until access to the data is requested by the host.

4. 4. The system of claim 3, wherein the first volume has a first volume serial number and the second volume has a second serial number different from the first volume serial number, and when user data is read from the first volume and the read data is copied to the second volume, modifying header data for storage in the second volume during the physical restore of the first volume includes replacing the first serial number of the first volume in header data with the second volume serial number of the second volume as header data when user data is read from the first volume and the read data is copied to the second volume.

5. 3. The system of claim 2, wherein the operations further include classifying the first volume as a read-only volume prior to mounting the first volume to prevent modification of the first volume by the restoration of the first volume during both the virtual and physical restoration of the first volume.

6. 6. The system of claim 1, wherein prior to initiation of the virtual restore of the first volume, the first volume is classified into a retention category in which a volume is retained for a period of time after designated deletion, and the virtual restore of the first volume of data stored in storage further comprises reclassifying the first volume into a hold category in which modification of a volume is prevented, and further responsive to completion of the transfer of data from the first volume to the second volume during the physical restore of the first volume, reclassifying the first volume from the hold category to the retention category, wherein modification of the first volume due to the restore of the first volume is avoided during both the virtual restore and the physical restore of the first volume.

7. The system of any preceding claim, wherein the operations further include assigning at least one policy to the second volume, the policy defining parameters regarding at least one of a period for which a volume is to be maintained and an allowed number of versions of the volume.

8. 8. The system of claim 1, wherein the operations further include importing a third volume into the storage, the fourth volume having a volume serial number that conforms to a volume serial numbering convention of the storage, and the virtual restoration of the third volume includes configuring metadata associated with the fourth volume to map the fourth volume to the third volume as a virtual restoration of the third volume.

9. The operation includes: deleting the second volume; and performing a second virtual restoration of the first volume using the third volume, comprising configuring metadata associated with the third volume to map the third volume to the first volume as a second virtual restoration of the first volume, wherein the first volume remains immutable across the first and second virtual restorations of the first volume.

10. The system of any one of claims 1 to 9, wherein the first volume is stored in a secondary storage coupled to a storage server having a primary storage, and the first volume remains unmounted in the secondary storage throughout the virtual restoration of the first volume.

11. A method executed by a computer system, comprising: performing a first virtual restoration of a first volume of data stored in storage using the second volume, the method including configuring metadata associated with the second volume to map the second volume to the first volume as a virtual restoration of the first volume; and performing a physical restore of the data of the first volume using the second volume, including, in response to a request by a host for data stored on the first volume, transferring data from the first volume to which the second volume is mapped by the virtual restore to the second volume and relabeling the transferred data as second volume data instead of first volume data, such that access to the data of the first volume is deferred until access to the data is requested by the host, and modification of data on the first volume associated with the restore of the first volume is avoided during the virtual and physical restore of the first volume. and

12. The transferring of data from the first volume to the second volume is in response to receiving a request by the host to mount the second volume on a storage drive, and in response to the request, mounting the second volume on a storage drive; mounting the first volume on a storage drive; copying data of the first volume mapped to the second volume by the metadata of the second volume, whereby copying of data from the first volume associated with a restore of the first volume using the second volume is deferred until the physical restore of the second volume, the first volume being stored in a secondary storage coupled to a storage server having primary storage, the first volume remaining unmounted in the secondary storage throughout the virtual restore of the first volume, relabeling transferred data as second volume data instead of first volume data includes modifying header data read from the first volume when data is stored to the second volume to identify data copied from the first volume as being data of the second volume instead of the first volume, whereby modifying the header data read from the first volume is deferred until access to the data is requested by the host; 12. The method of claim 11, wherein the first volume has a first volume serial number and the second volume has a second serial number different from the first volume serial number, and when user data is read from the first volume and the read data is copied to the second volume, modifying header data for storage in the second volume during the physical restore of the first volume includes replacing the first serial number of the first volume in header data with the second volume serial number of the second volume as header data.

13. classifying the first volume as a read-only volume prior to mounting the first volume to prevent modification of the first volume by the restoration of the first volume during both the virtual and physical restoration of the first volume; prior to initiation of the virtual restore of the first volume, the first volume is classified into a retention category in which a volume is retained for a period of time after designated deletion, and the virtual restore of the first volume of data stored in storage further includes reclassifying the first volume into a hold category in which modification of a volume is prevented, and further responsive to completion of the transfer of data from the first volume to the second volume during the physical restore of the first volume, reclassifying the first volume from the hold category to the retention category, wherein modification of the first volume due to the restore of the first volume is avoided during both the virtual restore and the physical restore of the first volume; 13. The method of claim 12, further comprising assigning at least one policy to the second volume, the policy defining parameters regarding at least one of a period for which a volume is to be maintained and an allowed number of versions of the volume.

14. 14. The method of claim 11, further comprising: importing a third volume into the storage, the fourth volume having a volume serial number that conforms to a volume serial numbering convention of the storage, and performing a virtual restore of a third volume using the fourth volume, the fourth volume having a volume serial number that conforms to a volume serial numbering convention of the storage, the virtual restore of the third volume comprising configuring metadata associated with the fourth volume to map the fourth volume to the third volume as a virtual restore of the third volume.

15. deleting the second volume; 15. The method of claim 11, further comprising: performing a second virtual restoration of the first volume using the third volume, the second virtual restoration comprising configuring metadata associated with the third volume to map the third volume to the first volume as a second virtual restoration of the first volume, the first volume remaining immutable across the first and second virtual restorations of the first volume.

16. A computer program for causing a computer system to execute the method described in any one of claims 11 to 15.

17. A computer-readable storage medium having recorded thereon the computer program of claim 16.

Images