NFS virtual machine mounting system and method based on storage stacking architecture

Abstract

The invention provides an NFS virtual machine mounting system and method based on a storage stacking framework. According to the invention, through the storage stacking architecture and the intelligent routing mechanism, the direct mounting recovery of the chained backup set is realized. The virtual disk synthesis module maps a logic address to a physical file in real time by using a reverse query algorithm to generate a continuous disk view; the read-write layer independently stores description files and snapshots, and guarantees original backup safety and data persistence during operation; route control is based on file type shunting operation, and read-write isolation is ensured. And finally, on the premise of not needing pre-merging and having no client agent, the recovery time is remarkably shortened, the storage redundancy is reduced, and the cross-platform compatibility is improved.

Description

Technical Field

[0001] This application relates to the field of backup chain data management, and in particular to an NFS virtual machine mounting system and method based on a storage stacking architecture. Background Technology

[0002] In modern data centers, server virtualization technology is widely used. To ensure business continuity, regular backups of virtual machines are crucial. Traditional virtual machine recovery methods typically require copying the entire data from backup storage back to production storage. This process is time-consuming, resulting in excessively long business recovery times and failing to meet the rapid recovery needs of critical business operations. To shorten business recovery time, some feasible implementations address these issues through instant recovery mechanisms. These implementations do not involve large-scale data copying; instead, they utilize standard storage protocols to directly mount backup data to the virtualization platform, thereby quickly starting the virtual machine.

[0003] For example, in instant recovery technology based on the NFS protocol, backup software stores a single, complete virtual machine disk backup file (usually a full backup format without compression or deduplication) on an NFS server, and then mounts this NFS shared directory to the virtualization host machine. The host machine can directly recognize and use this backup file to start the virtual machine.

[0004] Therefore, current virtual machine instant recovery methods do not fully support incremental backup chain data backup methods, and suffer from serious storage space waste and inflexible read / write management schemes. Consequently, the universality of data backup and the corresponding system performance need to be improved. Therefore, an NFS virtual machine mounting system and corresponding method based on storage stacking architecture are needed to solve the relevant problems. Summary of the Invention

[0005] The purpose of this application is to at least address one of the aforementioned technical deficiencies, particularly the lack of universality in data backup and the corresponding insufficient system performance in the prior art.

[0006] In a first aspect, this application provides an NFS virtual machine mounting system based on a storage stacking architecture, the system comprising:

[0007] The NFS service module is used to handle network communication and protocol parsing for NFS terminals.

[0008] The storage stacking module is used to receive file operation requests from the NFS service module, including a read-only layer and a read-write layer;

[0009] The read-only layer is used to provide a virtual disk view access interface, and the read-write layer is used to store the corresponding files during virtual machine runtime.

[0010] The virtual disk synthesis module is used to parse the target chained backup set and dynamically generate a virtual disk view to the read-only layer;

[0011] The routing control module is used to perform operation routing according to the file operation type requested by the NFS terminal, directing read operations to the virtual disk synthesis module or write operations to the read-write layer.

[0012] Secondly, this application provides a method for mounting an NFS virtual machine based on a storage stacking architecture, the method comprising:

[0013] Load backup chain metadata using the virtual disk synthesis module;

[0014] The backup chain metadata is used to record the temporal relationship between full backup files and incremental backup files, as well as the data block index.

[0015] Virtual machine disk description files are created at the read-write layer using the storage stacking module;

[0016] The storage stacking module includes a read-only layer and a read-write layer.

[0017] The routing control module performs route splitting based on the file operation type requested by the NFS terminal:

[0018] If the file operation type is a read operation, the data query is directed to the virtual disk synthesis module.

[0019] If the file operation type is a write operation, then physical storage is performed at the read-write layer.

[0020] As an optional implementation, the virtual disk synthesis module performs data queries in the following specific ways:

[0021] Parse the logical offset and data length in the read request;

[0022] Based on the logical offset and the data length, the physical location of the target data block is queried by going back step by step from the node of the latest incremental backup file, and the target data is read and returned from the physical location.

[0023] As an optional implementation, the step of querying the physical location of the target data block by traversing back from the node of the latest incremental backup file according to the logical offset and the data length includes:

[0024] Check whether the difference data block index table at the node of the latest incremental backup file includes the target data block;

[0025] If the target data block is included, the physical offset is calculated based on the logical offset and the data length to determine the physical location of the target data block;

[0026] If the target data block is not included, iterate through the previous level backup file until the full backup file is queried. At the backup node corresponding to the target data block, calculate the physical offset based on the logical offset and the data length to determine the physical location of the target data block.

[0027] As an optional implementation, the routing offloading includes:

[0028] When the target file type for a file operation is a disk data file identifier, execute the read operation route;

[0029] When the target file type is a virtual machine description file identifier or a snapshot file identifier, a write operation route is executed.

[0030] As an optional implementation, the step of creating a virtual machine disk description file at the read / write layer through the storage stacking module includes:

[0031] Based on the backup chain metadata, create a virtual disk view in the read-only layer;

[0032] Create a virtual machine disk description file pointing to the virtual disk view in the read / write layer;

[0033] The virtual machine disk description file includes a logical reference to a read-only layer virtual disk view and preset parameter identifiers. The virtual machine disk description file and the virtual disk view are integrated to form a virtual disk, which is used to isolate virtual machine operations from the physical location of actual files.

[0034] As an optional implementation, the method further includes storage optimization, specifically including:

[0035] When the backup chain depth reaches the preset depth threshold, merge the earliest incremental file into the full file.

[0036] Update the time sequence relationships and data block indexes in the backup chain metadata;

[0037] Release the storage space of the merged files.

[0038] Thirdly, this application provides an NFS virtual machine mounting device based on a storage stacking architecture, the device comprising:

[0039] The processing module is used to load backup chain metadata through the virtual disk synthesis module;

[0040] The backup chain metadata is used to record the temporal relationship between full backup files and incremental backup files, as well as the data block index.

[0041] The processing module is also used to create virtual machine disk description files at the read / write layer through the storage stacking module;

[0042] The storage stacking module includes a read-only layer and a read-write layer.

[0043] The processing module is also used to perform route splitting based on the file operation type requested by the NFS terminal through the routing control module:

[0044] If the file operation type is a read operation, the data query is directed to the virtual disk synthesis module.

[0045] If the file operation type is a write operation, then physical storage is performed at the read-write layer.

[0046] Fourthly, this application provides a computer device including one or more processors and a memory storing computer-readable instructions that, when executed by the one or more processors, perform the steps of the method described in the second aspect.

[0047] Fifthly, this application provides a storage medium storing computer-readable instructions that, when executed by one or more processors, cause the one or more processors to perform the steps of the method described in the second aspect.

[0048] As can be seen from the above technical solutions, the embodiments of this application have the following advantages:

[0049] Based on any of the above embodiments, this application proposes an innovative storage stacking architecture. A read-only layer and a read-write layer are constructed on the server side. A virtual disk synthesis module parses the metadata of the chained backup set and dynamically generates virtual disk views in the read-only layer. The routing control module intelligently distributes requests based on file identifier types: read operations are performed by the synthesis module through reverse lookup, while write operations are directly stored in the read-write layer. This design achieves three core effects: First, it enables instant recovery of the chained backup set: the dynamic synthesis engine converts the incremental chain into a continuous virtual disk view in real time, allowing virtual machines to start without waiting for backup merging, significantly shortening recovery time; second, it ensures data security and persistence: the read-write layer independently stores virtual machine description files and runtime incremental data, ensuring that the virtual machine's state is not lost after shutdown, and the original backup data is protected from modification by the read-only layer; third, it achieves agentless cross-platform compatibility: description files conforming to virtualization platform specifications are dynamically generated in the read-write layer, requiring only a standard network file system protocol for mounting by the client, without the need for additional drivers. Furthermore, an incremental merging mechanism is triggered by a backup chain depth threshold to optimize storage efficiency and maintain query performance. The overall solution significantly improves recovery efficiency and resource utilization while ensuring the integrity of backup data. Attached Figure Description

[0050] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0051] Figure 1 A flowchart illustrating an NFS virtual machine mounting method based on a storage stacking architecture provided in one embodiment of this application;

[0052] Figure 2 This is an internal structural diagram of a computer device provided in an embodiment of this application. Detailed Implementation

[0053] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0054] First, let's explain the important terms and concepts that may be involved in this application:

[0055] Virtual Machine (VM): A complete computer system simulated by software, possessing full hardware system functionality and running in a completely isolated environment.

[0056] Virtualization host (Hypervisor / Host): such as VMware ESXi, KVM, etc., is the underlying software, firmware or hardware used to create and run virtual machines.

[0057] Instant Recovery: A data recovery technology that quickly launches applications or virtual machines by directly mounting backup data to the production system without waiting for the data to be fully copied back to production storage.

[0058] Recovery Time Objective (RTO): The maximum time required for an information system or business function to recover from a shutdown to full operational capability after a disaster. Real-time recovery technologies aim to significantly shorten RTO.

[0059] Backup Chain: The product of a backup strategy, typically consisting of an initial full backup file and one or more subsequent incremental or differential backup files.

[0060] Network File System (NFS): A distributed file system protocol that allows computers on a network to share resources and files over a TCP / IP network, just like accessing local files.

[0061] File System Abstraction Layer (FSAL): A pluggable module in NFS server software such as NFS-Ganesha, used to translate NFS protocol operations (such as read, write, and lookup) into operations for specific backend storage systems. This invention is an innovative implementation at the FSAL level.

[0062] VMDK: A virtual disk file format developed for virtualization products, typically consisting of a descriptor file (.vmdk) and a data file (-flat.vmdk).

[0063] Logical Offset: The byte offset within a file, calculated from the beginning of the file. This is the address seen from the perspective of the upper-level application.

[0064] Physical Offset: The byte offset of data within the actual storage medium or physical file.

[0065] In modern data centers, server virtualization technologies (such as VMware vSphere / ESXi, KVM, etc.) are widely used. To ensure business continuity, regular backups of virtual machines are crucial. Traditional virtual machine recovery methods typically require completely copying the data from backup storage back to production storage. This process is time-consuming, resulting in excessively long Recovery Time Objectives (RTOs) and failing to meet the rapid recovery needs of critical business operations.

[0066] To shorten the Real-Time Objective (RTO), the industry has developed "Instant Recovery" technology. Its core idea is to avoid large-scale data replication and instead use standard storage protocols (such as NFS or iSCSI) to directly mount backup data to the virtualization platform, thereby quickly starting the virtual machine. Among these, instant recovery technology based on the NFS protocol has become a common approach due to its simple configuration and good compatibility.

[0067] The working principle of instant recovery technology based on the NFS protocol is as follows: The backup software stores a single, complete virtual machine disk backup file (usually an uncompressed and deduplicated full backup format) on an NFS server, and then mounts this NFS shared directory to a virtualization host such as ESXi. The host can directly recognize and use this backup file to start the virtual machine.

[0068] However, these feasible implementation methods have the following drawbacks or shortcomings:

[0069] Inefficient support for incremental backup chains: Most existing technologies rely on a single, complete disk backup file. However, in real-world backup scenarios, to save backup time and storage space, a chained backup strategy of "one full backup + multiple incremental / differential backups" is commonly used. Existing technologies cannot directly utilize this backup chain composed of multiple discrete files for instant recovery; it must first undergo a time-consuming data merging process to pre-combine them into a single full file, which contradicts the original intention of "instant" recovery.

[0070] Significant waste of storage space: Due to the heavy reliance on full backup files, the backup storage needs to retain a large number of uncompressed and deduplicated complete data copies, resulting in a serious waste of storage space.

[0071] Inflexible read / write management schemes and weak data persistence capabilities: Some simple implementations set the entire NFS share to read-only to protect the original backup files. In this approach, write operations performed during virtual machine startup cannot be saved, resulting in the loss of all changed data after the virtual machine shuts down, limiting application scenarios. Other solutions, while providing writable capabilities, typically redirect write operations to other storage locations, making their implementation more complex and lacking a clear, unified hierarchical management model.

[0072] In summary, three issues need to be addressed: First, existing NFS instant recovery technologies cannot directly utilize space-efficient chained backup sets (full + incremental), resulting in time-consuming data synthesis before recovery or reliance on inefficient full backups. This significantly reduces the flexibility and storage economy of instant recovery. Second, existing technologies lack a simple and efficient mechanism to separate read-only access to backup data from read / write access to runtime data. This makes it difficult to persistently store incremental data during virtual machine runtime while protecting the security of the original backup data. Third, existing technologies are not flexible enough in encapsulating the underlying backup data into a standard virtual disk format. Due to the simple processing model, it is difficult to dynamically generate disk descriptor files adapted to different virtualization platforms (such as VMware vSphere, KVM) within the same share, limiting the cross-platform application capabilities of the solution.

[0073] Based on this, this application proposes a virtual machine real-time mounting and recovery method that integrates dynamic parsing of backup chains and hierarchical storage. Through a custom NFS file system adaptation layer (FSAL), upon receiving a read request, data blocks from multiple chained backup files can be dynamically merged into a unified, read-only virtual disk file view in real time. Simultaneously, by stacking a read-write storage layer, not only can virtual machine disk descriptor files be created and written on this view to be encapsulated into a specific format (such as VMDK), but all incremental data generated during virtual machine operation (such as snapshot files) can also be persistently stored in this read-write layer. Thus, efficient, flexible, and persistent real-time recovery of chained backup sets is achieved without data pre-synthesis or sacrificing backup data security.

[0074] In summary, the technical concept of this application lies in proposing an innovative storage stacking architecture: a read-only layer and a read-write layer are constructed on the server side. A virtual disk synthesis module parses the metadata of the chained backup set and dynamically generates virtual disk views in the read-only layer. The routing control module intelligently distributes requests based on file identifier types: read operations are performed by the synthesis module through reverse lookup, while write operations are directly stored in the read-write layer. This design achieves three core effects: First, it enables instant recovery of the chained backup set: the dynamic synthesis engine converts the incremental chain into a continuous virtual disk view in real time, allowing virtual machines to start without waiting for backup merging, significantly shortening recovery time; second, it ensures data security and persistence: the read-write layer independently stores virtual machine description files and runtime incremental data, ensuring that the virtual machine's state is not lost after shutdown, and the original backup data is protected from modification by the read-only layer; third, it achieves agentless cross-platform compatibility: description files conforming to virtualization platform specifications are dynamically generated in the read-write layer, requiring only a standard network file system protocol for mounting by the client, without the need for additional drivers. Furthermore, an incremental merging mechanism is triggered by a backup chain depth threshold to optimize storage efficiency and maintain query performance. The overall solution significantly improves recovery efficiency and resource utilization while ensuring the integrity of backup data.

[0075] The methods provided in this application will be described in detail below based on the corresponding implementation methods in some practical application scenarios.

[0076] First, this application provides an NFS virtual machine mounting system based on a storage stacking architecture, the system comprising:

[0077] The NFS service module is used to handle network communication and protocol parsing for NFS terminals.

[0078] The storage stacking module is used to receive file operation requests from the NFS service module, including a read-only layer and a read-write layer;

[0079] The read-only layer is used to provide a virtual disk view access interface, and the read-write layer is used to store the corresponding files during virtual machine runtime.

[0080] The virtual disk synthesis module is used to parse the target chained backup set and dynamically generate a virtual disk view to the read-only layer;

[0081] The routing control module is used to perform operation routing according to the file operation type requested by the NFS terminal, directing read operations to the virtual disk synthesis module or write operations to the read-write layer.

[0082] Specifically, this application provides a virtual machine instant recovery system and method, the core of which is to build a converged storage NFS server that supports storage stacking. The system is deployed on a backup server and provides an NFS share to the outside world. Virtualization hosts (such as ESXi) connect to this share as NFS clients.

[0083] The NFS service module uses a standard NFS protocol service program (such as NFS-Ganesha) to handle network communication and protocol parsing from NFS clients.

[0084] Storage Stacking Module: This is one of the core components of this invention, serving as a File System Adaptation Layer (FSAL) implementation for the NFS service. Logically, this module "stacks" two different storage sources together, presenting a unified directory view to the outside world.

[0085] The bottom layer (read-only layer): Data is provided by the "Virtual Disk Composition Module". This layer is responsible for presenting a large, read-only virtual disk data file (e.g., disk-flat.vmdk).

[0086] Upper layer (read / write layer): A regular directory pointing to the server's local file system. This layer is used to store all files that need to be written to or modified.

[0087] Virtual disk composition module (Image_Chain_Reader): This is another core component of the invention, responsible for providing data to the read-only layer. It does not actually store a complete disk file, but rather dynamically generates data based on requests.

[0088] Input: One or more chained backup files (e.g., a .full full backup file and multiple .inc incremental backup files) and their metadata.

[0089] Output: A standard block device read interface (such as pread) for use by the upper-layer storage stacking module.

[0090] Internal working principle: This module achieves the function of converting scattered backup chains into a unified disk view in real time through the following steps:

[0091] a. Metadata Loading and Parsing: During initialization, the module loads and parses the metadata of the specified backup chain. The metadata records the time sequence of each backup file (full and incremental), as well as the change information (data block index list) of which data blocks are contained in each incremental backup file.

[0092] b. Receiving read requests: When the upper-layer module (storage stack module) needs to read data, it will call the read interface of the module and pass in a read request for a logical disk. The request includes the logical offset and the read length.

[0093] c. Mapping from Logical Address to Physical Address: This is the core algorithm of the module. For a requested logical offset, the module starts from the latest incremental backup point and performs a reverse lookup along the backup chain to the oldest full backup point. It checks the metadata of the current incremental backup point to determine if the required data block exists in that backup point. If it exists, it determines that the data block is located in this physical backup file and calculates its physical offset; if it does not exist, it continues to query the previous, older backup point, and so on, until the required data block is found in a backup file (which will eventually be in the full backup file).

[0094] d. Data Reading and Return: Once the physical backup file and physical offset of the data block are located, the module reads the requested length of data from the file and returns it to the upper-level caller.

[0095] e. Shielding Complexity: Through the steps described above, this module completely shields the upper-layer caller from the complex structure of the underlying backup chain. The upper-layer module sees a continuous, complete virtual disk image, which can be randomly accessed like a regular file.

[0096] Requests from the NFS client (ESXi) first reach the NFS service module, which then passes file operation requests (such as LOOKUP, READ, WRITE, CREATE) to the storage stack module. The storage stack module, based on the request type and target file, decides whether to route the request to the lower-level virtual disk compositing module (for read operations on read-only data files) or to the upper-level local file system directory (for read, write, or create operations on other files). This routing process can be accomplished by the routing control module, which can be a standalone system component or a functional module integrated into the storage stack module or the NFS service module.

[0097] This implementation uses a storage stacking architecture with separate read-only and read-write layers. The virtual disk merging module dynamically generates a virtual view of the chained backup set in the read-only layer, while the routing control module intelligently routes operations based on file operation type: read operations are handled by the merging module in real-time parsing of the backup chain data and returning results, while write operations are directed to independent storage in the read-write layer. This architecture allows virtual machines to directly mount the original backup data and start without pre-merging the backup chain, avoiding redundant storage of full copies. Simultaneously, by persisting runtime incremental data in the read-write layer, the security of the original backup and the preservation of runtime state are ensured, significantly shortening recovery time and improving storage efficiency.

[0098] Figure 1 This is a flowchart illustrating an NFS virtual machine mounting system and method based on a storage stacking architecture provided in one embodiment of this application, as shown below. Figure 1 As shown, this application provides a method for mounting an NFS virtual machine based on a storage stacking architecture, the method comprising:

[0099] S101. Load backup chain metadata through the virtual disk synthesis module;

[0100] The backup chain metadata is used to record the temporal relationship between full backup files and incremental backup files, as well as the data block index.

[0101] S102. Create a virtual machine disk description file at the read / write layer through the storage stacking module;

[0102] The storage stacking module includes a read-only layer and a read-write layer.

[0103] S103. The routing control module performs route splitting based on the file operation type requested by the NFS terminal:

[0104] If the file operation type is a read operation, the data query is directed to the virtual disk synthesis module.

[0105] If the file operation type is a write operation, then physical storage is performed at the read-write layer.

[0106] This implementation loads backup chain metadata through a virtual disk compositing module and creates a virtual machine disk description file at the read / write layer as the access entry point. The routing control module distributes traffic according to operation type: read requests are located by the compositing module through reverse traversal from the latest incremental node and the data is returned; write requests are directly stored by the read / write layer. This design dynamically transforms the dispersed backup chain into a continuous virtual disk view, allowing the virtual machine to start without waiting for data compositing. Simultaneously, by independently saving runtime incremental files at the read / write layer, physical isolation between the original backup and newly added data is achieved, balancing instant recovery and data persistence capabilities.

[0107] As an optional implementation, the virtual disk synthesis module performs data queries in the following specific ways:

[0108] Parse the logical offset and data length in the read request;

[0109] Based on the logical offset and the data length, the physical location of the target data block is queried by going back step by step from the node of the latest incremental backup file, and the target data is read and returned from the physical location.

[0110] This implementation parses the logical offset and data length of the read request, and then queries the target data block in reverse order from the latest incremental backup node: if the difference index table of the current incremental file contains the target block, the physical offset is calculated directly for reading; otherwise, the previous backups are iteratively queried until the full file is accessed. This process ensures that the latest version of the data is always returned, shielding the physical dispersion of the backup chain from the impact on upper-layer access, allowing the virtual machine to perceive only a single contiguous disk view, thus improving read efficiency and real-time performance.

[0111] As an optional implementation, the step of querying the physical location of the target data block by traversing back from the node of the latest incremental backup file according to the logical offset and the data length includes:

[0112] Check whether the difference data block index table at the node of the latest incremental backup file includes the target data block;

[0113] If the target data block is included, the physical offset is calculated based on the logical offset and the data length to determine the physical location of the target data block;

[0114] If the target data block is not included, iterate through the previous level backup file until the full backup file is queried. At the backup node corresponding to the target data block, calculate the physical offset based on the logical offset and the data length to determine the physical location of the target data block.

[0115] This implementation prioritizes checking the difference index table of the latest incremental node in reverse queries. If a match is found, the physical location is determined; otherwise, the query iterates forward to the entire file. This mechanism optimizes the query path for frequently accessed, up-to-date data, avoids unnecessary traversal of redundant nodes, and relies on block-level indexes in metadata to accurately locate data, reducing disk addressing overhead and thus improving the response speed of dynamic synthesis and the overall system efficiency.

[0116] As an optional implementation, the routing offloading includes:

[0117] When the target file type for a file operation is a disk data file identifier, execute the read operation route;

[0118] When the target file type is a virtual machine description file identifier or a snapshot file identifier, a write operation route is executed.

[0119] This implementation achieves precise routing based on file identifier type: if the target file is a disk data file identifier, read operations are directed to the synthesis module; if it is a virtual machine description file identifier or snapshot file identifier, write operations are directed to the read-write layer. By identifying file type, it distinguishes between read-only access to backup data and runtime file read-write operations, ensuring the original backup chain is not tampered with. It also supports the dynamic generation and modification of virtual machine configuration files, enhancing system security and flexibility.

[0120] As an optional implementation, the step of creating a virtual machine disk description file at the read / write layer through the storage stacking module includes:

[0121] Based on the backup chain metadata, create a virtual disk view in the read-only layer;

[0122] Create a virtual machine disk description file pointing to the virtual disk view in the read / write layer;

[0123] The virtual machine disk description file includes a logical reference to a read-only layer virtual disk view and preset parameter identifiers. The virtual machine disk description file and the virtual disk view are integrated to form a virtual disk, which is used to isolate virtual machine operations from the physical location of actual files.

[0124] This implementation dynamically synthesizes a virtual disk view at the read-only layer, while simultaneously generating a virtual machine disk description file containing logical references and platform parameter identifiers at the read-write layer. These two elements are integrated to form a standard virtual disk format, allowing the virtualization platform to directly recognize and mount it. This design masks the physical storage location of backup data through logical references, achieving cross-platform compatibility without requiring modifications to client protocols or drivers.

[0125] As an optional implementation, the method further includes storage optimization, specifically including:

[0126] When the backup chain depth reaches the preset depth threshold, merge the earliest incremental file into the full file.

[0127] Update the time sequence relationships and data block indexes in the backup chain metadata;

[0128] Release the storage space of the merged files.

[0129] This implementation merges the earliest incremental file into the full file when the backup chain depth reaches a preset value, updates the temporal relationship and block index in the metadata, and releases the space of the merged file. This mechanism avoids the decrease in query efficiency caused by an excessively long backup chain, reduces the number of incremental nodes by periodically merging, accelerates the dynamic synthesis process, and reclaims storage resources to maintain the long-term operating performance and storage economy of the system.

[0130] The various implementation methods of this application can be combined and implemented, thereby illustrating the working process of this application using a typical scenario of a virtual machine being restored from a backup set and a snapshot being created as an example:

[0131] The first step is the initialization process, which is used to present NFS shares:

[0132] The system administrator specifies a chained backup set (e.g., vm-backup.full, vm-backup-1.inc, vm-backup-2.inc) and a local directory (e.g., / data / write_layer) for storing incremental data as input.

[0133] The converged storage NFS server starts up. The storage stacking module begins operation.

[0134] It uses the / data / write_layer directory as a read-write upper layer.

[0135] It initializes the virtual disk compositing module and loads the specified backup chain metadata. Then, it "creates" a virtual, read-only large file, such as vm-disk-flat.vmdk, out of thin air in the rendered NFS shared root directory. This file is logically the same size as the original virtual machine disk, but does not occupy actual storage space.

[0136] The system automatically creates a small text file named vm-disk.vmdk in the read / write layer (i.e., the / data / write_layer directory). This is a VMDK descriptor file whose contents point to the virtual vm-disk-flat.vmdk file.

[0137] Ultimately, when the ESXi host mounts this NFS share, it will see a directory containing vm-disk.vmdk and vm-disk-flat.vmdk. The ESXi storage system will correctly recognize these two files as a usable, complete VMDK virtual disk.

[0138] Virtual machine startup and data retrieval:

[0139] In vCenter / ESXi, users register and start virtual machines using the vm-disk.vmdk file on this NFS share.

[0140] When the virtual machine operating system starts, it needs to read data from the boot sector. ESXi sends a read request (READ operation) to the NFS server for the vm-disk-flat.vmdk file, which includes the logical offset and length.

[0141] The request reaches the storage stack module via the NFS service module. Since the target is a read-only flat file, the request is forwarded to the virtual disk compositing module.

[0142] The virtual disk compositing module executes its internal workings (i.e., steps a through e detailed in Section 4.1), completes the mapping from logical addresses to physical addresses, reads data blocks from the correct physical backup file (whether full or incremental), and returns the data.

[0143] The entire process is completely transparent to ESXi, which thinks it is reading data from a plain -flat.vmdk file.

[0144] Virtual machine data writing and persistence:

[0145] To make the virtual machine writable, the administrator creates a VMware snapshot of it before starting the virtual machine.

[0146] ESXi will perform a snapshot creation operation, which will create a new incremental disk file (such as vm-disk-000001.vmdk) in the NFS shared directory.

[0147] The CREATE and WRITE operations are passed from the NFS service module to the storage stack module. Since this is not for a read-only flat file, the operation is routed to the read-write layer, and the vm-disk-000001.vmdk file is actually created in the server's / data / write_layer directory.

[0148] After that, all write operations during the virtual machine's runtime will be written to this snapshot file.

[0149] When a virtual machine is shut down or unloaded, all runtime changes are persisted because the snapshot file vm-disk-000001.vmdk is fully preserved in the read-write layer directory. The next time the virtual machine is reloaded, it will restore from the snapshot point, maintaining continuity of its working state.

[0150] Therefore, this application achieves the following improvements:

[0151] This invention enables direct and immediate recovery of chained backup sets, significantly improving recovery efficiency and storage space utilization. Through a virtual disk merging module, it directly utilizes a chained backup set containing full and incremental backups for recovery without prior data merging or conversion. This not only reduces recovery preparation time from hours to minutes but also allows backup storage to continue employing a space-efficient incremental backup strategy, avoiding the need to retain redundant full backup copies for immediate recovery, thus greatly saving storage costs.

[0152] Through an innovative read-write layered model, reliable persistence of virtual machine runtime data is achieved. This invention logically separates read-only raw backup data from read-write incremental data. All virtual machine write operations are directed to the read-write layer and physically saved in the form of snapshots. This completely solves the major defect in existing technologies where data is lost once the restored virtual machine is shut down, greatly expanding the application scenarios of instant recovery technology and enabling it to handle complex tasks requiring long-term operation and state maintenance, such as development testing, business drills, and sandbox analysis.

[0153] This invention enhances format compatibility and cross-platform capabilities, enabling seamless integration with virtualization platforms. Based on the file-level NFS protocol, it allows for the flexible creation and customization of disk descriptor files (such as VMware's .vmdk) conforming to specific platform specifications in the upper-level readable and writable directory. This capability allows underlying, format-independent backup data to be perfectly encapsulated into the virtualization platform's native disk format, thereby fully utilizing advanced features such as virtual machine snapshots provided by the platform. This achieves deeper integration and better compatibility than block device-based (iSCSI RDM) solutions.

[0154] Employing a standard protocol, this solution enables agentless and non-intrusive deployment. The entire solution is implemented on the server side; clients (virtualized host machines) only need a standard NFS client to connect, without requiring the installation of any proprietary drivers or agent programs. This ensures high compatibility and stability, reduces deployment and maintenance complexity, and avoids potential risks associated with kernel drivers.

[0155] This application also provides an NFS virtual machine mounting device based on a storage stacking architecture, the device comprising:

[0156] The processing module is used to load backup chain metadata through the virtual disk synthesis module;

[0157] The backup chain metadata is used to record the temporal relationship between full backup files and incremental backup files, as well as the data block index.

[0158] The processing module is also used to create virtual machine disk description files at the read / write layer through the storage stacking module;

[0159] The storage stacking module includes a read-only layer and a read-write layer.

[0160] The processing module is also used to perform route splitting based on the file operation type requested by the NFS terminal through the routing control module:

[0161] If the file operation type is a read operation, the data query is directed to the virtual disk synthesis module.

[0162] If the file operation type is a write operation, then physical storage is performed at the read-write layer.

[0163] This implementation loads backup chain metadata through a virtual disk compositing module and creates a virtual machine disk description file at the read / write layer as the access entry point. The routing control module distributes traffic according to operation type: read requests are located by the compositing module through reverse traversal from the latest incremental node and the data is returned; write requests are directly stored by the read / write layer. This design dynamically transforms the dispersed backup chain into a continuous virtual disk view, allowing the virtual machine to start without waiting for data compositing. Simultaneously, by independently saving runtime incremental files at the read / write layer, physical isolation between the original backup and newly added data is achieved, balancing instant recovery and data persistence capabilities.

[0164] As an optional implementation, the specific method by which the processing module performs data querying through the virtual disk synthesis module includes:

[0165] Parse the logical offset and data length in the read request;

[0166] Based on the logical offset and the data length, the physical location of the target data block is queried by going back step by step from the node of the latest incremental backup file, and the target data is read and returned from the physical location.

[0167] This implementation parses the logical offset and data length of the read request, and then queries the target data block in reverse order from the latest incremental backup node: if the difference index table of the current incremental file contains the target block, the physical offset is calculated directly for reading; otherwise, the previous backups are iteratively queried until the full file is accessed. This process ensures that the latest version of the data is always returned, shielding the physical dispersion of the backup chain from the impact on upper-layer access, allowing the virtual machine to perceive only a single contiguous disk view, thus improving read efficiency and real-time performance.

[0168] As an optional implementation, the specific method by which the processing module queries the physical location of the target data block by traversing back from the node of the latest incremental backup file according to the logical offset and the data length includes:

[0169] Check whether the difference data block index table at the node of the latest incremental backup file includes the target data block;

[0170] If the target data block is included, the physical offset is calculated based on the logical offset and the data length to determine the physical location of the target data block;

[0171] If the target data block is not included, iterate through the previous level backup file until the full backup file is queried. At the backup node corresponding to the target data block, calculate the physical offset based on the logical offset and the data length to determine the physical location of the target data block.

[0172] This implementation prioritizes checking the difference index table of the latest incremental node in reverse queries. If a match is found, the physical location is determined; otherwise, the query iterates forward to the entire file. This mechanism optimizes the query path for frequently accessed, up-to-date data, avoids unnecessary traversal of redundant nodes, and relies on block-level indexes in metadata to accurately locate data, reducing disk addressing overhead and thus improving the response speed of dynamic synthesis and the overall system efficiency.

[0173] As an optional implementation, the processing module performs routing and traffic splitting in the following ways:

[0174] When the target file type for a file operation is a disk data file identifier, execute the read operation route;

[0175] When the target file type is a virtual machine description file identifier or a snapshot file identifier, a write operation route is executed.

[0176] This implementation achieves precise routing based on file identifier type: if the target file is a disk data file identifier, read operations are directed to the synthesis module; if it is a virtual machine description file identifier or snapshot file identifier, write operations are directed to the read-write layer. By identifying file type, it distinguishes between read-only access to backup data and runtime file read-write operations, ensuring the original backup chain is not tampered with. It also supports the dynamic generation and modification of virtual machine configuration files, enhancing system security and flexibility.

[0177] As an optional implementation, the specific method by which the processing module creates virtual machine disk description files at the read / write layer through the storage stacking module includes:

[0178] Based on the backup chain metadata, create a virtual disk view in the read-only layer;

[0179] Create a virtual machine disk description file pointing to the virtual disk view in the read / write layer;

[0180] The virtual machine disk description file includes a logical reference to a read-only layer virtual disk view and preset parameter identifiers. The virtual machine disk description file and the virtual disk view are integrated to form a virtual disk, which is used to isolate virtual machine operations from the physical location of actual files.

[0181] This implementation dynamically synthesizes a virtual disk view at the read-only layer, while simultaneously generating a virtual machine disk description file containing logical references and platform parameter identifiers at the read-write layer. These two elements are integrated to form a standard virtual disk format, allowing the virtualization platform to directly recognize and mount it. This design masks the physical storage location of backup data through logical references, achieving cross-platform compatibility without requiring modifications to client protocols or drivers.

[0182] As an optional implementation, the processing module is also used for storage optimization, specifically including:

[0183] When the backup chain depth reaches the preset depth threshold, merge the earliest incremental file into the full file.

[0184] Update the time sequence relationships and data block indexes in the backup chain metadata;

[0185] Release the storage space of the merged files.

[0186] This implementation merges the earliest incremental file into the full file when the backup chain depth reaches a preset value, updates the temporal relationship and block index in the metadata, and releases the space of the merged file. This mechanism avoids the decrease in query efficiency caused by an excessively long backup chain, reduces the number of incremental nodes by periodically merging, accelerates the dynamic synthesis process, and reclaims storage resources to maintain the long-term operating performance and storage economy of the system.

[0187] It should be noted that the division of the various modules in the above device is merely a logical functional division. In actual implementation, they can be fully or partially integrated into a single physical entity, or they can be physically separated. Furthermore, these modules can be implemented entirely in software via processing element calls; they can be fully implemented in hardware; or some modules can be implemented by processing element calls to software, while others are implemented in hardware. For example, a processing module can be a separate processing element, or it can be integrated into a chip within the device. Alternatively, it can be stored as program code in the device's memory, and its functions can be called and executed by a processing element. The implementation of other modules is similar. Moreover, these modules can be fully or partially integrated together, or they can be implemented independently. The processing element here can be an integrated circuit with signal processing capabilities. During implementation, each step of the above method or each of the above modules can be completed through integrated logic circuits in the hardware of the processor element or through software instructions.

[0188] Indicatively, such as Figure 2 As shown, Figure 2 This is a schematic diagram of the internal structure of a computer device 300 provided in an embodiment of this application. The computer device 300 can be provided as a server. (Refer to...) Figure 2 The computer device 300 includes a processing component 302, which further includes one or more processors, and memory resources represented by memory 301 for storing instructions, such as application programs, that can be executed by the processing component 302. The application programs stored in memory 301 may include one or more modules, each corresponding to a set of instructions. Furthermore, the processing component 302 is configured to execute instructions to perform the methods of any of the embodiments described above.

[0189] The computer device 300 may also include a power supply component 303 configured to perform power management of the computer device 300, a wired or wireless network interface 304 configured to connect the computer device 300 to a network, and an input / output (I / O) interface 305. The computer device 300 may operate on an operating system stored in memory 301, such as Windows Server™, Mac OS X™, Unix™, Linux™, Free BSD™, or similar.

[0190] Those skilled in the art will understand that Figure 2 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0191] This application provides a storage medium storing computer-readable instructions that, when executed by one or more processors, cause the one or more processors to perform the method provided in any embodiment.

[0192] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0193] The various embodiments in this specification are described in a progressive manner. Each embodiment focuses on the differences from other embodiments. The various embodiments can be combined as needed, and the same or similar parts can be referred to each other.

[0194] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. An NFS virtual machine mounting system based on a storage stacking architecture, characterized in that, The system includes: The NFS service module is used to handle network communication and protocol parsing for NFS terminals. The storage stacking module is used to receive file operation requests from the NFS service module, including a read-only layer and a read-write layer; The read-only layer is used to provide a virtual disk view access interface, and the read-write layer is used to store the corresponding files during virtual machine runtime. The virtual disk synthesis module is used to parse the target chained backup set and dynamically generate a virtual disk view to the read-only layer; The routing control module is used to perform operation routing according to the file operation type requested by the NFS terminal, directing read operations to the virtual disk synthesis module or write operations to the read-write layer.

2. A method for mounting NFS virtual machines based on a storage stacking architecture, characterized in that, The method includes: Load backup chain metadata using the virtual disk synthesis module; The backup chain metadata is used to record the temporal relationship between full backup files and incremental backup files, as well as the data block index. Virtual machine disk description files are created at the read-write layer using the storage stacking module; The storage stacking module includes a read-only layer and a read-write layer. The routing control module performs route splitting based on the file operation type requested by the NFS terminal: If the file operation type is a read operation, the data query is directed to the virtual disk synthesis module. If the file operation type is a write operation, then physical storage is performed at the read-write layer.

3. The method according to claim 2, characterized in that, The specific methods by which the virtual disk synthesis module performs data queries include: Parse the logical offset and data length in the read request; Based on the logical offset and the data length, the physical location of the target data block is queried by going back step by step from the node of the latest incremental backup file, and the target data is read and returned from the physical location.

4. The method according to claim 3, characterized in that, The step of querying the physical location of the target data block by traversing back from the node of the latest incremental backup file according to the logical offset and the data length includes: Check whether the difference data block index table at the node of the latest incremental backup file includes the target data block; If the target data block is included, the physical offset is calculated based on the logical offset and the data length to determine the physical location of the target data block; If the target data block is not included, iterate through the previous level backup file until the full backup file is queried. At the backup node corresponding to the target data block, calculate the physical offset based on the logical offset and the data length to determine the physical location of the target data block.

5. The method according to claim 2, characterized in that, The routing and traffic splitting includes: When the target file type for a file operation is a disk data file identifier, execute the read operation route; When the target file type is a virtual machine description file identifier or a snapshot file identifier, a write operation route is executed.

6. The method according to claim 2, characterized in that, The process of creating a virtual machine disk description file at the read / write layer through the storage stacking module includes: Based on the backup chain metadata, create a virtual disk view in the read-only layer; Create a virtual machine disk description file pointing to the virtual disk view in the read / write layer; The virtual machine disk description file includes a logical reference to a read-only layer virtual disk view and preset parameter identifiers. The virtual machine disk description file and the virtual disk view are integrated to form a virtual disk, which is used to isolate virtual machine operations from the physical location of actual files.

7. The method according to any one of claims 2-6, characterized in that, The method also includes storage optimization, specifically including: When the backup chain depth reaches the preset depth threshold, merge the earliest incremental file into the full file. Update the time sequence relationships and data block indexes in the backup chain metadata; Release the storage space of the merged files.

8. An NFS virtual machine mounting device based on a storage stacking architecture, characterized in that, The device includes: The processing module is used to load backup chain metadata through the virtual disk synthesis module; The backup chain metadata is used to record the temporal relationship between full backup files and incremental backup files, as well as the data block index. The processing module is also used to create virtual machine disk description files at the read / write layer through the storage stacking module; The storage stacking module includes a read-only layer and a read-write layer. The processing module is also used to perform route splitting based on the file operation type requested by the NFS terminal through the routing control module: If the file operation type is a read operation, the data query is directed to the virtual disk synthesis module. If the file operation type is a write operation, then physical storage is performed at the read-write layer.

9. A computer device, characterized in that, The method includes one or more processors and a memory storing computer-readable instructions that, when executed by the one or more processors, perform the steps of the method as described in any one of claims 2-7.

10. A storage medium, characterized in that, The storage medium stores computer-readable instructions that, when executed by one or more processors, cause the one or more processors to perform the steps of the method as described in any one of claims 2-7.

Images