A cross-city disaster recovery method for cloud desktops combined with snapshot technology

Abstract

The present invention belongs to the field of data disaster recovery technology, and specifically relates to a cloud desktop cross-city disaster recovery method combined with snapshot technology. The cloud desktop cross-city disaster recovery method includes the following steps: the cloud desktop disaster recovery program sends a snapshot creation instruction; the driver module freezes all I / O write requests; the disaster recovery program generates a shadow copy; the driver module intercepts all I / O write requests and exchanges them to a buffer; the synchronization module obtains the shadow copy and buffer data and sends them to a disaster recovery resource pool. The present invention can obtain all read and write I / O requests during the process of creating a shadow snapshot and transmitting data, and perform efficient data exchange on the I / O requests, which can solve the problem of driver write I / O blocking and ensure the consistency and continuity of snapshot data. By storing a CRC check code for each data block to construct a full bitmap of the disk block, it can solve the problem of full retransmission and ensure the timeliness of disaster recovery data.

Description

Technical Field

[0001] The present invention belongs to the technical field of data disaster recovery, and in particular relates to a cloud desktop cross-city disaster recovery method combined with snapshot technology. Background Art

[0002] With the continuous development and deepening of cloud desktop technology, cloud desktops provide users with flexible and convenient computing services. High availability has gradually become a demand that users pay close attention to. Currently, OpenStack and Ceph are isolated from each other between cloud desktop resource pools. In the face of emergencies such as natural disasters, hardware failures, and software failures, if the resource pool where the user's virtual machine is located fails, it will cause user data loss and service interruption. Therefore, it is necessary to implement high availability technology for cloud desktop virtual machines across resource pools, so that the virtual machine data can be disaster-recovered to another resource pool in real time or incrementally. Once the resource pool where the virtual machine is located fails, the user can quickly switch to another resource pool to use it. In the existing technology, cross-city disaster recovery solutions for cloud desktops often rely on the snapshot capabilities of the underlying storage, with long RPO times and high storage costs. It is also impossible to achieve targeted disaster recovery for logical partitions. The real-time copy solution is difficult to meet application consistency requirements. In complex cross-city network environments, network jitter and interruptions are prone to occur. Once the transmission fails, it often requires full retransmission. Summary of the Invention

[0003] The purpose of the present invention is to provide a cloud desktop cross-city disaster recovery method combined with snapshot technology, which can obtain all read and write I / O requests during the process of creating volume shadow snapshots and data transmission, and perform efficient data exchange for I / O requests without occupying additional snapshot storage space. The volume shadow copy and IRP are sent synchronously through the synchronization module, thereby improving the consistency and continuity of the snapshot data. At the same time, by storing a CRC check code in each data block to construct a full bitmap of the disk block, it can not only solve the problem of full retransmission and driver write IO blocking, but also ensure the timeliness of the disaster recovery data.

[0004] The technical solutions adopted by the present invention are as follows:

[0005] A cloud desktop cross-city disaster recovery method using snapshot technology includes the following steps:

[0006] The cloud desktop disaster recovery program sends a snapshot creation instruction;

[0007] The driver module freezes all I / O write requests and refreshes the buffer data;

[0008] The disaster recovery program generates a volume shadow copy;

[0009] The driver module intercepts all I / O write requests and exchanges them to the buffer;

[0010] The synchronization module obtains the volume shadow copy and buffer data and sends them to the disaster recovery resource pool;

[0011] During disaster recovery switching, the client creates a backup cloud desktop and sets the read and write target of the backup cloud desktop as a block device in the disaster recovery resource pool;

[0012] The buffer zone includes a buffer queue, a temporary buffer zone and a data buffer zone.

[0013] In a preferred solution, the buffer stores data in the form of data packets.

[0014] In a preferred solution, each data block in the buffer stores a CRC check code.

[0015] In a preferred solution, each data block in the buffer further stores a write status bit.

[0016] In a preferred solution, the data packets in the buffer queue are kept in order and grow strictly monotonically.

[0017] In a preferred solution, the step before the driver module freezes all I / O write requests and refreshes the buffer data further includes: the driver module redirects the write data to a temporary buffer.

[0018] In a preferred embodiment, the driver module intercepts all I / O write requests and exchanges them to the buffer; comprising the following steps:

[0019] The cloud desktop disaster recovery program issues an I / O request;

[0020] The driver module converts the IRP corresponding to all I / O write requests and saves it to non-paged memory;

[0021] The cloud desktop disaster recovery program reads non-paged memory data and exchanges it to the data buffer via TCP connection.

[0022] In a preferred solution, the disaster recovery program generates a volume shadow copy according to the volume metadata structure and the buffer data, including the following steps:

[0023] VSS enumerates all writers and all metadata of all writers;

[0024] The writer creates metadata descriptions and writes data in memory and logs to the database. After writing is complete, it sends feedback information to VSS.

[0025] VSS writes the file system's cached data in memory to the source disk;

[0026] Requestor creates a shadow copy;

[0027] VSS unfreezes the file system, releases the inactive Writer, and verifies whether read and write I / O are successful during the shadow copy creation process.

[0028] If the read and write are successful, the synchronization module sends the shadow copy and buffer data to the disaster recovery resource pool and generates a corresponding snapshot;

[0029] In response to a read / write failure, the Requestor deletes the shadow copy.

[0030] A client, applicable to any of the above-mentioned cloud desktop cross-city disaster recovery methods combined with snapshot technology, includes a local calling module, which can call the cloud desktop image file in the disaster recovery resource pool block device to provide local cloud desktop services to users.

[0031] A computer-readable storage medium stores computer instructions. When the computer instructions are executed, the computer executes any one of the above-mentioned cloud desktop cross-city disaster recovery methods combined with snapshot technology.

[0032] The technical effects achieved by the present invention are:

[0033] When creating a shadow copy, the present invention obtains and freezes I / O requests, performs data exchange on all I / O requests, converts them into corresponding IRPs and stores them in a temporary buffer, without occupying additional snapshot storage space. The shadow copy and IRP are sent synchronously through a synchronization module, thereby improving the consistency and continuity of snapshot data.

[0034] The disaster recovery scope of the present invention can be customized, and no computing resources or shadow desktops are required. The disaster recovery desktop only needs to be created during the disaster recovery switching process. In addition to the local cache, a full bitmap of the disk block is constructed by storing a CRC check code in each data block, and the success of the transmission is judged by writing the status bit. This not only solves the problem of full retransmission and drive write IO blocking, but also saves costs, improves the timeliness of data transmission, and has the ability to recover from exceptions and reconnect. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] Figure 1 It is a schematic diagram of the overall process of the present invention;

[0036] Figure 2 It is a schematic diagram of the buffer solution of the present invention. DETAILED DESCRIPTION

[0037] In order to make the above-mentioned objects, features and advantages of the present invention more obvious and easy to understand, the specific embodiments of the present invention are described in detail below with reference to the accompanying drawings.

[0038] In the following description, many specific details are set forth to facilitate a full understanding of the present invention. However, the present invention may also be implemented in other ways different from those described herein. Those skilled in the art may make similar generalizations without violating the connotation of the present invention. Therefore, the present invention is not limited to the specific embodiments disclosed below.

[0039] Secondly, the term "one embodiment" or "embodiment" herein refers to a specific feature, structure, or characteristic that may be included in at least one implementation of the present invention. The phrase "in a preferred embodiment" appearing in various places throughout this specification does not necessarily refer to the same embodiment, nor does it constitute a separate or selective embodiment that is mutually exclusive of other embodiments.

[0040] Please see the attached Figure 1 FIG. 1 is a first embodiment of the present invention, which provides a cloud desktop cross-city disaster recovery method combined with snapshot technology, including the following steps:

[0041] Stp1: The cloud desktop disaster recovery program sends a snapshot creation command;

[0042] Stp2: The driver module freezes all I / O write requests and refreshes the buffer data;

[0043] Stp3: The disaster recovery program generates a shadow copy;

[0044] Stp4: The driver module intercepts all I / O write requests and exchanges them to the buffer;

[0045] Stp5: The synchronization module obtains the shadow copy and buffer data and sends them to the disaster recovery resource pool;

[0046] Stp6: The disaster recovery resource pool generates a desktop snapshot based on the volume shadow copy and the temporary cache data;

[0047] Stp7: During disaster recovery switching, the client creates a backup cloud desktop and sets the read and write target of the backup cloud desktop as the block device in the disaster recovery resource pool.

[0048] In a specific embodiment, the cloud desktop disaster recovery program sends a snapshot creation instruction. The requestor asks VSS to enumerate writers and their metadata to prepare for the shadow copy. The VSS initiates a request to temporarily freeze I / O write requests for each component to create a shadow copy. During this period, the VSS writes the file system's in-memory buff to the hard disk to ensure file consistency on the hard disk. The VSS notifies the requestor to create the shadow copy. After the shadow copy is created, the VSS unfreezes the file system and releases the inactive writers, waiting for all queued read and write IO operations to complete. The VSS confirms whether the read and write IO during the shadow copy creation process is successful. If successful, it starts copying the shadow copy data and generates the corresponding snapshot. If it fails, the VSS notifies the requestor to delete the shadow copy. This solution achieves data disaster recovery transmission with RPO and RTO times of seconds, fast transmission speed and recovery speed. In addition, this disaster recovery method supports multiple scenarios and has strong compatibility. It not only supports ordinary users but also supports high-IO read and write scenarios. At the same time, it does not rely on the snapshot capabilities of the cloud platform OpenStack storage layer and has the ability to recover local disasters to the cloud.

[0049] In a preferred embodiment, see Figure 2 As shown, the buffer includes a buffer queue, a temporary buffer and a data buffer, and the buffer stores data in the form of data packets, wherein the buffer queue is used for data synchronization between the data synchronization service and the target disk; the temporary buffer is used to temporarily store incremental snapshot metadata during full synchronization, because the incremental data must overwrite the full data to maintain data consistency; the data buffer is used to fully accept data push from the source disk to avoid blocking the connection of the source disk, and when pushing, it is necessary to support the push target signal for flow control.

[0050] In this embodiment, data is transmitted in the form of data packets, and the buffer zone can be used to temporarily store these data packets, waiting for the application to process them, thereby avoiding problems such as data loss or data overflow caused by the application processing speed being too fast. The setting of the buffer queue can ensure that temporary storage, sorting or scheduling data is effectively transferred to the target disk; when performing full synchronization, incremental metadata such as I / O requests may be generated. In order to avoid writing incremental metadata to the target disk, the setting of the temporary buffer zone can temporarily store metadata such as I / O requests, thereby more flexibly handling the data synchronization process, ensuring that important metadata is not lost during the data synchronization process; when performing full data synchronization, data is pushed from the source disk to the target disk, and the data buffer zone Here it acts as a medium for receiving pushed data, and needs to support the push target's signal for flow control, thereby effectively managing the flow of data, preventing the target system from being unable to process normally due to data overload, and ensuring that data transmission can be effectively managed and processed at the target end. Through the above-mentioned solution settings, the disaster recovery range can be customized, and it can support logical partition disaster recovery of the operating system, as well as disaster recovery that excludes specified files and directories. It has low usage costs, does not require computing resources, and does not require shadow desktops. Disaster recovery desktops are only created during the disaster recovery switching process. In addition to local cache, no additional snapshot storage space is required, and it can effectively improve the efficiency, data integrity, and data consistency of data synchronization, realize orderly and controllable data transmission, and avoid potential synchronization problems.

[0051] Furthermore, through the above-mentioned cache solution setting, the incremental disaster recovery problem of cloud desktops can be solved, and the stability and abnormal recovery capabilities of the backup process can be improved. At the same time, the cache solution has the following characteristics: 1. Supports breakpoint resumption; 2. Can greatly reduce the amount of data required to transmit for connection recovery; 3. The data synchronized to the target disk requires an available snapshot at any time point, that is, the data written to the target disk needs to be written in the order of incremental data as much as possible; 4. The source disk data is extracted from the operating system, and the write IO buffer may be very small, so protocol interaction needs to be designed to avoid synchronization blocking.

[0052] In a preferred embodiment, each data block in the buffer stores a CRC check code and a write status bit.

[0053] It's important to note that a CRC is a method used to detect errors in data transmission or storage. In this context, each data block is accompanied by a CRC checksum. This checksum is calculated by performing a special calculation on the data block's contents, and the receiver can use it to verify the integrity of the data. The write status bit is a flag used to indicate the write status of a data block. The write status bit identifies whether the data block has been written or is being written.

[0054] In this embodiment, a data buffer, a local temporary buffer, and a buffer queue are designed. A full bitmap of the disk block is constructed by storing a CRC checksum for each data block, and the success of the transmission is determined by writing a status bit. Compared with traditional public network solutions, this solution can solve the problems of full retransmission and drive write I / O blocking. Compared with dedicated network solutions, it saves costs. For example, if the write status bit of a data block shows "written", it means that the data in this data block has been completely written to the buffer; if the status bit shows "writing", it means that the data block is being processed and the data writing process has not yet been completed. The above solution can effectively prevent buffer data overflow caused by data loss or excessive processing speed, so that possible errors can be effectively detected and corrected during data transmission or storage, ensuring the reliability and consistency of data during storage and transmission. At the same time, it reduces disconnection and retransmission during data transmission, has automatic abnormal recovery and disconnection retransmission capabilities, and compares snapshots through CRC checksums, with advantages such as high availability, small retransmission volume, and fast recovery speed.

[0055] In a specific embodiment, whenever a data packet is sent successfully, a CRC check code is calculated for the data packet and then recorded at the address corresponding to the bitmap, and the write status is set to 1, otherwise it is set to 0. Once a retransmission occurs, the new full data is compared with the bitmap snapshot, and the difference data is resent to the target disk. This can reduce unnecessary public network traffic, significantly reduce the amount of retransmission, and improve the recovery speed.

[0056] In a preferred embodiment, the data packets in the buffer queue are kept in order and grow strictly monotonically.

[0057] It should be noted that, in this embodiment, the buffer queue is a ring buffer.

[0058] Here, the size of the buffer queue can be adjusted according to actual conditions to avoid occupying too much memory.

[0059] In this embodiment, the ring buffer is a common data structure that can effectively solve the problem of reducing the coordination between the writer and reader threads or between the front-end and back-end systems when multiple threads or the front-end and back-end (interrupt) are processed separately. The ring buffer maintains an array of fixed size as storage space and sets two pointers to identify the storage location of the data and the location of the next read and write. When a new data packet needs to be written, the new data packet is written to the buffer queue and the alignment pointer is moved. The data packets stored in the buffer queue can maintain a specific order and incrementality during transmission, processing or backup, which makes it easier to track the arrival order of the data packets and prevent confusion of the data packets during disaster recovery or backup, so as to enhance the reliability and recovery capability of the system.

[0060] In a specific embodiment, when the buffer queue is full, the array may be expanded, or data writing may be avoided through flow control logic.

[0061] In a preferred embodiment, the step before the driver module freezes all I / O write requests and file data and refreshes the buffer data further includes: the driver module redirects the write data to a temporary buffer.

[0062] In this embodiment, in data disaster recovery, the driver module redirects write data to the temporary cache area, which can solve the data processing problem when the master issues an I / O request to the disk and writes data to a certain LBA. Specifically, when the master issues a write IO request to the disk array to write the changed data from the cache to the LUN, the master's data synchronization engine will perceive this change and send the changed data block from the cache to the backup cache through the SAN switch. In this process, the driver module will redirect the request for the data to be written to the temporary cache area. Updating the source data only requires one write operation, which solves the performance problem of writing twice based on COW (copy-on-write) technology. For example: when a failure occurs and data needs to be restored, it can be quickly restored through the data in the temporary cache area, ensuring the consistency and integrity of the data. At the same time, this method also improves the system's I / O performance and fault tolerance.

[0063] In a preferred embodiment, the driver module intercepts all I / O write requests and exchanges them to the buffer; comprising the following steps:

[0064] The cloud desktop disaster recovery program issues an I / O request;

[0065] The driver module converts the IRP corresponding to all I / O write requests and saves it to non-paged memory;

[0066] The cloud desktop disaster recovery program reads non-paged memory data and exchanges it to the data buffer via TCP connection.

[0067] Furthermore, IRPs, or Input / Output Request Packets, correspond primarily to the type of access the upper layer has to the underlying device. For example, when an application executes file-related I / O functions such as CreateFile, ReadFile, WriteFile, and CloseHandle, the operating system converts these operations into IRPs of types such as IRP_MJ_CREATE, IRP_MJ_READ, IRP_MJ_WRITE, and IRP_MJ_CLOSE, and transmits these IRPs to the driver module's processing function. Common I / O request types also include "Create" (used to open or create a file or device), "Close" (used to close a file or device), "Read" (used to read data from a file or device), "Write" (used to write data to a file or device), and "I / O control" (used to perform specific I / O control operations).

[0068] In this implementation, for example, during the communication between R3 and R0, the application layer commands and data are encapsulated in the IRP structure by the system I / O manager. The hard disk drive device to be monitored is bound through the self-developed driver, the distribution routine is rewritten, and the interception of IRP requests such as IRP write IO is completed. The driver process and the synchronization process interact through the DeviceIoControl function and perform buffer control through the IOCTL request code. In this embodiment, the Neither method is adopted. The I / O manager directly passes the buffer address in user mode to the kernel driver module. The driver module copies the captured write Buffer to the output buffer. The application process takes out the IRP write request content from the output buffer, including but not limited to the offset length, size, and Buffer content. Due to the limitation of non-paged memory capacity, the buffer length needs to be adjusted. When it exceeds the limit, the IRP directly passes the completion routine and returns failure to the original application process, requiring the application process to rewrite.

[0069] It should be noted that in the operating system, R3 and R0 are two different permission levels. The system kernel state refers to R0, which is the highest permission level and mainly runs system code; the user state is R3, which has a lower permission level and mainly runs user code. The communication between R3 and R0 refers to the data exchange process between these two permission levels.

[0070] In a preferred embodiment, the disaster recovery program generates a volume shadow copy according to the volume metadata structure and the buffer data, comprising the following steps:

[0071] VSS enumerates all writers and all metadata of all writers;

[0072] The writer creates metadata descriptions and writes data in memory and logs to the database. After writing is complete, it sends feedback information to VSS.

[0073] VSS writes the file system's cached data in memory to the source disk;

[0074] Requestor creates a shadow copy;

[0075] VSS unfreezes the file system, releases the inactive Writer, and verifies whether read and write I / O are successful during the shadow copy creation process.

[0076] If the read and write are successful, the synchronization module sends the shadow copy and buffer data to the disaster recovery resource pool and generates a corresponding snapshot;

[0077] In response to a read / write failure, the Requestor deletes the shadow copy.

[0078] Furthermore, in this embodiment, the format of metadata description is XML format. XML is an open and customizable format that supports multiple applications and languages. It has the advantages of being lightweight and easy to read, and can better describe the basic characteristics and attributes of metadata.

[0079] It should be noted that, in this embodiment, VSS (Volume Shadow Copy Service) is part of the operating system service, which is used to ensure that various components can communicate and collaborate correctly; Requestor is the software that actually requests the creation of a volume shadow copy, which refers to the backup program in this embodiment; Writer is the component that actually ensures the consistency of the data set to be backed up, and is generally provided by various software vendors, such as SQL Server, Exchange Server, etc.; Provider is the component actually used to create and manage volume shadow copies, which can be an operating system, hardware or backup software.

[0080] In this implementation, the Requestor asks VSS to enumerate Writers and their metadata to prepare for the shadow copy. VSS notifies the Writer to prepare, and the Writer creates an XML-formatted metadata description and writes the data in memory and logs to the database. Upon completion, it returns this information to VSS. VSS receives this information and initiates a request to temporarily freeze I / O write requests from each component to create a shadow copy (the freezing of I / O write requests cannot exceed 60 seconds). During this period, VSS writes the file system's in-memory buff to the hard disk to ensure file consistency on the hard disk. VSS notifies the Requestor to create the shadow copy (this time cannot exceed 10 seconds). After the shadow copy is created, VSS unfreezes the file system and releases the inactive writers, waiting for all queued read and write I / O operations to complete. VSS then confirms whether the read and write I / O during the shadow copy creation process are successful. If the read and write I / O fails, VSS notifies the Requestor to delete the shadow copy. If the read and write I / O succeeds, it starts copying the shadow copy data to generate the corresponding snapshot.

[0081] A client is applicable to a cloud desktop cross-city disaster recovery method combined with snapshot technology as described in any of the above items, and the client includes a local calling module, which can call the cloud desktop image file in the disaster recovery resource pool block device to provide local cloud desktop services to users.

[0082] A computer-readable storage medium stores computer instructions. When the computer instructions are executed, the computer executes any one of the above-mentioned cloud desktop cross-city disaster recovery methods combined with snapshot technology.

[0083] Those skilled in the art will appreciate that all or part of the processes in the above-mentioned embodiment methods can be implemented by computer program instructions and related hardware. The computer program instructions can be stored in a non-volatile computer-readable storage medium. When the detection program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to storage elements, storage, databases or other media provided in this application and used in the embodiments may include non-volatile and / or volatile storage elements. Non-volatile storage elements may include read-only storage elements (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile storage elements may include random access storage elements (RAM) or external cache storage elements. By way of illustration and not limitation, RAM is available in many forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (SSRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct RAMbus dynamic RAM (DRDRAM), and RAMbus dynamic RAM (RDRAM), etc.

[0084] The foregoing is merely a preferred embodiment of the present invention. It should be noted that those skilled in the art may make various improvements and modifications without departing from the principles of the present invention, and such improvements and modifications are also within the scope of protection of the present invention. Structures, devices, and operating methods not specifically described or explained herein shall, unless otherwise specified or limited, be implemented in accordance with conventional means in the art.

Claims

1. A cloud desktop cross-city disaster recovery method using snapshot technology, characterized by: The following steps are involved: The cloud desktop disaster recovery program sends a snapshot creation instruction; The driver module freezes all I / O write requests and refreshes the buffer data; The disaster recovery program generates a volume shadow copy according to the volume metadata structure and the buffer data; The driver module intercepts all I / O write requests and exchanges them to the buffer; The synchronization module obtains the volume shadow copy and buffer data and sends them to the disaster recovery resource pool; The disaster recovery resource pool generates a desktop snapshot based on the volume shadow copy and the temporary cache data; During disaster recovery switching, the client creates a backup cloud desktop and sets the read and write target of the backup cloud desktop as a block device in the disaster recovery resource pool; The buffer zone includes a buffer queue, a temporary buffer zone and a data buffer zone.

2. The cloud desktop cross-city disaster recovery method incorporating snapshot technology according to claim 1, characterized in that: The buffer stores data in the form of data packets.

3. The cloud desktop cross-city disaster recovery method combined with snapshot technology according to claim 2 is characterized by: Each data block in the buffer stores a CRC check code.

4. The cloud desktop cross-city disaster recovery method combined with snapshot technology according to claim 2, characterized in that: Each data block in the buffer also stores a write status bit.

5. The cloud desktop cross-city disaster recovery method combined with snapshot technology according to claim 2, characterized in that: The data packets in the buffer queue are kept in order and increase strictly monotonically.

6. The cloud desktop cross-city disaster recovery method combined with snapshot technology according to claim 1, characterized in that: The step before the driver module freezes all I / O write requests and refreshes the buffer data also includes: the driver module redirects the write data to a temporary buffer.

7. The cloud desktop cross-city disaster recovery method combined with snapshot technology according to claim 1, characterized in that: The driver module intercepts all I / O write requests and exchanges them to the buffer, including the following steps: The cloud desktop disaster recovery program issues an I / O request; The driver module converts the IRP corresponding to all I / O write requests and saves it to non-paged memory; The cloud desktop disaster recovery program reads non-paged memory data and exchanges it to the data buffer via TCP connection.

8. The cloud desktop cross-city disaster recovery method combined with snapshot technology according to claim 1, characterized in that: The disaster recovery program generates a volume shadow copy according to the volume metadata structure and the buffer data, including the following steps: VSS enumerates all writers and all metadata of all writers; The writer creates metadata descriptions and writes data in memory and logs to the database. After writing is complete, it sends feedback information to VSS. VSS writes the file system's cached data in memory to the source disk; Requestor creates a shadow copy; VSS unfreezes the file system, releases the inactive Writer, and verifies whether read and write I / O are successful during the shadow copy creation process. If the read and write are successful, the synchronization module sends the shadow copy and buffer data to the disaster recovery resource pool and generates a corresponding snapshot; In response to a read / write failure, the Requestor deletes the shadow copy.

9. A client, applicable to the cloud desktop cross-city disaster recovery method combined with snapshot technology according to any one of claims 1 to 8, characterized in that: It includes a local calling module, which can call the cloud desktop image file in the disaster recovery resource pool block device to provide local cloud desktop services for users.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer instructions. When the computer instructions are executed, the computer executes a cloud desktop cross-city disaster recovery method combined with snapshot technology according to any one of claims 1 to 8.

Images