Backup method and electronic device

Abstract

The application discloses a backup method and an electronic device, relates to the technical field of data backup, and comprises the following steps: creating a target backup task to write target backup file data into a shared file cluster; updating the runtime state of the target backup task to a shared meta-database cluster; using the shared file cluster and the shared meta-database cluster to make the backup file data and the runtime state independent of a single backup node, thereby solving the problem of data loss caused by single backup node failure; when the first backup node fails, the shared meta-database cluster can quickly determine the second backup node, and the second backup node continues to execute the target backup task from the breakpoint indicated by the runtime state, thereby realizing the synchronization of the runtime state and the automatic switching of the backup node, and solving the problems of low backup efficiency and invalid resource consumption after the failure.

Description

Technical Field

[0001] This application relates to the field of data backup technology, and in particular to a backup method and electronic device. Background Technology

[0002] With the explosive growth of business data, the reliability and performance of backup systems have become crucial. Enterprises not only require that backup data not be lost, but also that business operations be able to be restored instantly in the event of a failure.

[0003] Currently, the industry commonly adopts a master-slave high-availability backup architecture based on shared disks (such as Storage Area Networks (SANs)). In this technical solution, the backup system consists of one master node and one or more slave nodes. The master node is active, handling all backup tasks and writing backup data and system metadata to the shared storage system. The slave nodes are in standby mode, continuously monitoring the health status of the master node (e.g., through a heartbeat mechanism). Once a master node failure is detected, the slave node takes over the service, mounts the shared storage, and attempts to resume interrupted backup tasks, thereby ensuring service continuity.

[0004] Although the master-slave high availability backup architecture mentioned above provides a certain level of high availability, its backup nodes typically do not hold or only asynchronously synchronize the runtime metadata of the master node (such as precise task progress, in-memory indexes, and breakpoint information). This means that when the master node fails, the backup node cannot immediately and accurately take over all task states, requiring a full scan of the storage or manual intervention. This extends the recovery time target to several minutes or even hours, and it is also highly susceptible to split-brain or data corruption during the switchover process due to inconsistent states. Summary of the Invention

[0005] This application provides a backup method and electronic device to at least solve the problems in related technologies where the backup node cannot immediately and accurately take over the task after the master node fails, requiring a full scan of the storage / manual intervention, resulting in long recovery time and the risk of split-brain or data corruption due to inconsistent status.

[0006] This application provides a backup method applied to a backup system, which includes at least multiple backup nodes and a shared metadata database cluster. The method includes: creating a target backup task, the target backup task being to write target backup file data into the shared file cluster; executing the target backup task through a first backup node of the backup system, and updating the runtime state of the target backup task to the shared metadata database cluster; determining, based on the runtime state, whether the first backup node has failed, through the shared metadata database cluster; when it is determined that the first backup node has failed, determining a second backup node from among the multiple backup nodes, and synchronizing the runtime state to the second backup node; and continuing execution of the target backup task from the breakpoint indicated by the runtime state through the second backup node.

[0007] This application also provides a backup system, including: a cluster virtual address unit, multiple backup nodes, a shared metadata cluster, and a shared file cluster; wherein, the cluster virtual address unit is used to provide a unified and unique access point for at least two backup clients; the multiple backup nodes are all active and used to process backup tasks simultaneously; the shared metadata cluster is used to store globally consistent system metadata for the multiple backup nodes, and the system metadata includes at least: system pre-configuration, client registration information, backup task definitions and policies, runtime status of backup tasks, and global lock information; the shared file cluster is used to provide a unified namespace for the multiple backup nodes and is used to store target backup file data generated by all backup tasks; the input end of the cluster virtual address unit is used to connect to at least two backup clients; the output end of the cluster virtual address unit is connected to each backup node; each backup node is communicatively connected to both the shared metadata cluster and the shared file cluster.

[0008] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for implementing the steps of any of the above backup methods when executing the computer program.

[0009] This application also provides a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of any of the above backup methods.

[0010] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the above backup methods.

[0011] This application discloses a backup method and electronic device. The backup method involves creating a target backup task, clearly defining its core objective as writing target backup file data into a shared file cluster. During execution, the first backup node of the backup system executes the target backup task, simultaneously updating the runtime status of the target backup task to the shared metadata cluster for unified management. The target backup file data is written to the same location within the shared file cluster, avoiding data conflicts or storage path chaos caused by parallel writing from multiple backup nodes. This ensures that the storage target and runtime status record of the target backup file data remain consistent regardless of whether the target backup task is executed by the first backup node or a subsequent second backup node, providing a fundamental guarantee for the integrity and traceability of the target backup file data. Furthermore, the shared metadata cluster continuously monitors the health status of backup nodes based on their runtime status. When a failure is detected in the first backup node, the shared metadata cluster automatically selects a healthy second backup node from multiple backup nodes and synchronizes the runtime status of the target backup task to the second backup node, enabling it to resume execution from the breakpoint indicated by the runtime status, preventing interruption of the target backup task due to a single point of failure. Therefore, by leveraging runtime state synchronization and breakpoint resume capabilities, this application eliminates the need for the second backup node to reprocess completed target backup file data. This reduces redundant calculations and data transmission, minimizes the ineffective consumption of storage, bandwidth, and other resources, and improves the execution efficiency of the target backup task and the stability of the backup system. Simultaneously, it solves the problems in existing technologies where the backup node cannot immediately and accurately take over the task after the primary node fails, requiring a full scan of storage / manual intervention, resulting in long recovery times and susceptibility to split-brain or data corruption due to inconsistent states. This achieves high availability and reliability for the backup system. Attached Figure Description

[0012] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments 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.

[0013] Figure 1 A schematic diagram of the structure of a backup system provided in an embodiment of this application;

[0014] Figure 2 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application;

[0015] Figure 3 A flowchart illustrating a backup method provided in this application embodiment. Figure 1 ;

[0016] Figure 4 A flowchart illustrating a backup method provided in this application embodiment. Figure 2 ;

[0017] Figure 5 A flowchart illustrating a backup method provided in this application embodiment. Figure 3 ;

[0018] Figure 6 A flowchart illustrating a backup method provided in this application embodiment. Figure 4 ;

[0019] Figure 7 A flowchart illustrating a backup method provided in this application embodiment. Figure 5 ;

[0020] Figure 8 A flowchart illustrating a backup method provided in this application embodiment. Figure 6 ;

[0021] Figure 9 This is a schematic diagram of a remote hybrid cloud expansion of a backup system provided in an embodiment of this application. Detailed Implementation

[0022] 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 of ordinary skill in the art without creative effort are within the protection scope of this application.

[0023] It should be noted that, in the description of this application, 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. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0024] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0025] The specific application environment architecture or specific hardware architecture on which the backup method depends is described here.

[0026] Figure 1This is a schematic diagram of a backup system provided in an embodiment of this application. Figure 1 As shown, the backup system 100 includes: a cluster virtual address unit (IP), multiple backup nodes (ActiveN), a shared metadata cluster 110, and a shared file cluster 120.

[0027] The cluster virtual address unit (IP) provides a unified and unique access point for at least two backup clients; it is typically a virtual IP (VIP) or domain name. These clients do not need to know the number of backend backup nodes or which specific node they are connecting to, simplifying configuration and management. Furthermore, the cluster IP is a logical address independent of any specific physical host; it represents the entire backup service cluster. When the primary / standby node fails, the cluster IP migrates to a healthy standby backup node through a high-availability mechanism, continuing to provide services. This failover process is completely transparent to the clients, effectively ensuring high service availability.

[0028] In actual operation, all requests related to control flow (such as registration, task initiation, status query, etc.) are distributed to the backend healthy backup nodes through this unified entry point. This completely shields the addition, removal, and failover of backend backup nodes, making it completely transparent to the backup client.

[0029] Multiple backup nodes (ActiveN) are active, handling actual backup tasks simultaneously, thus improving the overall throughput and backup speed of backup system 100. When the performance of backup system 100 is insufficient, simply add more backup nodes (ActiveN). Furthermore, since all backup nodes (ActiveN) are active, the failure of any one backup node (ActiveN) will not paralyze the entire backup system 100; other backup nodes (ActiveN) can take over its tasks.

[0030] It should be noted that the processing capacity of the backup nodes and the storage capacity / performance of the shared file cluster 120 can be expanded independently. Simply adding backup nodes can improve the ability to handle concurrent tasks, and simply adding OSS (Object Storage Server) and disks to the shared file cluster 120 can increase storage space and I / O bandwidth, thereby maximizing resource utilization.

[0031] The shared metadata cluster 110 is used to store globally consistent system metadata for multiple backup nodes. This system metadata includes at least: system pre-configuration, client registration information, backup task definitions and policies, backup task runtime status, and global lock information. Specifically, system pre-configuration includes at least: global policies, retention periods, and storage locations; client registration information records the attributes of all managed backup clients, including at least: the managed IP address and authentication information; backup task definitions and policies store detailed configurations for all backup tasks, including at least: backup task, backup time, and backup plan; the backup task runtime status records task execution information in real time, including at least: task status (running, successful, failed, etc.), progress percentage, amount of data transferred, start / end time, and checksum information. Global lock information is used to implement mutual exclusion access to shared storage resources, such as preventing multiple backup nodes from simultaneously modifying the same backup client or the same backup target, ensuring data consistency; it also supports lightweight master election for specific management functions, ensuring that critical operations have a unique execution backup node.

[0032] The shared metadata database cluster 110 can employ a highly available ETCD (Distributed Key-Value Store) cluster (i.e., multiple ETCD nodes) as the core of global metadata storage, serving as the brain and command center of the entire backup system 100. ETCD, based on the Raft consensus algorithm, ensures strong consistency and high availability of all system metadata, providing a unified and reliable state management foundation for distributed backup nodes and avoiding the risks of split-brain and data inconsistency. Raft is a distributed consensus algorithm used to manage the consistency of replication logs.

[0033] The shared file cluster 120 provides a unified namespace and high-concurrency data access capabilities for multiple backup nodes. It centrally stores the target backup file data (i.e., backup set data) and corresponding large index files generated by all backup tasks. This shared file cluster 120 is built on the high-performance Lustre distributed parallel file system. Lustre is an open-source, high-performance parallel distributed file system. In this application, it serves as the shared storage backend for all backup nodes, responsible for storing the actual backup set data and providing a unified namespace and high aggregate I / O bandwidth. The backup set data is the collection of all data files generated after a backup task is executed, stored in the shared file cluster 120.

[0034] Data is organized in the shared file cluster 120 according to preset rules, and the directory structure follows the format below:

[0035] / backup_data / <Client_Name> / <Job_Name> / <Date_Time> /

[0036] This structure ensures that the paths to the same file are completely consistent across any backup node, guaranteeing the uniformity of the global data view.

[0037] One of the core features of parallel file systems like Lustre is the unified namespace, which means that all backup clients (backup nodes) see the same global and consistent view of directories and files, without needing to pay attention to the distribution details of the underlying physical storage.

[0038] Furthermore, Lustre features a striped storage mechanism that distributes file data in parallel across multiple object storage targets (OSTs) for read and write operations, effectively aggregating I / O bandwidth. This mechanism enables near-linear performance improvements in backup and restore operations as the number of storage nodes increases, providing robust performance support for large-scale data backups.

[0039] The cluster virtual address unit (IP) has an input terminal that connects to at least two backup clients, enabling multiple backup clients to initiate target backup requests through a unified and unique access point. The output terminal of the cluster virtual address unit (IP) connects to each backup node (Active) to distribute target backup requests to available backup nodes (Actives) among the multiple backup nodes. Each backup node (Active) is communicatively connected to both the shared metadata cluster 110 and the shared file cluster 120. This allows the Active to write target backup file data generated during the execution of target backup tasks to the shared file cluster 120, and simultaneously write the runtime status of the shared file cluster 120 to the shared metadata cluster 110. Furthermore, each backup node (Active) can query data in both the shared metadata cluster 110 and the shared file cluster 120.

[0040] For example, at least two backup clients initiate target backup requests, which are transparently routed to any healthy backup node (Active) via the cluster virtual address unit (IP). This backup node (Active), leveraging its connections to the shared metadata cluster 110 and the shared file cluster 120, obtains task information, performs backups, and updates its status, all without relying on other backup nodes (Active). If this backup node (Active) fails during execution, the cluster virtual address unit (IP) routes subsequent target backup requests from target backup clients to a new backup node (Active). The new backup node (Active) can then query the shared metadata cluster 110 to determine the status of previous backup tasks and may take over any unfinished backup work, or at least ensure data consistency and prevent data corruption.

[0041] The backup system provided in this application can consist of a cluster virtual address unit, multiple backup nodes, a shared metadata database cluster, and a shared file cluster. The input of the cluster virtual address unit connects to at least two backup clients, greatly simplifying the configuration of multiple backup clients. The output of the cluster virtual address unit connects to each backup node, and each backup node communicates with both the shared metadata database cluster and the shared file cluster, avoiding the problem of a single backup node being overloaded while other backup nodes remain idle, and fully utilizing the overall processing power of the shared metadata database cluster and the shared file cluster. Therefore, the backup system provided in this application offers users a backup service that is uninterrupted, with linearly increasing performance, and absolutely reliable data.

[0042] Figure 2 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 2 As shown, the electronic device 200 may include a processor 210 and a memory 220.

[0043] The memory 220 stores machine-executable instructions that can be executed by the processor 210. When the electronic device 200 is running, these machine-executable instructions are executed. The processor 210 and the memory 220 communicate via a bus. The processor 210 can execute these machine-executable instructions to implement the backup method.

[0044] The memory 220, processor 210, and bus components are electrically connected directly or indirectly to enable data transmission or interaction. For example, these components can be electrically connected to each other via one or more communication buses or signal lines. The mobile storage device includes at least one software function module that can be stored in the memory 220 or embedded in the operating system (OS) of the electronic device in the form of software or firmware. The processor 210 is used to execute executable modules stored in the memory 220, such as software function modules and computer programs included in the backup method of the mobile storage medium.

[0045] The memory 220 may be, but is not limited to, random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), etc.

[0046] The electronic device 200 can be selected according to the actual situation; for example, it can be a mobile terminal, a computer, etc. Furthermore, the electronic device 200 has software or an application program capable of executing backup methods.

[0047] The backup method provided in this application embodiment can be executed by a processor in an electronic device 200 and applied to a backup system. The backup system includes at least multiple backup nodes and a shared metadata database cluster. The backup method provided in this application embodiment will be explained further below. Figure 3 A flowchart illustrating a backup method provided in this application embodiment. Figure 1 .like Figure 3 As shown, the method may include:

[0048] S310, Create target backup task.

[0049] The target backup task involves writing the target backup file data into the shared file cluster.

[0050] In one possible implementation, a user creates a target backup task in the backup system, the ultimate goal of which is to write the target backup file data generated by the specified target backup task to a shared file cluster.

[0051] S320: Execute the target backup task through the first backup node of the backup system, and update the runtime status of the target backup task to the shared metadata database cluster.

[0052] In one possible implementation, the created target backup task is executed by the first backup node of the backup system, and the runtime state of the target backup task is updated to the shared metadata database cluster. At the same time, the target backup file data generated by the target backup task is written to the shared file cluster.

[0053] The runtime status includes at least: processed backup data packet identifiers, task execution progress percentage, most recent successful checkpoint information, and a queue of pending subtasks. The processed backup data packet identifier records the identity of backup data packets that have been processed, ensuring that backup data packets are not processed repeatedly or lost, and supporting traceability. The task execution progress percentage is the most intuitive quantitative indicator of task progress, allowing users to quickly determine task completion and estimate remaining time. The most recent successful checkpoint information is a secure archive point for the target backup task, used for fault recovery and reducing repetitive work. The queue of pending subtasks is a to-do list for the target backup task, recording unexecuted sub-tasks, clearly showing the subsequent process of the target backup task, and facilitating troubleshooting of any blockages.

[0054] S330. Determine whether the first backup node has failed based on the runtime status through the shared metadata cluster. When it is determined that the first backup node has failed, determine the second backup node from multiple backup nodes and synchronize the runtime status to the second backup node.

[0055] In one possible implementation, a shared metadata cluster within the backup system monitors the runtime status of the target backup task to continuously check the health of the first backup node, i.e., to confirm whether the first backup node has failed. The shared metadata cluster acts as the "brain," detecting connection interruptions or other problems with the first backup node, thus determining that the first backup node has failed. When the shared metadata cluster determines that the first backup node has failed, it automatically selects a healthy second backup node from multiple backup nodes and synchronizes the runtime status of the target backup task to the second backup node. This runtime status includes breakpoint information at the time of the failure.

[0056] S340. Continue executing the target backup task from the breakpoint indicated by the runtime status through the second backup node.

[0057] In one possible implementation, the runtime state received by the second backup node is used to locate the breakpoint of the target backup task. Instead of restarting from the beginning of the target backup task, the execution of the target backup task continues from where the first backup node broke down.

[0058] For example, when the first backup node has completed 50% of the target file data backup in the target backup task, if the shared metadata cluster detects a failure of the first backup node, it will automatically select a healthy second backup node from the remaining backup nodes and synchronize the runtime status of the target backup task to the second backup node. Afterward, the second backup node will directly resume the transfer from the remaining 51% of the target file data and continue writing the target file data to the original storage location of the shared file cluster, ensuring seamless connection of the target backup task and consistency of data storage paths.

[0059] The backup method provided in this application creates a target backup task, clearly defining its core objective as writing target backup file data into a shared file cluster. During the execution phase, the first backup node of the backup system executes the target backup task, simultaneously updating its runtime status to the shared metadata cluster for unified management. The target backup file data is written to the same location within the shared file cluster, avoiding data conflicts or storage path chaos caused by parallel writing from multiple backup nodes. This ensures that the storage target and runtime status record of the target backup file data remain consistent regardless of whether the target backup task is executed by the first backup node or a subsequent second backup node, providing a fundamental guarantee for the integrity and traceability of the target backup file data. Furthermore, the shared metadata cluster continuously monitors the health status of backup nodes based on their runtime status. When a failure is detected in the first backup node, the shared metadata cluster automatically selects a healthy second backup node from among multiple backup nodes and synchronizes the runtime status of the target backup task to the second backup node. This allows the second backup node to resume execution of the target backup task from the breakpoint indicated by the runtime status, preventing interruption of the target backup task due to a single point of failure. Therefore, by leveraging runtime state synchronization and breakpoint resume capabilities, this application eliminates the need for the second backup node to reprocess completed target backup file data. This reduces redundant calculations and data transmission, minimizes the ineffective consumption of storage, bandwidth, and other resources, and improves the execution efficiency of the target backup task and the stability of the backup system. Simultaneously, it solves the problems in existing technologies where the backup node cannot immediately and accurately take over the task after the primary node fails, requiring a full scan of storage / manual intervention, resulting in long recovery times and susceptibility to split-brain or data corruption due to inconsistent states. This achieves high availability and reliability for the backup system.

[0060] Optionally, the above method involves executing the target backup task through the first backup node of the backup system, including:

[0061] The first backup node of the backup system splits the target backup file data into multiple backup data packets based on a preset data volume, and writes the multiple backup data packets into the shared file cluster in parallel.

[0062] The preset data size can be selected according to actual needs. For example, the preset data size can be selected as a fixed size of 64MB, 128MB, or 1MB.

[0063] In one possible implementation, after reading the target backup file data from the backup client, the first backup node does not transmit and store it as a complete monolithic file. Instead, it segments the complete target backup file data into multiple independent backup data packets according to a preset data volume. Each backup data packet is assigned a unique identifier (such as an ID or index), and then the first backup node concurrently starts multiple write threads or processes to transmit these backup data packets to the shared file cluster simultaneously, rather than processing them sequentially.

[0064] It should be noted that, due to the striping characteristics of Lustre in the shared file cluster, backup data packets can be written to multiple object storage targets (OSTs) in parallel, thereby aggregating I / O bandwidth and making backup and restore performance improve nearly linearly with the increase of storage nodes.

[0065] The backup method provided in this application, through the first backup node of the backup system, splits the target backup file data into multiple backup data packets based on a preset data volume, and writes these multiple backup data packets in parallel to a shared file cluster. Therefore, this application can fully utilize the aggregated I / O bandwidth of multiple storage nodes at the backend of the shared file cluster. The write speed of a single large file is no longer limited by the performance bottleneck of a single disk or a single storage node, making the backup speed of the target backup file data and the recovery speed of ultra-large files extremely fast, and the performance can achieve near-linear improvement as the storage cluster expands.

[0066] Optionally, in the above method, the target backup file data is split into multiple backup data packets based on a preset data volume using the first backup node of the backup system, including:

[0067] The first backup node of the backup system performs a splitting operation on the target backup file data based on a preset data volume, and generates a corresponding data check code for each backup data packet.

[0068] In one possible implementation, the first backup node splits the target backup file data into multiple backup data packets based on a preset data volume. During this process, for each generated backup data packet, the first backup node generates a unique data check code. This data check code is the digital fingerprint of the backup data packet, and any minor modification to the backup data packet will cause its data check code to change drastically.

[0069] The above method involves writing multiple backup data packets in parallel to the shared file cluster, including:

[0070] Write the backup data packet and its corresponding data checksum together into the shared file cluster.

[0071] In one possible implementation, the generated data checksum is recorded as key metadata along with the information of the backup data packet to which it belongs in the shared metadata database cluster.

[0072] The backup method provided in this application splits the target backup file data based on a preset data volume using the first backup node of the backup system. A corresponding data checksum is generated for each backup data packet, and the backup data packet and its corresponding checksum are written together into a shared file cluster. Therefore, at any subsequent time, the backup system can reread the backup data packet and calculate its current checksum, comparing it with the original checksum stored in the shared metadata cluster. This ensures that the backed-up target backup file data is completely consistent with the original backup file data, improving the reliability of the backup system.

[0073] Optionally, updating the runtime state of the target backup task to the shared metadata database cluster in the above method includes:

[0074] The first backup node of the backup system updates the runtime status of the target backup task based on a preset period and stores it in the shared metadata database cluster.

[0075] The preset cycle can be selected based on the actual situation of the backup system's internal strategy to ensure the regularity and timeliness of runtime status updates; no restrictions are imposed here. For example, the preset cycle can be selected to be once every 10 seconds.

[0076] In one possible implementation, during the execution of the target backup task by the first backup node, the backup system sets a fixed preset period. When each preset period arrives, the first backup node collects the real-time runtime status of the current target backup task, packages the collected runtime status as an update operation, and writes it into the shared metadata database cluster, overwriting the original runtime status record.

[0077] It should be noted that writing data to the shared metadata database cluster requires Raft consistency protocol operations. This means that after the first backup node sends a write operation request, it must wait for the shared metadata database cluster to complete the Raft consistency protocol and return the result. If the first backup node immediately updates the shared metadata database cluster every time it receives the runtime state, it may impact the performance of the shared metadata database cluster, and consequently, the performance of the target backup task. Therefore, it is usually advisable to set a reasonable, fixed preset period to control the update frequency within an acceptable range for the overall performance of the backup system.

[0078] Additionally, it should be noted that when the first backup node updates the runtime state to the shared metadata database cluster, an asynchronous queue approach can be used. For example, the runtime state update task can be placed in a queue and the update can be handled by a background thread, thus avoiding blocking the main transmission thread.

[0079] The backup method provided in this application updates the runtime state of the target backup task at a preset period using the first backup node of the backup system and stores it in a shared metadata database cluster. Thus, this application continuously synchronizes the runtime state of the target backup task to the shared metadata database cluster at a preset period, ensuring that the progress information recorded in the runtime state is always highly consistent with the actual execution of the target backup task. This periodically solidifies the execution progress of the target backup task, forming a reliable recovery checkpoint. If the first backup node fails, the backup system, after selecting a second backup node, can directly and accurately resume the task from the point of interruption based on the latest runtime state stored in the shared metadata database cluster, without having to start execution from scratch. This effectively avoids data duplication and time waste caused by backup node failures, providing a key benchmark for rapid and accurate fault recovery of the backup system.

[0080] Figure 4 A flowchart illustrating a backup method provided in this application embodiment. Figure 2 .like Figure 4 As shown, the method described above for creating a target backup task includes:

[0081] S410: In response to the target backup request from the target backup client, receive and parse the target backup request through any one of the multiple backup nodes to obtain the target backup task.

[0082] A target backup task includes at least: target backup operations, configuration information, and initial backup state. Target backup operations refer to the specific operations that the target backup task needs to perform; initial backup state refers to the initial state of the target backup task.

[0083] In one possible implementation, in response to a target backup request initiated by the target backup client, a healthy target backup node is selected from multiple backup nodes via the cluster virtual address unit (IP), and the target backup request is sent to that target backup node. The target backup node receives the target backup request, generates reply data, and forwards it to the target backup client via the cluster virtual address unit (IP). After receiving the target backup request, the target backup node parses the target backup request to obtain the target backup task.

[0084] S420, and stores the configuration information in the target backup task in the shared metadata database cluster.

[0085] The configuration information includes at least: scheduling time, backup source, backup type, target path, retention policy, and encryption settings.

[0086] In one possible implementation, after parsing the target backup request, the target backup task is obtained, and the configuration information in the target backup task is written into the shared metadata database cluster to store the target backup task in the shared metadata database cluster.

[0087] For example, the target backup node sends a write operation request to the Leader node in the shared metadata database cluster. Upon receiving this request, the Leader node replicates the write operation to multiple ETCD nodes using its built-in Raft consensus algorithm. Once the multiple ETCD nodes confirm the write operation, the Leader node commits the content of the write operation (to write the data) and then returns a write success response to the target backup node. At this point, the configuration information for the target backup task is stored in the shared metadata database cluster.

[0088] It should be noted that there is only one Leader node in the shared metadata database cluster, which is responsible for handling all write requests.

[0089] S430: By monitoring the shared metadata database cluster through multiple backup nodes, and based on the competition of configuration information of the target backup task, determine the execution right of the first backup node among the multiple backup nodes.

[0090] In one possible implementation, multiple backup nodes monitor the shared metadata cluster in real time for the release of new backup tasks or the scheduling of existing backup tasks. When a target backup task needs to be executed, all backup nodes that have detected this event will compete for the task based on the target backup task's configuration information (such as task type and resource requirements). The shared metadata cluster will determine one of the backup nodes as the executor of the target backup task based on the health status of each backup node, thus determining the execution right of the first backup node among the multiple backup nodes.

[0091] The backup method provided in this application, in response to a target backup request from a target backup client, receives and parses the target backup request through any one of multiple backup nodes to obtain the target backup task. This ensures that even if one backup node fails, other healthy backup nodes can still receive the request normally, avoiding the loss of the target backup request or the inability to start the task due to the failure of the sole receiving backup node. Simultaneously, the target backup client does not need to specify a particular backup node to send the target backup request; it only needs to initiate the target backup request to the backup system, reducing the coupling between the backup client and backup nodes and improving the overall reliability of target backup request processing. Furthermore, the configuration information in the target backup task is stored in a shared metadata database cluster, achieving centralized management of configuration information and ensuring the consistency of the target backup task. By having multiple backup nodes monitor the shared metadata database cluster and determine the execution right of the first backup node among multiple backup nodes based on the competition for the configuration information of the target backup task, the execution right of the first backup node is dynamically allocated, optimizing the utilization of backup node resources.

[0092] Figure 5 A flowchart illustrating a backup method provided in this application embodiment. Figure 3 .like Figure 5 As shown, in the above method, in response to a target backup request from a target backup client, the target backup request is received and parsed through any one of multiple backup nodes, including:

[0093] S510 responds to the target backup request from the target backup client through the cluster virtual address unit, and determines any backup node as the target backup node from multiple backup nodes according to the preset load balancing strategy.

[0094] The preset load balancing strategy can be selected according to the actual situation. For example, the preset load balancing strategy can be selected as a node weight allocation strategy.

[0095] In one possible implementation, the cluster virtual address unit serves as the sole external access address for the backup system. The target backup client does not need to remember the real addresses of multiple backup nodes; it only needs to send the target backup request to this cluster virtual address unit, which then uniformly accepts the request. The cluster virtual address unit then monitors the health status (such as current workload and / or network status) of multiple backup nodes in real time according to a built-in preset load balancing strategy (e.g., node weight allocation strategy). Based on the preset load balancing strategy, it selects the backup node with the optimal load or that meets the specified rules from among the healthy backup nodes and designates it as the target backup node.

[0096] S520 receives and parses the target backup request through the target backup node.

[0097] In one possible implementation, after the selected target backup node receives the target backup request forwarded by the virtual address unit, it parses the content of the target backup request (such as extracting the target backup requirements and verifying the legality of the target backup request), and finally generates an executable target backup task, laying the foundation for the configuration storage and execution of subsequent target backup tasks.

[0098] It should be noted that the target backup node verifies the target backup task based on preset standards in the shared metadata cluster (such as backup client identity information, permission identifiers, path identifiers, parameter identifiers, etc.) to confirm its legitimacy, ensure data security in the backup system, reduce unnecessary consumption, maintain the stability of the backup system, and lay the foundation for the reliable execution of subsequent target backup tasks. For example, verifying the legitimacy of the target backup task involves checking whether the target backup task's path is valid and whether the target backup operation can be executed. If both are valid, the target backup node writes the data to different locations based on the data type of the target backup task.

[0099] The backup method provided in this application responds to target backup requests from target backup clients through a cluster virtual address unit, reducing the configuration complexity and maintenance cost of backup clients and improving the overall usability and stability of the backup system. Based on a preset load balancing strategy, any backup node is selected as the target backup node from multiple backup nodes, avoiding resource waste and maximizing the utilization of standby node resources. The target backup node receives and parses the target backup request. Therefore, this application, by forwarding the target backup request from the target backup client through a cluster virtual address unit, breaks the strong coupling between the backup client and a single backup node, solves the single point of failure risk of relying on a single backup node to receive target backup requests, and improves the scalability of the backup system.

[0100] Figure 6 A flowchart illustrating a backup method provided in this application embodiment. Figure 4 .like Figure 6 As shown, before storing the configuration information of the target backup task in the shared metadata database cluster, the above method further includes:

[0101] S610: Request the creation of a lease from the shared metadata database cluster through each of the multiple backup nodes.

[0102] The lease is used to set a preset lifespan for information stored in the shared metadata database cluster. When the lease expires, the associated information will be automatically deleted. The preset lifespan can be selected according to the actual situation; for example, a preset lifespan of 5 minutes can be selected.

[0103] In one possible implementation, each backup node proactively initiates a lease creation request to the shared metadata database cluster, binding a preset lifespan (e.g., 5 minutes) to the backup node information to be stored subsequently. After the lease expires, the shared metadata database cluster automatically deletes its associated information.

[0104] S620. Each backup node receives a unique lease identifier returned by the shared metadata cluster based on the application to create a lease; and writes the node information of each backup node into the shared metadata cluster based on the unique lease identifier, so that the lease is associated with the node information of each backup node.

[0105] In one possible implementation, after receiving a lease creation request, the shared metadata cluster returns a unique lease identifier for each requesting backup node. This unique identifier allows the backup node to write its own node information (such as status and load) into the shared metadata cluster, achieving a one-to-one binding between the lease and the backup node's information. This ensures that subsequent operations can accurately locate the corresponding backup node. For example, based on the backup node corresponding to this lease, the shared metadata cluster processes the target backup task and maintains a heartbeat. This heartbeat indicates that the connection between the shared metadata cluster and this backup node is stable.

[0106] S630: Each backup node sends a lease renewal request to the shared metadata cluster based on a preset time interval and a unique lease identifier to reset the lease.

[0107] The preset time interval is shorter than the preset survival time. This preset time interval can also be selected according to the actual situation. For example, the preset time interval can be selected as 2 minutes.

[0108] In one possible implementation, each backup node sends a lease renewal request to the shared metadata cluster at a preset time interval (e.g., every 2 minutes) based on a unique lease identifier. Each renewal resets the preset lease lifetime (e.g., recalculates 5 minutes from the current time), proving that the backup node is still in a healthy operating state.

[0109] It should be noted that if the backup node fails (such as due to power outage or network outage) and is unable to send the lease renewal request on time, causing the heartbeat between the backup node and the shared metadata database cluster to stop, the lease will expire. The shared metadata database cluster will automatically delete the lease and the associated node information. The entire process requires no manual intervention.

[0110] The backup method provided in this application involves each of multiple backup nodes requesting the creation of a lease from a shared metadata cluster. Each backup node receives a unique lease identifier returned by the shared metadata cluster based on the lease request. Then, based on the unique lease identifier, each backup node writes its node information into the shared metadata cluster, thus associating the lease with each backup node's node information. Each backup node sends a lease renewal request to the shared metadata cluster at preset time intervals, based on the unique lease identifier, to reset the lease. Therefore, this application uses a lease mechanism to allow backup nodes to actively prove their existence in the shared metadata cluster. Only when a backup node renews its lease with the shared metadata cluster on time can its node information be retained in the shared metadata cluster. If a backup node fails, its node information is automatically deleted after the lease expires. The shared metadata cluster can directly determine the heartbeat status of the backup node by checking if a backup node is associated with a lease, avoiding the misjudgment that the shared metadata cluster retains the node information of a backup node that is offline, and providing a status basis for scheduling subsequent target backup tasks.

[0111] Figure 7 A flowchart illustrating a backup method provided in this application embodiment. Figure 5 .like Figure 7 As shown, in the above method, multiple backup nodes monitor the shared metadata database cluster, and based on competition for the configuration information of the target backup task, determine the execution right of the first backup node among the multiple backup nodes, including:

[0112] S710 continuously monitors changes in the configuration information of backup tasks stored in the shared metadata database cluster through multiple backup nodes.

[0113] S720: When the configuration information of the target backup task is created or updated, a first global lock uniquely associated with the target backup task is created in the shared metadata database cluster through each of the multiple backup nodes based on preset competition rules.

[0114] The first global lock is used to ensure that each backup node uniquely corresponds to the target backup task. The preset contention rules can be selected according to actual conditions; for example, the preset contention rules can be selected as the order in which the shared metadata cluster receives node information from each backup node.

[0115] In one possible implementation, multiple backup nodes continuously monitor the dynamics of the configuration information of the target backup task in the shared metadata database cluster. When new configuration information for the target backup task is created, or existing configuration information is updated, the multiple backup nodes immediately trigger contention. After contention is triggered, each backup node, according to a preset contention rule (such as the order in which the shared metadata database cluster receives node information from each backup node), initiates a request to create the first global lock to the shared metadata database cluster in this order. The backup node that successfully sends its node information to the shared metadata database cluster first has higher priority when creating the first global lock and can initiate the request to create the first global lock first. The first global lock is uniquely associated with the target backup task, meaning that only one first global lock can be successfully created for the same target backup task; subsequent creation requests from backup nodes will be rejected by the shared metadata database cluster due to duplicate identifiers.

[0116] S730, the backup node corresponding to the first global lock that was successfully created is identified as the first backup node to obtain the right to execute the target backup task.

[0117] In one possible implementation, the backup node that successfully creates the first global lock uniquely associated with the target backup task in the competition among all backup nodes will be recognized by the backup system as the first backup node to acquire the execution right of the target backup task; other backup nodes that fail to create the lock will automatically give up the competition for the target backup task and continue to listen for subsequent changes in the configuration information of the target backup task.

[0118] For example, when the configuration information for the target backup task is created or updated, the task scheduling engine of each backup node immediately constructs an ETCD transaction and submits it to the shared metadata database cluster. The Leader node in the shared metadata database cluster processes the ETCD transactions of each backup node in the order they were received, checking if each backup node's ETCD transaction is in a waiting state. It then changes the waiting state of the ETCD transaction of one backup node (such as the first backup node) to an executing state. This change is then replicated to multiple ETCD nodes in the shared metadata database cluster via the Raft protocol. Finally, the Leader returns a successful transaction response to this first backup node. This first backup node is the execution node for this target backup task.

[0119] The backup method provided in this application continuously monitors changes in the configuration information of backup tasks stored in the shared metadata database cluster through multiple backup nodes, reducing the startup latency of the target backup task and improving scheduling response efficiency. When the configuration information of the target backup task is created or updated, each of the multiple backup nodes creates a first global lock uniquely associated with the target backup task in the shared metadata database cluster based on preset competition rules. The backup node corresponding to the successful creation of the first global lock is determined as the first backup node to acquire the execution right of the target backup task. Thus, this application ensures that only one backup node can successfully create the first global lock and acquire the execution right at the same time, preventing multiple backup nodes from simultaneously believing they have acquired the execution right and thus repeatedly executing the same target backup task, ensuring the uniqueness of the target backup task execution, guaranteeing data consistency, and improving the high availability of the backup system.

[0120] Optionally, the above method determines whether the first backup node has failed based on the runtime state of the shared metadata cluster, including:

[0121] When the shared metadata cluster detects that the lease associated with the first backup node has expired, it determines that the first backup node has failed.

[0122] Among them, lease expiration refers to the event where the lease of the first backup node in the shared metadata database cluster expires and is not renewed, resulting in the lease being deleted due to expiration.

[0123] In one possible implementation, the shared metadata cluster will automatically delete the expired and unrenewed lease because the lease of the first backup node has reached the preset lifespan (such as the previously set 5 minutes) in the shared metadata cluster; and the first backup node did not send a lease renewal request before the expiration; thus, the shared metadata cluster will trigger a lease expiration event.

[0124] Since the shared metadata database cluster defaults to healthy backup nodes that can renew leases periodically, and faulty backup nodes that cannot renew leases and cause leases to expire, under normal circumstances, the first backup node will continuously send lease renewal requests at preset intervals to ensure that the lease is always valid. If the first backup node fails (such as power outage, network outage, process crash, etc.), it will lose the ability to actively send lease renewal requests, resulting in the lease being unable to be reset and eventually expiring and being deleted. When the shared metadata database cluster detects that the lease associated with the first backup node has been deleted (i.e., the lease has expired), it can directly determine that the first backup node has failed without additionally polling the status of the first backup node.

[0125] The backup method provided in this application determines that the first backup node has failed when the shared metadata database cluster detects that the lease associated with the first backup node has expired. Lease failure is defined as the first backup node's lease in the shared metadata database cluster expiring and not being renewed, resulting in the lease being deleted. Therefore, the lease failure in this application is a direct result of the first backup node's inability to properly execute lease renewal requests, and is only triggered when the first backup node completely loses its communication or operational capabilities. This mechanism relies more on the first backup node's proactive lease renewal activity, reducing the false fault detection rate. Furthermore, since a failure of the first backup node inevitably leads to lease failure, it also avoids missed fault detection due to excessively long polling intervals, ensuring the accuracy of fault detection.

[0126] Optionally, determining the second backup node from multiple backup nodes in the above method includes:

[0127] By using a shared metadata cluster, a second global lock is created within the shared metadata cluster that is uniquely associated with the target backup task, based on preset competition rules.

[0128] The second global lock is used to identify the unique correspondence between the second backup node and the target backup task; the backup node corresponding to the successful creation of the second global lock is identified as the second backup node.

[0129] In one possible implementation, a shared metadata database cluster, based on preset competition rules (such as the order in which the shared metadata database cluster receives node information from each backup node), will send a request to the shared metadata database cluster to create a second global lock, attempting to create this second global lock request record. Since the second global lock identifier is uniquely bound to the target backup task, the same target backup task can only successfully create the second global lock once.

[0130] Since only one candidate backup node can successfully create the second global lock, this backup node is determined to be the second backup node responsible for the target backup task. Backup nodes that fail to create the second global lock abandon the target backup task to avoid duplicate participation.

[0131] The backup method provided in this application, through a shared metadata cluster, creates a second global lock uniquely associated with the target backup task based on preset competition rules. The backup node corresponding to the successfully created second global lock is identified as the second backup node. Therefore, the second global lock of this application is uniquely bound to the target backup task and can only be created by one backup node, preventing multiple backup nodes from simultaneously executing the same target backup task, thus reducing storage resource waste and backup data conflicts.

[0132] Optionally, after continuing the target backup task from the breakpoint indicated by the runtime state via the second backup node in the above method, the method further includes:

[0133] For the newly generated target backup file data and runtime status generated during the execution of the target backup task; the newly generated target backup file data is written to the shared file cluster through the second backup node; and the newly generated runtime status is updated to the shared metadata database cluster.

[0134] In one possible implementation, after the second backup node resumes the target backup task from the breakpoint indicated by the runtime state, it generates target backup file data and runtime state, writes this target backup file data to the shared file cluster, and simultaneously updates the runtime state of this backup to the shared metadata database cluster. This parallel collaboration of the second backup node avoids the disconnect problem where the target backup file data has stopped being written but the runtime state still displays normally.

[0135] The backup method provided in this application, for the newly generated target backup file data and runtime state during the execution of the target backup task, writes the newly generated target backup file data to the shared file cluster through a second backup node; and updates the newly generated runtime state to the shared metadata database cluster. Therefore, the runtime state of this application is dynamically updated according to the progress of writing the target backup file data, reducing the waiting time for invalid events and improving fault recovery efficiency.

[0136] To facilitate understanding of the above backup method, this application also provides a flowchart example of the backup method, which will be further described below with reference to the accompanying drawings. Figure 8 A flowchart illustrating a backup method provided in this application embodiment. Figure 6 .like Figure 8 As shown in the illustration, the embodiments provided in this application provide... Figure 6 It may include:

[0137] S801, The target backup client sends the target backup task to the cluster virtual address unit.

[0138] S802, the cluster virtual address unit forwards the target backup task to the first backup node.

[0139] Specifically, when the first backup node starts, it reads the list of endpoint addresses of the shared metadata database cluster from its local configuration file. The first backup node uses these endpoint addresses to initialize the shared metadata database cluster. It establishes a connection pool with the shared metadata database cluster and automatically identifies the leader node. The first backup node requests a lease from the shared metadata database cluster, with a preset lease lifetime of 30 seconds. The shared metadata database cluster returns a unique lease identifier. The first backup node binds its node information (such as node ID, network address, resource status, etc.) to this unique lease identifier, writing it as a key-value pair to the shared metadata database cluster. At this point, the first backup node completes its registration with the shared metadata database cluster.

[0140] The target backup client initiates a connection request to the cluster virtual address unit, enabling the cluster virtual address unit to connect with the target backup client. Then, the cluster virtual address unit, through its built-in load balancer, selects the optimal backup node, such as the first backup node, from multiple active backup nodes based on health check results and preset weighting strategies (such as memory, number of tasks, etc.).

[0141] In response to a target backup request from a target backup client, the cluster virtual address unit forwards the target backup request to the first backup node.

[0142] S803. When the first backup node is working normally, the lease is renewed periodically with the shared metadata database cluster.

[0143] Specifically, when the first backup node is working normally, it needs to periodically renew its lease with the shared metadata database cluster to maintain its health. If the first backup node fails, its corresponding lease will expire after 30 seconds, and the shared metadata database cluster will automatically delete the node registration information of the first backup node, triggering a failover.

[0144] S804. The first backup node writes the target backup file data to the shared file cluster and updates the runtime status of the target backup task to the shared metadata database cluster.

[0145] Specifically, the first backup node receives and parses the target backup request to obtain the target backup task. Then, the first backup node verifies the target backup task according to preset standards obtained from the shared metadata database cluster (such as backup client identity information, permission identifiers, path identifiers, parameter identifiers, etc.) to confirm the legality of the target backup task, ensure data security in the backup system, reduce unnecessary consumption, maintain the stability of the backup system, and lay the foundation for the reliable execution of subsequent target backup tasks. After successful verification, the first backup node writes the configuration information of the target backup task into the shared metadata database cluster.

[0146] Because all backup nodes in the backup system continuously monitor the dynamics of the target backup task's configuration information in the shared metadata database cluster, multiple backup nodes will immediately trigger contention when new configuration information for the target backup task is created or existing configuration information is updated. After contention is triggered, each backup node will, according to a preset contention rule (such as the order in which the shared metadata database cluster receives node information from each backup node), initiate a request to the shared metadata database cluster to create the first global lock. The backup node that successfully creates the first global lock is determined as the first backup node to acquire the execution right of the target backup task.

[0147] The first backup node notifies the target backup client to begin transmitting data for the target backup task. The target backup client sends the target backup task data to the first backup node via the cluster virtual address unit. The first backup node receives the target backup task data, splits it into multiple backup data packets according to a preset data size, and then writes these multiple backup data packets in parallel to the shared file cluster. Simultaneously, the first backup node updates the runtime status of the target backup task at a preset period and stores it in the shared metadata database cluster. Finally, the first backup node sends a successful backup response to the target backup client.

[0148] S805. When the first backup node fails, the shared metadata cluster detects that the lease of the first backup node has expired.

[0149] Specifically, when the first backup node fails, it stops renewing its lease with the shared metadata cluster, and its lease in the shared metadata cluster expires. The shared metadata cluster will then automatically delete the node registration information associated with the first backup node.

[0150] S806, The second backup node detected that the lease of the first backup node has expired.

[0151] Specifically, in the backup system, all backup nodes other than the first backup node monitor the shared metadata cluster and detect in real time that the first backup node's node registration information has been deleted, meaning the first backup node's lease has expired. At this point, based on the shared metadata cluster's preset competition rules (such as the order in which the shared metadata cluster receives node information from each backup node), candidate backup nodes will initiate a request to the shared metadata cluster to create a second global lock, attempting to create this second global lock request record. Because the second global lock identifier is uniquely bound to the target backup task, the same target backup task can only successfully create this second global lock once.

[0152] Since only one candidate backup node can successfully create the second global lock, this backup node is determined to be the second backup node responsible for the target backup task. Backup nodes that fail to create the second global lock abandon the target backup task to avoid duplicate participation.

[0153] S807, the second backup node scans and takes over the target backup task of the first backup node.

[0154] Specifically, the second backup node scans the runtime status of the target backup task of the first backup node from the shared metadata database cluster. It finds that the runtime status of the target backup task that the first backup node is responsible for is still in execution, but the first backup node has lost contact. Therefore, it prepares to take over the target backup task.

[0155] S808, the second backup node reads the breakpoint information of the target backup task in the shared metadata database cluster.

[0156] Specifically, after the second backup node acquires the second global lock, it immediately reads the latest runtime status of the target backup task from the shared metadata database cluster and determines the breakpoint information of the target backup task.

[0157] S809, the second backup node sends a request to the target backup client for target backup task data from the breakpoint of the target backup task.

[0158] Specifically, the second backup node establishes a connection with the target backup client through the cluster virtual address unit. Based on the breakpoint information read from the shared metadata database cluster, the second backup node sends a request to the target backup client for the remaining target backup task data from the breakpoint of the target backup task.

[0159] S810, the target backup client continues to send the remaining target backup task data to the cluster virtual address unit.

[0160] Specifically, when the target backup client receives a request for target backup task data, it continues to send the remaining target backup task data to the cluster virtual address unit.

[0161] S811, the cluster virtual address unit receives and forwards the target backup task to the second backup node.

[0162] Specifically, the cluster virtual address unit receives and forwards the remaining target backup tasks to the second backup node.

[0163] S812, the second backup node executes the target backup task and writes the target backup file data of the target backup task to the same location in the shared file cluster; at the same time, it updates the runtime status of the target backup task to the shared metadata database cluster.

[0164] Specifically, the second backup node executes the remaining target backup tasks and writes the target backup file data generated by the remaining target backup tasks to the same location in the shared file cluster; at the same time, it updates the runtime state of the target backup tasks to the shared metadata database cluster. When the target backup tasks are completed, the second backup node updates the final runtime state to the shared metadata database cluster and clears the second global lock.

[0165] The backup method provided in this application involves the following steps: The target backup client sends a target backup task to the cluster virtual address unit, which receives and forwards the target backup task to the first backup node. When the first backup node is working normally, it periodically renews its lease with the shared metadata cluster. The first backup node writes the target backup file data to the shared file cluster and simultaneously updates the runtime status of the target backup task to the shared metadata cluster. When the first backup node fails, the shared metadata cluster detects that the first backup node's lease has expired. The second backup node also detects the expiration of the first backup node's lease. The second backup node scans for and takes over the target backup task from the first backup node. The second backup node reads the breakpoint information of the target backup task. The second backup node sends a request to the target backup client for target backup task data from the breakpoint of the target backup task. The target backup client continues to send the remaining target backup task data to the cluster virtual address unit. The cluster virtual address unit receives and forwards the target backup task to the second backup node. The second backup node executes the target backup task and writes the target backup file data of the target backup task to the same location in the shared file cluster, while simultaneously updating the runtime status of the target backup task to the shared metadata cluster. Therefore, this application constructs a backup system with strong consistency, high availability, excellent performance, and linear scalability through the close collaboration of multiple backup nodes, a shared metadata database cluster, and a shared file cluster. This allows two or more backup nodes to provide services simultaneously, and in the event of a failure in one node, the other can instantly, seamlessly, and transparently take over all backup tasks, achieving an RTO (Recovery Time Objective) close to zero. This significantly improves the resource utilization and overall economy of the backup system. Furthermore, it solves the three core challenges of metadata synchronization, storage sharing, and failover in traditional solutions.

[0166] Optionally, this application also provides an example of a backup system, which will be further described below with reference to the accompanying drawings. Figure 9 This is a schematic diagram illustrating a remote hybrid cloud expansion of a backup system provided in an embodiment of this application. Figure 9 As shown, the off-site hybrid cloud 900 of the backup system includes: local data center 910 and cloud data center 920.

[0167] Both the local data center 910 and the cloud data center 920 can be composed of a shared file cluster, a shared metadata cluster, and multiple backup nodes.

[0168] The shared metadata cluster between local data center 910 and cloud data center 920 maintains eventual or strong consistency of system metadata through a synchronization mechanism between the shared metadata clusters. This ensures that the system metadata (such as task configuration and status) of a backup task created in local data center 910 will be synchronized to cloud data center 920. Therefore, multiple backup nodes in cloud data center 920 can also detect and take over backup tasks in local data center 910, achieving unified management.

[0169] The shared file cluster in local data center 910 uses Lustre's off-site replication function to asynchronously replicate the target backup file data to the shared file cluster in cloud data center 920 for storage. This ensures that cloud data center 920 has a copy of local data center 910. When disaster recovery or cloud outbreaks are required, the backup nodes in cloud data center 920 can directly access the data copy in local data center 910 without the need for large-scale data migration.

[0170] The off-site hybrid cloud backup system provided in this application extends the shared metadata cluster and shared file cluster of the local data center to the off-site cloud data center. It can build a cross-regional collaborative architecture based on two core technological capabilities: first, ETCD's native cross-data center deployment characteristics; and second, Lustre's asynchronous replication mechanism (such as Lustre HSM). This architecture achieves two core objectives: first, to create a unified namespace across regions, thus completing off-site disaster recovery and ensuring data security and availability; and second, to support cloud bursting, establishing a resource collaboration channel between the local and cloud environments. In practical applications, when the local data center faces excessive load, the system can transparently offload some backup or computing tasks to the cloud data center. Leveraging the elastic scaling advantages of the cloud data center, it efficiently handles the offloaded load, fully releasing the unlimited expansion potential of the cloud and achieving dynamic optimization and scheduling of resources.

[0171] Optionally, embodiments of this application also provide a computer-readable storage medium storing a computer program. When the computer program is run by a processor, the processor executes the steps of the backup method for the removable storage medium described in the above embodiments. The specific implementation and technical effects are similar and will not be repeated here.

[0172] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0173] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above-described backup method embodiments.

[0174] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above-described backup method embodiments.

[0175] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0176] The foregoing has provided a detailed description of a backup method and electronic device provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are only intended to help understand the method and core ideas of this application. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A backup method, characterized in that, Applied to a backup system, wherein the backup system includes at least multiple backup nodes and a shared metadata database cluster, the method includes: Create a target backup task, wherein the target backup task is to write target backup file data into a shared file cluster; The target backup task is executed through the first backup node of the backup system, and the runtime status of the target backup task is updated to the shared metadata database cluster based on a preset period; the runtime status includes at least: the identifier of the processed backup data packet, the percentage of task execution progress, the information of the most recent successful checkpoint, and the queue of subtasks to be processed; When the shared metadata cluster detects that the lease associated with the first backup node has expired, it determines that the first backup node has failed. The lease expiration is an event in which the lease of the first backup node in the shared metadata cluster expires and is not renewed, resulting in the lease being deleted due to expiration. When it is determined that the first backup node has failed, a second global lock is created in the shared metadata cluster based on a preset competition rule, which is uniquely associated with the target backup task. The second global lock is used to represent that the second backup node is uniquely associated with the target backup task. The backup node corresponding to the second global lock is successfully created is determined to be the second backup node, and the runtime state is synchronized to the second backup node. The target backup task can be resumed from the breakpoint indicated by the runtime state via the second backup node.

2. The method according to claim 1, characterized in that, The execution of the target backup task through the first backup node of the backup system includes: The first backup node of the backup system splits the target backup file data into multiple backup data packets based on a preset data volume, and writes the multiple backup data packets into the shared file cluster in parallel.

3. The method according to claim 2, characterized in that, The first backup node of the backup system splits the target backup file data into multiple backup data packets based on a preset data volume, including: The first backup node of the backup system performs a splitting operation on the target backup file data based on a preset data volume, and generates a corresponding data check code for each backup data packet. The step of writing the multiple backup data packets into the shared file cluster in parallel includes: The backup data packet and its corresponding data checksum are written together into the shared file cluster.

4. The method according to claim 1, characterized in that, The task of creating the target backup includes: In response to a target backup request from a target backup client, the target backup request is received and parsed by any one of the plurality of backup nodes to obtain a target backup task; the target backup task includes at least: target backup operation, configuration information, and initial backup state; The configuration information of the target backup task is stored in the shared metadata database cluster; the configuration information includes at least: scheduling time, backup source, backup type, target path, retention policy, and encryption settings; The shared metadata database cluster is monitored by the multiple backup nodes, and the execution right of the first backup node among the multiple backup nodes is determined based on the competition of the configuration information of the target backup task.

5. The method according to claim 4, characterized in that, The process of responding to a target backup request from a target backup client by receiving and parsing the target backup request through any one of the plurality of backup nodes includes: The cluster virtual address unit responds to the target backup request from the target backup client and determines any one of the multiple backup nodes as the target backup node according to the preset load balancing strategy. The target backup request is received and parsed by the target backup node.

6. The method according to claim 4, characterized in that, Before storing the configuration information in the target backup task in the shared metadata database cluster, the method further includes: Each of the multiple backup nodes applies to the shared metadata database cluster to create a lease; the lease is used to set a preset lifespan for information stored in the shared metadata database cluster, and when the lease expires, the associated information will be automatically deleted; Each backup node receives a unique lease identifier returned by the shared metadata cluster based on the application to create a lease; and writes the node information of each backup node into the shared metadata cluster based on the unique lease identifier, so that the lease is associated with the node information of each backup node. Each backup node sends a lease renewal request to the shared metadata cluster based on a preset time interval and the unique lease identifier to reset the lease; wherein the preset time interval is less than the preset lifetime.

7. The method according to claim 4, characterized in that, The multiple backup nodes monitor the shared metadata database cluster and, based on competition over the configuration information of the target backup task, determine the execution right of the first backup node among the multiple backup nodes, including: The multiple backup nodes continuously monitor changes in the configuration information of backup tasks stored in the shared metadata database cluster. When the configuration information of the target backup task is created or updated, a first global lock uniquely associated with the target backup task is created in the shared metadata cluster by each of the multiple backup nodes based on a preset competition rule; the first global lock is used to characterize that each backup node uniquely corresponds to the target backup task. Among them, the backup node corresponding to the first global lock that was successfully created is determined to be the first backup node that has obtained the right to execute the target backup task.

8. The method according to claim 1, characterized in that, After continuing the execution of the target backup task from the breakpoint indicated by the runtime state via the second backup node, the method further includes: For the target backup file data and runtime status newly generated during the execution of the target backup task; The newly generated target backup file data is written to the shared file cluster through the second backup node; and the newly generated runtime state is updated to the shared metadata database cluster.

9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the steps of the method as claimed in any one of claims 1 to 8.

Images