US20090030954A1 - Management of multiple virtual data copies - Google Patents
Management of multiple virtual data copies Download PDFInfo
- Publication number
- US20090030954A1 US20090030954A1 US12/242,953 US24295308A US2009030954A1 US 20090030954 A1 US20090030954 A1 US 20090030954A1 US 24295308 A US24295308 A US 24295308A US 2009030954 A1 US2009030954 A1 US 2009030954A1
- Authority
- US
- United States
- Prior art keywords
- data
- volume
- storage media
- management system
- mvc
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1446—Point-in-time backing up or restoration of persistent data
- G06F11/1448—Management of the data involved in backup or backup restore
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1446—Point-in-time backing up or restoration of persistent data
- G06F11/1458—Management of the backup or restore process
- G06F11/1464—Management of the backup or restore process for networked environments
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1446—Point-in-time backing up or restoration of persistent data
- G06F11/1458—Management of the backup or restore process
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99931—Database or file accessing
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99951—File or database maintenance
- Y10S707/99952—Coherency, e.g. same view to multiple users
- Y10S707/99955—Archiving or backup
Definitions
- the present invention relates to maintaining copies of data in a storage management system.
- Removable storage media such as tape cartridges
- tape cartridges are often used for long-term data storage. Often, these tape cartridges are held in locations remote from where they are written and read. Remote locations for storing data provide several benefits. First, remote locations tend to be less expensive per square foot than on-site locations. Second, remote locations better ensure that data can be recovered in the event of a catastrophic, on-site disaster. Third, copies of the data may be required for access at off-site locations.
- One method for dealing with this increase is to use data cartridges that hold a greater amount of data in a given volume.
- Such data cartridges typically hold multiple data volumes or data sets.
- One example is multi-volume tape cartridges, each of which can hold one or more virtual tape volumes.
- Storage management systems track multi-volume tape cartridges and map the assignment of virtual tape volumes to multi-volume cartridges.
- two copies of data are written to removable storage media. This results in a given virtual tape volume being recorded on two separate multi-volume cartridges.
- One multi-volume cartridge is stored locally for archival and/or back-up purposes.
- the other multi-volume cartridge is sent to an off-site location.
- the storage management system is configured to record information pertaining to both multi-volume cartridges.
- a major problem with such storage management systems is the inability to rapidly retrieve data if the virtual tape volume containing the data cannot be read from the locally-maintained multi-volume cartridge upon which the virtual tape volume has been written. This can occur if the local multi-volume cartridge has been lost, damaged, accidentally overwritten, misplaced, or the like. Even if the physical multi-volume cartridge is found and is in good condition, the data may still not be readable due to difficulties with the storage media including defects, localized damage, wear, aging, and the like. Thus, the only way to obtain the desired data is to recall the off-site multi-volume cartridge, a process which can result in considerable delay and may violate disaster recovery policies.
- the present invention provides for managing more than two copies of data in a storage management system.
- a method of managing more than two multi-volume copies in a storage management system recognizing only a first multi-volume copy and a second multi-volume copy is provided.
- Each multi-volume copy holds at least one virtual volume.
- At least one virtual volume is directed from the first multi-volume copy to a receiving management class within the storage management system.
- Each virtual volume is exported to a third multi-volume copy based on the receiving management class. This third multi-volume copy is unknown to the storage management system.
- a manifest file is created listing each exported virtual volume.
- a second management class is defined.
- Each of the exported virtual volumes is assigned to the second management class. This permits additional virtual volumes to be directed to the receiving management class and subsequently exported to the third multi-volume copy without reexporting any virtual volume.
- the second multi-volume copy is removed to a location remote from the storage management system.
- Each determined erroneous virtual volume is unlinked from the storage management system.
- Each of the determined erroneous virtual volumes is imported into the storage management system from the third multi-volume copy.
- This usage threshold may be based on an amount of valid data remaining on the third multi-volume copy.
- Virtual volumes held on the third multi-volume copy are identified.
- At least one virtual volume, including at least one virtual volume identified from the third multi-volume copy, is exported from the storage management system to a fourth multi-volume copy.
- a new manifest file is produced listing the virtual volumes exported to the fourth multi-volume copy.
- a system is also provided.
- the system includes multi-volume storage devices, each capable of holding multiple data sets.
- a storage management system writes at least one data set onto each multi-volume storage device.
- the storage management system writes at least one data set onto both a first multi-volume storage device and a second multi-volume storage device.
- Each written data set is directed to a receiving management class.
- Data sets are exported to a third multi-volume storage device based on the receiving management class.
- a manifest file is created associating the third multi-volume storage device with the exported data sets.
- a disaster recovery method supporting local back-up is also provided.
- Data is written to a first storage media and a second storage media.
- the second storage media is sent off-site.
- the data is directed to a receiving management class.
- the data is written to a third storage media based on the receiving management class.
- a manifest file is created listing the data written to the third storage media.
- FIG. 1 is a block diagram illustrating a data storage system according to an embodiment of the present invention
- FIG. 2 a is a schematic diagram illustrating operation of a storage management system according to an embodiment of the present invention
- FIG. 2 b is a schematic diagram illustrating creation of a third multi-volume copy according to an embodiment of the present invention
- FIG. 2 c is a schematic diagram illustrating operation of a holding class according to an embodiment of the present invention.
- FIG. 2 d is a schematic diagram illustrating a local data recovery according to an embodiment of the present invention.
- FIG. 2 e is a schematic diagram illustrating an update of a third data copy according to an embodiment of the present invention.
- a data storage system shown generally by 20 , includes on-site location 22 and off-site location 24 .
- Location 24 is “off-site” relative to on-site location 22 in that storage devices held within off-site location 24 cannot be readily accessed by equipment at on-site location 22 .
- On-site location 22 includes tape library 26 capable of writing to and reading from multi-volume tape cartridges 28 .
- Tape library 26 typically includes a plurality of tape access devices for simultaneously accessing multiple multi-volume cartridges (MVCs) 28 .
- Tape library 26 may be automated, such as through the use of robotics, may allow for manual loading of cartridges 28 , or some combination of manual and automatic operation.
- Multi-volume tape cartridges 28 typically hold a plurality of virtual tape volumes (VTVs) 30 . Each virtual tape volume 30 may appear to a data access device as a physical tape.
- Multi-volume cartridge 28 may hold information subdivided in a number of ways such as, for example, as separate files, data sets, databases, and the like.
- Multi-volume cartridges 28 are moved to off-site location 24 for one or more of a variety of purposes, including to support disaster recovery, to reduce the cost of data storage, to provide data accessibility at off-site location 24 , or the like.
- On-site location 22 includes tape library controller 32 in communication with tape library 26 .
- Tape library controller 32 may be a part of tape library 26 or may be a separate device.
- Tape library controller 32 may be implemented in a host computer, may be distributed across a plurality of computers, may be a dedicated control device, or the like.
- Tape library controller 32 , tape library 26 , and associated support devices together comprise a storage management system, shown generally by 34 .
- Tape library controller 32 determines virtual tape volume 30 for archiving. Each virtual tape volume 30 so determined is written to two multi-volume cartridges 28 known to control logic within storage management system 34 . One multi-volume cartridge 28 is maintained at on-site location 22 and one multi-volume cartridge 28 is sent to off-site location 24 . If on-site multi-volume cartridge 28 is lost or damaged, or data held in virtual tape volumes 30 on local multi-volume cartridge 28 cannot be accessed, multi-volume cartridge 28 must be returned from off-site location 24 . Returning off-site multi-volume cartridge 28 may create significant delays in data access and may violate data recovery policies that require one copy to be maintained off-site at all times.
- Storage management system 34 includes buffer 40 holding data to be written to multi-volume cartridges 28 .
- Buffer 40 may reside in tape library 26 , tape library controller 32 , or a support device associated with storage management system 34 .
- Buffer 40 may include one or more of solid state memory, magnetic memory, optical memory, and the like.
- Storage management system 34 also includes an information set, referred to as a control data set (CDS) and referenced by 42 , which includes a listing of multi-volume cartridges, indicated by 44 , a listing of virtual tape volumes held within each multiple volume cartridge, indicated by 46 , and a listing of the validity of each virtual tape volume held by multi-volume cartridge, indicated by 48 , as is known by storage management system 34 .
- control data set 42 is implemented as two separate collections. The first set of control information is managed by tape library controller 32 . The second set of control information is managed by a third party tape management system.
- Virtual tape volumes 30 to be archived for disaster recovery or other purposes are held in buffer 40 .
- These virtual tape volumes 30 illustratively indicated as VTV 1 , VTV 2 , VTV 3 and VTV 4 , are written onto a first multi-volume cartridge (MV), indicated by 28 a .
- This same set of virtual tape volumes 30 is written onto a second multi-volume cartridge (MVC 2 ), indicated by 28 b .
- Control data set 42 is updated to indicate that both cartridges MVC 1 and MVC 2 contain valid virtual tape volumes VTV 1 - 4 .
- Second multi-volume cartridge 28 b is then sent to off-site location 24 .
- each virtual tape volume stored on second multi-volume cartridge 28 b was also written onto first multi-volume cartridge 28 a .
- multi-volume cartridge 28 a may actually be more than one cartridge 28 .
- data indicated as held by first multi-volume cartridge 28 a may also be maintained in any of a variety of storage media such as magnetic tape, optical tape, magnetic disk, optical disk, solid state memory, and the like.
- multi-volume cartridge is used for convenience of expression.
- Storage management system 34 defines receiving management class 60 capable of referencing virtual tape volumes 30 to be written onto a third multi-volume cartridge (MVC 3 ), indicated by 28 c .
- Receiving class 60 may be temporary or persistent within storage management system 34 and may be implemented as an object, file, or the like.
- Virtual tape volumes 30 to be copied are directed to receiving class 60 . This may occur automatically as part of the process of writing multi-volume cartridges 28 a and 28 b or may be triggered as a separate operation. Virtual tape volumes 30 to be listed in receiving class 60 may be expressly stated or may be determined by a masking operation on the name of each virtual tape volume 30 . In this latter case, a naming convention is chosen for automatically triplicating certain virtual tape volumes 30 .
- Virtual tape volumes 30 are then exported from storage management system 34 onto MVC 3 .
- virtual tape volumes 30 are read from MVC 1 into buffer 40 and then written from buffer 40 into MVC 3 .
- MVC 1 and MVC 3 are both written contemporaneously from buffer 40 .
- manifest file 62 indicating which virtual tape volumes 30 are held on multi-volume cartridge 28 c .
- Manifest 62 is preferably a metadata file accessible by storage management system 34 .
- manifest file 62 may be implemented in a variety of ways including hard copy, database, linked list, object instantiation, and the like.
- Storage management system 34 includes holding management class 64 .
- receiving class 60 and holding class 64 are of the same or related class type.
- holding class 64 may be implemented in a variety of ways.
- holding class 64 may be temporary or persistent within storage management system 34 .
- references to these virtual tape volumes 30 are moved into holding class 64 from receiving class 60 . This may be accomplished by, for example, renaming receiving class 60 . Alternatively, virtual tape volume references may be sent from receiving class 60 to holding class 64 , copied to holding class 64 then deleted from receiving class 60 , or the like.
- the present invention has been implemented in storage management system 34 including a Virtual Tape Control System from Storage Technology Corporation.
- the copy process begins by running an export command that exports by virtual storage manager management class as follows:
- Moving virtual tape volume references from receiving class 60 to holding class 64 permits writing a new virtual tape volume 30 onto MVC 3 without having to rewrite virtual tape volumes 30 (VTV 1 - 4 ) which have already been written. This facilitates automatic and distributed implementation of writing MVC 3 .
- FIG. 2 d a schematic diagram illustrating a local data recovery according to an embodiment of the present invention is shown.
- a determination is made that at least one virtual tape volume 30 on MVC 1 is erroneous. This typically occurs when storage management system 34 attempts to read data from MVC 1 .
- a request for data may be generated within storage management system 34 or by a computing device in communication with storage management system 34 .
- Storage management system 34 consults control data set 42 to determine which local multi-volume cartridge 28 a contains virtual volume 30 with the requested data. If the desired multi-volume cartridge 28 a cannot be located, is damaged, erased, or contains media from which some or all of the requested virtual tape volume 30 cannot be read, then multi-volume cartridge 28 a is considered to be an erroneous copy. In FIG. 2 d , VTV 1 and VTV 3 have been found to be erroneous on multi-volume cartridge 28 a.
- a copy of the requested data resides on MVC 3 .
- storage management system 34 is not inherently aware of the existence of a local copy of the desired data.
- Storage management system 34 acquires knowledge that VTV 1 and VTV 3 exist on MVC 3 by reading manifest 62 .
- References to erroneous virtual tape volumes 30 are unlinked from storage management system 34 by disassociating VTV 1 and VTV 3 from MVC 1 in control data set 42 .
- VTV 1 and VTV 3 are then imported from MVC 3 into buffer 40 . If possible, VTV 1 and VTV 3 are then written onto MVC 1 . If not, a new multi-volume cartridge 28 may be used to implement MVC 1 . In either case, this operation relinks VTV 1 and VTV 3 with MVC 1 in control data set 42 .
- Storage management system 34 including a Virtual Tape Control System may execute a sequence of commands for retrieving data found to be erroneous on MVC 1 .
- a drain command is run against the copy MVC 3 within control data set 42 as follows:
- FIG. 2 e a schematic diagram illustrating an update of a third data copy according to an embodiment of the present invention is shown.
- One or more virtual tape volumes 30 on multi-volume cartridge 28 a - c may become invalid.
- Virtual tape volumes 30 may become invalid due to the passage of time such as, for example, due to an expiration date set for virtual tape volume 30 .
- Virtual tape volume 30 may also become invalid because data contained in virtual tape volume 30 has been rendered obsolete by more recently generated data.
- Storage management system 34 tracks the validity of data on multi-volume cartridge 28 a and 28 b using control data set 42 .
- Storage management system 34 may replace invalid virtual tape volumes 30 with valid tape volumes 30 to efficiently utilize storage space on multi-volume cartridge 28 a . As illustrated in FIG.
- VTV 3 and VTV 4 have been replaced by VTV 5 and VTV 6 .
- virtual tape volumes 30 held on multi-volume cartridge 28 c are not inherently known to storage management system 34 . Therefore, MVC 3 cannot be updated through control data set 42 .
- multi-volume cartridge 28 c The contents of multi-volume cartridge 28 c are occasionally considered to determine if multi-volume cartridge 28 c is efficiently storing data.
- Manifest 62 indicating the contents of multi-volume cartridge 28 c is read by storage management system 34 to obtain a list of virtual tape volumes 30 held by multi-volume cartridge 28 c .
- Storage management system 34 determines if multi-volume cartridge 28 c falls beneath a usage threshold. This usage threshold may be based, for example, on an amount of valid data remaining on multi-volume cartridge 28 c . If multi-volume cartridge 28 c falls beneath the usage threshold, storage management system 34 writes data corresponding to valid virtual tape volumes 30 still held by multi-volume cartridge 28 c onto a new multi-volume cartridge (MVC 4 ), indicated by 28 d .
- MVC 4 new multi-volume cartridge
- MVC 4 may also be written with additional virtual tape volumes 30 .
- virtual tape volumes 30 from MVC 1 are read into buffer 40 and then written into MVC 4 .
- Storage management system 34 produces manifest file 70 indicating which virtual tape volumes 30 were written onto MVC 4 .
- Storage management system 34 including a Virtual Tape Control System may execute a sequence of commands to produce updated multi-volume copy 28 d .
- a report command is run against manifest file 62 as follows:
- Revised cumulative manifest file 70 is produced showing newly exported MVC 4 and eliminating low threshold MVC 3 .
Abstract
More than two copies of data in a storage management system may be managed by directing at least one virtual volume to a receiving management class within the storage management system. Each virtual volume is exported to a third multi-volume copy, unknown to the storage management system, based on the receiving management class. A manifest file is created listing each exported virtual volume.
Description
- This application is a divisional of U.S. application Ser. No. 10/374,024, filed Feb. 25, 2003.
- 1. Field of the Invention
- The present invention relates to maintaining copies of data in a storage management system.
- 2. Background Art
- Removable storage media, such as tape cartridges, are often used for long-term data storage. Often, these tape cartridges are held in locations remote from where they are written and read. Remote locations for storing data provide several benefits. First, remote locations tend to be less expensive per square foot than on-site locations. Second, remote locations better ensure that data can be recovered in the event of a catastrophic, on-site disaster. Third, copies of the data may be required for access at off-site locations.
- The amount of data that must be stored, both on-site and off-site, continues to increase. One method for dealing with this increase is to use data cartridges that hold a greater amount of data in a given volume. Such data cartridges typically hold multiple data volumes or data sets. One example is multi-volume tape cartridges, each of which can hold one or more virtual tape volumes.
- Storage management systems track multi-volume tape cartridges and map the assignment of virtual tape volumes to multi-volume cartridges. In a typical storage management system, two copies of data are written to removable storage media. This results in a given virtual tape volume being recorded on two separate multi-volume cartridges. One multi-volume cartridge is stored locally for archival and/or back-up purposes. The other multi-volume cartridge is sent to an off-site location. The storage management system is configured to record information pertaining to both multi-volume cartridges.
- A major problem with such storage management systems is the inability to rapidly retrieve data if the virtual tape volume containing the data cannot be read from the locally-maintained multi-volume cartridge upon which the virtual tape volume has been written. This can occur if the local multi-volume cartridge has been lost, damaged, accidentally overwritten, misplaced, or the like. Even if the physical multi-volume cartridge is found and is in good condition, the data may still not be readable due to difficulties with the storage media including defects, localized damage, wear, aging, and the like. Thus, the only way to obtain the desired data is to recall the off-site multi-volume cartridge, a process which can result in considerable delay and may violate disaster recovery policies.
- What is needed is management of data copies which permit a second local removable copy to be maintained by storage systems not inherently designed to handle more than two copies. This management should produce and maintain data copies in a reliable manner without requiring extensive modification of an existing storage management system.
- The present invention provides for managing more than two copies of data in a storage management system.
- To this purpose, a method of managing more than two multi-volume copies in a storage management system recognizing only a first multi-volume copy and a second multi-volume copy is provided. Each multi-volume copy holds at least one virtual volume. At least one virtual volume is directed from the first multi-volume copy to a receiving management class within the storage management system. Each virtual volume is exported to a third multi-volume copy based on the receiving management class. This third multi-volume copy is unknown to the storage management system. A manifest file is created listing each exported virtual volume.
- In an embodiment of the present invention, a second management class is defined. Each of the exported virtual volumes is assigned to the second management class. This permits additional virtual volumes to be directed to the receiving management class and subsequently exported to the third multi-volume copy without reexporting any virtual volume.
- In another embodiment of the present invention, the second multi-volume copy is removed to a location remote from the storage management system.
- In still another embodiment of the present invention, a determination is made that at least one exported virtual volume held on the first multi-volume copy is erroneous. Each determined erroneous virtual volume is unlinked from the storage management system. Each of the determined erroneous virtual volumes is imported into the storage management system from the third multi-volume copy.
- In yet another embodiment of the present invention, a determination is made that the third multi-volume copy falls beneath a usage threshold. This usage threshold may be based on an amount of valid data remaining on the third multi-volume copy. Virtual volumes held on the third multi-volume copy are identified. At least one virtual volume, including at least one virtual volume identified from the third multi-volume copy, is exported from the storage management system to a fourth multi-volume copy. A new manifest file is produced listing the virtual volumes exported to the fourth multi-volume copy.
- A system is also provided. The system includes multi-volume storage devices, each capable of holding multiple data sets. A storage management system writes at least one data set onto each multi-volume storage device. The storage management system writes at least one data set onto both a first multi-volume storage device and a second multi-volume storage device. Each written data set is directed to a receiving management class. Data sets are exported to a third multi-volume storage device based on the receiving management class. A manifest file is created associating the third multi-volume storage device with the exported data sets.
- A disaster recovery method supporting local back-up is also provided. Data is written to a first storage media and a second storage media. The second storage media is sent off-site. The data is directed to a receiving management class. The data is written to a third storage media based on the receiving management class. A manifest file is created listing the data written to the third storage media.
- The above features, and other features and advantages of the present invention are readily apparent from the following detailed descriptions thereof when taken in connection with the accompanying drawings.
-
FIG. 1 is a block diagram illustrating a data storage system according to an embodiment of the present invention; -
FIG. 2 a is a schematic diagram illustrating operation of a storage management system according to an embodiment of the present invention; -
FIG. 2 b is a schematic diagram illustrating creation of a third multi-volume copy according to an embodiment of the present invention; -
FIG. 2 c is a schematic diagram illustrating operation of a holding class according to an embodiment of the present invention; -
FIG. 2 d is a schematic diagram illustrating a local data recovery according to an embodiment of the present invention; and -
FIG. 2 e is a schematic diagram illustrating an update of a third data copy according to an embodiment of the present invention. - Referring to
FIG. 1 , a block diagram illustrating a data storage system according to an embodiment of the present invention is shown. A data storage system, shown generally by 20, includes on-site location 22 and off-site location 24.Location 24 is “off-site” relative to on-site location 22 in that storage devices held within off-site location 24 cannot be readily accessed by equipment at on-site location 22. - On-
site location 22 includestape library 26 capable of writing to and reading frommulti-volume tape cartridges 28.Tape library 26 typically includes a plurality of tape access devices for simultaneously accessing multiple multi-volume cartridges (MVCs) 28.Tape library 26 may be automated, such as through the use of robotics, may allow for manual loading ofcartridges 28, or some combination of manual and automatic operation.Multi-volume tape cartridges 28 typically hold a plurality of virtual tape volumes (VTVs) 30. Eachvirtual tape volume 30 may appear to a data access device as a physical tape.Multi-volume cartridge 28 may hold information subdivided in a number of ways such as, for example, as separate files, data sets, databases, and the like.Multi-volume cartridges 28 are moved to off-site location 24 for one or more of a variety of purposes, including to support disaster recovery, to reduce the cost of data storage, to provide data accessibility at off-site location 24, or the like. - On-
site location 22 includestape library controller 32 in communication withtape library 26.Tape library controller 32 may be a part oftape library 26 or may be a separate device.Tape library controller 32 may be implemented in a host computer, may be distributed across a plurality of computers, may be a dedicated control device, or the like.Tape library controller 32,tape library 26, and associated support devices together comprise a storage management system, shown generally by 34. -
Tape library controller 32 determinesvirtual tape volume 30 for archiving. Eachvirtual tape volume 30 so determined is written to twomulti-volume cartridges 28 known to control logic withinstorage management system 34. Onemulti-volume cartridge 28 is maintained at on-site location 22 and onemulti-volume cartridge 28 is sent to off-site location 24. If on-site multi-volume cartridge 28 is lost or damaged, or data held invirtual tape volumes 30 on localmulti-volume cartridge 28 cannot be accessed,multi-volume cartridge 28 must be returned from off-site location 24. Returning off-site multi-volume cartridge 28 may create significant delays in data access and may violate data recovery policies that require one copy to be maintained off-site at all times. - Referring now to
FIG. 2 a, a schematic diagram illustrating operation of a storage management system according to an embodiment of the present invention is shown.Storage management system 34 includesbuffer 40 holding data to be written tomulti-volume cartridges 28.Buffer 40 may reside intape library 26,tape library controller 32, or a support device associated withstorage management system 34.Buffer 40 may include one or more of solid state memory, magnetic memory, optical memory, and the like.Storage management system 34 also includes an information set, referred to as a control data set (CDS) and referenced by 42, which includes a listing of multi-volume cartridges, indicated by 44, a listing of virtual tape volumes held within each multiple volume cartridge, indicated by 46, and a listing of the validity of each virtual tape volume held by multi-volume cartridge, indicated by 48, as is known bystorage management system 34. In an embodiment of the present invention, control data set 42 is implemented as two separate collections. The first set of control information is managed bytape library controller 32. The second set of control information is managed by a third party tape management system. -
Virtual tape volumes 30 to be archived for disaster recovery or other purposes are held inbuffer 40. Thesevirtual tape volumes 30, illustratively indicated as VTV1, VTV2, VTV3 and VTV4, are written onto a first multi-volume cartridge (MV), indicated by 28 a. This same set ofvirtual tape volumes 30 is written onto a second multi-volume cartridge (MVC2), indicated by 28 b. Control data set 42 is updated to indicate that both cartridges MVC1 and MVC2 contain valid virtual tape volumes VTV1-4. Secondmulti-volume cartridge 28 b is then sent to off-site location 24. - In the example illustration, each virtual tape volume stored on second
multi-volume cartridge 28 b was also written onto firstmulti-volume cartridge 28 a. As will be recognized by one of ordinary skill in the art,multi-volume cartridge 28 a may actually be more than onecartridge 28. Additionally, data indicated as held by firstmulti-volume cartridge 28 a may also be maintained in any of a variety of storage media such as magnetic tape, optical tape, magnetic disk, optical disk, solid state memory, and the like. The use of the term “multi-volume cartridge” is used for convenience of expression. - Referring now to
FIG. 2 b, a schematic diagram illustrating creation of a third multi-volume copy according to an embodiment of the present invention is shown.Storage management system 34 defines receivingmanagement class 60 capable of referencingvirtual tape volumes 30 to be written onto a third multi-volume cartridge (MVC3), indicated by 28 c. Receivingclass 60 may be temporary or persistent withinstorage management system 34 and may be implemented as an object, file, or the like. -
Virtual tape volumes 30 to be copied are directed to receivingclass 60. This may occur automatically as part of the process of writingmulti-volume cartridges Virtual tape volumes 30 to be listed in receivingclass 60 may be expressly stated or may be determined by a masking operation on the name of eachvirtual tape volume 30. In this latter case, a naming convention is chosen for automatically triplicating certainvirtual tape volumes 30. -
Virtual tape volumes 30 are then exported fromstorage management system 34 onto MVC3. In one embodiment,virtual tape volumes 30 are read from MVC1 intobuffer 40 and then written frombuffer 40 into MVC3. In another embodiment, MVC1 and MVC3 are both written contemporaneously frombuffer 40. - Exporting
virtual tape volumes 30 onto MVC3 createsmanifest file 62 indicating whichvirtual tape volumes 30 are held onmulti-volume cartridge 28 c.Manifest 62 is preferably a metadata file accessible bystorage management system 34. However,manifest file 62 may be implemented in a variety of ways including hard copy, database, linked list, object instantiation, and the like. - Referring now to
FIG. 2 c, a schematic diagram illustrating operation of a holding class according to an embodiment of the present invention is shown.Storage management system 34 includes holdingmanagement class 64. Preferably, receivingclass 60 and holdingclass 64 are of the same or related class type. As with receivingclass 60, holdingclass 64 may be implemented in a variety of ways. In addition, holdingclass 64 may be temporary or persistent withinstorage management system 34. - Once
virtual tape volumes 30 have been written to MVC3, references to thesevirtual tape volumes 30 are moved into holdingclass 64 from receivingclass 60. This may be accomplished by, for example, renaming receivingclass 60. Alternatively, virtual tape volume references may be sent from receivingclass 60 to holdingclass 64, copied to holdingclass 64 then deleted from receivingclass 60, or the like. - The present invention has been implemented in
storage management system 34 including a Virtual Tape Control System from Storage Technology Corporation. The copy process begins by running an export command that exports by virtual storage manager management class as follows: -
- Export MGMT (mgmtclas-list) MANIFEST (manifest dd).
Manifest file 62 is produced by running the Export command together with the additional copies ofvirtual tape volumes 30 on MVC3. A virtual tape volume report is run against the manifest file produced by the export command as follows: - VTVRPT MANIFEST (ddname) FLAT (flat-file-dd-name).
The output of this report command is a flat file used by the following maintenance utility: - VTVMAINT VTVid (vol-list) MGMTclas (new-mgmt-clas-name).
The VTVMAINT utility changes the virtual storage manager management class ofvirtual tape volumes 30 just processed from receivingclass 60 to holdingclass 64 designated new-mgmt-clas-name.
- Export MGMT (mgmtclas-list) MANIFEST (manifest dd).
- Moving virtual tape volume references from receiving
class 60 to holdingclass 64 permits writing a newvirtual tape volume 30 onto MVC3 without having to rewrite virtual tape volumes 30 (VTV1-4) which have already been written. This facilitates automatic and distributed implementation of writing MVC3. - Referring now to
FIG. 2 d, a schematic diagram illustrating a local data recovery according to an embodiment of the present invention is shown. A determination is made that at least onevirtual tape volume 30 on MVC1 is erroneous. This typically occurs whenstorage management system 34 attempts to read data from MVC1. A request for data may be generated withinstorage management system 34 or by a computing device in communication withstorage management system 34.Storage management system 34 consults control data set 42 to determine which localmulti-volume cartridge 28 a containsvirtual volume 30 with the requested data. If the desiredmulti-volume cartridge 28 a cannot be located, is damaged, erased, or contains media from which some or all of the requestedvirtual tape volume 30 cannot be read, thenmulti-volume cartridge 28 a is considered to be an erroneous copy. InFIG. 2 d, VTV1 and VTV3 have been found to be erroneous onmulti-volume cartridge 28 a. - A copy of the requested data resides on MVC3. However, since MVC3 is not listed in control data set 42,
storage management system 34 is not inherently aware of the existence of a local copy of the desired data.Storage management system 34 acquires knowledge that VTV1 and VTV3 exist on MVC3 by readingmanifest 62. References to erroneousvirtual tape volumes 30 are unlinked fromstorage management system 34 by disassociating VTV1 and VTV3 from MVC1 in control data set 42. VTV1 and VTV3 are then imported from MVC3 intobuffer 40. If possible, VTV1 and VTV3 are then written onto MVC1. If not, a newmulti-volume cartridge 28 may be used to implement MVC1. In either case, this operation relinks VTV1 and VTV3 with MVC1 in control data set 42. -
Storage management system 34 including a Virtual Tape Control System may execute a sequence of commands for retrieving data found to be erroneous on MVC1. First, a drain command is run against the copy MVC3 within control data set 42 as follows: -
- MVCDRain MVC (
Copy 3 MVC).
The drain command allows subsequent manipulation of data within control data set 42. A maintenance utility unlinks the faulty virtualtape volume copy 30 in MVC1 and prepares MVC1 for replacement with corresponding data from MVC3 as follows: - VTVMAINT VTV (error-VTV) ULINKMVC (
Copy 1 MVC).
An import command then copies desiredvirtual tape volumes 30 intobuffer 40 as follows: - IMPORT VTV (error-VTV) REPLACE (ALL) IMMDRAIN(YES) MANIFEST (manifest).
Desiredvirtual tape volume 30 is then migrated into receivingclass 60 for processing into MVC1 or another suitablemulti-volume cartridge 28 a. At this point, data in migratedvirtual tape volume 30 is available for normal recall processing.
- MVCDRain MVC (
- Referring now to
FIG. 2 e, a schematic diagram illustrating an update of a third data copy according to an embodiment of the present invention is shown. One or morevirtual tape volumes 30 onmulti-volume cartridge 28 a-c may become invalid.Virtual tape volumes 30 may become invalid due to the passage of time such as, for example, due to an expiration date set forvirtual tape volume 30.Virtual tape volume 30 may also become invalid because data contained invirtual tape volume 30 has been rendered obsolete by more recently generated data.Storage management system 34 tracks the validity of data onmulti-volume cartridge Storage management system 34 may replace invalidvirtual tape volumes 30 withvalid tape volumes 30 to efficiently utilize storage space onmulti-volume cartridge 28 a. As illustrated inFIG. 2 e, virtual tape volumes VTV3 and VTV4 have been replaced by VTV5 and VTV6. However,virtual tape volumes 30 held onmulti-volume cartridge 28 c are not inherently known tostorage management system 34. Therefore, MVC3 cannot be updated through control data set 42. - The contents of
multi-volume cartridge 28 c are occasionally considered to determine ifmulti-volume cartridge 28 c is efficiently storing data.Manifest 62 indicating the contents ofmulti-volume cartridge 28 c is read bystorage management system 34 to obtain a list ofvirtual tape volumes 30 held bymulti-volume cartridge 28 c.Storage management system 34 determines ifmulti-volume cartridge 28 c falls beneath a usage threshold. This usage threshold may be based, for example, on an amount of valid data remaining onmulti-volume cartridge 28 c. Ifmulti-volume cartridge 28 c falls beneath the usage threshold,storage management system 34 writes data corresponding to validvirtual tape volumes 30 still held bymulti-volume cartridge 28 c onto a new multi-volume cartridge (MVC4), indicated by 28 d. MVC4 may also be written with additionalvirtual tape volumes 30. In the example illustrated inFIG. 2 e,virtual tape volumes 30 from MVC1 are read intobuffer 40 and then written into MVC4.Storage management system 34 producesmanifest file 70 indicating whichvirtual tape volumes 30 were written onto MVC4. -
Storage management system 34 including a Virtual Tape Control System may execute a sequence of commands to produce updatedmulti-volume copy 28 d. A report command is run againstmanifest file 62 as follows: -
- MVCRPT MANIFEST (ddname) FLATdd (ddname).
Storage management system 34 identifies anymulti-volume cartridge 28 c listed onmanifest 62 which falls below a predetermined usage threshold such as, for example, 25% or less of valid data remaining.Storage management system 34 identifies validvirtual tape volumes 30 on any low thresholdmulti-volume cartridge 28 c.
- MVCRPT MANIFEST (ddname) FLATdd (ddname).
- An export command is run on these
virtual tape volumes 30 to create an additional copy MVC4 unknown to control data set 42 as follows: -
- EXPORT VTV (VTV-list) MANIFEST (ddname).
A drain command is run against low thresholdmulti-volume cartridge 28 c as follows: - MVCDRain MVCid (vol-list).
The read-only bit is turned off on low thresholdmulti-volume cartridge 28 c as follows: - MVCMAINT MVCid (vol-list) READONLY (OFF).
- EXPORT VTV (VTV-list) MANIFEST (ddname).
- This allows MVC3 to be reused. Revised
cumulative manifest file 70 is produced showing newly exported MVC4 and eliminating low threshold MVC3. - While embodiments of the invention have been illustrated and described, it is not intended that these embodiments illustrate and describe all possible forms of the invention. Rather, the words used in the specification are words of description rather than limitation, and various changes may be made without departing from the spirit and scope of the invention. For example, the terms “first,” “second,” “third,” and “fourth” with regard to data cartridges have been used for ease of illustration and are not meant to restrict the number or type of data cartridges or to imply any order. Also, a tape system has been used in the example embodiment. However, any removable storage devices and their associated equipment may be used to implement the present invention. In addition, the example embodiments have used virtual tape volumes to refer to any kind of information sets held on removable storage devices. These information sets may include files, data sets, databases, and the like.
Claims (6)
1. A disaster recovery method supporting local backup comprising:
writing data to a first storage media;
writing the data to a second storage media;
sending the second storage media off-site;
directing the data to a receiving management class;
writing the data to a third storage media based on the receiving management class; and
creating a manifest file listing the data written to the third storage media.
2. A disaster recovery method supporting local backup as in claim 1 further comprising directing the data to a second management class after the data has been written to the third storage media.
3. A disaster recovery method supporting local backup as in claim 2 further comprising repeating directing, writing to the third storage media and creating the manifest for new data.
4. A disaster recovery method supporting local backup as in claim 1 further comprising:
determining that the data held on the first storage media is defective; and
reading data from the third storage media corresponding to the data determined defective on the first storage media.
5. A disaster recovery method supporting local backup as in claim 1 further comprising:
determining that usage of the third storage media falls beneath a threshold;
identifying any valid data held on the third storage media;
writing the identified valid data onto a fourth storage media; and
producing a new manifest file listing the data written to the fourth storage media.
6. A disaster recovery method supporting local backup as in claim 5 wherein the threshold is based on an amount of valid data remaining on the third storage media.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US12/242,953 US20090030954A1 (en) | 2003-02-25 | 2008-10-01 | Management of multiple virtual data copies |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US10/374,024 US7447714B1 (en) | 2003-02-25 | 2003-02-25 | Management of multiple virtual data copies |
US12/242,953 US20090030954A1 (en) | 2003-02-25 | 2008-10-01 | Management of multiple virtual data copies |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/374,024 Division US7447714B1 (en) | 2003-02-25 | 2003-02-25 | Management of multiple virtual data copies |
Publications (1)
Publication Number | Publication Date |
---|---|
US20090030954A1 true US20090030954A1 (en) | 2009-01-29 |
Family
ID=39916571
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/374,024 Active 2026-01-04 US7447714B1 (en) | 2003-02-25 | 2003-02-25 | Management of multiple virtual data copies |
US12/242,953 Abandoned US20090030954A1 (en) | 2003-02-25 | 2008-10-01 | Management of multiple virtual data copies |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/374,024 Active 2026-01-04 US7447714B1 (en) | 2003-02-25 | 2003-02-25 | Management of multiple virtual data copies |
Country Status (1)
Country | Link |
---|---|
US (2) | US7447714B1 (en) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20100265606A1 (en) * | 2009-04-16 | 2010-10-21 | Spectra Logic Corporation | Tape data recovery |
US20110039541A1 (en) * | 2009-01-02 | 2011-02-17 | Sung Jun Park | Random access scheme for user equipment |
US20130173859A1 (en) * | 2011-12-30 | 2013-07-04 | Oracle International Corporation | Logically Partitioning Remote Virtual Library Extensions for Use in Disaster Recovery of Production Data |
Families Citing this family (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8145861B1 (en) * | 2005-10-17 | 2012-03-27 | Unisys Corporation | Managing data transfer between different types of tape media with encryption |
JP2009129261A (en) * | 2007-11-26 | 2009-06-11 | Hitachi Ltd | Storage system and method of searching for connection path of storage system to external volume |
JP5729479B2 (en) * | 2011-09-27 | 2015-06-03 | 富士通株式会社 | Virtual tape device and control method of virtual tape device |
WO2013138587A1 (en) | 2012-03-14 | 2013-09-19 | Convergent .Io Technologies Inc. | Systems, methods and devices for management of virtual memory systems |
Citations (31)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5412801A (en) * | 1990-01-17 | 1995-05-02 | E-Net | Gap recovery for off-site data storage and recovery systems |
US5488701A (en) * | 1994-11-17 | 1996-01-30 | International Business Machines Corporation | In log sparing for log structured arrays |
US5546557A (en) * | 1993-06-14 | 1996-08-13 | International Business Machines Corporation | System for storing and managing plural logical volumes in each of several physical volumes including automatically creating logical volumes in peripheral data storage subsystem |
US5592618A (en) * | 1994-10-03 | 1997-01-07 | International Business Machines Corporation | Remote copy secondary data copy validation-audit function |
US5604862A (en) * | 1995-03-14 | 1997-02-18 | Network Integrity, Inc. | Continuously-snapshotted protection of computer files |
US5673382A (en) * | 1996-05-30 | 1997-09-30 | International Business Machines Corporation | Automated management of off-site storage volumes for disaster recovery |
US5742792A (en) * | 1993-04-23 | 1998-04-21 | Emc Corporation | Remote data mirroring |
US6182198B1 (en) * | 1998-06-05 | 2001-01-30 | International Business Machines Corporation | Method and apparatus for providing a disc drive snapshot backup while allowing normal drive read, write, and buffering operations |
US6216211B1 (en) * | 1997-06-13 | 2001-04-10 | International Business Machines Corporation | Method and apparatus for accessing mirrored logical volumes |
US6336173B1 (en) * | 1999-04-01 | 2002-01-01 | International Business Machines Corporation | Storing and tracking multiple copies of data in data storage libraries |
US6366988B1 (en) * | 1997-07-18 | 2002-04-02 | Storactive, Inc. | Systems and methods for electronic data storage management |
US20030028514A1 (en) * | 2001-06-05 | 2003-02-06 | Lord Stephen Philip | Extended attribute caching in clustered filesystem |
US6557089B1 (en) * | 2000-11-28 | 2003-04-29 | International Business Machines Corporation | Backup by ID-suppressed instant virtual copy then physical backup copy with ID reintroduced |
US6587935B2 (en) * | 1996-05-31 | 2003-07-01 | Emc Corporation | Method and apparatus for mirroring data in a remote data storage system |
US20030177266A1 (en) * | 2002-03-12 | 2003-09-18 | International Business Machines Corporation | Method, system, and program for configuring a source device to communicate with at least one target device |
US6697960B1 (en) * | 1999-04-29 | 2004-02-24 | Citibank, N.A. | Method and system for recovering data to maintain business continuity |
US20040044830A1 (en) * | 2002-08-29 | 2004-03-04 | Gibble Kevin Lee | System, method, and apparatus for logical volume duplexing in a virtual tape system |
US6728736B2 (en) * | 2001-03-14 | 2004-04-27 | Storage Technology Corporation | System and method for synchronizing a data copy using an accumulation remote copy trio |
US6748502B2 (en) * | 2001-01-12 | 2004-06-08 | Hitachi, Ltd. | Virtual volume storage |
US6757778B1 (en) * | 2002-05-07 | 2004-06-29 | Veritas Operating Corporation | Storage management system |
US20040153739A1 (en) * | 2002-12-09 | 2004-08-05 | Alacritus, Inc. | Method and system for creating and using removable disk based copies of backup data |
US6792518B2 (en) * | 2002-08-06 | 2004-09-14 | Emc Corporation | Data storage system having mata bit maps for indicating whether data blocks are invalid in snapshot copies |
US6813683B2 (en) * | 2000-01-28 | 2004-11-02 | Hitachi, Ltd. | Method and apparatus for copying data from a main site to a remote site |
US6834324B1 (en) * | 2000-04-10 | 2004-12-21 | Storage Technology Corporation | System and method for virtual tape volumes |
US6865043B2 (en) * | 2002-01-29 | 2005-03-08 | International Business Machines Corporation | Data set information for recovery of synchronized data on magnetic tape |
US6889285B2 (en) * | 2002-08-29 | 2005-05-03 | International Business Machines Corporation | Apparatus and method to maintain information using a plurality of storage attributes |
US6950871B1 (en) * | 2000-06-29 | 2005-09-27 | Hitachi, Ltd. | Computer system having a storage area network and method of handling data in the computer system |
US6954834B2 (en) * | 2001-07-07 | 2005-10-11 | Hewlett-Packard Development Company, L.P. | Data backup including tape and non-volatile memory units and method of operating same |
US6978282B1 (en) * | 2001-09-04 | 2005-12-20 | Emc Corporation | Information replication system having automated replication storage |
US6983295B1 (en) * | 2002-10-24 | 2006-01-03 | Unisys Corporation | System and method for database recovery using a mirrored snapshot of an online database |
US6996687B1 (en) * | 2002-12-20 | 2006-02-07 | Veritas Operating Corporation | Method of optimizing the space and improving the write performance of volumes with multiple virtual copies |
-
2003
- 2003-02-25 US US10/374,024 patent/US7447714B1/en active Active
-
2008
- 2008-10-01 US US12/242,953 patent/US20090030954A1/en not_active Abandoned
Patent Citations (31)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5412801A (en) * | 1990-01-17 | 1995-05-02 | E-Net | Gap recovery for off-site data storage and recovery systems |
US5742792A (en) * | 1993-04-23 | 1998-04-21 | Emc Corporation | Remote data mirroring |
US5546557A (en) * | 1993-06-14 | 1996-08-13 | International Business Machines Corporation | System for storing and managing plural logical volumes in each of several physical volumes including automatically creating logical volumes in peripheral data storage subsystem |
US5592618A (en) * | 1994-10-03 | 1997-01-07 | International Business Machines Corporation | Remote copy secondary data copy validation-audit function |
US5488701A (en) * | 1994-11-17 | 1996-01-30 | International Business Machines Corporation | In log sparing for log structured arrays |
US5604862A (en) * | 1995-03-14 | 1997-02-18 | Network Integrity, Inc. | Continuously-snapshotted protection of computer files |
US5673382A (en) * | 1996-05-30 | 1997-09-30 | International Business Machines Corporation | Automated management of off-site storage volumes for disaster recovery |
US6587935B2 (en) * | 1996-05-31 | 2003-07-01 | Emc Corporation | Method and apparatus for mirroring data in a remote data storage system |
US6216211B1 (en) * | 1997-06-13 | 2001-04-10 | International Business Machines Corporation | Method and apparatus for accessing mirrored logical volumes |
US6366988B1 (en) * | 1997-07-18 | 2002-04-02 | Storactive, Inc. | Systems and methods for electronic data storage management |
US6182198B1 (en) * | 1998-06-05 | 2001-01-30 | International Business Machines Corporation | Method and apparatus for providing a disc drive snapshot backup while allowing normal drive read, write, and buffering operations |
US6336173B1 (en) * | 1999-04-01 | 2002-01-01 | International Business Machines Corporation | Storing and tracking multiple copies of data in data storage libraries |
US6697960B1 (en) * | 1999-04-29 | 2004-02-24 | Citibank, N.A. | Method and system for recovering data to maintain business continuity |
US6813683B2 (en) * | 2000-01-28 | 2004-11-02 | Hitachi, Ltd. | Method and apparatus for copying data from a main site to a remote site |
US6834324B1 (en) * | 2000-04-10 | 2004-12-21 | Storage Technology Corporation | System and method for virtual tape volumes |
US6950871B1 (en) * | 2000-06-29 | 2005-09-27 | Hitachi, Ltd. | Computer system having a storage area network and method of handling data in the computer system |
US6557089B1 (en) * | 2000-11-28 | 2003-04-29 | International Business Machines Corporation | Backup by ID-suppressed instant virtual copy then physical backup copy with ID reintroduced |
US6748502B2 (en) * | 2001-01-12 | 2004-06-08 | Hitachi, Ltd. | Virtual volume storage |
US6728736B2 (en) * | 2001-03-14 | 2004-04-27 | Storage Technology Corporation | System and method for synchronizing a data copy using an accumulation remote copy trio |
US20030028514A1 (en) * | 2001-06-05 | 2003-02-06 | Lord Stephen Philip | Extended attribute caching in clustered filesystem |
US6954834B2 (en) * | 2001-07-07 | 2005-10-11 | Hewlett-Packard Development Company, L.P. | Data backup including tape and non-volatile memory units and method of operating same |
US6978282B1 (en) * | 2001-09-04 | 2005-12-20 | Emc Corporation | Information replication system having automated replication storage |
US6865043B2 (en) * | 2002-01-29 | 2005-03-08 | International Business Machines Corporation | Data set information for recovery of synchronized data on magnetic tape |
US20030177266A1 (en) * | 2002-03-12 | 2003-09-18 | International Business Machines Corporation | Method, system, and program for configuring a source device to communicate with at least one target device |
US6757778B1 (en) * | 2002-05-07 | 2004-06-29 | Veritas Operating Corporation | Storage management system |
US6792518B2 (en) * | 2002-08-06 | 2004-09-14 | Emc Corporation | Data storage system having mata bit maps for indicating whether data blocks are invalid in snapshot copies |
US6889285B2 (en) * | 2002-08-29 | 2005-05-03 | International Business Machines Corporation | Apparatus and method to maintain information using a plurality of storage attributes |
US20040044830A1 (en) * | 2002-08-29 | 2004-03-04 | Gibble Kevin Lee | System, method, and apparatus for logical volume duplexing in a virtual tape system |
US6983295B1 (en) * | 2002-10-24 | 2006-01-03 | Unisys Corporation | System and method for database recovery using a mirrored snapshot of an online database |
US20040153739A1 (en) * | 2002-12-09 | 2004-08-05 | Alacritus, Inc. | Method and system for creating and using removable disk based copies of backup data |
US6996687B1 (en) * | 2002-12-20 | 2006-02-07 | Veritas Operating Corporation | Method of optimizing the space and improving the write performance of volumes with multiple virtual copies |
Cited By (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20110039541A1 (en) * | 2009-01-02 | 2011-02-17 | Sung Jun Park | Random access scheme for user equipment |
US8493994B2 (en) | 2009-01-02 | 2013-07-23 | Lg Electronics Inc. | Random access scheme for user equipment |
US20100265606A1 (en) * | 2009-04-16 | 2010-10-21 | Spectra Logic Corporation | Tape data recovery |
US20120287528A1 (en) * | 2009-04-16 | 2012-11-15 | Spectra Logic Corporation | Tape data recovery |
US8332686B2 (en) * | 2009-04-16 | 2012-12-11 | Spectra Logic Corp. | Tape data recovery |
US8453010B2 (en) * | 2009-04-16 | 2013-05-28 | Spectra Logic Corp. | Tape data recovery |
US20130173859A1 (en) * | 2011-12-30 | 2013-07-04 | Oracle International Corporation | Logically Partitioning Remote Virtual Library Extensions for Use in Disaster Recovery of Production Data |
US9575684B2 (en) * | 2011-12-30 | 2017-02-21 | Oracle International Corporation | Logically partitioning remote virtual library extensions for use in disaster recovery of production data |
US9703648B2 (en) * | 2011-12-30 | 2017-07-11 | Oracle International Corporation | Logically partitioning remote virtual library extensions for use in disaster recovery of production data |
Also Published As
Publication number | Publication date |
---|---|
US7447714B1 (en) | 2008-11-04 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7873802B2 (en) | Systems and methods for recovering electronic information from a storage medium | |
US7213116B2 (en) | Method and apparatus for mirroring objects between storage systems | |
US5029125A (en) | Method of reading and writing files on nonerasable storage media | |
US6223269B1 (en) | Stacked mapped storage system | |
RU2182360C2 (en) | Method for computer system stored data access, method for data filing, and computer system for implementing these methods | |
US7363540B2 (en) | Transaction-safe FAT file system improvements | |
US6557073B1 (en) | Storage apparatus having a virtual storage area | |
US20090030954A1 (en) | Management of multiple virtual data copies | |
US20040186900A1 (en) | Method of maintaining a plurality of snapshots, server apparatus and storage apparatus | |
CN1957414B (en) | Data recording/reproduction for write-once discs | |
US20040193564A1 (en) | Robust, self-maintaining file system | |
CN101137981A (en) | Methods and apparatus for managing the storage of content in a file system | |
US6675257B1 (en) | System and method for managing storage space on a sequential storage media | |
US8400897B2 (en) | Migrating data from one recording medium to another | |
US6192376B1 (en) | Method and apparatus for shadowing a hierarchical file system index structure to enable error recovery | |
KR100224524B1 (en) | Method for incrementally archiving primary storage to archive storage by utlizing both a partition archive status array and a partition map | |
US7895164B1 (en) | Efficient checkpoint process | |
US20050262033A1 (en) | Data recording apparatus, data recording method, program for implementing the method, and program recording medium | |
US6574704B1 (en) | Information storage management device and method, control device and method | |
US20060026459A1 (en) | Method and apparatus for storing data | |
US20060143423A1 (en) | Storage device, data processing method thereof, data processing program thereof, and data processing system | |
CN100562937C (en) | The data record method of Write-once optical disc and device | |
US20040133740A1 (en) | Computer operating system feature for preserving and accessing prior generations of a data set | |
US6886021B1 (en) | Method for tracking audit files spanning multiple tape volumes | |
US20080140729A1 (en) | Method for Changing Operation on a Storage Medium from a Current File System to a New or Updated File System |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- AFTER EXAMINER'S ANSWER OR BOARD OF APPEALS DECISION |