Method, device, computer device, readable storage medium and program product for processing change block tracking resources in backup

Abstract

This application relates to a method, apparatus, computer device, readable storage medium, and program product for processing change block tracking resources during backup. By monitoring the completion of change block tracking resource acquisition for a device during backup, the method reads the corresponding change block based on the change block tracking resource, performs backup based on the change block, and if resource processing conditions are met during the backup process, and it is determined that the remaining validity time is less than the remaining backup time based on the lifecycle context of the change block tracking resource, the remaining validity time of the change block tracking resource is extended until a preset termination condition is met, at which point the change block tracking resource is cleaned up. Compared to the traditional method where change block tracking resources are always valid by default, this application improves backup efficiency by combining the lifecycle of the change block tracking resource and the remaining backup time, dynamically monitoring the validity time of the change block tracking resource during the backup process, and adaptively renewing the change block tracking resource.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a method, apparatus, computer device, computer-readable storage medium, and computer program product for processing change block tracking resources in backups. Background Technology

[0002] In cloud server backups, Change Block Tracking (CBT) resources are typically used. These resources identify resource objects that have changed since the last backup point, making them crucial for incremental backups and similar processes. Currently, CBT resources are only used as an interface or tool for reading changed blocks during backups, and are assumed to be always active throughout the backup process. However, this default assumption of CBT resource availability during backups leads to reduced backup efficiency because various anomalies can occur with CBT resources during the backup process. The lack of monitoring and handling for these anomalies results in reduced backup efficiency.

[0003] Therefore, the current method for handling change block tracking resources in backups suffers from low backup efficiency. Summary of the Invention

[0004] Therefore, it is necessary to provide a method, apparatus, computer device, computer-readable storage medium, and computer program product for processing change block tracking resources in backup, which can improve backup efficiency, in order to address the above-mentioned technical problems.

[0005] Firstly, this application provides a method for processing change block tracking resources in backups, including:

[0006] When the backup conditions are met, the change block tracking resource corresponding to the device to be backed up is obtained; the change block tracking resource includes the lifecycle context.

[0007] If the acquisition of the change block tracking resource is detected to be complete, then the change block corresponding to the device is read according to the change block tracking resource and backup is performed according to the change block;

[0008] During the backup process based on the change block, if the resource processing conditions are detected, the remaining valid time of the resource tracked by the change block is determined according to the lifecycle context.

[0009] If the remaining valid time is less than the remaining backup time corresponding to the current backup, the remaining valid time of the change block tracking resource is extended until the preset end condition is met, at which point the change block tracking resource is cleaned up; the remaining backup time is obtained based on the total disk capacity of the server corresponding to the current backup, the amount of data already transferred corresponding to the current backup, and the data transfer rate.

[0010] Secondly, this application also provides a processing apparatus for tracking change blocks in backup resources, comprising:

[0011] The acquisition module is used to acquire the change block tracking resources corresponding to the device to be backed up when the backup conditions are detected; the change block tracking resources include the lifecycle context.

[0012] The reading module is used to read the change block corresponding to the device and back it up based on the change block tracking resource if the acquisition of the change block tracking resource is detected to be complete.

[0013] The determination module is used to determine the remaining valid time of the resource tracked by the change block based on the lifecycle context if the resource processing conditions are detected during the backup process based on the change block.

[0014] The processing module is configured to extend the remaining validity time of the change block tracking resource if the remaining valid time is less than the remaining backup time corresponding to the current backup, until a preset termination condition is met, and then clean up the change block tracking resource; the remaining backup time is obtained based on the total disk capacity of the server corresponding to the current backup, the amount of data already transferred corresponding to the current backup, and the data transfer rate.

[0015] 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.

[0016] 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.

[0017] 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.

[0018] The aforementioned method, apparatus, computer device, computer-readable storage medium, and computer program product for processing change block tracking resources during backup monitor the completion of acquiring the change block tracking resources corresponding to the device during backup. Based on the change block tracking resources, the corresponding change blocks are read, and backup is performed according to the change blocks. During the backup process, if resource processing conditions are met, the remaining validity time is determined based on the lifecycle context of the change block tracking resources. If the remaining validity time is less than the remaining backup time, the remaining validity time of the change block tracking resources is extended until a preset termination condition is met, at which point the change block tracking resources are cleaned up. Compared to the traditional method where change block tracking resources are always valid by default, this application improves backup efficiency by combining the lifecycle and remaining backup time of the change block tracking resources, dynamically monitoring the validity time of the change block tracking resources during backup, and adaptively renewing the change block tracking resources. Attached Figure Description

[0019] 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.

[0020] Figure 1 This is an application environment diagram of a method for processing change block tracking resources in backups in one embodiment;

[0021] Figure 2 This is a flowchart illustrating a method for processing change block tracking resources in a backup, as described in another embodiment.

[0022] Figure 3 This is a flowchart illustrating the method for processing change block tracking resources in a backup in yet another embodiment;

[0023] Figure 4 This is a structural block diagram of a processing apparatus for tracking change blocks in a backup, as shown in one embodiment.

[0024] Figure 5 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, change block tracking resources are resource objects provided by cloud platforms or virtualization platforms to identify change blocks since the last backup point. These resources have lifecycle attributes such as creation, validity period, renewal, and release, and occupy cloud platform quotas. The backup system requests or activates this resource from the cloud platform before starting the backup, reads change blocks through this resource during the backup process, and releases, retains, or updates the resource according to the cloud platform interface requirements after the backup is completed.

[0028] Currently, the focus is on how to obtain change blocks or how to use change blocks to complete data-level issues such as incremental backups, data migrations, and redundancy removal. Examples include generating incremental backups based on disk bitmap comparisons, scheduling full / incremental data migrations based on network bandwidth pressure, and identifying and cleaning redundant backup data blocks based on version chains and overwrite tags. All of the above solutions assume that change block tracking resources are continuously available during backups / migrations, using them only as interfaces or tools for reading change blocks. They do not consider the change block tracking resources exposed by the cloud platform themselves as managed objects with expiration dates, creation timeouts, and residual risks, nor do they address the closed loop of creation, renewal, timeout detection, reconstruction, and cleanup throughout the entire backup task lifecycle.

[0029] For example, a solution might involve calling the change block tracking interface exposed by the cloud platform or virtualization platform to read changed blocks and generate incremental backups during cloud host / virtual machine backups. This type of solution focuses on obtaining changed block data as its core objective, and typically handles the change block tracking resource objects it depends on in one of the following ways: defaulting to keeping resources valid throughout the backup period; using a fixed renewal period; or directly returning an error and having the upper-level task retry on failure. None of these solutions provide a systematic mechanism for handling resource validity, creation timeout consistency, abnormal remnants, and cross-task cleanup. The following defects and shortcomings exist: Change block tracking resources have an expiration period, and fixed renewal or non-renewal strategies cannot cover long-term backup tasks caused by large-capacity disks, slow networks, or slow cloud platform responses; Change block tracking resource creation requests may time out, but the cloud platform background may still complete the creation, and if the backup system directly retryes, duplicate or residual resources will be generated; After backup tasks are canceled, nodes fail, or processes exit abnormally, change block tracking resources, snapshots, and temporary tasks may remain, occupying cloud platform quotas and affecting subsequent backups; Incremental backup, data migration, and redundancy removal solutions focus on the acquisition, transmission, or cleanup of change block data itself, and do not cover the pre-backup scanning, adaptive renewal during backup, detection and reconstruction after creation / renewal timeout, and resource cleanup closed loop according to dependency order after task completion or abnormal exit of change block tracking resource objects throughout the entire lifecycle of the backup task; Different cloud platforms have different semantics for change block tracking creation, renewal, closure, and deletion interfaces, and lack a unified resource ownership judgment and cleanup strategy.

[0030] This leads to the following technical issues: how to adaptively maintain change blocks to track resource availability throughout the entire lifecycle of a cloud host backup task, and accurately reclaim residual resources in abnormal scenarios to avoid resource expiration, duplicate creation, and quota occupation.

[0031] Based on this, this application relates to the fields of cloud computing, virtualization backup, and cloud platform resource lifecycle management technology. Specifically, it relates to a method for adaptively renewing and cleaning up residual resources of change block tracking resources provided by the cloud platform during the execution of a cloud host backup task. By combining the lifecycle of change block tracking resources and the remaining backup time, the effective time of change block tracking resources is dynamically monitored during the backup process, and the change block tracking resources are adaptively renewed, thereby improving the efficiency of backup.

[0032] In one embodiment, such as Figure 1 As shown, a method for processing change block tracking resources in backup is provided. This embodiment illustrates the application of this method to a server. It is understood that this method can also be applied to a terminal, and further to a system including both a terminal and a server, and is implemented through interaction between the terminal and the server, including the following steps S202 to S208. Wherein:

[0033] Step S202: When the backup conditions are met, the change block tracking resources corresponding to the device to be backed up are obtained; the change block tracking resources include the lifecycle context.

[0034] The aforementioned server can be a server used for data backup, such as a server used for backing up data in cloud platforms like cloud hosts / virtual machines. The aforementioned backup conditions can be pre-defined conditions that trigger the backup process. For example, a backup condition could be that the backup conditions are met upon detecting a backup task trigger. Backup tasks can be triggered manually or according to a set cycle. When a backup task is triggered, the server can back up the data from the device to be backed up to the server. The aforementioned backup can include various types, such as full backup, incremental backup, and cumulative backup. During backup, the server can use the change block tracking resources of the device to be backed up. The change block tracking resources can identify resource objects of changed blocks since the last backup point, used to record cloud platform or virtualization platform resources of virtual disk changed blocks, so that the server can back up the device to be backed up based on the change block tracking resources. The device to be backed up can include various types, such as cloud hosts and virtual machines. The aforementioned change block tracking resources include a lifecycle context. The lifecycle context represents the set of creation time, validity period, renewal count, task stage, and cleanup status recorded by the server for a single change block tracking resource. The lifecycle context includes lifecycle information for the change block tracking resource, such as the remaining validity period of the change block tracking resource. The remaining validity period indicates the remaining time the change block tracking resource will remain valid.

[0035] Among them, the resource objects of the changed blocks since the last backup point can be recorded in the device to be backed up. Before the backup, the server extracts the resource objects of the changed blocks since the last backup point recorded in the device by calling the interface of the device's change block tracking resources, and then generates the corresponding change block tracking resources for backup.

[0036] Step S204: If the acquisition of the change block tracking resource is completed, then the change block corresponding to the device is read and backed up according to the change block tracking resource.

[0037] The server can call the interface of the device to be backed up to create a change block tracking resource. Once the change block tracking resource is created (e.g., the server receives the created resource), the server can read the corresponding change blocks for the device and perform a backup based on those blocks. The change blocks record the data blocks in the device to be backed up that have changed since the last successful backup (e.g., changes such as additions, deletions, queries, and modifications). The server can perform incremental or cumulative backups based on the change blocks. Incremental backups use the data from the most recent successful backup of the device as the baseline, while cumulative backups use the data from the most recent full backup of the device as the baseline.

[0038] Step S206: During the backup process based on the above change block, if the resource processing conditions are detected, the remaining valid time of the resource tracked by the above change block is determined based on the above lifecycle context.

[0039] During the backup process based on change blocks, the validity period of change block tracking resources gradually decreases. To prevent backup failure due to the expiration of a single change block tracking resource before the backup is complete, the server can monitor the validity period of change block tracking resources during the backup process. For example, if the server detects that resource processing conditions are met during the backup process, it can obtain the lifecycle context of the change block tracking resource and determine its remaining validity period based on the lifecycle context. The resource processing conditions can be determined based on a preset period; for example, if the current time meets a preset period, the resource processing conditions are determined to be met. In other words, the server can periodically check the lifecycle context of change block tracking resources during the backup process to determine their remaining validity period.

[0040] Step S208: If the remaining valid time is less than the remaining backup time corresponding to the current backup, the remaining valid time of the change block tracking resource is extended until the preset end condition is met, and then the change block tracking resource is cleared. The remaining backup time is obtained based on the total disk capacity of the server corresponding to the current backup, the amount of data already transferred corresponding to the current backup, and the data transfer rate.

[0041] When the server detects the remaining validity time of change block tracking resources based on the lifecycle context, it can determine the processing strategy for the change block tracking resources based on the specific value of the remaining validity time. Specifically, if the remaining validity time is greater than or equal to the remaining backup time corresponding to the current backup, the server can determine that the current backup can be completed successfully and continue the backup process without extending the validity time of the change block tracking resources. The remaining backup time can be obtained based on the total disk capacity of the server corresponding to the current backup, the amount of data already transferred for the current backup, and the data transfer rate. The amount of data already transferred represents the amount of data in the current backup that has been transferred from the device to be backed up to the server.

[0042] If the server detects that the remaining validity period is less than the remaining backup time corresponding to the current backup, the server can extend the remaining validity period of the aforementioned change block tracking resources. Specifically, the server can continuously monitor the remaining validity period of the change block tracking resources at a set period, and extend the remaining validity period each time it detects that the remaining validity period is less than the remaining backup time. That is, the server can repeat the above monitoring and extension steps until a preset termination condition is met, at which point the change block tracking resources are cleaned up. The preset termination condition can include backup completion. Backup completion includes successful backup, backup failure, etc. At the end of the backup, the server can clean up the change block tracking resources. The cleaned-up change block tracking resources can be those of unrelated tasks, such as those associated with tasks that have ended, exited abnormally, or do not exist, thereby improving the processing efficiency of change block tracking resources.

[0043] In the aforementioned method for handling change block tracking resources during backup, the process involves monitoring the completion of acquiring the change block tracking resource corresponding to the device during backup. Based on the change block tracking resource, the corresponding change block is read, and backup is performed according to the change block. During the backup process, if resource processing conditions are met, the remaining validity period is determined based on the lifecycle context of the change block tracking resource. If the remaining validity period is less than the remaining backup time, the remaining validity period of the change block tracking resource is extended until a preset termination condition is met, at which point the change block tracking resource is cleaned up. Compared to the traditional method where change block tracking resources are always valid by default, this application combines the lifecycle of the change block tracking resource and the remaining backup time to dynamically monitor the validity period of the change block tracking resource during backup, adaptively renewing the change block tracking resource, thus improving backup efficiency.

[0044] In one embodiment, before obtaining the change block tracking resource corresponding to the device to be backed up, the method further includes: querying the associated change block tracking resource corresponding to the device according to preset backup attribute information; if it is determined that the associated change block tracking resource meets the cleanup conditions according to the backup attribute information corresponding to the associated change block tracking resource, then the associated change block tracking resource is cleaned according to the cleanup order corresponding to the associated change block tracking resource; the cleanup order includes one or more of the following: closing the session for reading change blocks, deleting the temporary snapshot corresponding to the associated change block tracking resource, releasing the associated change block tracking resource, and deleting the temporary task corresponding to the associated change block tracking resource.

[0045] In this embodiment, before backup begins, the server can clean up any remaining change block tracking resources on the server. Specifically, the server can query the associated change block tracking resources corresponding to the aforementioned devices based on preset backup attribute information. The preset backup attribute information can be pre-defined backup-related attributes, such as the identifier of the device to be backed up, the disk identifier, the naming rules of the backup system on the server, and resource tags. This query can be performed on the device to be backed up, such as querying the cloud platform based on the preset backup attribute information. Associated change block tracking resources refer to change block tracking resources already existing on the server. That is, the server can query the corresponding change block tracking resources and other data from the cloud platform based on the preset backup information. The server then checks among the various changed block tracking resources obtained from the query to determine the change block tracking resources that match its own server, which are then designated as associated change block tracking resources, allowing the server to clean up these associated change block tracking resources.

[0046] The server can clean up associated change block tracking resources that meet the cleanup conditions. For example, the server determines whether the associated change block tracking resource meets the cleanup conditions based on the backup attribute information corresponding to the resource. These cleanup conditions may include that the task associated with the resource has ended, exited abnormally, or does not exist, or that the resource's creation time has exceeded a set time window. Therefore, the server can clean up the associated change block tracking resources according to the cleanup order. In one embodiment, the cleanup conditions include one or more of the following: the associated change block tracking resource does not belong to the server corresponding to the current backup (i.e., the resource needs to be cleaned up when it is unrelated to the server); the backup task associated with the resource is not in execution (i.e., the resource needs to be cleaned up when the task associated with it has ended, been canceled, exited abnormally, or does not exist); and the resource's creation time is earlier than a preset time window (i.e., the resource needs to be cleaned up if its creation time is too early).

[0047] The cleanup sequence includes one or more of the following: closing the session that reads the change block, deleting the temporary snapshot corresponding to the aforementioned associated change block tracking resource, releasing the aforementioned associated change block tracking resource, and deleting the temporary task corresponding to the aforementioned associated change block tracking resource. Here, a session that reads the change block refers to a session where the server reads the change block from the device to be backed up; a temporary snapshot refers to a snapshot that the associated change block tracking resource depends on in its backup task; and a temporary task refers to a backup task associated with the associated change block tracking resource that is no longer in execution.

[0048] Specifically, the server can perform a residual resource scan before backup. This involves the server querying the cloud platform (the device to be backed up) for candidate change block tracking resources (associated change block tracking resources), temporary snapshots, and temporary tasks based on preset backup attribute information such as the target virtual machine identifier, disk identifier, backup system naming rules, and resource tags.

[0049] The server further determines resource ownership. For each candidate resource returned by the query, the server determines whether it belongs to the backup system (server) based on the resource name, tag, task identifier, virtual machine identifier, disk identifier, and creation time. If it does, the candidate resource is included as a related change block tracking resource, and the server further determines whether the associated backup task for the related change block tracking resource has ended, failed, been canceled, or does not exist (is not in an executing state). If so, and the creation time has exceeded the protection time window (preset time window), the cleanup process begins; otherwise, it is skipped. The protection time window represents the minimum retention time set to avoid accidental deletion of resources that are still being created or used.

[0050] The server can perform residual cleanup on associated change block tracking resources. The cleanup process follows a sequence: closing read sessions, deleting temporary snapshots, releasing change block tracking resources, and deleting dependencies of temporary tasks (cleanup order). Resources that fail to be cleaned up are placed in a background retry queue and generate audit events.

[0051] In this embodiment, the server can clean up residual change block tracking resources by combining attribute information before backup, thereby avoiding the use of invalid change block tracking resources during backup and improving backup efficiency.

[0052] In one embodiment, obtaining the change block tracking resource corresponding to the device to be backed up includes: sending a change block tracking resource generation request to the device through the device's change block tracking resource interface; the change block tracking resource generation request instructs the device to generate the change block tracking resource corresponding to the current backup; if the change block tracking resource generated by the device is not received within a preset time window, then querying the associated change block tracking resource corresponding to the device based on the backup attribute information corresponding to the current backup; if a target change block tracking resource exists among the associated change block tracking resources, then obtaining the change block tracking resource corresponding to the device based on the target change block tracking resource; the target change block tracking resource satisfies the following conditions: belongs to the server corresponding to the current backup, is associated with the task of the current backup, and its creation time is within the preset time window.

[0053] In this embodiment, the server can generate corresponding change block tracking resources based on the device to be backed up during backup. The device to be backed up stores change information for data blocks since the last backup and has a change block tracking resource interface. To access this change information during backup, the server can send a change block tracking resource generation request to the device through this interface. This request instructs the device to generate change block tracking resources. For example, it might instruct the device to generate the change block tracking resource corresponding to the current backup.

[0054] After issuing a request, the server can monitor the generation of change block tracking resources. If the server does not receive change block tracking resources generated by the aforementioned device within a preset time window, it needs to determine if there are any abnormalities in the generation process. Specifically, the server can query the associated change block tracking resources corresponding to the aforementioned device based on the backup attribute information corresponding to the current backup. The backup attribute information can be information related to the attributes of the device to be backed up, and the associated change block tracking resources represent the change block tracking resources already generated for that device.

[0055] The server checks among all associated change block tracking resources for the existence of a target change block tracking resource. The target change block tracking resource must meet the following conditions: it belongs to the server corresponding to the current backup, it is associated with the task of the current backup, and its creation time is within the aforementioned preset time window. If the server detects the existence of a target change block tracking resource among the aforementioned associated change block tracking resources, the server can obtain the change block tracking resource corresponding to the aforementioned device based on the target change block tracking resource.

[0056] Specifically, the server can create change block tracking resources during backup. This involves the server calling the cloud platform (the device to be backed up) interface to create the change block tracking resources required for the task and initializing the resource lifecycle context `ResourceLeaseContext`, recording fields such as `task_id` (task identifier), `vm_id` (virtual machine identifier), `disk_id` (disk identifier), `cbt_resource_id` (change block tracking resource identifier), `created_at` (resource creation time), and `expire_at` (resource expiration time). If the creation request times out, the server performs a creation timeout detection and reconstruction step; otherwise, it performs backup execution and adaptive renewal steps.

[0057] In the creation timeout detection and reconstruction step, the server queries candidate resources (associated change block tracking resources) by VM (virtual machine identifier), disk, and task identifier after a consistency delay window (e.g., 5 to 30 seconds). If an available resource for the current task (target change block tracking resource) is found, it is reused and backup and adaptive renewal steps are performed. If an unavailable resource is found, the server cleans it up and then reconstructs it according to the number of retries. If no resource is found, reconstruction continues according to the number of retries. If the retry limit is exceeded (e.g., 3 to 5 times), the created snapshot and temporary resources are cleaned up and the process fails. The consistency delay window represents the waiting time after the cloud platform interface timeout, during which the background resource status may not be consistent with the query results.

[0058] When a change block tracking resource creation request times out, the server does not immediately determine failure. Instead, it queries candidate resources by VM (virtual machine identifier), disk, and task identifier after a consistency delay window. If the current task resource (target change block tracking resource) is found and its status is available, the resource is reused and backup continues. If an unavailable resource is found, it is deleted or marked for cleanup before being recreated. If no resource is found, it is recreated according to the number of retries. After exceeding the retry limit, the server cleans up the created snapshots and temporary tasks and exits upon failure.

[0059] In this embodiment, when the creation of change block tracking resources times out, the server can avoid immediately determining failure, but instead actively query the actual existence status of the change block tracking resources, thus preventing the backup task from getting deadlocked and improving the backup efficiency.

[0060] In one embodiment, the step of obtaining the remaining backup time includes: determining the amount of data to be transferred based on the difference between the total disk capacity and the amount of data already transferred; determining the remaining backup time based on the ratio of the amount of data to be transferred to the data transfer rate; wherein the data transfer rate represents the larger of the average transfer rate and the minimum transfer rate corresponding to the current backup.

[0061] In this embodiment, the server can determine whether to extend the change block tracking resource based on the remaining backup time of the current backup and the remaining validity time of the change block tracking resource. The server can continuously monitor the remaining backup time of the current backup. The server can obtain the difference between the total disk capacity of the device to be backed up (e.g., a virtual machine) and the amount of data already transferred (e.g., the amount of data already transferred to the server). The server can determine the amount of data to be transferred based on this difference. The amount of data to be transferred represents the amount of data remaining to be transferred in the current backup.

[0062] The server can also obtain the ratio of the amount of data to be transferred to the data transfer rate. The data transfer rate represents the rate at which data is transferred during the current backup. Specifically, the data transfer rate can be the greater of the average transfer rate and the minimum transfer rate corresponding to the current backup. Therefore, the server can determine the remaining backup time based on the ratio of the amount of data to be transferred to the data transfer rate. The server can extend the validity period of the change block tracking resource if the remaining valid time is less than the remaining backup time.

[0063] Specifically, the server can perform backup execution and adaptive renewal. During backup, the server begins reading changed blocks and writing them to the backup target. During this process, a renewal threshold (whether it is less than the remaining backup time) is determined periodically by a period T (resource processing condition, e.g., 10 to 60 seconds). When the remaining validity period of the resource is insufficient to cover the sum of the remaining backup time and the safety buffer, the server calls the cloud platform's renewal interface to extend the validity period and updates last_extend_at (the time of the last renewal) and extend_count (the number of renewals). When a renewal request times out, the server first queries the actual status of the resource before deciding whether to retry or rebuild.

[0064] The server maintains a lifecycle context, ResourceLeaseContext, for each change block tracking resource, which includes at least the following: task_id (task identifier), vm_id (virtual machine identifier), disk_id (disk identifier), cbt_resource_id (change block tracking resource identifier), created_at (resource creation time), expire_at (resource expiration time), last_extend_at (last renewal time), extend_count (number of renewals), disk_size (disk size), transferred_bytes (transferred data), average_speed (average transfer rate), safety_margin (safety margin), and status (resource status).

[0065] The renewal threshold (whether the remaining validity time is less than the remaining backup time) for change block tracking resources is calculated as follows:

[0066] estimated_remaining_time=(disk_size-transferred_bytes) / max(average_speed,minimum_speed); safety_margin=max(platform_response_p95, configured_min_margin); if resource_remaining_time≤estimated_remaining_time+safety_margin:extend_resource_lifetime().

[0067] Among them, `resource_remaining_time` is the remaining validity period (remaining effective time) of the current change block tracking resource, which is obtained by the difference between `expire_at` (resource expiration time) and the current server time; `minimum_speed` (minimum transfer rate) is the lower limit of speed estimation, used to avoid the estimation tending to infinity due to the instantaneous speed being zero, and its value range is, for example, 1MB / s to 10MB / s, which can be configured according to the actual situation; `average_speed` (average transfer rate) is the ratio of the number of bytes transferred to the time elapsed, which can also be replaced by the sliding window speed or the speed of historical similar tasks; `platform_response_p95` is the most recent N... The 95th percentile of the time taken for cloud platform renewal or query interfaces (e.g., N=100) is obtained from online server statistics; configured_min_margin is the minimum safety buffer configured by the administrator, with a value range of, for example, 30 seconds to 300 seconds; safety_margin is the larger of platform_response_p95 and configured_min_margin, to avoid renewal requests not being completed in time when the cloud platform response is jittery; when extend_count exceeds the preset limit (e.g., 10 times), an alarm is triggered and the process is switched to timeout detection and reconstruction to prevent unlimited renewals from masking underlying faults.

[0068] The above renewal process can be represented as follows: Calculate the estimated remaining time of the current backup (estimated_remaining_time): Subtract the amount of transferred data (transferred_bytes) from the total disk capacity (disk_size), and then divide by the greater of the average transfer rate (average_speed) and the minimum transfer rate (minimum_speed). Calculate the safety margin (safety_margin): Take the greater of the platform's 95th percentile response time (platform_response_p95) and the configured minimum margin (configured_min_margin). Perform a conditional check: If the remaining resource validity time (resource_remaining_time) is less than or equal to the remaining backup time (estimated_remaining_time) plus the safety margin (safety_margin), then execute the extend resource lifetime operation (extend_resource_lifetime).

[0069] Through this embodiment, the server can determine the remaining backup time by combining the total disk capacity, the amount of data transferred, and the transfer rate, thereby improving the accuracy of obtaining the remaining backup time. Furthermore, by combining the remaining backup time with the remaining validity time of the change block tracking resource, the validity period of the change block tracking resource can be extended to avoid the change block tracking resource becoming invalid during backup, thus improving backup efficiency.

[0070] In one embodiment, cleaning up the change block tracking resources includes: if the current backup has ended, cleaning up the change block tracking resources according to the cleaning order; the cleaning order includes one or more of the following: closing the session that reads the change block, deleting the temporary snapshot corresponding to the change block tracking resources, releasing the change block tracking resources, and deleting the temporary task corresponding to the change block tracking resources.

[0071] In this embodiment, for completed backup tasks, the server can clean up the change block tracking resources of these completed backup tasks. Specifically, when the server detects that the current backup has ended, it can clean up the change block tracking resources corresponding to the current task in a cleanup order. This cleanup order includes one or more of the following: closing the session reading the change block, deleting the temporary snapshot corresponding to the change block tracking resource, releasing the change block tracking resource, and deleting the temporary task corresponding to the change block tracking resource.

[0072] Specifically, the server can perform task termination processing. If the backup is successful, the server releases or retains change block tracking resources and deletes temporary snapshots and temporary tasks in the order of dependencies (cleanup order); if it fails or is canceled, the cleanup process is triggered.

[0073] The server can trigger a cleanup process both before backup and after abnormal exit. The server filters resources (change block tracking resources) that match the backup system's (server's) naming rules and whose associated tasks have ended, failed, been canceled, or do not exist. If a resource's creation time has exceeded the protection window and it has not been used, it is cleaned up in the following order: closing the read session, deleting temporary snapshots, releasing change block tracking resources, and deleting temporary tasks. Resources that fail to be cleaned up are placed in a background retry queue, and an audit event is generated.

[0074] Through this embodiment, the server can promptly clean up the relevant change block tracking resources when the backup is completed, thereby improving the processing efficiency of change block tracking resources.

[0075] In one exemplary embodiment, such as Figure 2 As shown, Figure 2 This is a flowchart illustrating the processing method for change block tracking resources during backup in another embodiment. In this embodiment, a change block tracking resource lifecycle context is introduced into the cloud host backup task. Before backup, residual resources are scanned based on task identifier, virtual machine identifier, disk identifier, resource naming rules, and creation time. During backup, the renewal threshold is dynamically calculated based on disk capacity, backed-up data volume, average transfer speed, remaining resource validity period, and cloud platform response time. When creation or renewal times out, the actual resource status on the cloud platform is queried first, and then a decision is made on reuse, reconstruction, or cleanup. After the task succeeds, fails, or is canceled, change block tracking resources, snapshots, and temporary tasks are released or retained according to resource dependency order. The change block tracking resource object exposed by the cloud platform itself is treated as a managed entity, providing resource management including scanning, creation, renewal, timeout detection, reconstruction, cleanup, and auditing throughout the entire lifecycle of the backup task.

[0076] The server system includes a residual resource scanning module, a resource ownership determination module, a change block tracking resource creation module, an adaptive renewal module, a timeout detection and reconstruction module, an anomaly cleanup module, and an auditing and alarm module. The residual resource scanning module is responsible for querying the target virtual machine, disk, and related change block tracking resources, snapshots, and temporary tasks before the backup task begins. The resource ownership determination module determines whether a resource belongs to the backup system and whether cleanup is allowed based on the resource name, tag, task identifier, virtual machine identifier, disk identifier, and creation time. The change block tracking resource creation module is responsible for calling the cloud platform interface to create resources and recording metadata, including the resource lifecycle context. The adaptive renewal module periodically calculates the remaining backup time and safety buffer during the backup process and performs backup data transmission. The timeout detection and reconstruction module handles creation timeouts, renewal timeouts, and query anomalies. The success handling module is used to release or retain change block tracking resources in dependency order and delete temporary snapshots and temporary tasks. The anomaly cleanup module cleans up resources according to dependencies when failures or cancellations occur. These dependencies are released sequentially from the outside in: read sessions, temporary snapshots, change block tracking resources, and temporary tasks. This prevents the cloud platform interface from returning an error indicating that resources are occupied due to an incorrect cleanup order. A read session is a read context created on the cloud platform when the backup system pulls change blocks from change block tracking resources. The auditing and alerting module records the creation, renewal, reconstruction, and cleanup results.

[0077] like Figure 3 As shown, Figure 3 This is a flowchart illustrating the processing method for change block tracking resources during backup in another embodiment. It includes the following steps: The cloud host (the device to be backed up) backup task loads virtual machine and disk information, scans for historical residual change block tracking resources and snapshots. If cleanable residual resources exist, they are cleaned according to ownership and protection window; otherwise, change block tracking resources for the current task are created. If creation fails, timeout detection and reconstruction are performed; otherwise, resource metadata and validity period are recorded.

[0078] The server initiates backup data transmission and periodically checks the progress and remaining validity of resources. If the expected threshold is not reached, the backup continues until completion. When the renewal threshold is reached, the change block tracking resource renewal is executed. If renewal fails, the status is queried and a decision is made to retry or rebuild, and the backup continues until completion. If the backup is not complete, the process returns to the steps of periodically checking progress and remaining validity. When the backup is complete, the change block tracking resources are released or retained according to the policy, and the audit results are recorded.

[0079] Specifically, it includes the following steps:

[0080] Step S1: Perform a scan for residual resources before backup.

[0081] The server queries the cloud platform (the device to be backed up) for candidate change block tracking resources (associated change block tracking resources), temporary snapshots, and temporary tasks based on preset backup attribute information such as the target virtual machine identifier, disk identifier, backup system naming rules, and resource tags. Residual resources represent change block tracking resources, snapshots, or temporary tasks that are still retained in the cloud platform even after the backup task has ended or no longer exists.

[0082] Step S2, resource ownership determination.

[0083] In this process, for each candidate resource returned by the query, the server determines whether it belongs to the backup system (server) based on the resource name, tag, task identifier, virtual machine identifier, disk identifier, and creation time. If it does, the candidate resource is used as an associated change block tracking resource, and it is further determined whether the associated backup task of the associated change block tracking resource has ended, failed, been canceled, or does not exist (is not in an execution state). If so, and the creation time has exceeded the protection time window (preset time window), the cleanup process is initiated; otherwise, it is skipped. In some embodiments, the resource ownership identifier can use the resource name, tag, metadata table, or cloud platform-defined attributes.

[0084] Step S3: Perform residual cleanup on the associated change block tracking resources.

[0085] The server cleans up resources in the following order: closing read sessions, deleting temporary snapshots, releasing change block tracking resources, and deleting dependencies of temporary tasks (cleanup order). Resources that fail to be cleaned up are entered into the background retry queue and an audit event is generated.

[0086] Step S4: Change block tracking resource creation.

[0087] The process involves the server calling the cloud platform (the device to be backed up) interface to create the change block tracking resources required for this task and initializing the resource lifecycle context ResourceLeaseContext, recording fields such as task_id (task identifier), vm_id (virtual machine identifier), disk_id (disk identifier), cbt_resource_id (change block tracking resource identifier), created_at (resource creation time), and expire_at (resource expiration time). If the creation request times out, the server performs a creation timeout detection and reconstruction step; otherwise, it performs backup execution and adaptive renewal steps. The cloud platform interface is adaptable to change block tracking resources, snapshot, or incremental change query mechanisms from different vendors.

[0088] Step S5: Create timeout detection and reconstruction.

[0089] The server queries candidate resources (associated change block tracking resources) by VM (virtual machine identifier), disk, and task identifier after a consistency delay window (e.g., 5 to 30 seconds). If an available resource (target change block tracking resource) for the current task is found, it is reused and backup and adaptive renewal steps are performed. If an unavailable resource is found, the server cleans it up and rebuilds it according to the number of retries. If no resource is found, it continues to rebuild according to the number of retries. If the retry limit is exceeded (e.g., 3 to 5 times), the created snapshots and temporary resources are cleaned up and the process fails and exits.

[0090] When a change block tracking resource creation request times out, the server does not immediately determine failure. Instead, it queries candidate resources by VM (virtual machine identifier), disk, and task identifier after a consistency delay window. If the current task resource (target change block tracking resource) is found and its status is available, the resource is reused and backup continues. If an unavailable resource is found, it is deleted or marked for cleanup before being recreated. If no resource is found, it is recreated according to the number of retries. After exceeding the retry limit, the server cleans up the created snapshots and temporary tasks and exits upon failure.

[0091] Step S6: Backup execution and adaptive renewal.

[0092] During backup, the server begins reading changed blocks and writing them to the backup target. During this process, a renewal threshold (whether it is less than the remaining backup time) is determined periodically by a period T (resource processing condition, e.g., 10 to 60 seconds). When the remaining validity period of the resource is insufficient to cover the sum of the remaining backup time and the safety buffer, the server calls the cloud platform's renewal interface to extend the validity period and updates last_extend_at (the time of the last renewal) and extend_count (the number of renewals). When the renewal request times out, the server first queries the actual status of the resource before deciding whether to retry or rebuild.

[0093] The server maintains a lifecycle context, ResourceLeaseContext, for each change block tracking resource, which includes at least the following: task_id (task identifier), vm_id (virtual machine identifier), disk_id (disk identifier), cbt_resource_id (change block tracking resource identifier), created_at (resource creation time), expire_at (resource expiration time), last_extend_at (last renewal time), extend_count (number of renewals), disk_size (disk size), transferred_bytes (transferred data), average_speed (average transfer rate), safety_margin (safety margin), and status (resource status).

[0094] The renewal threshold (whether the remaining validity time is less than the remaining backup time) for change block tracking resources is calculated as follows:

[0095] estimated_remaining_time=(disk_size-transferred_bytes) / max(average_speed,minimum_speed); safety_margin=max(platform_response_p95, configured_min_margin); if resource_remaining_time≤estimated_remaining_time+safety_margin:extend_resource_lifetime().

[0096] Among them, `resource_remaining_time` is the remaining validity period (remaining effective time) of the current change block tracking resource, which is obtained by the difference between `expire_at` (resource expiration time) and the current server time; `minimum_speed` (minimum transfer rate) is the lower limit of speed estimation, used to avoid the estimation tending to infinity due to the instantaneous speed being zero, and its value range is, for example, 1MB / s to 10MB / s, which can be configured according to the actual situation; `average_speed` (average transfer rate) is the ratio of the number of bytes transferred to the time elapsed, which can also be replaced by the sliding window speed or the speed of historical similar tasks; `platform_response_p95` is the most recent N... The 95th percentile of the time taken for cloud platform renewal or query interfaces (e.g., N=100) is obtained from online server statistics; `configured_min_margin` is the minimum safety buffer configured by the administrator, with a value ranging from 30 to 300 seconds; `safety_margin` is the larger of `platform_response_p95` and `configured_min_margin` to prevent renewal requests from not being completed in time when the cloud platform response fluctuates; when `extend_count` exceeds a preset limit (e.g., 10 times), an alarm is triggered and the process switches to timeout detection and reconstruction to prevent unlimited renewals from masking underlying faults. In some embodiments, the average speed in the renewal threshold can be replaced by the sliding window speed, median speed, or historical speed of similar tasks.

[0097] The above renewal process can be represented as follows: Calculate the estimated remaining time of the current backup (estimated_remaining_time): Subtract the amount of transferred data (transferred_bytes) from the total disk capacity (disk_size), and then divide by the greater of the average transfer rate (average_speed) and the minimum transfer rate (minimum_speed). Calculate the safety margin (safety_margin): Take the greater of the platform's 95th percentile response time (platform_response_p95) and the configured minimum margin (configured_min_margin). Perform a conditional check: If the remaining resource validity time (resource_remaining_time) is less than or equal to the remaining backup time (estimated_remaining_time) plus the safety margin (safety_margin), then execute the extend resource lifetime operation (extend_resource_lifetime).

[0098] Step S7: Task completion processing.

[0099] If the backup is successful, the server releases or retains change block tracking resources and deletes temporary snapshots and temporary tasks in the order of dependencies (cleanup order); if it fails or is canceled, the cleanup process is triggered.

[0100] The server can trigger a cleanup process both before backup and after abnormal exit. The server filters resources (change block tracking resources) that match the backup system's (server's) naming rules and whose associated tasks have ended, failed, been canceled, or do not exist. If a resource's creation time has exceeded the protection time window and it has not been used, it is cleaned up in the following order: closing the read session, deleting temporary snapshots, releasing change block tracking resources, and deleting temporary tasks. Resources that fail to be cleaned up are placed in a background retry queue, and an audit event is generated. In some embodiments, the protection time window can be dynamically determined based on a fixed configuration, task type, or cloud platform consistency delay; the handling of cleanup failures can employ scheduled retries, event-driven retries, or cleanup after manual confirmation.

[0101] Step S8, Audit and Alerts.

[0102] The server writes the creation, renewal, reconstruction, and cleanup results of each of the above stages to the audit log and generates alerts for events such as cleanup failure, renewal failure, and retry limit triggering.

[0103] Through the above embodiments, the server combines the lifecycle of the change block tracking resource and the remaining backup time to dynamically monitor the validity period of the change block tracking resource during the backup process, and adaptively renews the change block tracking resource, thereby improving the backup efficiency.

[0104] Furthermore, it can prevent the expiration of change block tracking resources during large disk or slow link backups; avoid duplicate creation and quota waste after creation timeout; improve the success rate of subsequent backups through pre-backup scanning; reduce the probability of resource deletion failure through dependency-based cleanup; prevent failed tasks from occupying cloud platform resources for a long time through anomaly cleanup and background retries; and reduce unnecessary renewal calls and reduce the pressure on cloud platform interfaces through adaptive renewal.

[0105] 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.

[0106] Based on the same inventive concept, this application also provides a backup change block tracking resource processing apparatus for implementing the above-described backup change block tracking resource processing method. The solution provided by this apparatus is similar to the implementation described in the above-described method. Therefore, the specific limitations of one or more backup change block tracking resource processing apparatus embodiments provided below can be found in the above-described limitations of the backup change block tracking resource processing method, and will not be repeated here.

[0107] In one exemplary embodiment, such as Figure 4 As shown, a processing apparatus for tracking change blocks in backup resources is provided, comprising: an acquisition module 500, a reading module 502, a determination module 504, and a processing module 506, wherein:

[0108] The acquisition module 500 is used to acquire the change block tracking resources corresponding to the device to be backed up when the backup conditions are detected; the change block tracking resources include the lifecycle context.

[0109] The reading module 502 is used to read the change block corresponding to the device and back it up based on the change block tracking resource if the acquisition of the change block tracking resource is detected.

[0110] The determination module 504 is used to determine the remaining valid time of the resource tracked by the change block in the process of backing up the change block, if the resource processing conditions are detected, based on the lifecycle context.

[0111] The processing module 506 is used to extend the remaining validity time of the change block tracking resource if the remaining validity time is less than the remaining backup time corresponding to the current backup, until the preset end condition is met, and then clean up the change block tracking resource; the remaining backup time is obtained based on the total disk capacity of the server corresponding to the current backup, the amount of data already transferred corresponding to the current backup, and the data transfer rate.

[0112] In one embodiment, the apparatus further includes: a residual cleanup module, configured to query the associated change block tracking resources corresponding to the device based on preset backup attribute information; if it is determined that the associated change block tracking resources meet the cleanup conditions based on the backup attribute information corresponding to the associated change block tracking resources, then clean up the associated change block tracking resources according to the cleanup order corresponding to the associated change block tracking resources; the cleanup order includes one or more of the following: closing the session for reading change blocks, deleting the temporary snapshot corresponding to the associated change block tracking resources, releasing the associated change block tracking resources, and deleting the temporary tasks corresponding to the associated change block tracking resources.

[0113] In one embodiment, the acquisition module 500 is configured to send a change block tracking resource generation request to the device via the device's change block tracking resource interface; the change block tracking resource generation request instructs the device to generate a change block tracking resource corresponding to the current backup; if no change block tracking resource generated by the device is received within a preset time window, the associated change block tracking resource corresponding to the device is queried based on the backup attribute information corresponding to the current backup; if a target change block tracking resource exists among the associated change block tracking resources, the change block tracking resource corresponding to the device is obtained based on the target change block tracking resource; the target change block tracking resource satisfies the following conditions: it belongs to the server corresponding to the current backup, it is associated with the task of the current backup, and its creation time is within the preset time window.

[0114] In one embodiment, the processing module 506 is configured to determine the amount of data to be transferred based on the difference between the total disk capacity and the amount of data already transferred; and to determine the remaining backup time based on the ratio of the amount of data to be transferred to the data transfer rate; wherein the data transfer rate represents the larger of the average transfer rate and the minimum transfer rate corresponding to the current backup.

[0115] In one embodiment, the processing module 506 is configured to clean up the change block tracking resources according to a cleanup order if the current backup has ended; the cleanup order includes one or more of the following: closing the session that reads the change block, deleting the temporary snapshot corresponding to the change block tracking resources, releasing the change block tracking resources, and deleting the temporary tasks corresponding to the change block tracking resources.

[0116] The modules in the aforementioned processing device for changing block tracking resources 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 memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0117] In one exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 5 As shown, this computer device includes a processor, memory, input / output (I / O) interfaces, 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 computational 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 an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores backup 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 executed by the processor, the computer program implements a method for processing change block tracking resources in a backup.

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

[0119] 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 above-described method for processing change block tracking resources in backups.

[0120] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the processing method for tracking resources with change blocks in the backup as described above.

[0121] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the above-described method for processing change block tracking resources in a backup.

[0122] 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.

[0123] 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.

[0124] 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.

[0125] 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 method for processing change block tracking resources in a backup, characterized in that, The method includes: When the backup conditions are met, the change block tracking resource corresponding to the device to be backed up is obtained; the change block tracking resource includes the lifecycle context. If the acquisition of the change block tracking resource is detected to be complete, then the change block corresponding to the device is read according to the change block tracking resource and backup is performed according to the change block; During the backup process based on the change block, if the resource processing conditions are detected, the remaining valid time of the resource tracked by the change block is determined according to the lifecycle context. If the remaining valid time is less than the remaining backup time corresponding to the current backup, the remaining valid time of the change block tracking resource is extended until the preset end condition is met, at which point the change block tracking resource is cleaned up; the remaining backup time is obtained based on the total disk capacity of the server corresponding to the current backup, the amount of data already transferred corresponding to the current backup, and the data transfer rate.

2. The method according to claim 1, characterized in that, Before obtaining the change block tracking resources corresponding to the device to be backed up, the process also includes: Based on the preset backup attribute information, query the associated change block tracking resources corresponding to the device; If the associated change block tracking resource is determined to meet the cleanup conditions based on the backup attribute information corresponding to the associated change block tracking resource, then the associated change block tracking resource is cleaned up according to the cleanup order corresponding to the associated change block tracking resource; the cleanup order includes one or more of the following: closing the session that reads the change block, deleting the temporary snapshot corresponding to the associated change block tracking resource, releasing the associated change block tracking resource, and deleting the temporary task corresponding to the associated change block tracking resource.

3. The method according to claim 2, characterized in that, The cleanup conditions include one or more of the following: The associated change block tracking resource does not belong to the server corresponding to the current backup, the backup task associated with the associated change block tracking resource is not in execution, and the creation time of the associated change block tracking resource is earlier than the preset time window.

4. The method according to claim 1, characterized in that, The acquisition of change block tracking resources corresponding to the device to be backed up includes: A change block tracking resource generation request is sent to the device via the device's change block tracking resource interface; the change block tracking resource generation request is used to instruct the device to generate the change block tracking resource corresponding to the current backup. If no change block tracking resource generated by the device is received within the preset time window, then the associated change block tracking resource corresponding to the device is queried according to the backup attribute information corresponding to the current backup. If a target change block tracking resource exists among the associated change block tracking resources, then the change block tracking resource corresponding to the device is obtained based on the target change block tracking resource; the target change block tracking resource meets the following conditions: it belongs to the server corresponding to the current backup, it is associated with the task of the current backup, and its creation time is within the preset time window.

5. The method according to claim 1, characterized in that, The steps for obtaining the remaining backup time include: The amount of data to be transferred is determined based on the difference between the total disk capacity and the amount of data already transferred. The remaining backup time is determined based on the ratio of the amount of data to be transmitted to the data transmission rate; the data transmission rate represents the larger of the average transmission rate and the minimum transmission rate corresponding to the current backup.

6. The method according to any one of claims 1 to 5, characterized in that, The cleanup of the change block tracking resources includes: If the current backup has ended, then clean up the change block tracking resources according to the cleanup order; The cleanup sequence includes one or more of the following: closing the session that reads the change block, deleting the temporary snapshot corresponding to the change block tracking resource, releasing the change block tracking resource, and deleting the temporary task corresponding to the change block tracking resource.

7. A processing apparatus for tracking change blocks in backup resources, characterized in that, The device includes: The acquisition module is used to acquire the change block tracking resources corresponding to the device to be backed up when the backup conditions are detected; the change block tracking resources include the lifecycle context. The reading module is used to read the change block corresponding to the device and back it up based on the change block tracking resource if the acquisition of the change block tracking resource is detected to be complete. The determination module is used to determine the remaining valid time of the resource tracked by the change block based on the lifecycle context if the resource processing conditions are detected during the backup process based on the change block. The processing module is configured to extend the remaining validity time of the change block tracking resource if the remaining valid time is less than the remaining backup time corresponding to the current backup, until a preset termination condition is met, and then clean up the change block tracking resource; the remaining backup time is obtained based on the total disk capacity of the server corresponding to the current backup, the amount of data already transferred corresponding to the current backup, and the data transfer rate.

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