A data recovery method and system

Abstract

A data recovery method and system, the system comprises a receiving module, a first processing module and a second processing module; the receiving module is used for providing a unified file access interface for a plurality of application programs in a kernel state, receiving a first read request of a first application program, the first read request is used for requesting to access a first file; the first processing module is used for responding to the first read request, in the case that the first file data is lost in a production storage device, obtaining a first backup file of the first file from a backup copy of a backup system of the production storage device, and returning the first backup file to the first application program; the second processing module is also used for writing the first backup file into the production storage device.

Description

Technical Field

[0001] This application relates to the field of data processing, and in particular to a data recovery method and system. Background Technology

[0002] Traditional data backup solutions typically involve two steps in data recovery based on backup copies: 1. Restoring backup data from the backup system to the production system; 2. Waiting for the backup data recovery to complete before restarting the production application. In most scenarios, these two steps must be executed sequentially during recovery. This leads to the problem that the larger the amount of data to be recovered, the longer the recovery time, resulting in a poorer recovery time objective (RTO), often reaching several hours to days. With the continuous increase in data volume, the maximum time allowed to restore data and business systems to normal operation (i.e., the recovery time objective RTO) becomes increasingly difficult and stressful after system failures or disasters.

[0003] To overcome these challenges, an instant recovery technology has emerged, combining... Figure 1 ( Figure 1 (Taking VMware as an example) The data recovery process in this technology is as follows:

[0004] (1) Virtual storage volume: The backup system first virtualizes the backup data as a "standard storage volume" that the production system can directly access. This storage volume provides common storage protocols (such as standard iSCSI / FC protocol, NFS / SMB protocol) or VMDK disk file format, which is convenient for the production system to identify and use.

[0005] (2) Business startup and data reading and writing: The production system can start and run business immediately based on the "standard storage volume".

[0006] (3) Data migration in the background: The backup system uses the online volume migration capability of the production system to gradually migrate the data in the "standard storage volume" to the production storage in the background. This process will not affect the current business operation of the production system based on the "standard storage volume".

[0007] (4) Online volume switching: After the data migration is completed, the online volume switching capability of the production system is used to switch the storage of the production system from the "standard storage volume" of the backup system to the production storage online, thus completing the entire recovery process.

[0008] The advantage of this technology is that the entire instant recovery process does not require waiting for all backup data to be restored to the production system, and the production system can be started even without restoring any data. This greatly shortens the recovery time target (RTO) to the minute or even second level, with the main time consumption depending on the startup time of the production system itself.

[0009] Despite their significant advantages, existing instant recovery technologies still face serious challenges in practice: their applicability is extremely limited, primarily relying on whether production system applications possess two key capabilities—online data migration (such as VMware's Storage vMotion) and online volume swapping (such as Oracle Database 12c+'s ALTER DATABASE MOVEDATAFILE). These technologies require built-in logic within the application itself (e.g., Oracle Database coordinating IO requests and tracking read / write operation sequences during migration) to ensure data consistency and avoid service interruptions caused by file locking or data block conflicts. If the application lacks these capabilities, not only can instant recovery not be achieved, but forcibly attempting a background migration may lead to data corruption or service crashes. In such cases, only traditional shutdown recovery solutions can be used, suspending business operations and waiting for the backup to complete. This highlights the high dependence of instant recovery technologies on specific application ecosystems.

[0010] In summary, in the current backup technology field, only a few specific application scenarios, such as VMware virtualization environments and Oracle databases, can support the feature of instant recovery, and timely recovery for unspecified application scenarios cannot be achieved. Summary of the Invention

[0011] This application provides a data recovery method and system that implements a universal instant recovery architecture applicable to various applications, thereby overcoming the predicament of existing instant recovery technologies being highly dependent on specific applications.

[0012] In a first aspect, this application provides a data recovery system for online data recovery of a production system in the event of data loss, using backup data from a backup system. The production system includes production equipment (such as a server) and production storage equipment (such as a hard disk). The production equipment runs at least one application, and the production storage equipment stores data that the application may access during its operation. The data recovery system includes a receiving module, a first processing module, and a second processing module. The receiving module provides a unified file access interface, such as a Virtual File System (VFS), to multiple applications in kernel mode. It receives read requests (referred to as a first read request) from an application running on the production equipment (referred to as a first application), requesting access to a first file. The first processing module, in response to the first read request, reads backup data of the first file (referred to as a first backup file) from a backup copy of the backup system in the event of data loss in the production storage device, and returns the first backup file to the first application. The second processing module asynchronously writes the first backup file to the production storage device to recover the first file.

[0013] Through the above design, this data recovery system provides a unified file access interface for multiple applications in kernel mode. In the event that a file accessed by any application is lost in the production system, the first processing module redirects the application's read request to the backup system, retrieves the required file (such as the first file) from the backup system, and simultaneously returns the retrieved file to the application while writing it to the production storage device to recover the file. This solution can respond promptly to application read requests without pausing the application and also recovers lost files from the production storage (the first file does not need to be recovered again in subsequent recovery processes, thus reducing the amount of data recovered). Therefore, this solution can recover data while running, achieving real-time recovery.

[0014] Furthermore, this technology provides read request services to applications based on kernel mode, and is not bound to any specific application. Applications are unaware of data recovery, essentially providing a general recovery solution that is not tied to any application. Compared to technologies where each application provides its own recovery solution, it offers better versatility.

[0015] In one possible design of the first aspect, the first processing module may run in kernel mode or in user mode. For example, the receiving module includes a user-space filesystem driver (FUSE Driver), and the first processing module is a fuse process running in user mode.

[0016] With the above design, the first processing module runs in user space and is a user-mode module. Compared with the first processing module running in kernel space, the development of user-mode modules does not require modification of kernel program code. The user-mode development environment is relatively simple. In addition, user-mode modules run in user space and cannot directly access kernel resources and hardware devices. If a user-mode module encounters an error or is maliciously attacked, its impact is usually limited to the module itself and will not easily cause the entire system to crash.

[0017] In one possible design of the first aspect, the system further includes a data migration module; the data migration module is used to asynchronously migrate backup data of multiple files included in the backup copy online to the production storage device. Upon writing the first backup file to the production storage device, the data migration module migrates the backup data of all files other than the first backup file to the production storage device. In other words, before migrating the backup data of a file, the data migration module checks whether valid data for the file to be migrated exists in the production storage device. If it does, the migration is not repeated; otherwise, the backup data of that file is not migrated to the production storage device.

[0018] The above design allows for the asynchronous migration of backup data to production storage devices in the background, eliminating the need to wait for application access before data migration, thus accelerating data recovery.

[0019] In one possible design of the first aspect, when the first processing module reads the first backup file from a backup copy of the backup system, it is specifically configured to: read the first backup file from a virtual volume of the backup system; the virtual volume is generated based on the backup copy and mounted to the production device via a file access protocol. In this case, the virtual volume may include a file system generated from the backup copy, so that in the event of data loss on the production storage device, the application can run based on the virtual volume.

[0020] Through the above design, when a virtual volume is generated based on the files included in the backup copy, this virtual volume has the same file directory as the original file directory of the production system. Mounting this virtual volume to the production system to run applications allows applications to browse files in the virtual volume as if they were accessing the original file system of the production system, thus providing a foundation for ensuring the normal operation of applications. Furthermore, by shielding the details of the underlying storage device from the virtual volume, the storage addresses of files in the virtual volume can be mapped to either the production or backup storage device. This allows the underlying physical storage (production or backup storage device) to be directed based on the file path of the files accessed by the application, thereby decoupling the physical address binding between the production system and the underlying storage, enabling online volume switching at the file system level, and supporting seamless data access during migration.

[0021] In one possible design of the first aspect, the storage device in the backup system is a block storage device, which stores multiple data blocks included in the first file; when the processing module reads the first file from the backup copy of the backup system, it is specifically used to: read multiple data blocks from the block storage device, including: determining the logical block address (LBA) of the first file in the virtual volume based on the metadata of the first file; determining the physical block address corresponding to the LBA of the first file based on the address mapping relationship; and obtaining the multiple data blocks from the block storage device based on the physical block address.

[0022] Through the above design, virtual volumes shield the details of the underlying storage devices, thereby decoupling the physical address binding between the production system and the underlying storage. In the event of production data loss, online volume switching at the file system level can be achieved. For example, virtual volumes can map the physical address of backup data that has not been migrated to the block storage device, and map the physical address of the migrated backup data to the production storage device. This online volume switching method is not bound to any specific application, and therefore does not depend on whether the application has the ability to switch online volumes, thus achieving online volume switching at the file system level that is independent of the application's own capabilities.

[0023] In one possible design of the first aspect, when the second processing module writes the first backup file to the production storage device, it is specifically used to write the first backup file to the production storage device in a block storage manner. For example, if the production storage device is a block storage device, the second processing module may have the function of a block device driver, dividing the first backup file into multiple data blocks in a block storage manner, writing the multiple data blocks to the production storage device, and recording the mapping relationship between the first backup file and the multiple data blocks.

[0024] In one possible design of the first aspect, the receiving module is further configured to receive a write request sent from a first application or a second application, the write request including a third file to be written; the first processing module is configured to respond to the write request and write the third file to the production storage device through the second processing module.

[0025] The above design allows for processing business write requests while restoring production system data, ensuring that the business operations of the production system are not interrupted.

[0026] In one possible design of the first aspect, the receiving module is further configured to receive a second read request from a second application running in the production system, the second read request being for requesting access to a second file; the first processing module is configured to, in response to the second read request, read the data of the second file from a backup copy in the event that the data of the second file is lost in the production storage device, and return the data of the second file to the second application; the second processing module is further configured to write the data of the second file to the production storage device.

[0027] With the above design, the data recovery system can be used to handle access requests from multiple applications in the production system without having to set up a separate data recovery system for each application, providing a more lightweight instant recovery architecture.

[0028] Secondly, this application provides a data recovery method, which may include the method performed by the data recovery system in the first aspect and any possible design of the first aspect. For example, the method includes: receiving a first read request from a first application, the first read request being used to request access to a first file; in response to the first read request, in the event that the data of the first file is lost in the production storage device, reading the first file from a backup copy of the backup system of the production storage device and returning the first file to the first application; and writing the first file to the production storage device.

[0029] Thirdly, this application also provides a computing device. The computing device includes a processor and a memory, the memory being used to store instructions and / or data. The memory is coupled to the processor, and when the processor executes the program instructions stored in the memory, it can realize the data recovery system behavior described in the first aspect above. The computing device also includes a communication interface for communicating with other devices.

[0030] Fourthly, this application also provides a computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to perform the operations described in the first aspect and the various possible designs of the first aspect performed by the data processing system.

[0031] Fifthly, this application also provides a computer program product containing instructions that, when run on a computer, cause the computer to perform the operations described in the first aspect and the various possible designs of the first aspect performed by the data processing system.

[0032] In a sixth aspect, this application also provides a computing chip connected to a memory, which is used to read and execute software programs stored in the memory to perform the operations performed by the data processing system in the first aspect and various possible designs of the first aspect.

[0033] For the description of the beneficial effects of any of the second to sixth aspects above, please refer to the description of the technical effects in any possible implementation of the first aspect above, and this application will not repeat it here. Attached Figure Description

[0034] Figure 1 This is a schematic diagram of an instant recovery architecture;

[0035] Figure 2 This is one of the hardware architecture diagrams of an instant recovery system provided in the embodiments of this application;

[0036] Figure 3 This is a schematic diagram of the structure of a host provided in an embodiment of this application;

[0037] Figure 4 This is a schematic diagram of a file system provided in an embodiment of this application;

[0038] Figure 5A This is one of the software architecture diagrams of an instant recovery system provided in the embodiments of this application;

[0039] Figure 5B This is a second schematic diagram of the software architecture of an instant recovery system provided in this application embodiment;

[0040] Figure 6 This is the third schematic diagram of the software architecture of an instant recovery system provided in this application embodiment;

[0041] Figure 7 This is a schematic flowchart of a data recovery method provided in an embodiment of this application;

[0042] Figure 8 This is a schematic diagram of a virtual volume provided in an embodiment of this application;

[0043] Figure 9 This is a schematic diagram of the structure of a computing device provided in an embodiment of this application;

[0044] Figure 10 This is a schematic diagram of another computing device provided in an embodiment of this application. Detailed Implementation

[0045] The data recovery method provided in this application can be applied to various fields, typically those with high requirements for data security and business continuity, such as the financial industry (e.g., banking systems, securities trading systems), the medical industry (e.g., hospital information systems, medical image archiving and communication systems), the e-commerce industry (e.g., e-commerce trading platform systems, e-commerce warehouse management systems), and the manufacturing industry (e.g., enterprise resource planning (ERP) systems, product lifecycle management (PLM) systems). These business fields usually require the simultaneous deployment of production systems and backup systems. In these systems, the production system is critical to the enterprise's operation, while the backup system is a crucial link in ensuring data security and business continuity; both play a pivotal role.

[0046] This application provides a general-purpose instant recovery system that can be widely applied in the aforementioned business areas. It is used to perform instant recovery using a backup system when a production system has data recovery needs. Instant recovery refers to achieving near real-time recovery when a system or data failure occurs in a production system, allowing users to quickly launch applications directly from backup storage without waiting for traditional data recovery processes (such as completely copying backup data back to the original device after a shutdown). This process is typically completed in seconds or minutes, and recovery can be performed while the system is running.

[0047] Figure 2 This is a schematic diagram of the hardware architecture of an instant recovery system provided in an embodiment of this application. Figure 2 In terms of overall architecture, the system architecture includes production system 10 and backup system 20.

[0048] Production system 10 is used in the company's daily operations to process business data, run business processes, and provide services. It is typically responsible for real-time processing and storage of the company's critical business data, ensuring business continuity and efficient operation. Backup system 20 is used to periodically back up and store the data in production system 10. It uses specific backup software and hardware to copy the data from production system 10 to other storage media to prevent data loss or corruption. The main function of backup system 20 is to quickly restore data in the event of a failure in production system 10, a cyberattack, data loss / corruption, natural disasters, or other unforeseen circumstances, ensuring normal business operations and preventing the company from falling into crisis due to data loss.

[0049] For example, in a banking system, production system 10 handles critical business processes such as customer account management, fund transfers, loan disbursements, and transaction clearing, requiring real-time processing of large amounts of transaction data. Backup system 20 ensures that data and business operations can be quickly restored in the event of a disaster or failure in production system 10, protecting customer funds and ensuring normal bank operations.

[0050] For example, a hospital information system encompasses multiple aspects, including patient registration, consultation, examination and testing, inpatient management, drug management, and financial management. The production system 10 typically stores critical patient medical information and hospital operational data. The backup system 20 ensures the security and recoverability of patient medical data in the event of a failure or data corruption in the production system 10, guaranteeing the normal operation of hospital medical services and preventing data loss from affecting patient diagnosis and treatment.

[0051] For example, an e-commerce transaction platform system is responsible for handling business processes such as product display, user registration and login, order generation and processing, payment settlement, and logistics delivery. The production system 10 handles daily e-commerce transactions, processing user orders, payments, and inventory management, directly impacting the company's sales and operational efficiency. The backup system 20 ensures rapid business recovery in the event of unforeseen circumstances in the production system 10, protecting user information and transaction data, and maintaining the e-commerce platform's reputation and normal operation.

[0052] For example, such as Figure 2 As shown, the production system 10 may include a host 101, a production storage device 102, and a network device 103. Optionally, it may also include a terminal device 104. It should be noted that... Figure 2 The main features shown are the components of each system, but the number of each device is not specified. In actual applications, each device may be one or more.

[0053] Host 101 is a device with computing capabilities that provides computing resources to production system 10. Host 101 can be a server, high-performance computer, desktop computer, computing instance (such as virtual machine or container), etc. The number of hosts 101 in production system 10 can be one or more. According to the function of host 101, host 101 can be further divided into application server 1011, database server 1012, etc.

[0054] Application server 1011 typically runs various applications to implement specific business functions and is responsible for dynamic business logic and data interaction. These applications are usually software developed according to the enterprise's business needs, such as banking systems, customer relationship management (CRM) software, risk management software, e-banking service systems, enterprise resource planning (ERP) systems, product lifecycle management (PLM) systems, etc., without specific limitations.

[0055] Database server 1012 is used to run database management systems such as Oracle, MySQL, and SQL Server, and to store, manage, and query business data in production system 10.

[0056] Optionally, host 101 can also be other types of servers. Figure 2 (Not shown), such as a web server. The web server stores website files (HTML, images, databases, etc.), responds to user browser requests, and returns content. This is merely an example; in actual applications, the production system 10 may include one or more of the above-mentioned servers, and there is no limit to the number of each type of server.

[0057] Production storage includes one or more production storage devices 102, which can be persistent storage media such as hard disks or disk arrays, used for persistent storage of data, such as business data in the production system 10. This data can be received by the host 101 from external devices (such as terminal device 104) or generated by the host 101. Applications may access this data during operation.

[0058] In one example, production storage device 102 can be a standalone storage device external to host 101, such as... Figure 2 As shown, host 101 does not include production storage device 102. When production storage device 102 is an external storage device of host 101, host 101 and production storage device 102 can be connected via a network or via network device 103.

[0059] Optionally, the production storage device 102 can also be built into the host 101. Figure 2 (Not shown), in this case, the host 101 is a device with both computing and storage capabilities. For example, the host 101 includes storage devices such as hard disks, which can be used as production storage devices 102. When the production storage device 102 is a storage device built into the host 10, the host 101 and the production storage device 102 can be connected via a computer bus.

[0060] Production storage may include storage devices built into host 101 and / or storage devices external to host 101.

[0061] Network devices 103, including switches, routers, firewalls, etc., are used to ensure data transmission and network security within the production system 10. For example, they facilitate interconnection and communication between multiple hosts 101, such as between multiple application servers 1011, multiple database servers 1012, and between application servers 1011 and database servers 1012. Network devices can also be used for connection and communication between the production system 10 and external networks. For instance, they facilitate connection and communication between hosts 101 and backup system 20, such as between application servers 1011 and backup system 20, and between database servers 1012 and backup system 20. Furthermore, they facilitate connection and communication between hosts 101 and other external devices, such as terminal devices 104. It is understood that the selection of network devices depends on the network environment and communication requirements of the devices. For example, devices within a local area network (LAN) are typically interconnected through switches; while routers are typically used to connect LANs and wide area networks (WANs).

[0062] Terminal device 104 may include user terminal devices, such as mobile phones, computers, tablets, POS machines, smartwatches, and other physical devices. The user terminal device is the interface used by the user to interact with host 101, and can be used to input data, query information, and obtain services. For example, the user sends requests to host 101 through terminal device 104, such as order submission requests, order query requests, web browsing requests, etc. Host 101 responds to these requests from terminal device 104, generating production data and writing it to production storage device 102, or reading the data required for the request from production storage device 102 and returning it to terminal device 104. Terminal device 104 may also include a client, which is essentially a software program running on physical devices such as mobile phones and computers. Clients include shopping software running on mobile phones and computers, and cashier software running on POS machines, whose functions include presenting a user interface and sending requests to host 101.

[0063] The previous section introduced production system 10; the following section introduces backup system 20. See also... Figure 2 The backup system 20 typically includes a backup server 201 and a backup storage device 202.

[0064] The number of backup servers 201 can be one or more. When multiple backup servers 201 exist, they can be used together to handle data backup for the same business, or they can be used separately to handle data backup for different businesses. Optionally, for the same business, the backup system 20 includes at least two redundantly deployed backup servers 201, which back each other up, such as backup server 0 and backup server 1. When backup server 0 fails, backup server 1 can take over the business of backup server 0. When backup server 1 fails, backup server 0 can take over the business of backup server 1. The number and deployment mode of backup servers 201 can be determined according to business needs.

[0065] Backup server 201 is responsible for coordinating and controlling the entire backup process. Backup server 201 runs backup software, which can direct operations such as copying, transmitting, and storing data (denoted as production data) in production system 10 according to preset backup strategies. Among them, backup software provides various functions of backup system 20, such as setting backup strategies (including full backup, incremental backup, differential backup, etc. and backup time intervals, etc.), data transmission management, data encryption, compression, storage management, and recovery functions.

[0066] Backup storage includes one or more backup storage devices 202. Backup storage devices 202 are used for persistent storage of backup data from production data, including but not limited to some or all of disk arrays, tape libraries, optical disc libraries, and cloud storage. Disk arrays are characterized by fast read / write speeds and rapid data recovery, making them suitable for backing up and quickly restoring recent data. Tape libraries offer advantages such as large capacity, low cost, and suitability for long-term archiving. Optical disc libraries can be used for long-term storage of important but infrequently accessed data. Cloud storage provides secure, flexible, and low-cost data storage and management capabilities.

[0067] The main functions of the backup system 20 include obtaining backup data of production data from the production system 10, forming a complete backup copy of all selected data copied in each backup, and writing it to the backup storage device 202 for persistent storage. In this embodiment, the host 101 (application server 1011 or database server 1012) can use the data recovery method of this application to perform real-time recovery using the backup copy.

[0068] The following uses application server 1011 as an example to describe a possible structure of host 101 provided in an embodiment of this application. See also Figure 3 As shown, Figure 3 A schematic diagram of the structure of an application server 1011 provided in this application is shown below. Figure 3As shown, a production system 10 may include an application server cluster, which may include one or more application servers 1011. Figure 3 Three application servers 1011 are shown, but this embodiment is not limited to three application servers 1011. Optionally, the production system 10 may also include a database server cluster. Figure 3 (Not shown), this database server cluster includes one or more database servers 1012. Multiple application servers 1011, multiple database servers 1012, and multiple application servers 1011 and multiple database servers 1012 can communicate with each other. The structure of database server 1012 can be found in the description of application server 1011, and will not be repeated here.

[0069] In terms of hardware, the application server 1011 includes a processor 123, memory 124, and optionally, a hard disk 125.

[0070] Processor 123 can be a central processing unit (CPU) that can independently handle access requests from external sources (such as terminal device 104) and also handle internally generated access requests. For example, if the access request is a write request, when CPU 123 receives a write request from terminal device 104 carrying data to be written, it stores the data in memory 124. When the total amount of data in memory 124 reaches a certain threshold, CPU 123 sends the data stored in memory 124 to hard disk 125 for persistent storage. The access request can also be a read request; for example, when CPU 123 receives a read request from terminal device 104, it reads the target data from memory 124 or hard disk 125 and returns it to terminal device 104.

[0071] Optionally, CPU 123 can coordinate with database server 1012 to handle access requests. For example, when CPU 123 receives a write request from terminal device 104, it calls database server 1012 to complete the write operation of the data to be written. For instance, when a user clicks "Submit Order" on terminal device 104, CPU 123 responds to the request by generating order data, such as order ID, user ID, product information, and amount. Then, CPU 123 sends a transaction request to database server 1012, and database server 1012 inserts a new record (containing order data) into the "Order Table" stored on production storage device 102 (which may be a hard drive or other storage device included in database server 1012, or an external storage device). Alternatively, CPU 123 receives a read request (such as an order query request) sent by terminal device 104, forwards the read request to database server 1012, database server 1012 reads the target data, and then returns the target data to CPU 123, which then returns it to terminal device 104.

[0072] It should be noted that Figure 3 The processor 123 is illustrated using a CPU as an example. In practical applications, the processor 123 can also be implemented using other general-purpose processors, digital signal processors (DSPs), hardware logic circuits, processing cores, application-specific integrated circuits (ASICs), AI chips, or programmable logic devices (PLDs). The aforementioned PLD can be a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), generic array logic (GAL), a system-on-chip (SoC), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, or any combination thereof. Furthermore, Figure 3 Only one CPU123 is shown in this embodiment. In practical applications, there are often multiple CPU123s, and each CPU123 has one or more processor cores. This embodiment does not limit the number of processors or the number of processor cores.

[0073] Memory 124 refers to the internal memory that directly exchanges data and instructions with CPU 123. It can read and write data at any time and at a very high speed, serving as temporary data storage for the operating system or other running applications. Memory 124 includes, but is not limited to: random access memory (RAM), read-only memory (ROM), static random access memory (SRAM), dynamic random access memory (DRAM), double data rate memory (DDR), and storage class memory (SCM). Read-only memory can be programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), etc. In practical applications, application server 1011 can be configured with multiple memory modules 124, and different types of memory modules 124. This embodiment does not limit the number or type of memory modules 124.

[0074] CPU 123 is connected to memory 124 via a Double Data Rate (DDR) bus or other type of bus. CPU 123 executes the following instructions by calling computer program instructions stored in memory 124. Figure 7 The embodiments include some methods that the server needs to execute.

[0075] Hard disk 125 is used for persistent data storage. When data is not found in memory 124, data can be read from hard disk 125 and loaded into memory 124. Hard disk 125 can be non-volatile memory, such as read-only memory (ROM), hard disk drive (HDD), or solid-state drive (SSD). Application server 1011 may include one or more hard disks 125, which can be used as production storage device 102.

[0076] At the software level, application server 1011 runs one or more applications, such as the business software described above. Application server 1011 receives external access requests through the running applications. For access requests received from external sources, the applications can forward the request to other components (such as CPU 123) or services for processing or generate new read / write requests. For example, when an application receives a request to read specific data from a database, it may convert this request into a database query statement and then send it to the database management system to execute the query operation. Alternatively, the application may actively initiate a read / write request. In either case, the question arises as to how the application accesses the data. In this embodiment, a file system is built in the production storage device 102 to provide file-level data access for the applications.

[0077] Combination Figure 4In essence, a file system is a structured way of storing and organizing data files. All data in a computer consists of 0s and 1s, and the series of 0s and 1s stored on the hardware medium are completely indistinguishable and unmanageable to users. Therefore, the concept of "files" is used to organize this data. Data used for the same purpose is grouped into different types of files according to the structural requirements of different applications. For example, logical objects such as order tables and logs mentioned above are converted into specific file types for storage. Different file extensions are usually used to represent different types, and each file is given a name that is easy to understand and remember. When there are many files, they are grouped according to a certain partitioning method, and each group of files is placed in the same directory (or folder). Furthermore, in addition to files, directories can also have subdirectories (called subdirectories or subfolders), and all files and directories form a tree structure. This tree structure has a specific name: a file system. There are many types of file systems, the most common being Windows' FAT / FAT32 / NTFS, and Linux's EXT2 / EXT3 / EXT4 / XFS / BtrFS, etc. To facilitate searching, directories are listed level by level from the root node down to the file itself. The names of these directories, subdirectories, and files are concatenated using special characters (e.g., "\" in Windows / DOS, " / " in Unix-like systems). This string of characters is called a file path, such as " / etc / systemd / system.conf" in Linux or "C:\Windows\System32\taskmgr.exe" in Windows. A path is a unique identifier for accessing a specific file. For example, D:\data\file.exe in Windows is a file path, representing the file.exe file located in the data directory on the D partition.

[0078] The file system is built on block storage devices (such as hard disk 125), such as... Figure 4As shown, in block storage devices, all data is divided into blocks of fixed size, and each block is assigned a number for addressing (such as a Logical Block Addressing (LBA)). The file system not only records the file path but also which blocks constitute a file and which blocks record directory / subdirectory information. Different file systems have different organizational structures. For ease of management, block storage devices such as hard drives can typically be divided into multiple logical block devices, also known as hard drive partitions. Conversely, since the capacity and performance of a single medium are limited, multiple physical block storage devices can be combined into a single logical block device using certain techniques, such as various levels of RAID and JBOD. File systems can also be built on top of these logical block storage devices. In any case, the application does not need to know the specific location of the file it wants to access on the underlying block storage device; it only needs to send the file name / ID to the file system, which then retrieves the file path based on the file name / ID.

[0079] Common file access protocols include NFS, CIFS, or SMB, and this embodiment does not limit them in any way.

[0080] In summary, production system 10 stores production data in file format. For example, logical objects such as the order table mentioned above are converted into specific file types for storage. When the application accesses data in the order table, it still accesses the data at the file level.

[0081] Correspondingly, backup system 20 also stores backup data in file format. For example, each backup copy includes backup data of one or more files stored in production storage.

[0082] The following section continues using application server 1011 as an example to illustrate how application server 1011 accesses production data and backup data at the file level in this embodiment of the application.

[0083] See Figure 5A As shown, Figure 5A This is a schematic diagram of the software architecture of a possible instant recovery system provided in an embodiment of this application. Figure 5A In the middle, the application server 1011 runs an operating system ( Figure 5A (Not shown) and applications. The execution modes of an operating system are divided into kernel mode (privileged mode) and user mode (non-privileged mode). Applications usually run in user mode (also known as user space). The data processing system 50 provided in this embodiment can run in kernel mode, and applications can perform file reading, writing and other operations through the system 50.

[0084] like Figure 5AAs shown, the data processing system 50 includes a receiving module 500, an I / O driver module 501, a data migration module 502, and a processing module 503. The receiving module 500, the I / O driver module 501, the data migration module 502, and the processing module 503 are all kernel modules, that is, they all run in kernel mode.

[0085] The receiving module 500 is used to provide a unified file access interface for multiple applications in kernel mode, such as a Virtual File System (VFS). This unified file access interface receives read / write requests from one or more applications running on the application server 1011.

[0086] The IO driver module 501 receives and processes read / write data requests from the application. These requests may carry a file identifier (such as a file path or file handle) and an operation type (such as open, read, write, etc.). For write requests, the IO driver module 501 writes the data to be written, as included in the write request, to the file indicated by the file identifier. For read requests, the IO driver module 501 reads data from the file indicated by the file identifier (denoted as the target file) from the production storage device 102. If there is no valid data for the target file in the production storage device 102, the IO driver module 501 reads the backup data of the target file from the backup copy in the backup system 20's virtual volume and returns it to the application.

[0087] The data migration module 502 is used to asynchronously migrate backup data from the backup copy online to the production storage device 102.

[0088] The processing module 503 is used to write data to the production storage device 102 in a block storage manner.

[0089] See Figure 5B As shown, Figure 5B A schematic diagram of the software architecture of another possible instant recovery system provided in this application embodiment.

[0090] like Figure 5B As shown, the data recovery system 50 includes a receiving module 500, an IO driver module 501, a data migration module 502, and a processing module 503. Figure 5B and Figure 5A The differences include that the receiving module 500 and the processing module 503 run in kernel mode, while the IO driver module 501 and the data migration module 502 run in user mode.

[0091] Figure 6 This is a specific example of an instant recovery system provided in the embodiments of this application.

[0092] Among them, the receiving module 500 is a virtual file system (VFS), and the processing module 503 is a filesystem-in-userspace driver (FUSE Driver).

[0093] Virtual File System (VFS) is an abstraction layer in the operating system that allows different file system implementations to be accessed in a unified way. User-space applications can interact with various file systems through the VFS interface without needing to know the specific underlying file system type, such as ext4 or NTFS. VFS hides the differences between various file systems, such as local disk file systems and network file systems, providing applications with a consistent view, including concepts such as files, directories, and permissions. Through VFS, applications can easily perform operations such as opening, reading, writing, and closing files without needing to know where the data is actually stored or what storage format it uses. It improves application portability and compatibility, enabling applications to run in different storage environments without requiring extensive modifications.

[0094] exist Figure 6 In VFS, applications can initiate access requests, such as read or write requests as mentioned above. VFS forwards the request to the appropriate file system driver based on the file identifier and operation type in the access request. If a file system implemented through the FUSE Driver is involved, VFS will forward the request to the FUSE Driver.

[0095] FUSE is a mechanism that allows non-privileged users to implement a file system in user space without modifying kernel code. With FUSE, developers can write the file system logic, while the FUSE module handles communication with the kernel's Virtual File System (VFS). This allows developers to implement a file system in user space rather than kernel space, reducing the difficulty and risk of file system development. Because development in user space avoids direct interaction with the kernel, it avoids the risk of system crashes due to kernel programming errors, and also facilitates debugging and maintenance.

[0096] Fuse Driver is a file system driver developed based on the Fuse mechanism. Fuse Driver can package various non-traditional storage sources or data processing logic into a file system and present it to users and applications. For example, Fuse Driver can virtualize network storage, cloud storage, and data files in special formats as local file systems, allowing users and applications to access data in these storage locations as if they were local files.

[0097] Figure 6System 50 in the diagram is a file system driver developed based on the FUSE mechanism. Essentially, it's a FUSE process running in user space. System 50 is registered with the FUSE Driver to handle access requests that the FUSE Driver cannot process. For example, when the FUSE Driver receives an access request requesting data that is not found in the production storage (e.g., file data is corrupted or lost in the production storage device), the FUSE Driver routes the access request to System 50 for processing. The IO driver module 501 redirects the access request to the virtual volume of the backup system 20 to perform file read / write operations. The data migration module 502 then asynchronously migrates the data from the backup copy online to the production storage. This way, when performing data recovery on the production storage, business operations do not need to be interrupted. It achieves online migration and online volume switching at the file system layer, independent of the application's own capabilities, thus achieving a general-purpose, instant recovery method.

[0098] It should be noted that, Figures 5A-6 This is merely an example; in practical applications, the software architecture of this instant recovery system may include more or fewer modules. For instance, the IO driver module 501 can be divided into a receiving module and a processing module. The receiving module performs the operation of receiving file access requests in the IO driver module 501, and the processing module performs the operation of processing access requests in the IO driver module 501. As another example, the receiving module 500 and the IO driver module 501 can be deployed in one module, and the processing module 503 and the data migration module 502 can be deployed in one module. This embodiment of the application does not limit this. It should also be noted that the above... Figures 2-4 The architecture shown is merely an example, and the embodiments of this application do not limit the system architecture, whether hardware or software, in actual applications.

[0099] The data recovery method provided in this application embodiment can be applied to various applications. When the production system 10 has a data recovery requirement, it can use the backup copy in the backup system for immediate recovery. In this method, the system 50 coordinates and processes the access request, and simultaneously initiates an online data migration from the backup copy to the production storage in the background. The application is unaware of this, realizing a universal, application-independent immediate recovery method, which significantly improves the RTO level of the backup system 20 in common application scenarios.

[0100] Next, let's apply it to... Figure 6 Taking this example, the data recovery method provided in the embodiments of this application will be described in detail.

[0101] Figure 7 This is a flowchart illustrating a data recovery method provided in an embodiment of this application. The method may include some or all of the steps in the following process, such as... Figure 7As shown, the process may include:

[0102] Step 701: Backup server 201 determines the backup copy to be used for data recovery.

[0103] Backup server 201 typically performs backups according to a predetermined schedule, such as daily, weekly, or monthly backups at specific times. Over time, it accumulates a series of backup copies generated at different points in time. In the event of data loss or corruption in production storage device 102, users (such as maintenance personnel of production system 10) can select a backup copy from a specified time point (such as the most recent one) from backup system 20 to restore the data.

[0104] Optionally, backup server 201 may provide a user-friendly interface on which the user selects the time point for the backup copy. Accordingly, backup server 201 determines the backup copy selected by the user on the user interface as the backup copy used for data recovery.

[0105] Optionally, the production system 10 determines whether data loss or corruption has occurred by monitoring the data status in the production storage device 102. For example, if the pre-stored data fingerprint and the actual data fingerprint are different, it is considered that the data in the production storage device 102 is lost or corrupted. At this time, the production system 10 prompts the user to select a backup copy.

[0106] Optionally, the backup system 20 can monitor the data status of the production storage device 102 and remind the user to select a backup copy.

[0107] Optionally, if the user does not select a backup copy, the backup server 201 may default to using a backup copy from a specified time point (such as the most recent one) as the backup copy for data recovery.

[0108] Step 702, Backup server 201 generates a virtual volume based on the determined backup copy.

[0109] A virtual volume is a logical storage unit created in the backup system 20 using software technology. It is not a real physical storage device, but rather a virtual storage unit presented to the user after abstracting and integrating the underlying physical storage resources. Typically, the backup system 20 first identifies and manages various underlying physical storage devices (i.e., backup storage devices 202), such as hard drives and disk arrays. These physical storage devices may have different capacities, performance levels, and interface types. Then, through virtual volume management software, these dispersed physical storage resources are uniformly planned and integrated to form a logical storage pool. Afterward, logical spaces of different sizes are partitioned from the storage pool; these logical spaces are virtual volumes. The size of a virtual volume can be flexibly configured according to user needs and actual application scenarios. For example, independent virtual volumes can be allocated to different backup tasks, different users, or departments. Each virtual volume can be considered an independent storage unit with its own file system and access permissions.

[0110] Specifically, the functions of a virtual volume include providing a unified storage interface: A virtual volume provides a unified storage interface for various data within the backup system 20. Regardless of the complexity of the underlying physical storage devices, the virtual volume abstracts them into a simple, manageable logical unit. This allows the backup system 20 to easily perform read and write operations on the virtual volume without needing to concern itself with the specific details of the underlying physical storage, improving the efficiency and flexibility of storage management. Its functions also include supporting multi-protocol access: For example, the virtual volume provides file access protocol interfaces such as Network File System (NFS) and Server Message Block (SMB), allowing computers with different operating systems and platforms to access data on the virtual volume over a network. NFS is commonly used for file sharing between UNIX and Linux systems, while SMB is widely used in Windows systems and is also supported by other operating systems. Through these protocol interfaces, different types of computers can easily share and access data in the backup system, achieving cross-platform data interaction and sharing.

[0111] In this embodiment, generating a virtual volume based on a backup copy means encapsulating the backup data (backup data of all files included in the backup copy) into a virtual storage volume (such as a logical volume exposed via NFS or MBS). Its content is identical to the backup data, but it appears as a "labeled disk" to the production system 10. Then, the virtual volume is connected (e.g., mounted via NFS or MBS) to the host 101, making it a storage device recognizable by the host 101.

[0112] Specifically, backup server 201 can first clone the backup copy determined in step 701 to obtain a readable and writable backup copy (denoted as the clone copy), and then generate a virtual volume based on the clone copy. Subsequently, system 50 reads or writes files in the clone copy through the virtual volume, instead of operating directly on the original backup copy. When there are abnormalities in the read / write operations on the clone copy, the original backup copy can still be obtained, thereby enhancing the security and reliability of the backup data.

[0113] In some embodiments, if the backup copy is itself a storage volume, then the virtual volume is a cloned volume obtained by cloning this storage volume.

[0114] In other embodiments, if the backup copy itself is not a storage volume, the backup server 201 needs to first create a virtual volume and then mount the files included in the backup copy to this virtual volume.

[0115] Optionally, backup server 201 may only write stub data of the files in the backup copy to the virtual volume, without writing the file content data. Stub data contains file information but not file content data (such as text, images, binary data, and other entity content).

[0116] In one example, file information includes file metadata and a pointer to the file content storage location. The file metadata includes, but is not limited to, one or more of the following: filename, path, creation / modification time, size, and hash value (such as a content data fingerprint). The file content storage location pointer records the storage location of the (backed-up) file's content data blocks in the backup storage. The backup file refers to the file included in the backup copy.

[0117] See Figure 8 As shown, the virtual volume includes a metadata storage area and a content data reference area. The metadata storage area stores stub data, such as metadata for files included in the backup copy, stored using a hierarchical directory structure (similar to a file system). The content data reference area stores file content location pointers. Content data references the original storage through these pointers, such as the storage location of data blocks included in the cloned copy within the backup storage device 201. For example, in the backup storage device 201, content data can be stored named using content data fingerprints. A content data fingerprint (typically based on a hash algorithm, such as SHA-256) is a fixed-length value that uniquely identifies the data content. File metadata can contain a mapping between content data fingerprints and file content location pointers. When searching for file content data, the corresponding file content location pointer is found based on the content data fingerprint for addressing.

[0118] Optionally, a virtual volume can contain only file metadata without pointers to the file content storage location, such as containing only a metadata storage area without a content data reference area. When searching for content data, it can be addressed directly based on the content data fingerprint.

[0119] The above design constructs a lightweight virtual volume by separating the storage of metadata and content data. On this basis, a lightweight and highly flexible instant recovery architecture is realized, which is particularly suitable for enterprise-level scenarios with stringent RTO requirements.

[0120] In an alternative approach, backup system 20 can also create virtual volumes that contain both file information and file content data.

[0121] In another alternative approach, the backup server can operate directly on a defined backup copy without creating a clone copy.

[0122] Step 703: After the backup system 20 mounts the virtual volume to the host 101, it starts the production system 10 to run the application.

[0123] In step 704, VFS501 receives read / write requests from the application and routes the read / write requests to IO driver module 501 via FUSE Driver503.

[0124] For ease of description, FUSE Driver503 will be abbreviated as FUSE Driver and VFS500 as VFS in the following text.

[0125] System 50 provides standard file operation interfaces (Portable Operating System Interface, POSIX API) to applications in host 101, such as functions like open(), read(), write(), and close(). Any application conforming to the POSIX standard can access files through these interfaces without needing to know the underlying storage details. System 50 ensures that the virtual volume is accessed in the same way as the local disk, transparent to upper-layer applications. In this way, applications do not need to adapt to the special interface of backup storage and can directly access data through the standard file API. Applications are unaware that the underlying storage is backup storage.

[0126] Applications initiate access requests (including read / write requests) via the POSIX API, including file paths. The VFS receives these access requests and can forward them to the appropriate file system driver based on the file identifier and operation type requested.

[0127] In some cases, VFS forwards file access requests to the FUSE Driver. For example:

[0128] (1) When the file system accessed by the application is of type FUSE, for example, when the file system is mounted via FUSE (e.g., via mount-t fuse or FUSE-related tools), all file / directory operations (such as opening, reading, writing, getting attributes, deleting, etc.) under the mount point will be forwarded by VFS to the FUSE Driver.

[0129] (2) Operations requiring user-space logic processing, such as: ① Permission checks and security policies: The FUSE daemon intercepts file access requests and enforces additional security and privacy policies (such as application sandboxing and permission isolation). ② File attribute and metadata processing: User space needs to customize file attributes (such as permissions and timestamps) or implement special metadata logic (such as encryption and compression). ③ Data storage logic: File data is not directly stored in the kernel file system (such as EXT4), but is managed by user-space programs (such as memory file systems, network storage, etc.). VFS forwards file access requests for these operations to FUSEDriver.

[0130] (3) Specific file system operations, such as the FUSE Driver registering a series of callbacks (such as read(), write(), readdir()), and VFS forwards the file access requests for these operations to the FUSE Driver.

[0131] In addition, other forwarding conditions are supported in the embodiments of this application, and no specific limitations are imposed.

[0132] Optionally, in this embodiment of the application, the FUSE Driver can intercept all access requests received by the VFS.

[0133] After receiving an access request from the VFS, the Fuse Driver routes the request to the IO driver module 501. The IO driver module 501 then directs the access request to the virtual volume to retrieve the data required for business operations.

[0134] These access requests can come from one application or multiple applications. For example, multiple applications may include at least a first application and a second application. The FUSE Driver can forward the received access request from the first application to the IO driver module 501, or it can forward the received access request from the second application to the IO driver module. The IO driver module 501 processes each access request.

[0135] Step 705: The IO driver module 501 processes the received access request.

[0136] Access requests include read requests and write requests. We will first introduce the processing flow of read requests.

[0137] For ease of explanation, the data requested by a read request will be referred to as the target data. For example, the processing flow for a read request may include:

[0138] Step a: When the IO driver module 501 receives a read request, it checks whether the production storage device 102 contains the target data. If it does, it proceeds to step b; otherwise, it proceeds to step c.

[0139] When production system 10 undergoes a data recovery phase due to system failure or data loss / corruption, migration module 502 migrates the data of backup files from the backup copy to production storage device 102 for data recovery. Therefore, in some cases, IO driver module 501 may not be able to find the target data in production storage device 102, possibly because the target data is lost / corrupted, meaning the target data is data to be recovered, the backup data has not yet been migrated, and the user has not updated the target data. In this case, IO driver module 501 can obtain the target data from the virtual volume (see step c).

[0140] In other cases, after the production system 10 enters the data recovery phase, the migration module 502 migrates the backup data of the target data to the production storage device 102, or the user updates the target data through the application. In this case, the IO driver module 501 can directly obtain the target data from the production storage device 102 (see step b).

[0141] In other words, after receiving a read request from the application, the IO driver module 501 can read the target data from the backup storage or the production storage.

[0142] To determine the location of the target data, in one example, the IO driver module 501 can record the migration status and address mapping relationship of the virtual volume logical address. This address mapping relationship includes the mapping between the virtual volume logical address and the physical storage address. Each backup file's data block is assigned a virtual volume logical address. If the data block has been migrated to the production storage device 102, its virtual volume logical address is mapped to the production storage physical address; otherwise, it is mapped to the backup storage physical address. Therefore, the IO driver module 501 selectively reads the target data from a specific data source (production storage or backup storage) based on this information.

[0143] For example, the IO driver module 501 translates a read request into a block-level read operation on the virtual volume. For instance, when an application calls `read(" / data / file.txt")` to request access to the file `file.txt`, the file system resolves the path, finds the file's metadata (such as an iNode), determines the logical block address (LBA) range corresponding to the file data (such as LBA1000-2000), and then the IO driver module 501 maps this LBA range to the corresponding logical block address of the virtual volume (such as V-LBA0-1000).

[0144] If the data block corresponding to logical block address V-LBA0-1000 has been migrated to production storage (e.g., production storage physical addresses 3000-4000), then the migration status of logical block address V-LBA0-1000 is "migrated," and V-LBA0-1000 is mapped to production storage physical addresses 3000-4000 in the address mapping table. If the block corresponding to logical block address V-LBA0-1000 has not been migrated and is still stored in the virtual volume (e.g., backup storage physical addresses 5000-6000), then the migration status of logical block address V-LBA0-1000 is "not migrated," and V-LBA0-1000 is mapped to backup storage physical addresses 5000-6000.

[0145] In this way, the IO driver module 501 can selectively obtain target data from backup storage or production storage based on the data migration status.

[0146] Among them, the physical address of the data block in production storage refers to the physical storage address of the database in production storage device 102, and the physical address of the database in backup storage refers to the physical storage address of the database in backup storage device 102, such as the storage address pointed to by the file content storage location pointer of the database.

[0147] If it is necessary to read target data from the backup storage, the IO driver module 501 sends a read request to the backup system 20. The read request may carry the physical address of the backup storage (such as 5000-6000) and the data block is obtained based on the physical address of the backup storage.

[0148] Optionally, the read request initiated by the IO driver module 501 may also carry only metadata such as the file path of the file to be read. The virtual volume can directly address the file based on its metadata or address the file content storage location pointer corresponding to the file's metadata to obtain the data blocks included in the backup file.

[0149] Optionally, the address mapping table above can also record only the mapping relationship between the logical block address of the migrated file and the physical address of the production storage. Files not recorded are considered as unmigrated files and are still stored in the backup storage.

[0150] Optionally, the IO driver module 501 can also combine the data migration status and dirty block marking to select which data source to retrieve data from. The dirty block marking is used to indicate whether a data block has been updated (e.g., rewritten or modified). If it has been updated, the dirty block marking is changed to "updated," and the updated data can be directly updated to the production storage. This type of data can be read from the production storage device 102. The address mapping of the dirty block is also modified to point to the physical address of the production storage. If the dirty block marking of a data block is "updated," it can be read from the production storage regardless of whether a backup of that data block has been migrated in. However, if the original version is required, it can also be read from the backup storage. If the dirty block marking is "not updated," it can be selectively read from either the production storage or the backup storage based on the data block's migration status.

[0151] If it is necessary to read target data from production storage, the IO driver module 501 will return the read request to the Fuse driver, which will then retrieve the target data from the production storage device 102.

[0152] Optionally, the target data can be the entire file or a portion of the file's data blocks. For example, a read request may carry a file identifier, the offset of the data block to be read, and its length.

[0153] Optionally, the IO driver module 501 can also read all the data from the virtual volume instead of from the production storage device 102, in which case care must be taken to ensure data consistency.

[0154] Optionally, the IO driver module 501 can also determine whether there is target data in the production storage device 102 in other ways. For example, it can check whether the pre-stored content data fingerprint and the actual content data fingerprint of the target data in the production storage device 102 are consistent. If they are consistent, it means that the production storage device 102 includes the target data. If they are inconsistent, it is determined that the production storage device 102 does not have valid data of the target data.

[0155] Optionally, the virtual volume and the production storage have the same metadata structure (such as inode table, directory structure, permission information, partition table, logical volume mapping, etc.) so that the IO driver module 501 can coordinate the data source and selectively obtain the same content data from the backup storage device 102 or the production storage device 202 according to the data migration status, dirty block marking, etc., to ensure that read requests return the latest and consistent data.

[0156] It should be noted that the read request content above is only an example. In network file system protocols (such as NFS and SMB), I / O requests can include file paths or file handles to locate files. For example, the NFS request format is READ(file_handle, offset, length), where file_handle is the file handle, generated from the file path mapping. Offset represents the offset, and length represents the length. The SMB request format is Read Request for \\server\share\folder\file.txt. No specific limitations are imposed.

[0157] Step b: The IO driver module 501 obtains the target data from the production storage device 102 and returns the target data to the application.

[0158] If the read request is triggered by terminal device 104, the application may also return the target data to terminal device 104.

[0159] Step c: The IO driver module 501 redirects the read request to the virtual volume of the backup system 20 and reads the backup data of the target data from the virtual volume.

[0160] Step d: The IO driver module 501 returns the backup data of the acquired target data to the application.

[0161] In the return path, the IO driver module 501 can first send the target data to the Fuse driver, which then returns it to the application via the VFS. If the read request is triggered by the terminal device 104, the application may also return the target data to the terminal device 104.

[0162] Step e: The IO driver module 501 asynchronously writes the backup data of the target data to the production storage device 102 to restore the target data in the production storage.

[0163] Here, asynchronous means that the operation of returning the target data to the application and the operation of writing the target data to the production storage device 102 are decoupled in time, and the two do not need to wait for each other to complete. For example, steps d and e can be executed simultaneously, or step d can be executed before step e, or step d can be executed after step e.

[0164] When writing target data to production storage device 102, IO driver module 501 sends the target data to Fusedriver, and Fusedriver writes the target data to production storage device 102.

[0165] exist Figure 6In the illustrated architecture, the IO driver module 501 sends backup data of the target data to the Fuse driver, which then writes the backup data to the production storage. Optionally, when the Fuse driver writes the backup data to the production storage device 102 (such as a hard disk), it can do so via a block storage device driver in block storage mode (see [link to documentation]). Figure 4 (The relevant introduction will not be repeated here) Write the data to the production storage device 102.

[0166] Write conflicts can be handled by using locking during the writing process.

[0167] Optionally, after the backup data of the target data is written, the migration status of the data block corresponding to the backup data is changed to "migrated in", and the corresponding address mapping relationship is modified.

[0168] Step f: Migration module 502 asynchronously migrates the data in the backup copy online to production storage device 202 (see step 706).

[0169] The migration method in this application embodiment supports online migration, meaning that the migration module 502 can asynchronously migrate backup data to production storage online. Online migration refers to data migration performed while the system is running (without service interruption), so the user is unaware of it. Offline migration, on the other hand, refers to migration performed after the system is shut down, during which service is unavailable, causing business interruption and failing to meet business requirements. Asynchronous migration means that the processing of application access requests and data migration are decoupled in time; neither needs to wait for the other to complete. While processing access requests, the backup copy data can be migrated to the production storage device 102 in the background. Therefore, there is no strict time constraint between step f and any of steps a-e; they can be executed simultaneously or sequentially, without specific limitations.

[0170] Through the above design, the physical address binding between the production system 10 and the underlying storage (production storage device 102, backup storage device 202) can be decoupled. During the data recovery process of the production system, the IO driver module 501 directs the access requests of online services to virtual volume processing, realizing an online volume switching at the file system layer. The migration module 502 asynchronously migrates the backup data in the background, realizing an online data migration at the file system layer. It supports seamless access to data during the migration process, without the application being aware of it. It enables the production system 10 to perform data recovery while running, and is a general-purpose instant recovery method that is independent of application capabilities. It has better versatility and significantly improves the RTO level of the backup system 20 in common application scenarios.

[0171] The above describes the processing flow for read requests. The following describes the processing flow for write requests:

[0172] Step A: The IO driver module 501 writes the data to be written, as indicated by the write request, to the production storage device 102.

[0173] For example, when the data to be written is the content data of a file or the metadata of a file, the IO driver module 501 writes the data to be written to the production storage device 102. Write conflicts can be handled by locking before writing.

[0174] Optionally, the write request carries a file identifier to indicate the file path. The file system parses the file path, finds the file's metadata (such as iNode), determines the virtual volume logical block address range corresponding to the data to be written, and maps the virtual volume logical block address range to the production storage physical address used to store this data after the data to be written is completed.

[0175] Optionally, after the data to be written is completed, the virtual volume logical block address of the data is marked as a dirty block.

[0176] Optionally, if the data to be written is metadata or other information of a file, the IO driver module 501 may also write the data to be written to the virtual volume and the cloned copy.

[0177] Optionally, in the above address mapping relationship, the logical block address of the data block can be used instead of the logical block address of the virtual volume.

[0178] Step B: Migration module 502 asynchronously migrates backup data from the backup copy online to production storage device 202 (see step 706).

[0179] Since the migration module 502 is executed asynchronously, there is no strict timing constraint between step B and step A. Step B and step A can be executed simultaneously, or step B can be executed first and then step A, or step A can be executed first and then step B. There is no specific restriction.

[0180] Step 706: Migration module 502 asynchronously migrates backup data to production storage.

[0181] During data migration, the migration module 502 can read the backup data to be restored randomly or in a specific order.

[0182] In one example, migration module 502 may read the data included in the backup copy (denoted as backup data) in a random read manner.

[0183] In another example, migration module 502 can read backup data in a specific order. For instance, it can read data sequentially according to the physical order in which it is stored (such as the physical or logical order of the data included in the backup copy within the storage medium). The physical order could be the block order of a tape or disk, and the logical order could be the order of entries in the backup file or the logical timestamp order, etc. Sequential reading eliminates the need for frequent addressing, making it suitable for continuous reading of large files and offering higher efficiency.

[0184] Among the above methods, the migration module 502 can also be combined with batch reading of migration data. Batch reading refers to reading multiple data blocks at once, such as reading 1MB or 1GB of data sequentially, rather than reading them one by one, thereby reducing the number of I / O operations and reducing system overhead.

[0185] Before writing the backup data of the backup file to the production storage, the migration module 502 determines whether the production storage contains valid data for the backup file. Valid data here can refer to data read and then written by the production system 10 front-end (such as terminal device 104 or an application), such as the data written in step e. Alternatively, it can refer to newly written data from the production system 10 front-end; if such data exists, it will not be written again; otherwise, the backup data will be written to the production storage. This can be determined by the migration status and dirty block marking of the backup data. If the migration status is "migrated in" or the dirty block marking is "updated," it is determined that the production storage contains valid data for the backup file, and the migration module 502 will not re-migrate the backup data. When the production storage device 102 does not contain valid data for the backup file, the backup data of the backup file is written to the production storage device 102.

[0186] exist Figure 6 In the architecture shown, when migration module 502 writes backup data to production storage, it can send the backup data to the Fuse driver, which then writes the data to the production storage device. Optionally, when the Fuse driver writes the data to production storage device 102 (such as a hard disk), it can do so via a block storage device driver in block storage mode (see [link to documentation]). Figure 4 (The relevant information will not be repeated here.) Write the data to the production storage device 102. Write conflicts can be handled by locking before writing.

[0187] Step 707: After all data in production storage 10 has been restored, IO driver module 501 switches all subsequent access requests to production storage online.

[0188] In some embodiments, after all data in the production system 10 has been restored, the IO driver module 501 will still receive read / write requests forwarded by the Fuse Driver, but will directly route the received access requests back to the Fuse Driver. The IO driver module 501 will no longer process the read / write requests, and the Fuse Driver will perform read / write operations from the production storage.

[0189] In other embodiments, after all data in the production system 10 has been restored, the backup system 20 unloads the IO driver module 501. At this time, the host 101 will revert to its original software architecture, and the Fuse Driver will switch all read / write requests from the production system 10 back to the production storage.

[0190] The complete recovery of all data in production system 10 means that the migration status of all data blocks included in the backup file in the backup copy is all migrated, or the dirty blocks of data blocks with an unmigrated status are marked as updated. This ensures that production system 10 has complete and up-to-date file data.

[0191] Through the above design, this technology provides read request services to applications based on kernel mode. In the event of data loss of any file accessed by an application in the production system, the IO driver module 501 redirects the application's read request to the backup system, retrieving the required file (such as the first file) from the backup system. This retrieved file is then returned to the application, and simultaneously written to the production storage device to restore the file. This solution can respond promptly to application read requests without pausing the application and also recovers lost files from the production storage (the first file does not need to be recovered in subsequent recovery processes, thus reducing the amount of data recovered). Therefore, this solution can restore data while running, achieving real-time recovery.

[0192] Furthermore, this technology is not tied to any specific application; the application is unaware of data recovery, essentially providing a universal recovery solution that is not tied to any application. Compared to technologies where each application provides its own recovery solution, it offers better versatility and significantly improves the RTO (Recovery Time Objective) of the backup system 20 in common application scenarios.

[0193] The methods provided by the embodiments of this application have been described above with reference to the accompanying drawings. The apparatus provided by the embodiments of this application will be described below with reference to the accompanying drawings.

[0194] Based on the same inventive concept as the method embodiments, this application also provides a data recovery system, which is used to perform the above-described... Figure 7 The methods performed in the embodiments. For example... Figure 9As shown, system 900 includes a receiving module 901, a first processing module 902, and a second processing module 903. Optionally, it also includes a data migration module 904. For example, interface module 901 includes VFS 500. The first processing module 902 is an IO driver module 501, the second processing module 903 is a FUSE Driver 503, and the data migration module 904 is a migration module 502. Specifically, in this device 900, the modules are connected through a communication path.

[0195] Receiver module 901 is used to provide a unified file access interface for multiple applications in kernel mode, receiving a first read request from a first application, which requests access to a first file; see details below. Figure 7 The description of step 704 in the method embodiment will not be repeated here.

[0196] The first processing module 902 is configured to, in response to a first read request, read backup data of the first file (denoted as the first backup file) from a backup copy of the backup system in the event of loss of the first file data in the production storage device, and return the first backup file to the first application; see details below. Figure 7 The description of step 705 in the method embodiment will not be repeated here.

[0197] The second processing module 903 is also used to write the first backup file to the production storage device. See details below. Figure 7 The description of step 705 in the method embodiment will not be repeated here.

[0198] In one optional design, the backup copy includes multiple files; a data migration module 904 is used to asynchronously migrate the multiple files included in the backup copy online to the production storage device; before writing, it determines whether valid data for the files to be migrated already exists in the production storage device. If so, the migration is not repeated. For example, if the first backup file has already been written to the production storage device, the data migration module 904 can migrate only the backup data of the files other than the first file to the production storage device. The data migration module 904 can run in kernel mode or user mode. See details... Figure 7 The description of step 706 in the method embodiment will not be repeated here.

[0199] In an optional design, when the first processing module 902 reads the first backup file from the backup copy of the backup system, it is specifically used to: read the first backup file from the virtual volume of the backup system; the virtual volume is generated based on the backup copy and mounted to the host of the production system via a file access protocol. See details... Figure 7 The descriptions of steps 701-705 in the method embodiment will not be repeated here.

[0200] In an optional design, the storage device in the backup system is a block storage device, which stores multiple data blocks included in the first file. When the first processing module 902 reads the first file from a backup copy of the backup system, it specifically performs the following steps: determining the Logical Block Address (LBA) of the first file in the virtual volume based on the metadata of the first file (or the first backup file); determining the physical block address corresponding to the LBA based on the address mapping relationship; and retrieving the multiple data blocks from the block storage device based on the physical block address. See details... Figure 7 The description of step 704 in the method embodiment will not be repeated here.

[0201] In an alternative design, the system operates in kernel mode; see [link to design]. Figure 5A As shown. Alternatively, the system runs in user mode, see [link to relevant documentation]. Figure 5B As shown. The first processing module 902 can be a fuse process running in user mode. For example, see Figure 6 As shown, in one example, the first processing module 902 is the IO driver module 501, the second processing module 902 is a module in fusedriver 503, and the data migration module 803 is the migration module 502.

[0202] In an optional design, when the second processing module 902 writes the first backup data to the production storage device, it is specifically used to write the first backup file to the production storage device in a block storage manner.

[0203] In an optional design, the receiving module 901 is further configured to receive a second read request from a second application running in the production system, the second read request being for requesting access to a second file; the first processing module 902 is configured to, in response to the second read request, read backup data of the second file (denoted as the second backup file) from the backup copy in the event that the second file is lost in the production storage device, and return the second backup file to the second application; the second processing module 903 is configured to write the second backup file to the production storage device.

[0204] In an optional design, the receiving module 901 is further configured to receive a write request sent from a first application or a second application, the write request including a third file to be written; the first processing module 902 is configured to respond to the write request and write the third file to the production storage device via the second processing module 903. See details below. Figure 7 The description of step 704 in the method embodiment will not be repeated here.

[0205] This application also provides a computing device 1000. For example... Figure 10As shown, the computing device 1000 includes a bus 1002, a processor 1004, a memory 1006, and a communication interface 1008. The processor 1004, the memory 1006, and the communication interface 1008 communicate with each other via the bus 1002. The computing device 1000 may be a server, a storage array, or a hard disk enclosure, etc. It should be understood that this application does not limit the number of processors and memories in the computing device 1000.

[0206] Bus 1002 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of representation, Figure 10 The bus 1002 may be represented by a single line, but this does not mean that there is only one bus or one type of bus. The bus 1002 may include a path for transmitting information between various components of the computing device 1000 (e.g., memory 1006, processor 1004, communication interface 1008).

[0207] The processor 1004 may include any one or more processors such as a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP).

[0208] The memory 1006 may include volatile memory, such as random access memory (RAM). The processor 1004 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid state drive (SSD), etc., without limitation.

[0209] In one implementation, see Figure 10As shown, the computing device 1000 performs the functions of the data recovery system 900. The memory 1006 stores executable program code, and the processor 1004 executes this executable program code to implement the functions of the aforementioned receiving module 901, first processing module 902, second processing module 903, and data migration module 904, thereby realizing the data recovery method. That is, the memory 1006 stores instructions for the computing device 1000 to execute the data recovery method provided in this application for use on the data processing unit side.

[0210] The communication interface 1008 uses transceiver modules such as, but not limited to, network interface cards and transceivers to enable communication between the computing device 1000 and other devices or communication networks.

[0211] Based on the above embodiments, this application also provides a computer program that, when run on a computer, causes the computer to perform... Figure 7 The illustrated embodiment provides a data recovery method.

[0212] Based on the above embodiments, this application also provides a computer-readable storage medium storing a computer program, which, when executed by a computer, causes the computer to perform... Figure 7 The illustrated embodiment provides a data recovery method. The storage medium can be any available medium accessible to a computer. For example, but not limited to, a computer-readable medium can include RAM, ROM, EEPROM, CD-ROM or other optical disc storage, disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program code having an instruction or data structure form and accessible to a computer.

[0213] Based on the above embodiments, this application also provides a chip, which is used to read a computer program stored in a memory and implement... Figure 7 The illustrated embodiment provides a data recovery method.

[0214] Based on the above embodiments, this application provides a chip system including a processor for supporting computer devices to implement... Figure 7 The illustrated embodiment provides a data recovery method. In one possible design, the chip system further includes a memory for storing programs and data necessary for the computer device. The chip system may consist of chips or may include chips and other discrete components.

[0215] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0216] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0217] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0218] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0219] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the scope of protection of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A data recovery system, characterized in that, The system includes: The receiving module is used to provide a unified file access interface for multiple applications in kernel mode, and to receive the first read request from the first application, which is used to request access to the first file; The first processing module is configured to, in response to the first read request, obtain a first backup file of the first file from the backup copy of the backup system of the production storage device in the event that the first file data is lost in the production storage device, and return the first backup file to the first application. The second processing module is also used to write the first backup file to the production storage device.

2. The system as described in claim 1, characterized in that, The first processing module runs in kernel mode, or the first processing module runs in user mode.

3. The system as described in claim 1 or 2, characterized in that, The backup copy includes backup data for multiple files; the system also includes: The data migration module is used to asynchronously migrate the backup data of other files besides the first file from the plurality of files to the production storage device when the second processing module writes the first backup file to the production storage device.

4. The system according to any one of claims 1-3, characterized in that, When the first processing module reads the first backup file of the first file from the backup copy of the backup system, it is specifically used for: The first backup file is read from a virtual volume of the backup system, the virtual volume being generated based on the backup copy and supporting file access protocols.

5. The system as described in claim 4, characterized in that, The backup copy is stored in a block storage device, which stores multiple data blocks included in the first backup file; When the first processing module reads the first backup file of the first file from the backup copy of the backup system, it is specifically used for: The logical block address (LBA) of the first file in the virtual volume is determined based on the metadata of the first file. The physical block address corresponding to the LBA is determined based on the address mapping relationship; The plurality of data blocks are obtained from the block storage device according to the physical block address.

6. The system according to any one of claims 1-5, characterized in that, The receiving module includes a user-space file system driver (fuse driver), and the first processing module is a fuse process, which runs in user space.

7. The system according to any one of claims 1-6, characterized in that, The unified file access interface is the Virtual File System (VFS).

8. The system according to any one of claims 1-7, characterized in that, The second processing module is specifically used to write the first backup file to the production storage device in a block storage manner.

9. The system according to any one of claims 1-8, characterized in that, The receiving module is further configured to receive a second read request from a second application running in the production system, the second read request being used to request access to a second file; The first processing module is configured to, in response to the second read request, if the second file is not recovered in the production storage device, read a second backup file of the second file from the backup copy and return the second backup file to the second application; The second processing module is further configured to write the second backup file to the production storage device.

10. The system according to any one of claims 1-9, characterized in that, The receiving module is further configured to receive a write request sent from the first application, the write request including a third file to be written; The first processing module is used to respond to the write request and write the third file to the production storage device through the second processing module.

11. A data recovery method, characterized in that, The method includes: In kernel mode, a first read request is received from a first application, which is used to request access to a first file. In kernel mode, a second read request from a second application is received, which is used to request access to a second file. In response to the first read request, if the first file data is lost in the production storage device, a first backup file of the first file is read from the backup copy of the backup system of the production storage device, and the first backup file is returned to the first application. In response to the second read request, in the event that the second file data is lost in the production storage device, a second backup file of the second file is read from the backup copy of the backup system of the production storage device, and the second backup file is returned to the second application; Write the first backup file to the production storage device; Write the second backup file to the production storage device.

12. The method as described in claim 11, characterized in that, The backup copy includes backup data for multiple files; The method further includes: when the first backup file and the second backup file are written to the production storage device, asynchronously migrating the backup data of other files in the plurality of files, excluding the first backup file and the second backup file, to the production system online.

13. The method as described in claim 11 or 12, characterized in that, The step of reading the first backup file from the backup copy of the backup system includes: The first backup file is read from the virtual volume of the backup system, the virtual volume being generated based on the backup copy and supporting file access protocols; The second backup file, which reads the second file from a backup copy of the backup system, includes: Read the second backup file from the virtual volume.

14. The method as described in claim 13, characterized in that, The storage device in the backup system is a block storage device, which stores multiple data blocks included in the first backup file and multiple data blocks included in the second backup file. The step of reading the first backup file from the backup copy of the backup system includes: The first logical block address (LBA) of the first backup file in the virtual volume is determined based on the metadata of the first backup file. The first physical block address corresponding to the first LBA is determined based on the address mapping relationship; The first backup file contains multiple data blocks obtained from the block storage device based on the first physical block address; The second backup file, which reads the second file from a backup copy of the backup system, includes: The second logical block address (LBA) of the second backup file in the virtual volume is determined based on the metadata of the second backup file. The second physical block address corresponding to the second LBA is determined based on the address mapping relationship; The second backup file contains multiple data blocks obtained from the block storage device based on the second physical block address.

15. The method according to any one of claims 11-14, characterized in that, The method further includes: Receive a write request from the first application, the write request including a third file to be written; In response to the write request, the third file is written to the production storage device.

16. The method according to any one of claims 11-15, characterized in that, The method further includes: The first read request and the second read request are received through the Virtual File System (VFS).

17. The method according to any one of claims 1-8, characterized in that, Writing the first backup file to the production storage device includes: writing the first backup file to the production storage device in a block storage manner; Writing the second backup file to the production storage device includes writing the second backup file to the production storage device in a block storage manner.

18. A data recovery device, characterized in that, Including processor and memory; The processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device to cause the computing device to perform the data recovery method as described in any one of claims 11-17.

19. A computer-readable storage medium, characterized in that, When the computer-readable storage medium is executed by a computing device, the computing device performs the data recovery method as described in any one of claims 11-17.

Images