Method, apparatus and computer program product for backup

Abstract

The invention relates to a method, a device and a computer program product for backup. The method comprises the following steps: determining a plurality of parameters of a plurality of copy sessions in a waiting queue in response to the fact that a backup execution command is triggered; the method further includes determining a plurality of weights for the plurality of replication sessions based on the plurality of parameters for the plurality of replication sessions. The method further includes selecting at least one replicated session from the plurality of replicated sessions into a run queue based on the plurality of weights for the plurality of replicated sessions. The method further includes performing a backup task for at least one replication session in the run queue. In this way, each copy session is subjected to priority ranking, and a plurality of parameters are considered during ranking, so that the backup efficiency is improved, the number of waiting and failed tasks is reduced, data are better protected, the copy capacity of the system is enhanced, the copy limit number is increased, and the memory of the system is prevented from being used up.

Description

Technical Field

[0001] Embodiments of the present disclosure relate to the field of data management, and more particularly, to methods, devices, and computer program products for backup. Background Art

[0002] Data backup is a crucial measure for protecting data security and privacy. Backup tools can be used to protect data from unexpected loss in the event of a hardware or storage media failure. During the data backup process, the recovery point objective (RPO) is a key indicator of disaster recovery capabilities. RPO refers to the point in time to which systems and data must be restored after a disaster, representing the maximum amount of data loss a facility can tolerate.

[0003] When a large number of backup tasks are waiting to be executed on the same system, some are executed first in the run queue, while others are placed in the wait queue. Typically, backups use a first-in, first-out (FIFO) strategy. A FIFO memory is a dual-port buffer with a first-in, first-out policy. The first data entered is the first to be removed, meaning that the backup task that entered the wait queue first is selected first for the run queue. Summary of the Invention

[0004] Embodiments of the present disclosure provide a method, device, and computer program product for backup.

[0005] In a first aspect of an embodiment of the present disclosure, a backup method is provided. The method includes determining multiple parameters of multiple replication sessions in a waiting queue in response to a backup execution command being triggered. The method also includes determining multiple weights of the multiple replication sessions based on the multiple parameters of the multiple replication sessions. The method also includes selecting at least one replication session from the multiple replication sessions and placing it into a running queue based on the multiple weights of the multiple replication sessions. The method also includes executing a backup task for the at least one replication session in the running queue.

[0006] In a second aspect of an embodiment of the present disclosure, an electronic device is provided. The electronic device includes one or more processors; and a storage device for storing one or more programs. When the one or more programs are executed by the one or more processors, the one or more processors implement a method for backup. The method includes determining multiple parameters of multiple replication sessions in a waiting queue in response to a backup execution command being triggered; the method also includes determining multiple weights of the multiple replication sessions based on the multiple parameters of the multiple replication sessions. The method also includes selecting at least one replication session from the multiple replication sessions to enter a running queue based on the multiple weights of the multiple replication sessions. The method also includes executing a backup task for at least one replication session in the running queue.

[0007] In a third aspect of an embodiment of the present disclosure, a computer-readable storage medium is provided, storing a computer program thereon. When executed by a processor, the program implements a backup method. The method includes determining, in response to a backup execution command being triggered, multiple parameters of multiple replication sessions in a waiting queue. The method also includes determining multiple weights of the multiple replication sessions based on the multiple parameters of the multiple replication sessions. The method also includes selecting, based on the multiple weights of the multiple replication sessions, at least one replication session from the multiple replication sessions to enter a running queue. The method also includes executing a backup task for the at least one replication session in the running queue.

[0008] It should be understood that the contents described in the Summary of the Invention section are not intended to limit the key or important features of the embodiments of the present disclosure, nor are they intended to limit the scope of the present disclosure. Other features of the present disclosure will become readily understood through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] The above and other features, advantages and aspects of the embodiments of the present disclosure will become more apparent with reference to the following detailed description in conjunction with the accompanying drawings. In the accompanying drawings, the same or similar reference numerals represent the same or similar elements, wherein:

[0010] Figure 1 A schematic diagram illustrating an example environment in which various embodiments of the present disclosure may be implemented;

[0011] Figure 2 A flowchart of a method for backup according to some embodiments of the present disclosure is shown;

[0012] Figure 3 A flowchart illustrating a process from starting a backup to completing the backup according to some embodiments of the present disclosure is shown;

[0013] Figure 4 A schematic diagram illustrating a process of sorting replication sessions in a waiting queue according to weight according to some embodiments of the present disclosure is shown;

[0014] Figure 5 A schematic diagram illustrating a process of selecting a replication session from a waiting queue to enter a running queue according to some embodiments of the present disclosure; and

[0015] Figure 6 A block diagram of a device in which various embodiments of the present disclosure may be implemented is shown.

[0016] Throughout the drawings, the same or similar reference numbers denote the same or similar elements. DETAILED DESCRIPTION

[0017] The following describes embodiments of the present disclosure in more detail with reference to the accompanying drawings. Although certain embodiments of the present disclosure are shown in the accompanying drawings, it should be understood that the present disclosure can be implemented in various forms and should not be construed as limited to the embodiments described herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of the present disclosure. It should be understood that the drawings and embodiments of the present disclosure are for illustrative purposes only and are not intended to limit the scope of protection of the present disclosure.

[0018] In the description of the embodiments of the present disclosure, the term "including" and similar terms should be understood as open inclusion, that is, "including but not limited to". The term "based on" should be understood as "based at least in part on". The term "one embodiment" or "the embodiment" should be understood as "at least one embodiment". The terms "first", "second", etc. can refer to different or the same objects, unless explicitly stated otherwise. Other explicit and implicit definitions may also be included below.

[0019] When a system's hardware or storage media fails, a large number of backup tasks often occur on the same system. However, the system cannot execute all of these tasks simultaneously, forcing some backup tasks to wait in a waiting queue. Typically, the backup queuing strategy uses a FIFO method, where replication sessions are sorted by the time they arrived in the waiting queue. When a vacancy in the running queue becomes available, the replication session that arrived first is selected to enter the running queue for backup execution.

[0020] The FIFO approach often results in many queued tasks, which can lead to several problems over time. First, if the first replication session in the queue takes a long time to process, the waiting time for subsequent replication sessions will also be extended, causing them to miss one or more RPOs, resulting in a continuous data lag. Replication sessions that miss the RPO increase data inconsistency between the source and remote ends, increasing the risk of data loss.

[0021] Secondly, many long-running tasks are running in parallel. Due to the long-term resource consumption, more short-running tasks cannot be allowed to enter the running state. This reduces the system's replication capacity, making the system unable to support a short RPO and limiting the current number of replication limits. Finally, as time goes by, more and more tasks are queued, and the system becomes increasingly slow, not only leading to system out of memory (OOM) but also degrading the customer experience.

[0022] To this end, an embodiment of the present disclosure provides a solution for backup. The solution is to determine multiple parameters of multiple replication sessions in a waiting queue, determine the weights of the multiple replication sessions based on the multiple parameters, and select one or more replication sessions from the waiting queue to enter the running queue according to the weights of the replication sessions. In this way, each replication session will be prioritized, and multiple parameters are taken into account when sorting to improve backup efficiency, reduce the number of queued and failed backup tasks, improve the system's operating capacity, and reduce the number of backup tasks that miss the RPO, so that data is better protected, enhance the system's replication capabilities, support a shorter RPO, and increase the number of replication limits to avoid system memory exhaustion.

[0023] Figure 1 1 shows a schematic diagram of an example environment 100 in which various embodiments of the present disclosure may be implemented. Figure 1 As shown, example environment 100 may include backup task 101, which may include replication sessions 104, 105, 106, 107, 108, 109, and other replication sessions. In specific implementations, the number and generation times of replication sessions in backup task 101 are determined by the data that needs to be backed up in the event of a disaster. In some embodiments, replication sessions 104 through 109 may be generated in chronological order, e.g., replication session 104 is the earliest generated session, and replication session 109 is the latest generated session.

[0024] In some embodiments, the example environment 100 may also include a waiting queue 102. The copy sessions in the backup task 101 may reach the waiting queue 102 in chronological order. After the copy sessions enter the waiting queue 102, multiple parameters of the multiple copy sessions in the waiting queue may be determined. The parameters may include but are not limited to the arrival time, estimated processing time, turnaround time, and running queue length of the copy sessions. The type and quantity of parameters may be selected according to actual needs. All data that affect the backup results during the backup process may be selected as parameters, specifically to meet the purpose of supporting a shorter RPO and improving the system backup capability.

[0025] According to an embodiment of the present disclosure, after determining multiple parameters of multiple replication sessions in the waiting queue 102, weights of the multiple replication sessions can be calculated based on the determined multiple parameters. The weight of each replication session can be calculated based on one parameter or a combination of multiple parameters. The calculation method can be any algorithm determined based on the parameters. The scope of the present disclosure is not limited in this respect. After determining the weight of each replication session, the replication sessions can be sorted according to their weights, for example, Figure 1As shown, the weights of the copy session 110 , the copy session 111 , the copy session 112 , the copy session 113 , the copy session 114 , the copy session 115 , the copy session 116 , and the copy session 117 may increase in sequence or may decrease in sequence.

[0026] refer to Figure 1 The example environment 100 may also include a run queue 103. After the weight of each replication session is determined in the waiting sequence 102, the replication session can be selected from the waiting queue 102 according to the weight to enter the run queue 103. For example, the replication session 118, replication session 119, replication session 120 and other replication sessions 121 with the largest or smallest weight can be selected to enter the run queue 103, and the backup task is executed based on the replication sessions in the run queue 103.

[0027] As can be seen from the above description, the disclosed solution determines multiple parameters for multiple replication sessions in a waiting queue, weights the multiple replication sessions based on these parameters, and selects one or more replication sessions from the waiting queue according to the replication session weights to enter the running queue. This approach improves backup efficiency, reduces the risk of the system being stuck in a large queue, and avoids system resource exhaustion. It also reduces the number of backup tasks that miss their RPO, better protects disaster recovery data, and enhances the system's replication capabilities, supporting shorter RPOs and increasing the maximum number of replications.

[0028] It should be understood that the architecture and functions in the example environment 100 are described for exemplary purposes only and do not imply any limitation on the scope of the present disclosure. The embodiments of the present disclosure may also be applied to other environments with different structures and / or functions.

[0029] The following will be combined Figures 2 to 6 The process of the embodiment of the present disclosure is described in detail. For ease of understanding, the specific data mentioned in the following description are exemplary and are not intended to limit the scope of protection of the present disclosure. It is understood that the embodiment described below may also include additional actions not shown and / or may omit the actions shown, and the scope of the present disclosure is not limited in this respect.

[0030] Figure 2 FIG2 shows a flow chart of a method 200 for backup according to some embodiments of the present disclosure. At block 202, in response to a backup execution command being triggered, multiple parameters of multiple copy sessions in a waiting queue are determined. For example, Figure 1As shown, when a replication session in backup task 101 arrives in waiting queue 102, a backup execution command is triggered, and the system begins synchronizing the replication sessions between the source and remote ends. The synchronization process includes determining multiple parameters for the multiple replication sessions in waiting queue 102. The type and number of parameters can be selected based on actual needs. Any data that affects the backup result during the backup process can be selected as a parameter, specifically to achieve the goal of supporting a shorter RPO and improving the system's backup capabilities.

[0031] At block 204, a plurality of weights of the plurality of replication sessions are determined based on the plurality of parameters of the plurality of replication sessions. Figure 1 As shown, after determining multiple parameters of each replication session, a weight of each replication session in the waiting queue 102 is determined based on the multiple parameters. The weight of each replication session can be calculated based on one parameter or a combination of multiple parameters, and the calculation method can be any algorithm determined based on the parameters, and the scope of the present disclosure is not limited in this respect.

[0032] At block 206, at least one replication session is selected from the plurality of replication sessions based on the plurality of weights of the plurality of replication sessions and entered into a run queue. Figure 1 As shown, replication sessions can be sorted from smallest to largest based on their weights. Replication session 117 has a greater weight than replication session 116. Therefore, when there is a vacancy in run queue 103, replication session 117 will be prioritized over replication session 116 and the backup command of replication session 117 will be executed first. In this way, each replication session is prioritized, and the sorting takes into account various parameters to improve execution efficiency, thereby reducing the number of waiting jobs and ensuring that the risk of missing the RPO is reduced.

[0033] At block 208, a backup task is executed for at least one replication session in the run queue. Figure 1 As shown, the backup task can be executed for the copy session 118, copy session 119, copy session 120 and other copy sessions 121 in the running queue 103 at the same time, or the backup task can be executed for any one or more copy sessions in the running queue 103. The specific selection can be made according to actual needs, and the scope of the present disclosure is not limited in this respect.

[0034] In this way, backup efficiency can be improved, the risk of the system being in a huge queue can be reduced, and the problem of system resource exhaustion can be avoided. It can also reduce the number of backup tasks that miss the RPO, better protect disaster recovery data, enhance the system's replication capabilities, support shorter RPOs, and increase the number of replication limits.

[0035] The following will be combined Figures 3 to 6The backup execution process is described in detail. The specific data mentioned in the following description are exemplary and are not intended to limit the scope of protection of the present disclosure. It is understood that the embodiments described below may also include additional actions not shown and / or may omit the actions shown, and the scope of the present disclosure is not limited in this respect.

[0036] Figure 3 FIG. 3 is a schematic diagram illustrating a process 300 from starting a backup to completing a backup in some embodiments of the present disclosure. At block 302, a backup execution command is triggered. For example, Figure 1 As shown, when the copy session in the backup task 101 arrives at the waiting queue 102, the backup execution command is triggered. At box 304, the copy session is sorted according to the arrival time. For example, Figure 1 As shown, the replication sessions may be sorted according to arrival time. Since the replication session 112 arrives at the waiting queue 102 earlier than the replication session 113 , the replication session 112 may be sorted before the replication session 113 .

[0037] At block 306 , replication session parameters are determined. Parameters for each replication session can be determined sequentially in sorted order to avoid omissions. The type and number of replication session parameters can be selected based on actual needs. Any data that affects the backup results during the backup process can be selected as a parameter, specifically to achieve a shorter RPO and improve system backup capabilities.

[0038] In some embodiments, the plurality of parameters may include a waiting time (WT) of each replication session in the waiting queue, an estimated execution time (PT) of each replication session, a data recovery point objective (RPO) of each replication session, a user-defined level (UP) of each replication session, a run queue length (QL), an arrival time (AT) of each replication session arriving at the waiting queue, and a start execution time (ST) of each replication session arriving at the run queue, wherein the waiting time (WT) may be expressed as:

[0039] WT=ST-AT (1)

[0040] The multiple parameters may further include turnaround time (TT) and weighted turnaround time (WTT). The turnaround time (TT) may be expressed as:

[0041] TT=ST+AT-PT (2)

[0042] Weighted Turnover Time (WTT) can be expressed as:

[0043] WTT=TT / PT (3)

[0044] At block 308 , the replication session weight is calculated. The weight of each replication session may be calculated based on the determined multiple parameters. The calculation method may be an algorithm determined based on the parameters. The scope of the present disclosure is not limited in this respect.

[0045] In some embodiments, the weight of each replication session may be determined based on the waiting time (WT) of each replication session in the waiting queue and the estimated execution time (PT) of each replication session. The weight of each replication session may be expressed as:

[0046] SW=(WT+PT) / PT (4)

[0047] The waiting time (WT) of each replication session in the waiting queue is used as the denominator, which means that the longer the waiting time (WT), the greater the weight SW of the replication session. When the waiting time (WT) is the same, the shorter the expected execution time (PT) of each replication session, the greater the weight SW of the replication session.

[0048] In some embodiments, the weight of each replication session may be determined based on the waiting time (WT) of each replication session in the waiting queue, the estimated execution time (PT) of each replication session, and the data recovery point objective (RPO) of each replication session. The weight of each replication session may be expressed as:

[0049] SW=(WT+PT) / PT*(WT / RPO) (5)

[0050] From formula (5), we can see that the shorter the data recovery point objective (RPO) of each replication session, the greater the weight SW of the replication session.

[0051] In some embodiments, the weight of each replication session may be determined based on the waiting time (WT) of each replication session in the waiting queue, the estimated execution time (PT) of each replication session, the data recovery point objective (RPO) of each replication session, and the user-defined level (UP). The weight of each replication session may be expressed as:

[0052] SW=(WT+PT) / PT*(WT / RPO)*UP (6)

[0053] When the parameters of two replication sessions are identical, users can customize the replication session levels to select the replication session that enters the run queue first.

[0054] At block 310, a determination is made as to whether the run queue is full. Typically, a run queue has a limited number of concurrently running sessions. A new replication session can be added to the run queue only when there are empty slots in the run queue. For example, if the maximum number of concurrently running sessions in the run queue is 500, and there are 400 backup tasks currently executing, then the run queue has 100 empty slots. If there are 500 backup tasks currently executing, then the run queue is full.

[0055] At block 312, a copy session is selected to enter the run queue. When there is a vacancy in the run queue, the copy session may be selected to enter the run queue according to the weight, for example, Figure 1 As shown, the replication sessions can be sorted from small to large according to their weights. The weight of replication session 117 is greater than that of replication session 116. Then, when there is a vacancy in the run queue 103, replication session 117 will enter the run queue 103 before replication session 116, and the backup command of replication session 117 will be executed first.

[0056] At block 314, wait for the run queue to be empty. When the run queue is full, the number of concurrently running sessions has reached the upper limit, and it is necessary to wait for some backup tasks to be completed. At block 316, check whether there is an empty space. When some or all backup tasks in the run queue are completed, the run queue is not full, which means that there is an empty space in the run queue, and at least one copy session can be selected from multiple copy sessions to enter the run queue. When it is detected that there is no empty space in the run queue,

[0057] At block 318, a determination is made as to whether the waiting queue is empty. After selecting a replication session to enter the running queue, if there are no remaining replication sessions waiting to be run in the waiting queue, i.e., the waiting queue is empty, the process proceeds to block 320, indicating that the backup task has been completed. In response to the waiting queue being empty, the backup task is determined to be complete.

[0058] Figure 4 A schematic diagram of a process 400 for sorting replication sessions by weight in a waiting queue according to some embodiments of the present disclosure is shown. In a waiting queue 401, weights of multiple replication sessions can be calculated based on multiple determined parameters, and the replication sessions can be sorted by their weights. In some embodiments, the weight of each replication session in the waiting queue 401 can be calculated according to any one of formulas (4), (5), or (6), and the replication sessions can be sorted in ascending order. For example, the weights of replication sessions 402, 403, 404, 405, 406, 407, 408, and 409 become larger in sequence.

[0059] In some embodiments, a replication session with a higher weight in the waiting queue may be selected to enter the run queue. For example, replication session 409 is the replication session with the highest weight in the current waiting queue 401 calculated according to formula (6). If there is a vacancy in the run queue, replication session 409 has a higher priority than other replication sessions in entering the run queue.

[0060] Figure 5 A schematic diagram of process 500 for selecting a replication session from a waiting queue to enter a run queue according to some embodiments of the present disclosure. In waiting queue 501, weights of multiple replication sessions can be calculated based on multiple determined parameters, and the replication sessions can be sorted according to their weights. In some embodiments, the weight of each replication session in waiting queue 501 can be calculated according to any one of formulas (4), (5), or (6), with the weights of replication sessions 502, 503, 504, 505, 506, 507, 508, and 509 increasing in order.

[0061] In some embodiments, in response to the running queue being not full, the number of vacancies in the running queue 510 is determined, each replication session in the waiting queue 501 is sorted from low to high according to weight, and the replication sessions with the number of vacancies at the end are selected to enter the running queue 510. For example, in the running queue 510, replication session 512, replication session 513, and other replication sessions 514 are being executed, and the number of vacancies 511 is 3, then the three replication sessions with larger weights in the waiting queue 501 will be preferentially selected to enter the running queue 510 to execute the backup task. In this way, each replication session will be prioritized, and the waiting time (WT), expected execution time (PT), data recovery point objective level (RPO) and user-defined level (UP) are taken into consideration when sorting, so as to improve execution efficiency, thereby reducing the number of waiting jobs and ensuring that the risk of missing the RPO is reduced, better protecting disaster recovery data, enhancing the replication capability of the system, and avoiding the problem of system resource exhaustion.

[0062] In some embodiments, the present disclosure simulated various RPOs using 1,000 sessions and compared the FIFO strategy with the backup method of the present disclosure. When the backup method of the present disclosure was adopted, the waiting time (WT) of the replication session was significantly reduced by about 15%, the turnaround time (TT) of the replication session was reduced by about 10%, and the weighted turnaround time (WTT) of the replication session was significantly reduced by more than 40% to 70%. The above data show that compared with the FIFO strategy, the backup method of the present disclosure has higher backup efficiency, supports a shorter RPO, and can reduce the possibility of data loss.

[0063] Figure 6A schematic block diagram of an example device 600 that can be used to implement an embodiment of the present disclosure is shown. As shown, the device 600 includes a computing unit 601 that can perform various appropriate actions and processes based on computer program instructions stored in a read-only memory (ROM) 602 or loaded from a storage unit 608 into a random access memory (RAM) 603. Various programs and data required for the operation of the device 600 can also be stored in the RAM 603. The computing unit 601, the ROM 602, and the RAM 603 are connected to each other via a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.

[0064] Various components in device 600 are connected to I / O interface 605, including an input unit 606, such as a keyboard, mouse, etc.; an output unit 607, such as various types of displays, speakers, etc.; a storage unit 608, such as a magnetic disk, optical disk, etc.; and a communication unit 609, such as a network card, modem, wireless communication transceiver, etc. The communication unit 609 allows device 600 to exchange information / data with other devices via a computer network such as the Internet and / or various telecommunication networks.

[0065] The computing unit 601 can be a variety of general-purpose and / or specialized processing components with processing and computing capabilities. Some examples of the computing unit 601 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various dedicated artificial intelligence (AI) computing chips, various computing units that run machine learning model algorithms, a digital signal processor (DSP), and any appropriate processor, controller, microcontroller, etc. The computing unit 601 performs the various methods and processes described above, such as method 200. For example, in some embodiments, method 200 can be implemented as a computer software program that is tangibly contained in a machine-readable medium, such as a storage unit 608. In some embodiments, part or all of the computer program can be loaded and / or installed on the device 600 via ROM 602 and / or communication unit 609. When the computer program is loaded into RAM 603 and executed by the computing unit 601, one or more steps of the method 200 described above can be performed. Alternatively, in other embodiments, the computing unit 601 can be configured to perform method 200 in any other appropriate manner (e.g., by means of firmware).

[0066] The functions described above herein may be performed, at least in part, by one or more hardware logic components. For example, and without limitation, exemplary types of hardware logic components that may be used include: field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), systems on chips (SOCs), load programmable logic devices (CPLDs), and the like.

[0067] The program code for implementing the method of the present disclosure can be written in any combination of one or more programming languages. These program codes can be provided to a processor or controller of a general-purpose computer, a special-purpose computer, or other programmable data processing device so that when the program code is executed by the processor or controller, the functions / operations specified in the flow chart and / or block diagram are implemented. The program code can be executed entirely on the machine, partially on the machine, as a stand-alone software package, partially on the machine and partially on a remote machine, or entirely on a remote machine or server.

[0068] In the context of the present disclosure, a machine-readable medium may be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, device, or apparatus. A machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, device, or apparatus, or any suitable combination of the foregoing. More specific examples of machine-readable storage media may include an electrical connection based on one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In addition, although each operation is depicted in a specific order, this should be understood as requiring that such operations be performed in the specific order shown or in a sequential order, or requiring that all illustrated operations be performed to obtain the desired result. In certain environments, multitasking and parallel processing may be advantageous. Likewise, although several specific implementation details are included in the above discussion, these should not be construed as limiting the scope of this disclosure. Certain features described in the context of separate embodiments may also be implemented in combination in a single implementation. Conversely, various features described in the context of a single implementation may also be implemented in multiple implementations individually or in any suitable subcombination.

[0069] Although the subject matter has been described in language specific to structural features and / or methodological logical acts, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are merely example forms of implementing the claims.

Claims

1. A method for backup, comprising: In response to a backup execution command being triggered, determining a plurality of parameters of a plurality of replication sessions in a waiting queue; determining a plurality of weights for the plurality of replication sessions based on the plurality of parameters for the plurality of replication sessions; selecting at least one replication session from the plurality of replication sessions to enter a run queue based on the plurality of weights of the plurality of replication sessions; as well as A backup task is executed for the at least one replication session in the run queue.

2. The method of claim 1 , wherein determining a plurality of parameters of a plurality of replication sessions in a waiting queue comprises: A wait time of each of the plurality of replication sessions in the wait queue, an estimated execution time of each replication session, a data recovery point objective rating of each replication session, and a user-defined rating of each replication session are determined.

3. The method of claim 2, wherein determining a plurality of weights of the plurality of replication sessions comprises: A weight of each replication session is determined based on a waiting time of each replication session in the waiting queue and an estimated execution time of each replication session.

4. The method of claim 3 , wherein determining the weight of each replication session comprises: determining a sum of the waiting time and the estimated execution time; as well as The weight of each replication session is determined based on a ratio of the sum of the waiting time and the estimated execution time to the estimated execution time.

5. The method of claim 3 , wherein determining the weight of each replication session further comprises: The weight of each replication session is determined based on the waiting time of each replication session in the waiting queue, the estimated execution time of each replication session, and the ratio of the estimated execution time of each replication session to the data recovery point objective level of each replication session.

6. The method of claim 5, wherein determining the weight of each replication session further comprises: A weight of each replication session is determined based on a waiting time of each replication session in the waiting queue, an estimated execution time of each replication session, a ratio of the estimated execution time of each replication session to a data recovery point objective level of each replication session, and a user-defined level of each replication session.

7. The method according to claim 1 , wherein selecting at least one replication session from the plurality of replication sessions to enter into a run queue comprises: Detecting whether the run queue is full; In response to the run queue being full, waiting for a vacant position in the run queue; as well as In response to the run queue being not full, at least one replication session is selected from the plurality of replication sessions and entered into the run queue.

8. The method of claim 7, wherein in response to the run queue being not full, selecting at least one replication session from the plurality of replication sessions to enter the run queue comprises: In response to the run queue being not full, determining a number of empty bits in the run queue; Sort each replication session in the waiting queue by weight from low to high; as well as The number of replication sessions arranged at the rear of the empty slots is selected to enter the run queue.

9. The method according to claim 1, further comprising: Detecting whether the waiting queue is an empty queue; as well as In response to the waiting queue being an empty queue, it is determined that the backup task is completed.

10. An electronic device comprising: at least one processor; as well as coupled to the at least one processor and having instructions stored thereon, the instructions, when executed by the at least one processor, causing the electronic device to perform actions, the actions comprising: In response to a backup execution command being triggered, determining a plurality of parameters of a plurality of replication sessions in a waiting queue; determining a plurality of weights for the plurality of replication sessions based on the plurality of parameters for the plurality of replication sessions; selecting at least one replication session from the plurality of replication sessions to enter a run queue based on the plurality of weights of the plurality of replication sessions; and A backup task is executed for the at least one replication session in the run queue.

11. The apparatus of claim 10, wherein determining a plurality of parameters of a plurality of replication sessions in the waiting queue comprises: A wait time of each of the plurality of replication sessions in the wait queue, an estimated execution time of each replication session, a data recovery point objective rating of each replication session, and a user-defined rating of each replication session are determined.

12. The apparatus of claim 11 , wherein determining a plurality of weights of the plurality of replication sessions comprises: A weight of each replication session is determined based on a waiting time of each replication session in the waiting queue and an estimated execution time of each replication session.

13. The apparatus of claim 12, wherein determining the weight of each replication session comprises: determining a sum of the waiting time and the estimated execution time; as well as The weight of each replication session is determined based on a ratio of the sum of the waiting time and the estimated execution time to the estimated execution time.

14. The apparatus of claim 12, wherein determining the weight of each replication session further comprises: The weight of each replication session is determined based on the waiting time of each replication session in the waiting queue, the estimated execution time of each replication session, and the ratio of the estimated execution time of each replication session to the data recovery point objective level of each replication session.

15. The apparatus of claim 14, wherein determining the weight of each replication session further comprises: A weight of each replication session is determined based on a waiting time of each replication session in the waiting queue, an estimated execution time of each replication session, a ratio of the estimated execution time of each replication session to a data recovery point objective level of each replication session, and a user-defined level of each replication session.

16. The apparatus of claim 10, wherein selecting at least one replication session from the plurality of replication sessions to enter into a run queue comprises: Detecting whether the run queue is full; In response to the run queue being full, waiting for a vacant position in the run queue; as well as In response to the run queue being not full, at least one replication session is selected from the plurality of replication sessions and entered into the run queue.

17. The apparatus of claim 16, wherein in response to the run queue being not full, selecting at least one replication session from the plurality of replication sessions to enter the run queue comprises: In response to the run queue being not full, determining a number of empty bits in the run queue; Sort each replication session in the waiting queue by weight from low to high; as well as The number of replication sessions arranged at the rear of the empty slots is selected to enter the run queue.

18. The apparatus of claim 10, further comprising: Detecting whether the waiting queue is an empty queue; as well as In response to the waiting queue being an empty queue, it is determined that the backup task is completed.

19. A computer program product tangibly stored on a non-transitory computer-readable medium and comprising machine-executable instructions that, when executed, cause a machine to perform actions comprising: In response to a backup execution command being triggered, determining a plurality of parameters of a plurality of replication sessions in a waiting queue; determining a plurality of weights for the plurality of replication sessions based on the plurality of parameters for the plurality of replication sessions; selecting at least one replication session from the plurality of replication sessions to enter a run queue based on the plurality of weights of the plurality of replication sessions; as well as A backup task is executed for the at least one replication session in the run queue.

20. The computer program product of claim 19, wherein determining a plurality of parameters of a plurality of replication sessions in a waiting queue comprises: A wait time of each of the plurality of replication sessions in the wait queue, an estimated execution time of each replication session, a data recovery point objective rating of each replication session, and a user-defined rating of each replication session are determined.

Images