Source: http://patents.com/us-9785523.html
Timestamp: 2018-06-22 11:53:50
Document Index: 500802210

Matched Legal Cases: ['Application No. 619304', 'Application No. 12802797', 'Application No. 201280030475', 'Application No. 14', 'Application No. 714756', 'Application No. 3615', 'Application No. 2014', 'Application No. 201280030475', 'Application No. 2013156675', 'Application No. 2012273366', 'Application No. 2012273366', 'Application No. 1', 'Application No. 2013156675']

US Patent # 9,785,523. Managing replicated virtual storage at recovery sites - Patents.com
United States Patent 9,785,523
Chiruvolu , et al. October 10, 2017
Chiruvolu; Phani (Hyderabad, IN), Sinha; Gaurav (Hyderabad, IN), Singh; Devdeep (Hyderabad, IN), Oshins; Jacob (Seattle, WA), Eck; Christopher L. (Sammamish, WA)
Chiruvolu; Phani
Sinha; Gaurav
Singh; Devdeep
Oshins; Jacob
Eck; Christopher L.
Family ID: 1000002879413
13/163,760
US 20120324183 A1 Dec 20, 2012
Current CPC Class: G06F 11/2038 (20130101); G06F 11/2097 (20130101); G06F 2201/84 (20130101); G06F 2201/815 (20130101); G06F 11/1484 (20130101)
Current International Class: G06F 12/00 (20060101); G06F 11/20 (20060101); G06F 11/14 (20060101)
7533229 May 2009 van Rietschote
2006/0085792 April 2006 Traut
2006/0225065 October 2006 Chandhok et al.
2007/0208918 September 2007 Harbin
2009/0113109 April 2009 Nelson et al.
2009/0144515 June 2009 Benari
2012/0191908 July 2012 North
101421715 Apr 2009 CN
2009146169 Jul 2009 JP
2009533777 Sep 2009 JP
2433458 Nov 2011 RU
VMware, Inc. "Virtual Disk API Programming Guide, Virtual Disk Development Kit (VDDK) 1.2" [released Nov. 18, 2010] (labeled A011 NPL VMware VDDK). cited by examiner .
Petrovic, Darko, "Virtual Machine Replication", Retrieved at <<http://wiki.epfl.ch/edicpublic/documents/Candidacy%20exam/petrovi- c%20darko%20-%20candidacy%20exam%20report.pdf>>, 2009, pp. 8. cited by applicant .
Neurohr, Jason, "Recovering Your Virtual Machine. How to Manually Merge Hyper-V Snapshots Back into one VHD", Retrieved at <<http://networkfoo.org/server-infrastructure/recovering-your-virtu- al-machine-how-manually-merge-hyper-v-snapshots-back-one->>, Oct. 15, 2009, pp. 10. cited by applicant .
"Using Differencing Disks", Retrieved at <<http://technet.microsoft.com/en-us/library/cc720381(WS.10).aspx&g- t;>, Retrieved Date: Mar. 23, 2011, pp. 3. cited by applicant .
PCT International Search Report and Written Opinion for Application No. PCT/US2012/042107, Reference 332617-02, Jan. 23, 2013. cited by applicant .
Office Action received for New Zealand Patent Application No. 619304, Mail date: Jul. 17, 2014, 2 Pages. cited by applicant .
Search Report Issued in European Patent Application No. 12802797.6, Mail Date: Feb. 20, 2015, 7 Pages. cited by applicant .
First Office Action and Search Report Issued in Chinese Patent Application No. 201280030475.4, Mail Date: Aug. 4, 2015, 14 Pages. cited by applicant .
Office Action Issued in Colombia Patent Application No. 14-009479, Mailed Date: Jul. 16, 2015, 8 Pages. (W/O English Translation). cited by applicant .
International Preliminary Report on Patentability Issued in PCT Application No. PCT/US2012/042107, Mailed Date: Dec. 23, 2013, 8 Pages. cited by applicant .
"Office Action Issued in New Zealand Patent Application No. 714756", Mailed Date: Dec. 22, 2015, 2 Pages. cited by applicant .
Office Action Issued in Chile Patent Application No. 3615-2013, Mail Date: May 4, 2015, 5 Pages. (w/o English Translation). cited by applicant .
Office Action Issued in Japanese Patent Application No. 2014-517016, Mailed Date: Apr. 26, 2016, 5 Pages. cited by applicant .
"Second Office Action Issued in Chinese Patent Application No. 201280030475.4", Mailed Date: Mar. 17, 2016, 10 Pages. cited by applicant .
"Office Action Issued for Russian Patent Application No. 2013156675", Mailed Date: Jun. 2, 2016, 5 Pages. (w/o English Translation). cited by applicant .
"Office Action Issued in Australian Patent Application No. 2012273366", dated Aug. 8, 2016, 3 Pages. cited by applicant .
"Office Action Issued in Australian Patent Application No. 2012273366", dated Sep. 28, 2016, 4 Pages. cited by applicant .
"Office Action Issued in Philippines Patent Application No. 1-2013-502660" dated Sep. 8, 2016, 5 Pages. cited by applicant .
"Office Action Issued in Mexican Patent Application No. Mx/a/2013/015361", dated Jun. 9, 2016, 6 Pages. cited by applicant .
"Office Action Issued in Philippines Patent Application No. Jan. 2013-502660", dated Nov. 4, 2016, 2 Pages. cited by applicant .
"Noticeof Allowance Issued in Russian Patent Application No. 2013156675", dated Jan. 11, 2017, 11 Pages. cited by applicant .
"Office Action Issued in Philippines Patent Application No. PH/1/2013/502660", dated May 12, 2017, 2 Pages. cited by applicant.
1. An apparatus comprising: one or more storage devices that store replicated virtual storage of a replicated virtual machine, including at least a replicated base virtual disk substantially corresponding to a primary base virtual disk to be replicated; a receiver configured to receive a plurality of copies of differencing disks, of a plurality of copy types, each associated with the primary base virtual disk; and a replication management module configured to: arrange the received copies of the differencing disks of the plurality of copy types relative to the replicated base virtual disk as the differencing disks were arranged relative to the primary base virtual disk, the received copies of the differencing disks of the plurality of copy types and the replicated base virtual disk being arranged in a chain, a first differencing disk of the received copies arranged in the chain comprising an application-consistent copy type based on application data that has been prepared for creation of the copy, and a second differencing disk of the received copies arranged in the chain comprising a crash-consistent snapshot type based on application data that has not been prepared for creation of the copy, the first differencing disk and the second differencing disk having a parent-child relationship, store a plurality of the received copies of the differencing disks, each of the plurality of received copies of the differencing disks being selectable as a potential restoration point for initiating operation of the replicated virtual machine.
8. A computer-implemented method on a first computing device comprising: storing a base virtual disk image of a virtual disk associated with a virtual machine; storing changes to the virtual disk by recording the changes to a current read-write differencing disk at the top of a disk chain that includes the base virtual disk image and any intervening differencing disks, write operations performed by the virtual machine being directed only to the current read-write differencing disk, at least a first of the intervening differencing disks in the disk chain being of an application-consistent copy type based on application data that has been prepared for creation of the copy and at least a second of the intervening differencing disks in the disk chain being of crash-consistent snapshot type based on application data that has not been prepared for creation of the copy, the first of the intervening differencing disks in the disk chain and the second of the intervening differencing disks in the disk chain having a parent-child relationship; recurrently creating transferable copies of the changes to the virtual disk for replicated storage by creating a copy of the current read-write differencing disk and prohibiting further changes thereto, creating a new current differencing disk at the top of the disk chain, and transferring the copies of the differencing disks for the replicated storage to a second computing device.
15. The computer-implemented method of claim 8, further comprising: receiving a read operation to a first differencing disk of the differencing disks in the disk chain; and obtaining data not found in the first differencing disk from a parent disk of the first differencing disk in accordance with a pointer included in the first differencing disk that specifies the parent disk.
16. The computer-implemented method of claim 8, further comprising: maintaining the base virtual disk image and the differencing disks on the first computing device after said transferring, one or more read operations performed by the virtual machine being initially directed to the current read-write differencing disk and, in response to a determination that data requested by the one or more read operations is not found in the current read-write differencing disk, sequentially directing the one or more read operations to at least one of one or more of the intervening differencing disks and the base virtual disk image in the disk chain until the data requested by the one or more read operations is found.
17. Computer-readable media having instructions stored thereon which are executable by a computing system for performing steps comprising: creating a chain of read-only snapshots of a virtual machine's differencing disk, with a new differencing disk being created upon each snapshot that provides read and write capability at the tip of the chain, the chain including a plurality of types of the snapshots on the chain, including at least an application-consistent snapshot type based on application data that has been prepared for creation thereof and a crash-consistent snapshot type based on application data that has not been prepared for creation thereof, a first snapshot in the chain being of the application-consistent snapshot type and a second snapshot in the chain being of the crash-consistent snapshot type having a parent-child relationship; servicing write operations performed by the virtual machine by only accessing the new differencing disk at the tip of the chain; determining whether data requested by one or more read operations is found in the new differencing disk at the tip of the chain; in response to determining that the data requested by the one or more read operations is found in the new differencing disk at the tip of the chain, servicing the one or more read operations by the new differencing disk at the tip of the chain; and in response to determining that the data requested by the one or more read operations is not found in the new differencing disk at the tip of the chain, sequentially servicing the one or more read operations by one or more of the read-only snapshots until the data requested by the one or more read operations is found.
18. The computer-readable media as in claim 17, further comprising: providing a copy of the chain of the read-only snapshots to a replicated virtual machine.
A particular implementation of such a technique involves the copies of the differencing disks being of a plurality of replication or "copy" types, where the replication management module is configured to arrange the plurality of replication types relative to the replicated base virtual disk as they were arranged relative to the primary base virtual disk. Examples of the plurality of types include copies of the differencing disks that were obtained after one or more applications operating on the virtual machine prepared themselves for the copy, and copies of the differencing disks that were obtained without notice or preparation for the copy.
The disaster recovery process can be simplified by having a replicated copy of a machine's storage, or of a virtual machine, at a site different from the site where the primary server(s) is running. As used herein, unless otherwise noted, a "copy" generally refers to a replication of the virtual machine or virtual machine storage at issue. Thus, "replication" and "copy" may be used interchangeably herein. Updates from the primary server to the replicated copy of the virtual machine or storage may be made. Replicating a virtual machine differs from backing up an application or operating system stack, as replication of a virtual machine involves replicating both the storage and virtual machine configuration, and the workload arrives at the recovery site in a condition where it does not require reconfiguration. For example, the virtual machine container will already have the correct number of network interfaces and other such configurations, and they are configured in the manner that the workload is expecting.
In one embodiment, replication of stored data or other information in the virtual storage 108 includes the use of a storage state chain or tree, where the top of the chain (also referred to herein as the tip of tree) provides both read and write capability to record changes written to the virtual storage. For example, the virtual storage 108 may represent a virtual hard disk having a virtual hard disk (VHD) file format. The storage tree may include a base virtual disk 110, and one or more differencing disks 112A-112n that are associated with the base virtual disk 110. The differencing disk 112A that is the child of the base virtual disk 110 captures changes to the virtual storage 108. As described more fully below, a differencing disk such as differencing disk 112A may be preserved through write protection, and a new differencing disk such as differencing disk 112B can be created to accept changes to the virtual storage 108 from that point forward. This can continue through any number of differencing disks 112n, thereby creating a chain of preserved virtual disks and a differencing disk 112n to capture new changes.
At least one second site 150 is provided that includes one or more host computing systems 152, 153, 154 where replicated information from the first site 100 may be received and stored, and where recovery computing operations can be initiated in the event of disaster or other event rendering the first site 100 unable to continue its computing responsibilities. The first site 100 and second site 150 communicate by way of communication links 130, which can involve any type of electronic communication interface such as direct cabling, wireline networks, wireless networks and the like, and any combination thereof. A replication of the virtual machine 106 may be provided to the second site 150 by way of electronic means or otherwise to provide the replicated virtual machine 156. Similarly, the differencing disks 112A-112n or other portions of the virtual storage 108 designed to capture changes to the virtual storage 108 may be transferred when the data has been protected from further write operations, as described more fully below. The replicated virtual storage 158 therefore corresponds to that which has been transferred from the virtual storage 108 at the primary site 100.
Storage, such as virtual storage 108 at the first site 100, could stream its data to the second site asynchronously. However, in such an arrangement, if the first site 100 was to fail, it would be difficult for the second site 150 to know what has been successfully transferred and whether the storage is coherent. The present disclosure describes that snapshots (or other fixed images) of the first site's 100 differencing disks 112A-112n are created, and transferred to the second site 150. Using a snapshotting feature enables asynchronous replication of the storage 108 of a virtual machine 106 from one place to another. In this manner, if a primary server(s) at the first site 100 fails or otherwise goes offline, there will be no differences between the snapshots and the data that was replicated. Consequently, it will be known what data has been received at the second site 150. The disclosure thus contemplates the first site 100 transferring snapshots or other images of differencing disks at particular times to the second site 150.
For example, when a replication of the virtual storage 108 is obtained, it may further involve transferring the differencing disk data to the second site 150, and creating a new differencing disk. As a more particular example, a snapshot 114 or other replication/copy may be taken of differencing disk 112B to provide an image (e.g., AVHD image file) to the host computing system 152 at the second site 150. In one embodiment, the differencing disk 112B of which the snapshot 114 was taken will be changed to read-only, and a new differencing disk 112n will be created as a read/write virtual storage file.
Some embodiments involve different types of copies of the differencing disks or other virtual storage images. FIG. 1 depicts a plurality of such different replication or "copy" types, including copy type-A 116, copy type-B 118 through copy type-n 120. For example, a first copy type, such as copy type-B 118, may represent a low-impact copy/snapshot of a differencing disk 112A-112n that has occurred without significant efforts to increase the coherency of the data. One manner of obtaining such a copy is to mark the particular differencing disk read-only at any desired time, and create a new differencing disk to capture written data thereafter. For example, a virtual machine snapshot may be obtained using, for example, virtualization software, a hypervisor, operating system functionality, etc., which can capture the state, data and hardware configuration of a running virtual machine. This type of copy or other similar low-impact copy may be referred to in this disclosure as a crash-consistent copy, as what is stored on the differencing disk generally corresponds to that which would be on the disk following a system failure or power outage. In these cases, applications may be running that temporarily store data in cache or memory that has not been stored to memory. File system metadata may not have all managed to make it onto the disk before it was marked read-only. With this type of copy, it is possible that an attempt to reanimate the copy at a recovery site will not be entirely successful as the data may not be completely coherent. Nevertheless, this type of copy does not cause the running programs to be interrupted, and therefore has very low cost as it pertains to system performance of the computing systems 102-104 at the first site 100.
Another type of copy, such as copy type-A 116, may represent a higher coherency copy/snapshot of a differencing disk 112A-112n that occurred with some effort to increase the coherency of the data prior to the snapshot 114 being taken. For example, such a snapshot 114 may be obtained using an operating system service such as the volume shadow copy service (VSS) by MICROSOFT.RTM. Corporation that coordinates between the backup functionality and the user applications that update data on the disk. The running software (i.e., the data writers) can be notified of an impending backup, and bring their files to a consistent state. This type of copy provides a higher likelihood of proper reanimation at the second site 150. However, because the running applications may need to prepare for the backup by flushing input/output (I/O), saving its state, etc., the running workload is interrupted and subject to latencies and lower throughput. Different copy types can be used at different times or on different schedules to provide a desired balance between workload interruption and data coherency.
As described above, the disclosure sets forth manners in which stored data associated with a physical machine(s) or virtual machine(s) is replicated from a first site 100 to at least one second site 150. Embodiments involve providing snapshots or other copies of disk image portions such as differencing disks, while enabling multiple types of copies to be obtained to regularly provide replicated data at a second or "recovery" site while keeping processing interruptions at the first or "primary" site at a manageable level. Snapshots transferred to the second site 150 can be chained analogously to that at the primary site 100. Further, the servers at both the first and second sites 100, 150 can facilitate the merging of write protected differencing disks into their respective parent disks, to reduce storage capacity requirements, reduce access latencies, etc. As described more fully below, the differencing disks transferred by the first site 100 are received at the second site 150 and chained at the top of the existing disk chain of the replicated copy of the virtual machine, thereby keeping the data view of the replicated virtual machine synchronized with that of the primary server(s).
FIGS. 2A and 2B depict representative computing environments in which replication in accordance with the disclosure may be implemented. The representative systems of FIGS. 2A and 2B are merely examples, and clearly do not represent exclusive arrangements. The computing environment in FIG. 2A illustrates a first site, such as a primary server site 200. In this example, the primary server site 200 includes one or more servers 202A-202n or other computing devices. Each of the servers 200A-200n may respectively include computing capabilities such as one or more physical or logical processors 204A, 204n, memory 206A, 206n, storage 208A, 208n, etc. Storage 208A, 208n may be replicated, such that storage copies 210A, 210n such as storage snapshots may be provided to a recovery site(s) 212 for disaster recovery purposes. FIG. 2A illustrates that the techniques described herein are applicable to any storage associated with a processor, as well as applicable to virtual storage and virtual machines. It should be noted that the recovery site 212 may include servers or other computing devices having similar processing, memory and storage capabilities.
FIG. 2B illustrates an example involving one or more virtual machines. In this example, primary 220 and recovery 250 server sites respectively include one or more servers 222A-222n, which each may include computing capabilities such as one or more physical or logical processors 224A, 224n, memory 226A, 226n, storage 228A, 228n, etc. One or more of the servers may include a hypervisor 230A, 230n or other virtual machine management module that presents a virtual operating platform on which operating systems 232A, 232n and virtual machines 234A-236A, 234n-236n may operate. Features of the hypervisor 230A, 230n and/or operating system 232A, 232n may be used, adapted or added to provide functionality such as the replication management module (RMM) 238A, 238n. In accordance with the present disclosure, the replication management module 238A, 238n can provide functionality such as storing which changes (e.g., differencing disk) were the last changes to be transferred from the primary site 220 to the recovery site 250, requesting that copies be made in response to schedules or other event triggers, readying information for transfer to the recovery site 250, merging differencing disks into their respective parent disks, etc. Virtual storage (not shown) is associated with each virtual machine, which may be stored in files in the servers' 222A, 222n memory 226A, 226n, local storage 228A, 228n, clustered storage (not shown) if the servers 222A, 222n are configured in a cluster, etc. The virtual storage may be replicated, such that storage snapshots or other copies 242A, 242n are provided to a recovery site(s) 250 for disaster recovery or other purposes. FIG. 2B therefore illustrates that techniques described herein are applicable to virtual storage associated with a virtual machine. It should be noted that the recovery site 250 may include servers or other computing devices having analogous processing, memory, storage, virtual machine and virtual machine management capabilities as described in FIGS. 2A and/or 2B.
The differencing disk that was at the top of the chain has been marked read-only, as depicted by the R/O differencing disk 410B in FIG. 4B. With this disk 410B having been write-protected, block 306 shows that a new differencing disk 420 may be created as the new top of the disk chain 404B to replace the differencing disk 410B that was just copied. This new "tip of tree" differencing disk 420 will assume the responsibilities of handling both read and write operations. In one embodiment, any non-merged intermediate differencing disks 408, 410B and the base virtual disk 406 below it will remain read-only.
These methodologies further enable replication to be continued while running a "test" on the replicated copy of the virtual machine, without making a copy of the replicated virtual machine's virtual hard disks. For example, the method provides the ability to generate a "test" copy of the replicated virtual machine using two (or more) sets of differencing disks pointing to the same parent virtual hard disks. The writes executed from the "test" virtual machine are captured in one set of differencing disks, which are discarded when the test is complete. Periodic sync up changes or "deltas" arriving from the primary server may be collected in the other set of differencing disks, which can be merged into the parent once the test is complete.
The solution further provides the ability to continue replication while the initial replica for the virtual machine (e.g., the base virtual disk) is being transported out of band. The mechanism provides support for transporting the initial replica of the virtual machine "out of band;" i.e., outside the network transport channel used for transporting data from the primary site to the remote site. A differencing disk may be created on the remote site that is pointing to (or "parenting to") an empty virtual hard disk, where subsequent differencing disks received from the primary server during replication are chained on top of created differencing disk. When the out-of-band replica is received on the remote site, the differencing disk that was created to point to the empty virtual hard disk can be "re-parented" to point to the virtual hard disks received in the initial replica.
In this example, a primary computing site 700 represents the first computing environment, and a second or "recovery" computing site 750 represents the second computing environment. The primary site 700 includes one or more operating computing devices (e.g., servers), as does the recovery site 750. The recovery site 750 represents one or more computing devices/servers capable of receiving virtual disks or other storage files for preservation and possible reanimation in the event of a disaster or other event impacting the primary site's 700 ability to carry out its duties.
One purpose for performing a merge function is to reduce the number of links that a read operation may be subject to in order to locate stored data on the virtual disk. Referring now to FIG. 9, an example of such linking is described. It is assumed that a copy 901 of a base virtual disk 902 has been provided to the recovery servers 950, as depicted by the replicated base virtual disk 952. A newly-created differencing disk (e.g., differencing disk 904) will include a pointer 906 or link to its parent disk which is also the previous "tip of tree" disk. In this example, differencing disk 904 would include a pointer 906 to the base virtual disk 902. If a read operation 908 was issued on the primary servers 900 for data not found in the new differencing disk 904, the read operation 908 may obtain the data at a location farther back in the disk chain that is specified by the pointer 906, link or other analogous directing mechanism. In this example, the read operation 908 would obtain the data from the base disk 902, based on the pointer 906 in differencing disk 904, if differencing disk 904 did not have the data associated with the read request.
If the replication management at the primary site 700 makes a request for such a pre-prepared or "application-consistent" copy, the VSS or other management module for the operating system may be involved to generate the snapshot set. When the snapshot is created, the differencing disk D2 706 shown in FIG. 7C may be converted to read-only, and another new read/write differencing disk D3 710 may be created to now capture the data being written to the virtual disk. With differencing disk D3 710 now recording changes to the virtual disk, the prior "tip of tree" differencing disk D2 706 is transferred to the recovery site 750 as depicted by replicated differencing disk D2 758 shown in FIG. 7D
At the recovery site 750, the newly received crash-consistent copy 760 is now the most recent copy (tip of tree). In this embodiment, the replicated application-consistent copy D2 758 and the replicated crash-consistent copy D3 760 are both available as restoration points. For example, assume that a primary server at the primary site 700 fails or otherwise becomes unable to properly perform its duties, and assume this failure occurs at a point of time generally corresponding to that depicted in FIG. 7E. A recovery virtual machine (or alternatively physical machine) at the recovery site 750 may be invoked using, for example, the most recently received replicated application-consistent copy D3 760. Although the application-consistent copy D3 760 was received at the recovery site 750 earlier in time, it is a copy type that has a higher likelihood of reanimating properly at the recovery site 750. As noted above, this is due to this "type" of copy, which in this example involved notifying applications/software at the primary site 700 of the impending snapshot before the respective snapshot was taken, thereby enabling the software to prepare itself for the snapshot.
Thus, in the illustrated example, automatic or manual selection of a first virtual disk at the recovery site 750 may include the read-only disk 756 (including the base virtual disk and D1), the read-only application-consistent differencing disk D2 758, and the read/write crash-consistent differencing disk D3 760. Alternatively, automatic or manual selection of a second virtual disk may include the read-only disk 756 (including the base virtual disk and D1), the read-only application-consistent differencing disk D2 758, and the differencing disk 762 that was created at the recovery site 750. Different recovery scenarios are possible in view of the different "futures" provided by having multiple read/write differencing disks point to a common parent disk.
As an example, assume a replication management module at the primary site 700 requests the running workload of a virtual machine to make an application-consistent copy of the virtual storage or other snapshot that involves software preparing itself for the snapshot. In response, application software may attempt to make itself coherent for the snapshot, but it may be difficult to coordinate the snapshot being taken in the virtual disk with the information "flushes" that are occurring in the application. When the application software appears to have completed the data flush to storage, the virtual disk snapshot is taken. Thereafter, the snapshotted differencing disk is marked read-only, and a new differencing disk is created. Between the time that the virtual disk snapshot is taken and the time that the corresponding differencing disk was written to read-only, one or more stray data writes may have found their way onto the differencing disk that was the subject of the snapshot. Therefore, it is possible that the differencing disk may not correspond exactly with the differencing disk snapshot 758 that was transferred to the recovery site 750. In this case, even without having failed over to the recovery site 750, the differencing disk 758 can be mounted as a live virtual disk in order to locate those stray writes, and to back those stray writes out of the differencing disk D2 758 and onto the differencing disk 762 created at the recovery site 750. In this manner, if a failover is ultimately needed, this task has already been handled. This function of backing out the stray writes may be accomplished using the virtual machine that would eventually be recovered, or alternatively could be done as part of a service that mounts the disk image and manipulates it to extract the stray writes.
In this example, a base virtual disk is provided to the recovery site as depicted at block 1000. As shown at block 1002, a differencing disk or other storage structure is created at the primary site to record changes to the virtual disk. In this example, some number "n" of different types of snapshots/copies are provided, including copy type-A, copy type-B through copy type-n. When replication management or other primary site control module requests a copy of the virtual storage as determined at block 1004, it may specify which type of copy is desired. The identification of a copy type may be made by a user via a user interface, or configured into hardware or software such as being requested pursuant to a policy such as that described in connection with FIG. 8, or otherwise.
Previous Patent US 9,785,522 | Next Patent US 9,785,524