Load-aware elastic backup method and device, computer device, readable storage medium and program product

Abstract

The application relates to a load-aware elastic backup method and device, computer equipment, a readable storage medium and a program product. When a pre-backup time arrives, if current resource load information of a business system to be backed up does not satisfy a target backup condition, a target delay time is set, and a target backup condition changing with time is detected according to a target detection period within the target delay time. If the current resource load information satisfies the target backup condition, a backup task for the business system is executed. Compared with a traditional backup method of executing backup according to a fixed period, the application sets a target delay time when a pre-backup time arrives but current resource load information is too high, sets a target backup condition changing with time within the target delay time, judges whether the current resource load information satisfies the target backup condition within the target delay time, and determines whether to execute backup, thereby providing a backup buffer time for the system, avoiding backup when the load is too high, and improving backup efficiency.

Description

Technical Field

[0001] This application relates to the field of backup technology, and in particular to a load-aware elastic backup method, apparatus, computer equipment, computer-readable storage medium, and computer program product. Background Technology

[0002] As enterprise business systems expand and data becomes increasingly important, data backup has become a core means of ensuring business continuity. Existing backup systems generally employ a scheduled mechanism, triggering backup tasks according to preset time periods (such as hourly, daily, or weekly). Currently, the execution time of backup tasks is fixed. However, performing data backups according to a fixed time period can lead to reduced backup efficiency under high load conditions.

[0003] Therefore, current backup methods suffer from low backup efficiency. Summary of the Invention

[0004] Therefore, it is necessary to provide a load-aware elastic backup method, apparatus, computer equipment, computer-readable storage medium, and computer program product that can improve backup efficiency in response to the above-mentioned technical problems.

[0005] Firstly, this application provides a load-aware elastic backup method, including:

[0006] When the preset backup time is detected, obtain the current resource load information of the business system to be backed up;

[0007] If it is determined from the current resource load information that the target backup conditions are not met, then within the target delay time, the current resource load information is checked according to the target detection period to see if the target backup conditions are met; the target backup conditions and the target detection period are adjusted according to the change of the current time after the preset backup time.

[0008] If the current resource load information is detected to meet the target backup conditions within the target delay time, then a backup task for the business system is executed.

[0009] Secondly, this application also provides a load-aware elastic backup device, comprising:

[0010] The acquisition module is used to acquire the current resource load information of the business system to be backed up when the preset backup time is detected.

[0011] The detection module is used to detect whether the current resource load information meets the target backup conditions within a target delay time and according to a target detection period if it is determined from the current resource load information that the target backup conditions are not met. The target backup conditions and the target detection period are adjusted according to the change of the current time after the preset backup time.

[0012] The backup module is used to execute a backup task for the business system if the current resource load information is detected to meet the target backup conditions within the target delay time.

[0013] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the above-described method.

[0014] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the above-described method.

[0015] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the above-described method.

[0016] The aforementioned load-aware elastic backup method, apparatus, computer equipment, computer-readable storage medium, and computer program product, upon detecting that a preset backup time has arrived and determining that the target backup conditions are not met based on the current resource load information of the business system to be backed up, checks whether the current resource load meets the target backup conditions that change over time within a target delay time, according to a target detection period. If it does, a backup task for the business system is executed. Compared to traditional backups performed at fixed intervals, this application, by setting a target delay time and defining the target backup conditions that change over time within the target delay time when the preset backup time arrives but the current resource load information is too high, and determining whether to perform a backup within the target delay time to check whether the current resource load information meets the target backup conditions, provides a backup buffer time for the system, eliminating the need for backups when the load is too high, thus improving backup efficiency. Attached Figure Description

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

[0018] Figure 1This is a flowchart illustrating a load-aware elastic backup method in one embodiment.

[0019] Figure 2 This is a schematic diagram of the scheduling steps in one embodiment;

[0020] Figure 3 This is a schematic diagram of the progressive monitoring steps in one embodiment;

[0021] Figure 4 This is a schematic diagram illustrating the independent scheduling of multiple backup tasks in one embodiment;

[0022] Figure 5 This is a flowchart illustrating a load-aware elastic backup method in another embodiment;

[0023] Figure 6 This is a structural block diagram of a load-aware elastic backup device in one embodiment;

[0024] Figure 7 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0025] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0026] It should be noted that the terms "first," "second," etc., used in this application can be used to describe various elements, but these elements are not limited by these terms. These terms are only used to distinguish the first element from the second element. The terms "comprising" and "having," and any variations thereof, used in this application, are intended to cover non-exclusive inclusion. The term "multiple" used in this application refers to two or more. The term "and / or" used in this application refers to one of the embodiments, or any combination of multiple embodiments.

[0027] In related technologies, as enterprise business systems expand and the importance of data increases, data backup has become a core means of ensuring business continuity. Backup systems generally adopt a scheduled mechanism, triggering backup tasks according to preset time periods (such as hourly, daily, or weekly). Scheduled backup mechanisms are simple to implement and intuitive to configure, and are widely used in various commercial backup software and open-source backup tools.

[0028] However, scheduled backups present a fundamental contradiction: the execution time of backup tasks is fixed, but the resource load of business systems changes dynamically. When the execution time of a scheduled backup task coincides with peak business periods, the backup task will consume a large amount of central processing unit (CPU), memory, disk I / O, and network bandwidth resources, leading to a decline in business system performance, increased response latency, and even affecting the normal operation of business transactions.

[0029] To address this issue, some existing solutions have introduced load-based backup scheduling mechanisms. For example, some solutions monitor system resource utilization (CPU utilization, memory utilization, disk queue depth, etc.) and postpone or pause backup tasks when resource load is high, resuming execution when the load decreases. Other solutions use machine learning models to predict periods of low system load and adjust the initiation time of backup tasks accordingly. Still other solutions dynamically adjust the backup rate (throttling) during the backup process to complete the backup without affecting business operations.

[0030] Specifically, this includes backup systems based on scheduled operations. These systems execute backup tasks at fixed time periods (e.g., hourly, daily, weekly), typically supporting full, incremental, and differential backups, as well as backup window limits. They support cron-style scheduled backup plans. The core scheduling logic of this type of system is: at a preset time point, check if execution conditions (e.g., whether the backup window is open); if so, start the backup; otherwise, skip or wait for the next cycle. Its limitation is that the execution time is entirely determined by the fixed schedule and cannot be dynamically adjusted according to the real-time system load. Another approach is backup scheduling based on load prediction. For example, using machine learning models to analyze historical resource utilization data, predicting periods of low system load, and scheduling backup tasks to execute during these predicted low times. The core of this approach is to replace the original schedule with prediction, treating the original scheduled plan as an optimizable suggestion rather than an unbreakable anchor point. Its limitation is the lack of a fixed delay boundary calculated from the original schedule point. When the prediction results lead to continuous delays in backups, there is a lack of a mandatory enforcement mechanism, potentially causing the backup protection window to exceed the business's tolerance.

[0031] Backup throttling or pause schemes based on real-time load. These schemes can dynamically reduce the backup rate based on system I / O latency during backup execution, or pause backup when resource load exceeds a threshold. The core of this type of scheme is to adjust resource usage during the backup process, rather than selecting the execution time based on load before backup starts. Its limitation is that once a backup task starts, it occupies resources, and even if throttling reduces resource usage, it will still have some impact on business operations; furthermore, this type of scheme does not address when to start, but rather how to minimize the impact on business operations after startup.

[0032] Intelligent backup scheduling schemes based on application and system load consider both to determine whether to execute backups immediately or postpone them. The core of this type of scheme is a binary decision (execute or postpone) based on the current load status, but it lacks a time-based constraint mechanism. Its limitation is that when the system is under sustained high load, backup tasks may be repeatedly postponed, eventually triggering alarms or requiring manual intervention from administrators. There is no built-in maximum delay boundary to enforce backup protection rhythm. Backup scheduling schemes based on Service Level Agreements (SLAs) specify backup frequency (e.g., once daily, once hourly) and retention policies. The SLA is a contract that defines backup frequency, retention policies, and compliance requirements. When backups are postponed due to high load or other reasons, the system relies on the latest completion time stipulated in the SLA to trigger alarms or force execution. The core of this type of scheme is to indirectly constrain backup frequency through the SLA. Its limitations are: the latest completion time of the service level agreement is usually defined by an external policy management module, rather than an intrinsic constraint within the scheduler; the granularity of the service level agreement is usually at the frequency level (such as daily), rather than a fixed delay duration calculated from the original time point; more importantly, the service level agreement mechanism is usually used to trigger alarms and compliance reports, rather than as a direct input parameter for the scheduler's execution decision.

[0033] Load-aware scheduling algorithms in the field of elastic scaling and task scheduling. For example, they can dynamically adjust task or resource allocation based on system load. The core of this type of solution is resource-task matching optimization. Its limitations lie in its application domain being general computing resource scheduling, rather than backup task scheduling; it lacks the concepts of anchor constraints for scheduled plans and maximum latency boundaries; and it typically does not focus on the protection rhythm of task execution and recovery point objective (RPO) guarantees. The recovery point objective refers to the maximum allowable data loss time range when a business system fails.

[0034] Therefore, the above-mentioned load-based scheduling schemes typically have the following limitations: First, they treat the scheduled plan as a completely negligible suggestion. When the system is under continuous high load, backup tasks may be postponed indefinitely, causing the backup protection window to exceed the business's tolerance range. Second, they lack fixed delay boundary constraints calculated from the original scheduled point. The scheduling decision is based solely on the current load state, without considering the time interval since the last backup. Third, they do not treat the scheduled plan anchor point as an inescapable constraint, causing the execution time of the backup task to lose its correlation with the original plan, thus disrupting the determinism of the backup protection rhythm.

[0035] This leads to the following problems: 1. Mismatch between backup task execution timing and business load. Scheduled backups execute unconditionally at a preset time. When this time overlaps with peak business periods, backup tasks consume significant system resources, causing performance degradation. While load prediction-based solutions can schedule backups during off-peak hours, prediction errors may result in backups being scheduled at suboptimal times or missing the window of opportunity for sudden business disruptions. 2. Lack of scheduled plan anchor constraints. Pure load-aware solutions treat the original scheduled plan as a completely negligible suggestion; the actual execution time of backup tasks is unrelated to the original plan. This makes it difficult for operations personnel to determine the actual backup protection rhythm and predict the recovery point target's protection status. When the system is under high load for a prolonged period, problems such as inconsistent backup intervals and disordered protection rhythms may occur. 3. Lack of intrinsic constraint mechanisms for maximum latency boundaries. Constraints preventing backups from being indefinitely postponed are usually provided indirectly by external service level agreement (SLA) modules, rather than being intrinsic parameters within the scheduler. The SLA constraint granularity is frequency-level (e.g., once a day), rather than a fixed latency duration calculated from the original scheduled point. This leads to backup tasks being repeatedly postponed until a Service Level Agreement (SLA) alarm is triggered when the system is under sustained high load. SLA alarms are typically reactive and passive, rather than proactive and preventative. There is a risk of permanent backup delays due to sustained high load. In pure load-aware solutions, if the business system is under sustained high load (such as during e-commerce promotions or peak database batch processing periods), backup tasks may be repeatedly postponed, eventually exceeding the business's acceptable recovery target. There is a lack of a mechanism to force backups to start under sustained high load, typically relying on manual administrator intervention or post-event alarms, increasing operational risks and human burden. Scheduling decisions lack time-dimensional optimization. Load-aware solutions typically make binary decisions (execute or postpone) based on the current load threshold, without considering the time dimension of how much time has passed since the original planned point. For example, a daily task scheduled for 2 PM might be postponed if the load is high at 2 PM, postponed if the load is moderate at 3 PM, but might be started if the load is slightly high at 4 PM—because it has already been delayed by 2 hours, approaching the maximum delay boundary. There is a lack of a time-load joint optimization decision-making mechanism. The switch between scheduled backups and load awareness is abrupt. Scheduled backups and load awareness are typically mutually exclusive: either pure scheduled backups (without load awareness) or pure load awareness (ignoring the scheduled schedule). There is a lack of a smooth, bounded, and flexible transition mechanism that allows backup tasks to dynamically switch between scheduled and flexible modes based on load status and time offsets. Backup window management is coarse-grained. A backup window is the time interval within a backup scheme during which backup tasks are allowed to execute, typically used to avoid peak business periods. A backup window is usually a global time interval (e.g., 23:00 to 06:00 the next day), within which backups are allowed to execute.However, this coarse-grained management cannot adapt to fine-grained fluctuations in business load—for example, there may be brief business spikes within the backup window, while business troughs may occur outside the backup window. There is a lack of mechanisms to further fine-tune based on real-time load within the backup window framework. There is also a lack of a progressive resource monitoring strategy during periods of delay. After postponing backups, a fixed interval (e.g., checking every 5 minutes) is typically used to reassess the load. This fixed-interval strategy is not responsive enough when the load changes rapidly, and may incur unnecessary monitoring overhead when the load is stable. There is also a lack of a strategy to dynamically adjust the monitoring frequency based on load change trends.

[0036] Therefore, a backup scheduling solution is needed that can maintain the determinism of the scheduled backup plan while dynamically adjusting the execution time based on the resource load of the business system and setting a maximum delay boundary relative to the original scheduled point. This solution should ensure that backup tasks are executed promptly when the load is low and conditionally and elastically offset when the load is high, but it must never allow them to escape the protection range of the scheduled plan due to sustained high load.

[0037] Based on this, this application provides a backup buffer time for the system when the preset backup time arrives but the current resource load information is too high. It also sets a target delay time and a target backup condition that changes over time within the target delay time. Within the target delay time, it determines whether the current resource load information meets the target backup condition, and then decides whether to perform a backup. This eliminates the need to perform backups when the load is too high, improving backup efficiency. While retaining the scheduled backup plan as a fixed anchor point, a resource load awareness mechanism is introduced, allowing backup tasks to flexibly shift their execution time when the load is high. Simultaneously, a maximum delay boundary relative to the original scheduled point is introduced. When this boundary is reached, backup is forcibly started, thus preventing backup tasks from being permanently delayed due to continuous high load.

[0038] Specifically, this could be a ternary coupled scheduling model based on scheduled anchor points, load-aware elastic offsets, and a maximum latency hard boundary. This model uses the maximum latency boundary as an independent constraint parameter within the scheduler to prevent backup tasks from being permanently delayed due to sustained high load. Instead of treating scheduled backups and load awareness as an either-or alternative, it integrates them into a bounded, elastic, unified scheduling framework. This framework can minimize the impact of backups on business system resources without compromising the deterministic nature of the backup protection rhythm, while simultaneously eliminating the risk of indefinite delays inherent in pure load-aware solutions through the maximum latency boundary.

[0039] In one embodiment, such as Figure 1As shown, a load-aware elastic backup method is provided. This embodiment illustrates the application of this method to a server. It is understood that this method can also be applied to terminals, and also to systems including terminals and servers, and is implemented through interaction between the terminal and the server, including the following steps S202 to S206. Wherein:

[0040] Step S202: When the preset backup time is detected, obtain the current resource load information of the business system to be backed up.

[0041] The server can be a device used for backup management. The server can pre-set a backup time for the business system. This pre-set backup time, also known as the scheduled anchor point, represents the preset execution time of the backup task, serving as an indispensable baseline time for scheduling decisions. Examples include 2:00 PM daily or 2:00 AM every Monday. When the pre-set backup time arrives, the server can obtain the current resource load information of the business system to be backed up. This current resource load information can be determined based on the resource load status of the business system. Resource load status refers to the resource utilization of the business system at a given moment, which may include one or more dimensions such as CPU utilization, memory utilization, disk I / O queue depth, network bandwidth utilization, and application layer response time. The current resource load information can also be called a comprehensive load index, which refers to an index that combines multiple resource load indicators into a single value for direct comparison with a load threshold.

[0042] Step S204: If it is determined from the above current resource load information that the target backup conditions are not met, then within the target delay time, the above current resource load information is checked according to the target detection period to see if the target backup conditions are met; the above target backup conditions and the above target detection period are adjusted according to the change of the current time after the above preset backup time.

[0043] Once the server determines the current resource load information, it can compare this information with the target backup conditions to determine whether the current load meets those conditions. For example, if the current load does not meet the backup conditions, the server can initially delay the backup task and, within the target delay time, check the current load to see if it meets the backup conditions according to the target detection cycle.

[0044] The target backup conditions can be pre-set conditions used to check whether the current resource load information is sufficient to start the backup at a preset backup time. Target backup conditions can be based on resource load thresholds. For example, target backup conditions may include a high load threshold and a low load threshold. A low load threshold means that when the overall load index (current resource load information) is below this threshold, the backup task will be started immediately (regardless of latency). A high load threshold means that when the overall load index is above this threshold, the backup task will be delayed, and this threshold can be dynamically relaxed as the latency increases. The target backup conditions can be adjusted as the current time changes after the preset backup time. For example, if the preset backup time arrives but the backup has not started, the server can adjust the resource load threshold as the current time changes after the preset backup time, thus relaxing the target backup conditions. This dynamic threshold adjustment can gradually relax the high load threshold strategy as the latency increases, allowing the backup task to start even under high load when the latency is large. Among them, the dynamic threshold adjustment for the target backup conditions is not limited to linear relaxation, but can also adopt step relaxation, exponential relaxation, adaptive relaxation based on load prediction curve, or threshold optimization strategy based on reinforcement learning.

[0045] The target delay time represents the pre-defined maximum delay boundary. The maximum delay boundary represents the maximum allowable delay time relative to the original scheduled execution time (preset backup time). When the cumulative delay of the backup task since the scheduled execution time reaches this boundary, the backup must be forcibly started regardless of the current load. Forced start means that when the delay time of the backup task reaches the maximum delay boundary, the backup is started immediately regardless of the current load status. Thus, the server achieves elastic offset of the actual execution time of the backup task by setting the target delay time. Elastic offset means that the backup task is conditionally delayed after the scheduled execution time (preset backup time) according to the resource load status, and the offset is constrained by the maximum delay boundary (target delay time). The maximum delay boundary (target delay time) can be manually configured by the user, automatically generated by the system according to the backup frequency (e.g., equal to the backup frequency cycle), or dynamically adjusted according to the business importance level (the maximum delay boundary is shorter for important businesses).

[0046] The target detection period refers to the period during which the server checks whether the current resource load information meets the target backup conditions when the preset backup time arrives but the backup task has not yet started. The target detection period can also be adjusted as the current time changes after the preset backup time. For example, as the current time moves further away from the preset backup time, the accumulated time from the preset backup time to the current time gets closer to the target delay time. The server can gradually increase the target detection period, making the detection period slower as the backup task startup delay increases. This achieves a progressive monitoring strategy, that is, a strategy that dynamically adjusts the monitoring period and monitoring granularity based on the delay progress and load change trend after the backup task is delayed. For progressive monitoring strategies, the server's monitoring period (target detection period) adjustment is not limited to a three-stage (initial / mid-term / late-term) approach; it can also employ more stages or continuous functional adjustments. The adjustment logic of the monitoring period can also be based on the load change rate (derivative) rather than the delay progress.

[0047] Step S206: If the current resource load information is detected to meet the target backup conditions within the target delay time, then a backup task for the business system is executed.

[0048] Within the target delay time, the server can check whether the current resource load information meets the target backup conditions at the current moment according to the target detection cycle. If so, the server can determine that the backup task can be executed at the current moment, and thus execute the backup task for the business system. If the server's current resource load information still does not meet the target backup conditions when the target delay time arrives, the server can also force the backup task to start. During the execution of the backup task, the server can perform load throttling, that is, the server dynamically reduces the backup rate to reduce the consumption of system resources.

[0049] Specifically, this embodiment relates to load-aware bounded elastic timed backup scheduling in the fields of computer data backup, disaster recovery protection, system resource scheduling, and intelligent task scheduling. It can be applied to timed backup scenarios for virtualization platforms, physical servers, container clusters, database systems, and various business applications. These business systems include, but are not limited to, enterprise systems, financial systems, database services, web application services, containerized microservices, virtualization platforms, and various business middleware.

[0050] like Figure 2 As shown, Figure 2 This is a schematic diagram of the scheduling steps in one embodiment. The scheduling process is implemented based on a ternary coupled scheduling model. The ternary coupled scheduling model represents a scheduling model composed of three coupled elements: a timing plan anchor point (preset backup time), a load-aware elastic offset, and a maximum delay hard boundary (target delay time).

[0051] The server employs a ternary coupled scheduling model consisting of a scheduled anchor point, load-aware elastic offset, and a maximum latency hard boundary. In this model, the scheduled anchor point is an inescapable point; the load-aware elastic offset is a tool for fine-tuning around the anchor point; and the maximum latency hard boundary is an intrinsic parameter within the scheduler. These three elements work together to ensure that backup tasks can be executed promptly during periods of low load to minimize business impact, and can be enforced during periods of sustained high load to maintain backup protection rhythm.

[0052] In the aforementioned load-aware elastic backup method, when the preset backup time is detected and the current resource load information of the business system to be backed up determines that the target backup conditions are not met, the method checks whether the current resource load meets the target backup conditions that change over time within the target delay time, according to the target detection period. If it does, the backup task for the business system is executed. Compared to traditional backups performed at fixed intervals, this application provides a backup buffer time for the system by setting a target delay time and defining the target backup conditions that change over time within the target delay time when the preset backup time arrives but the current resource load information is too high. It also determines whether to perform a backup by judging whether the current resource load information meets the target backup conditions within the target delay time. This eliminates the need to perform backups when the load is too high, thus improving backup efficiency.

[0053] In one embodiment, obtaining the current resource load information of the business system to be backed up includes: obtaining various operating information corresponding to the business system; determining the weight of each type of operating information according to the type of backup task corresponding to the business system; and determining the current resource load information of the business system according to the various types of operating information and their corresponding weights.

[0054] In this embodiment, the server can determine the current resource load information by combining various operational information of the business system. Specifically, the server can acquire various operational information corresponding to the business system; that is, the server can acquire multiple types of operational information corresponding to the business system. The server can also determine the weight of various operational information based on the type of backup task corresponding to the business system. The weights of the acquired operational information can differ for different types of backup tasks, meaning different backup tasks can emphasize different operational load concerns. Therefore, the server can determine the current resource load information of the business system based on the aforementioned operational information and its corresponding weights. For example, the server sets corresponding indicator values ​​for various operational information and performs a weighted calculation by combining the weights of various operational information to obtain the current resource load information. In other words, the current resource load information can represent a numerical value indicating the severity of the current resource load on the business system.

[0055] Specifically, the server may include a resource load awareness module. This module detects the resource load status of the business system when the planned execution time (preset backup time) arrives, and during the monitoring period (target detection period) of the delay period (target delay time). The resource load status may include one or more dimensions of metrics (operational information), such as CPU utilization, memory utilization, disk I / O queue depth, network bandwidth utilization, disk latency, memory swapping rate, and application layer response time (e.g., database query response time, HTTP request response time). The server can configure which metrics participate in the evaluation and the weight of each metric (operational information) through the module. For example, for database backup tasks, disk I / O queue depth and database query response time can be configured to have higher weights; for file server backup tasks, disk read / write speed and network bandwidth utilization can be configured to have higher weights. The server uses the module to comprehensively calculate a single composite load index as the current resource load information for subsequent threshold comparisons.

[0056] The comprehensive load index can be calculated using different combinations of indicators and weighting methods, such as adding indicators like network bandwidth utilization, application-layer transaction throughput, disk latency, and memory swapping rate. Indicators can also be extended from the system level to the application level, such as database query response time, message queue backlog depth, and cache hit rate. The comprehensive load index is not limited to weighted averages; it can also employ the maximum value method (taking the largest value among all indicators), fuzzy comprehensive evaluation, principal component analysis, or a machine learning-based comprehensive scoring model.

[0057] Through this embodiment, the server can determine the current resource load information based on various operational information and the weights corresponding to the backup task types, thereby improving the accuracy of determining the resource load status of the business system.

[0058] In one embodiment, the step of obtaining the target delay time includes: obtaining the preset backup period corresponding to the above-mentioned business system; and determining the target delay time based on the time size corresponding to the preset backup period.

[0059] In this embodiment, the server can set a target delay time for backup tasks that cannot start on time at the preset backup time. The target delay time represents the maximum time that the backup task is allowed to start with a delay starting from the preset backup time. When determining the target delay time, the server can base it on the preset backup cycle of the business system. The preset backup cycle represents the pre-set cycle for backing up the business system. After obtaining the preset backup cycle corresponding to the business system, the server can determine the target delay time based on the time value corresponding to the preset backup cycle.

[0060] Specifically, the server includes a maximum latency boundary management module. This module is used to set and maintain the maximum latency boundary (target latency time) relative to the original scheduled execution time (preset backup time). The maximum latency boundary is a fixed duration, such as 24 hours (for a daily backup plan), 4 hours (for an hourly backup plan), or 7 days (for a weekly backup plan). The maximum latency boundary can be configured by the user or automatically generated by the system based on the backup frequency (preset backup cycle) (e.g., the maximum latency boundary equals the preset backup cycle). When the cumulative latency of the backup task since the scheduled execution time reaches the maximum latency boundary, the maximum latency boundary management module sends a forced start signal to the elastic offset decision module. Regardless of the current resource load, the backup task must start immediately. This module is also responsible for recording the forced start event to the audit and alarm module during forced start, so that operations and maintenance personnel can trace it.

[0061] This embodiment allows the server to determine the target latency time based on the preset backup cycle of the business system, avoiding indefinite backup delays and improving backup efficiency. It eliminates the indefinite postponement inherent in pure load-aware solutions. Through hard constraints on the maximum latency boundary, even if the business system remains under high load, backup tasks will not be postponed indefinitely, ensuring that the backup protection window remains within a controllable range.

[0062] In one embodiment, the step of obtaining the target backup conditions includes: determining the cumulative delay time based on the preset backup time and the current time; adjusting the target resource load threshold based on the cumulative delay time to obtain the target backup conditions; the magnitude of the target resource load threshold is positively correlated with the magnitude of the cumulative delay time.

[0063] In this embodiment, the server can dynamically adjust the target backup conditions as the current time changes after the preset backup time. The server can determine the cumulative delay time based on the preset backup time and the current time; for example, the server accumulates the time from the preset backup time to the current time. The server can adjust the target resource load threshold based on the cumulative delay time corresponding to the current time, obtaining the target resource load threshold for the current time, which serves as the target backup condition. The target resource load threshold can be a threshold for determining whether to allow the backup task to start. The server determines whether to allow the backup task to start by comparing the threshold with the current resource load information. The size of the target resource load threshold can be positively correlated with the size of the cumulative delay time. For example, the longer the cumulative delay time, the larger the value of the target resource load threshold can be, thus exhibiting a state where the longer the delay without starting the backup task, the more relaxed the conditions for allowing the backup task to start are, to prevent affecting the efficiency of the backup task.

[0064] Specifically, the server includes an elastic offset decision module. This module determines whether to initiate or delay backup based on the current resource load status when the scheduled execution time (preset backup time) or monitoring period (preset backup period) arrives. The core logic of the module is as follows: when the overall load index (current resource load information) is lower than a preset threshold (low load threshold), the backup task is initiated immediately; when the overall load index is higher than a preset threshold (high load threshold, target resource load threshold), the backup task is delayed, and a waiting monitoring loop is entered. The module is also responsible for dynamically adjusting the load threshold (target resource load threshold) based on the accumulated delay time. Specifically, as the delay time increases, the high load threshold (target resource load threshold) can be gradually relaxed (e.g., from CPU utilization <30% to CPU utilization <50%), allowing the backup task to start even under moderate load when the delay is large. This threshold gradual change strategy allows for a smooth transition between load-priority and time-priority scheduling decisions. The elastic offset decision module can be implemented using a rule engine, state machine, finite automaton, decision tree, or optimization solver. The decision-making logic is not limited to threshold comparison; it can also employ multi-objective optimization (simultaneously minimizing resource impact and latency).

[0065] like Figure 3 As shown, Figure 3 This is a schematic diagram of the progressive monitoring steps in one embodiment. In the initial stage of delay, corresponding to a delay less than 20% (target delay time), the monitoring period can be 30 seconds, the load threshold is strict (50%), the decision strategy is priority waiting, characterized by high-frequency strict monitoring, and the overall mode is high-frequency monitoring plus a strict threshold. For the middle stage of delay, corresponding to a delay between 20% and 80%, the monitoring period is 2 minutes, the load threshold is moderate (60%), the decision strategy is a balanced strategy, characterized by mid-frequency balance, and the overall mode is mid-frequency monitoring plus a balanced threshold. In the later stage of delay, corresponding to a delay greater than 80%, the monitoring period is 5 minutes, the load threshold is relaxed (70%), the decision strategy is to prioritize time, characterized by low-frequency monitoring plus a countdown, and the overall mode is low-frequency monitoring plus a relaxed threshold plus a countdown. The overall change logic is time progression, delay increase, and threshold relaxation.

[0066] The server can also independently schedule multiple backup tasks, such as Figure 4 As shown, Figure 4 This is a schematic diagram illustrating the independent scheduling of multiple backup tasks in one embodiment. The horizontal axis is the time axis, which includes two independent timelines corresponding to task A (preset backup time is 14:00 every day) and task B (preset backup time is 14:30 every day). Each timeline is equipped with a dedicated anchor point (preset backup time), a delay monitoring interval (target delay time), a start node, and a completion node.

[0067] Task A's anchor point is aligned to the 14:00 timescale. Since the current resource status information at 14:00 does not meet the target backup conditions for that time, the server delays its start to 14:45 via latency monitoring. After starting at 14:45, backup task A is executed until completion. Task B's anchor point is aligned to the 14:30 timescale. Since the current resource status information at 14:30 does not meet the target backup conditions for that time, the server delays its start to 15:10 via latency monitoring. After starting at 15:10, backup task B is executed until completion. Each task is independently evaluated, independently delayed, and independently timed; the timing of the two tasks does not interfere with each other.

[0068] This embodiment allows the server to dynamically adjust target backup conditions based on cumulative latency, gradually increasing the probability of delayed backup tasks being initiated as the cumulative latency increases. This improves backup efficiency and enables a smooth transition between load-priority and time-priority scheduling. Through a dynamic threshold adjustment mechanism, it prioritizes waiting for low-load windows in the early stages of latency, gradually relaxing load requirements in the later stages, and finally initiating unconditionally when the maximum latency boundary is reached. This ensures a smooth transition between resource protection and data protection in scheduling decisions. Furthermore, it supports independent scheduling of multiple tasks. Each backup task has an independent planning anchor, latency timer, and scheduling decision chain, ensuring that multiple tasks do not interfere with each other and facilitating the management of diverse backup strategies in complex environments.

[0069] In one embodiment, the step of obtaining the target detection period includes: if the ratio of the cumulative delay time to the target delay time is less than a first proportional threshold, then determining the target detection period based on a first detection period; if the ratio of the cumulative delay time to the target delay time is greater than or equal to the first proportional threshold and less than a second proportional threshold, then determining the target detection period based on a second detection period; if the ratio of the cumulative delay time to the target delay time is greater than or equal to the second proportional threshold, then determining the target detection period based on a third detection period; wherein the durations of the first detection period, the second detection period, and the third detection period increase sequentially.

[0070] In this embodiment, the target detection period can be dynamically adjusted as the cumulative latency changes. For example, the server determines the adjustment method for the target detection period based on the ratio of the cumulative latency to the target latency. The server can set a first proportional threshold (e.g., 20%) and a second proportional threshold (e.g., 80%). The second proportional threshold can be greater than the first proportional threshold.

[0071] If the server detects that the ratio of the cumulative latency time to the target latency time is less than a first proportional threshold, it indicates that the current latency processing is in its initial stage, and the server determines the target detection period based on a first detection period. If the ratio of the cumulative latency time to the target latency time is greater than or equal to the first proportional threshold and less than a second proportional threshold, it indicates that the current latency is in its middle stage, and the server determines the target detection period based on a second detection period. If the ratio of the cumulative latency time to the target latency time is greater than or equal to the second proportional threshold, it indicates that the current latency is in its later stage, and the server determines the target detection period based on a third detection period. The durations of the first, second, and third detection periods increase sequentially; for example, the first detection period could be 30 seconds, the second detection period could be 2 minutes, and the third detection period could be 5 minutes.

[0072] Specifically, the server includes a progressive monitoring strategy module. This module dynamically adjusts the monitoring cycle (target detection cycle) and monitoring granularity after backup tasks are delayed. The core logic of the module is as follows: In the early stages of delay (e.g., when the delay time is less than 20% of the maximum delay boundary (first proportional threshold)), a shorter monitoring cycle (first detection cycle, such as checking every 30 seconds) and a stricter load threshold are used to start backups as soon as the load decreases; in the middle stages of delay (e.g., when the delay time is between 20% (first proportional threshold) and 80% (second proportional threshold) of the maximum delay boundary), a medium monitoring cycle (second detection cycle, such as checking every 2 minutes) and a medium load threshold are used to balance monitoring overhead and startup timeliness; in the later stages of delay (e.g., when the delay time is greater than 80% of the maximum delay boundary), a longer monitoring cycle (third detection cycle, such as checking every 5 minutes) is used, but the load threshold is significantly relaxed, and a forced startup countdown reminder is added. In addition, the server can dynamically adjust the monitoring cycle according to load change trends (such as load increase, decrease, or fluctuation), shortening the monitoring cycle when the load drops rapidly and extending the monitoring cycle when the load is stable.

[0073] Through this embodiment, the server can dynamically adjust the detection cycle of current resource load information within the target latency time based on the cumulative latency time. Through a progressive monitoring strategy, high-frequency monitoring is performed in the early stage of latency to capture load troughs, medium-frequency monitoring is performed in the middle stage of latency to balance overhead, and low-frequency monitoring is performed in the later stage of latency to reduce resource consumption, thereby reducing the overall resource consumption of the monitoring mechanism itself.

[0074] In one embodiment, after detecting whether the current resource load information meets the target backup conditions according to the target detection cycle within the target delay time, the method further includes: if the current resource load information does not meet the target backup conditions when the target delay time is reached, then executing a backup task for the business system according to the forced backup signal.

[0075] In this embodiment, when the start of the backup task is delayed, the server dynamically monitors whether the current resource load information meets the target backup conditions at the corresponding time within the target delay time. If the cumulative delay time from the preset backup time has reached the target delay time, but the current resource load information does not meet the target backup conditions, the server can determine that the backup task needs to be forcibly started. At this time, the server can trigger a forced backup signal and execute the backup task for the aforementioned business system according to the forced backup signal. If the backup task is started based on the forced backup signal, the server can issue corresponding alarms based on the forced backup signal.

[0076] Through this embodiment, the server can force a backup to be performed when the target delay time is reached, avoiding the backup being delayed indefinitely and improving backup efficiency.

[0077] In one exemplary embodiment, such as Figure 5 As shown, Figure 5 This is a flowchart illustrating a load-aware elastic backup method in another embodiment. In this embodiment, when the scheduled anchor point (preset backup time) arrives, the server first sequentially checks the resource load (current resource load information), calculates the comprehensive load index (target backup condition), and determines whether the load (current resource load information) is less than a low threshold. If the determination result is yes, the backup task is started immediately and executed. If the determination result is no, the server determines whether the load is greater than a high threshold (target resource load threshold, latency monitoring). If the determination result is yes, the server performs latency entry monitoring and progressive monitoring (dynamic adjustment cycle), and then determines whether the maximum latency boundary (target latency time) has been reached. If the determination result is yes, the backup is forcibly started and the backup task is executed. If the load is less than or equal to the high threshold, corresponding to a medium load scenario, the backup task is executed directly. After the backup task is completed, the latency timer is reset, and the server waits for the next anchor point.

[0078] The server may include an elastic backup system, which can be divided into a scheduled plan anchor management module, a resource load awareness module, an elastic offset decision module, a maximum latency boundary management module, a progressive monitoring strategy module, a backup task scheduling and execution module, and an auditing and alarm module.

[0079] The scheduled task anchor management module is used to maintain and manage the preset scheduled tasks (preset backup times) for backup tasks. Each backup task is associated with a scheduled execution time (e.g., 14:00 daily). This scheduled execution time is set by the user through the configuration interface or generated by the system default policy. Once set, the scheduled execution time serves as an anchor point that cannot be arbitrarily changed, and all subsequent scheduling decisions revolve around this anchor point. The module is also responsible for sending a scheduling evaluation request to the elastic offset decision module when the scheduled execution time arrives.

[0080] The resource load awareness module detects the resource load status of the business system when the planned execution time (preset backup time) arrives, and during the monitoring period (target detection period) of the delay period (target delay time). Resource load status can include one or more dimensions of metrics (operational information), such as CPU utilization, memory utilization, disk I / O queue depth, network bandwidth utilization, disk latency, memory swapping rate, and application layer response time (e.g., database query response time, HTTP request response time). The server can configure which metrics participate in the evaluation and the weight of each metric (operational information) through the module. For example, for database backup tasks, disk I / O queue depth and database query response time can be configured to have higher weights; for file server backup tasks, disk read / write speed and network bandwidth utilization can be configured to have higher weights. The server uses the module to comprehensively calculate a single composite load index (Composite LoadIndex) from the multi-dimensional metrics as the current resource load information for subsequent threshold comparisons.

[0081] The elastic offset decision module determines whether to initiate or delay backup based on the current resource load status when the scheduled execution time (preset backup time) or monitoring period (preset backup period) arrives. The core logic of the module is as follows: when the overall load index (current resource load information) is lower than a preset threshold (low load threshold), the backup task is initiated immediately; when the overall load index is higher than a preset threshold (high load threshold, target resource load threshold), the backup task is delayed and a waiting monitoring loop is entered. The module is also responsible for dynamically adjusting the load threshold (target resource load threshold) based on the accumulated delay time (cumulative delay time). Specifically, as the delay time increases, the high load threshold (target resource load threshold) can be gradually relaxed (e.g., from CPU utilization <30% to CPU utilization <50%), allowing the backup task to start even under moderate load when the delay is significant. This threshold gradual change strategy allows for a smooth transition in scheduling decisions between load priority and time priority.

[0082] The Maximum Delay Boundary Management module is used to set and maintain the maximum delay boundary (target delay time) relative to the original scheduled execution time (preset backup time). The maximum delay boundary is a fixed duration, such as 24 hours (for a daily backup plan), 4 hours (for an hourly backup plan), or 7 days (for a weekly backup plan). The maximum delay boundary can be configured by the user or automatically generated by the system based on the backup frequency (preset backup cycle) (e.g., the maximum delay boundary equals the preset backup cycle). When the cumulative delay of the backup task from the scheduled execution time reaches the maximum delay boundary, the Maximum Delay Boundary Management module sends a forced start signal to the Elastic Offset Decision Module. Regardless of the current resource load, the backup task must start immediately. This module is also responsible for recording the forced start event to the Audit and Alarm Module during forced start for maintenance personnel to trace.

[0083] The progressive monitoring strategy module dynamically adjusts the monitoring cycle (target detection cycle) and monitoring granularity after backup tasks are delayed. The core logic of the module is as follows: In the early stages of delay (e.g., when the delay time is less than 20% of the maximum delay boundary (first proportional threshold)), a shorter monitoring cycle (first detection cycle, such as checking every 30 seconds) and a stricter load threshold are used to initiate backups as quickly as possible when the load decreases; in the middle stages of delay (e.g., when the delay time is between 20% (first proportional threshold) and 80% (second proportional threshold) of the maximum delay boundary), a medium monitoring cycle (second detection cycle, such as checking every 2 minutes) and a medium load threshold are used to balance monitoring overhead and startup timeliness; in the later stages of delay (e.g., when the delay time is greater than 80% of the maximum delay boundary), a longer monitoring cycle (third detection cycle, such as checking every 5 minutes) is used, but the load threshold is significantly relaxed, and a forced startup countdown reminder is added. Furthermore, the server can dynamically adjust the monitoring cycle based on load change trends (e.g., load increase, decrease, or fluctuation), shortening the monitoring cycle when the load drops rapidly and lengthening the monitoring cycle when the load stabilizes.

[0084] The backup task scheduling and execution module receives the start command from the elastic offset decision module and executes the actual backup operation. Backup types can include full backup, incremental backup, differential backup, log backup, snapshot backup, etc. Before starting the backup, it confirms the current latency status with the maximum latency boundary management module so that the latency timer can be reset after the backup is completed. If the backup execution fails, the module reports a failure event to the elastic offset decision module, which then decides whether to reschedule within the latency boundary.

[0085] The auditing and alarm module records all scheduling decision events, including: arrival of planned execution time, load detection results (high / low), delayed start decisions, monitoring cycle adjustments, threshold adjustments, arrival of maximum latency boundaries, forced start events, successful / failed backup execution, and latency reset after backup completion. The module supports outputting audit logs to log files, databases, or external monitoring systems. When a forced start event occurs (i.e., a backup is forcibly executed based on a forced backup signal due to reaching the maximum latency boundary), the module sends an alarm notification to operations and maintenance personnel. Notification methods may include email, SMS, instant messaging, or system alarms.

[0086] The scheduling framework is not limited to backup tasks; it can also be applied to other scheduled background tasks, such as data archiving, log cleanup, index rebuilding, statistical analysis, and security scanning—tasks that need to be executed at specific intervals but can be moderately offset. Each module can be deployed locally on the backup server or distributed across agent nodes, agent nodes, or the cloud control plane. The resource load awareness module can collect data locally from the protected business system or from a centralized monitoring platform. Audit logs can be stored in local log files, relational databases, time-series databases, or distributed log systems. Alarm notifications can be sent via email, SMS, webhooks, instant messaging, or Simple Network Management Protocol (SNMP) traps. Regarding integration with external systems, the scheduling framework can be integrated as a standalone module with existing backup software or implemented as an embedded function within the backup software.

[0087] In some embodiments, an example of the coordinated operation of scheduled anchors, elastic offsets, and maximum latency boundaries is provided. The following example describes the complete execution flow of a typical backup task within a bounded elastic scheduling framework. Assume a user configures an incremental backup task to execute daily at 14:00 (the preset backup time), and configures the maximum latency boundary (target latency time) to be 24 hours (i.e., it must be executed no later than 14:00 the following day). Resource load awareness metrics are configured as CPU utilization (weight 40%), memory utilization (weight 30%), and disk I / O queue depth (weight 30%). The overall load index is calculated as: Overall Load Index = 0.4 * CPU Utilization + 0.3 * Memory Utilization + 0.3 * Disk I / O Queue Depth. The high load threshold (target resource load threshold) is initially set to 50%, and the low load threshold is set to 30%.

[0088] Scenario 1: At 14:00, the overall load index of the business system is 25% (below the load threshold of 30%), and the elastic offset decision module immediately starts the backup task. After the backup is completed, the maximum delay boundary management module resets the delay timer and waits for the next scheduled execution time (14:00 the next day).

[0089] Scenario 2: At 14:00, the system's overall load index is 65% (above the high load threshold of 50%), and the elastic offset decision module decides to delay startup. The progressive monitoring strategy module begins monitoring the load every 30 seconds. At 14:30, the load drops to 45% (below the initial high threshold of 50% but above the low threshold of 30%), at which point a delay of 30 minutes has occurred (approximately 2% of the maximum delay boundary of 24 hours), placing it in the early stages of delay. The elastic offset decision module decides to continue waiting for a lower load. At 15:00, the load drops to 28% (below the low threshold of 30%), and the elastic offset decision module initiates backup. After backup is complete, the delay timer is reset.

[0090] Scenario 3: At 14:00, the system's overall load index was 75% (above the high load threshold), and the system started with a delay. Subsequently, the system load remained high (60%-80%), and the backup task was repeatedly postponed. As the delay time increased, the elastic offset decision module gradually relaxed the load threshold: at 18:00 (4-hour delay, accounting for 16.7% of the maximum delay boundary), the high threshold was relaxed from 50% to 55%; at 22:00 (8-hour delay, accounting for 33.3%), the high threshold was relaxed to 60%; and at 06:00 the next day (16-hour delay, accounting for 66.7%), the high threshold was relaxed to 70%. The progressive monitoring strategy module simultaneously adjusted the monitoring cycle: from every 30 seconds to every 2 minutes (after a 4-hour delay), and then to every 5 minutes (after a 16-hour delay). At 13:00 the next day, the system load was 65%, lower than the currently relaxed high threshold of 70%, and the elastic offset decision module initiated the backup. After the backup was completed, the delay timer was reset.

[0091] Scenario 4: At 14:00, the system's overall load index was 80% (above the high load threshold), resulting in a delayed startup. Subsequently, the system load remained extremely high (85%-95%), and the backup task consistently failed to meet the relaxed threshold. The progressive monitoring strategy module issued an alarm when the delay approached the maximum delay boundary. At 13:55 the following day, with only 5 minutes remaining until the maximum delay boundary (14:00 the next day), the maximum delay boundary management module sent a forced startup signal to the elastic offset decision module. The elastic offset decision module ignored the current load status and immediately started the backup. The audit and alarm module recorded the forced startup event and sent an alarm notification to the operations and maintenance personnel. After the backup was completed, the delay timer was reset.

[0092] Scenario 5: The system is configured with multiple backup tasks, each with an independent scheduled execution time and maximum delay boundary. Task A executes daily at 14:00 with a maximum delay boundary of 24 hours; Task B executes daily at 14:30 with a maximum delay boundary of 24 hours. If Task A is delayed at 14:00 due to high load, the system will not automatically postpone Task B because of Task A's delay. Task B independently assesses its load status and makes a decision to start or delay at 14:30. The delay timers for the two tasks are maintained independently. If Task A starts at 14:45, and Task B is also delayed at 14:30, there will be no conflict because the backup execution module itself can manage concurrent or serial execution strategies.

[0093] Through the above embodiments, the server sets a target delay time and a target backup condition that changes over time within the target delay time when the preset backup time arrives but the current resource load information is too high. It then determines whether the current resource load information meets the target backup condition within the target delay time and decides whether to perform a backup. This provides a backup buffer time for the system, eliminating the need to perform backups when the load is too high and improving backup efficiency.

[0094] Furthermore, it can reduce the impact of backups on business systems. Through load-aware elastic offset, backup tasks can be executed during periods of low business load, reducing competition for CPU, memory, disk I / O, and network resources between backup tasks and business systems, thereby minimizing the impact of backups on business performance. It can also maintain the determinism of backup protection rhythm. Through a scheduled anchoring mechanism, the execution of backup tasks always revolves around preset schedule points, allowing operations personnel to clearly understand the actual protection rhythm of backups and facilitating the estimation of the protection status of recovery point targets. It also improves operational transparency and traceability. Through the auditing and alarm modules, all scheduling decisions (delay, startup, forced startup, threshold adjustment, etc.) are recorded, and forced startup events proactively alert operations personnel, facilitating problem tracing and strategy optimization. It is also compatible with existing scheduled backup frameworks, incrementally introduced without modifying the existing backup task model. Existing scheduled backup tasks can be seamlessly upgraded to bounded elastic scheduling mode or remain unchanged in pure scheduled mode, achieving a smooth transition. This also enhances user experience and configuration flexibility. Users can set scheduled tasks, maximum latency boundaries, load metrics, weights, and thresholds through a unified configuration interface, enjoying the benefits of intelligent scheduling without needing to understand the complexity of the underlying scheduling algorithms. Furthermore, it reduces the burden of manual maintenance, automatically making judgments based on the maximum latency boundary mechanism when the system is under continuous high load, minimizing the need for manual intervention.

[0095] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps. It is understood that the steps in different embodiments can be freely combined as needed, and all non-contradictory solutions formed by such combinations are within the scope of protection of this application.

[0096] Based on the same inventive concept, this application also provides a load-aware elastic backup device for implementing the load-aware elastic backup method described above. The solution provided by this device is similar to the implementation described in the above method; therefore, the specific limitations in one or more load-aware elastic backup device embodiments provided below can be found in the limitations of the load-aware elastic backup method described above, and will not be repeated here.

[0097] In one exemplary embodiment, such as Figure 6 As shown, a load-aware elastic backup device is provided, comprising: an acquisition module 500, a detection module 502, and a backup module 504, wherein:

[0098] The acquisition module 500 is used to acquire the current resource load information of the business system to be backed up when the preset backup time is detected.

[0099] The detection module 502 is used to detect whether the current resource load information meets the target backup conditions within the target delay time according to the target detection period if it is determined that the target backup conditions are not met based on the current resource load information. The target backup conditions and the target detection period are adjusted according to the change of the current time after the preset backup time.

[0100] The backup module 504 is used to execute a backup task for the business system if the current resource load information is detected to meet the target backup conditions within the target delay time.

[0101] In one embodiment, the acquisition module 500 is used to acquire various operational information corresponding to the business system; determine the weight of each type of operational information based on the type of backup task corresponding to the business system; and determine the current resource load information of the business system based on the various types of operational information and their corresponding weights.

[0102] In one embodiment, the detection module 502 is used to obtain the preset backup cycle corresponding to the business system and determine the target delay time based on the time size corresponding to the preset backup cycle.

[0103] In one embodiment, the detection module 502 is used to determine the cumulative delay time based on the preset backup time and the current time; adjust the target resource load threshold based on the cumulative delay time to obtain the target backup conditions; the magnitude of the target resource load threshold is positively correlated with the magnitude of the cumulative delay time.

[0104] In one embodiment, the detection module 502 is configured to: determine the target detection period according to a first detection period if the ratio of the cumulative delay time to the target delay time is less than a first proportional threshold; determine the target detection period according to a second detection period if the ratio of the cumulative delay time to the target delay time is greater than or equal to the first proportional threshold and less than a second proportional threshold; and determine the target detection period according to a third detection period if the ratio of the cumulative delay time to the target delay time is greater than or equal to the second proportional threshold; wherein the durations of the first detection period, the second detection period, and the third detection period increase sequentially.

[0105] In one embodiment, the apparatus further includes a forced backup module, configured to perform a backup task for the business system according to a forced backup signal if the current resource load information does not meet the target backup conditions when the target delay time is reached.

[0106] The modules in the aforementioned load-aware elastic backup device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the computer device's memory as software, so that the processor can invoke and execute the corresponding operations of each module.

[0107] In one exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 7As shown, this computer device includes a processor, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operating system and computer programs stored in the non-volatile storage media. The database stores business data. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. When the computer program is executed by the processor, it implements a load-aware, resilient backup method.

[0108] Those skilled in the art will understand that Figure 7 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.

[0109] In one exemplary embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the load-aware resilient backup method described above.

[0110] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the load-aware resilient backup method described above.

[0111] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the load-aware resilient backup method described above.

[0112] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0113] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0114] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0115] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A load-aware elastic backup method, characterized in that, The method includes: When the preset backup time is detected, obtain the current resource load information of the business system to be backed up; If it is determined from the current resource load information that the target backup conditions are not met, then within the target delay time, the current resource load information is checked according to the target detection period to see if the target backup conditions are met; the target backup conditions and the target detection period are adjusted according to the change of the current time after the preset backup time. If the current resource load information is detected to meet the target backup conditions within the target delay time, then a backup task for the business system is executed.

2. The method according to claim 1, characterized in that, The process of obtaining the current resource load information of the business system to be backed up includes: Obtain various operational information corresponding to the business system; The weights of various operational information are determined based on the type of backup task corresponding to the business system. Based on the various operational information and their corresponding weights, the current resource load information of the business system is determined.

3. The method according to claim 1, characterized in that, The steps for obtaining the target delay time include: Obtain the preset backup cycle corresponding to the business system; The target delay time is determined based on the time size corresponding to the preset backup cycle.

4. The method according to claim 1, characterized in that, The steps for obtaining the target backup conditions include: The cumulative delay time is determined based on the preset backup time and the current time. Based on the cumulative delay time, the target resource load threshold is adjusted to obtain the target backup conditions; the magnitude of the target resource load threshold is positively correlated with the magnitude of the cumulative delay time.

5. The method according to claim 4, characterized in that, The steps for obtaining the target detection period include: If the ratio of the cumulative delay time to the target delay time is less than the first ratio threshold, then the target detection period is determined according to the first detection period; If the ratio of the cumulative delay time to the target delay time is greater than or equal to the first ratio threshold and less than the second ratio threshold, then the target detection period is determined according to the second detection period; If the ratio of the cumulative delay time to the target delay time is greater than or equal to the second ratio threshold, then the target detection period is determined according to the third detection period; The durations of the first detection cycle, the second detection cycle, and the third detection cycle increase sequentially.

6. The method according to any one of claims 1 to 5, characterized in that, After detecting whether the current resource load information meets the target backup conditions according to the target detection period within the target delay time, the method further includes: If the current resource load information does not meet the target backup conditions when the target delay time is reached, then a backup task for the business system is executed according to the forced backup signal.

7. A load-aware elastic backup device, characterized in that, The device includes: The acquisition module is used to acquire the current resource load information of the business system to be backed up when the preset backup time is detected. The detection module is used to detect whether the current resource load information meets the target backup conditions within a target delay time and according to a target detection period if it is determined from the current resource load information that the target backup conditions are not met. The target backup conditions and the target detection period are adjusted according to the change of the current time after the preset backup time. The backup module is used to execute a backup task for the business system if the current resource load information is detected to meet the target backup conditions within the target delay time.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

Images