Snapshot generation method and computing device

Abstract

The embodiment of the invention provides a snapshot generation method and computing equipment, relates to the technical field of servers, and is used for reducing the time consumption of generating snapshots by multiple disks and improving the overall operation efficiency. The method comprises the following steps: in response to a received snapshot generation instruction, pausing write-in operation on a plurality of disks; performing snapshot operation on each disk in sequence to obtain snapshots corresponding to the plurality of disks; in the process of executing the snapshot operation on the plurality of disks, if the estimated snapshot time is less than or equal to the minimum predicted silence time, recovering the write-in operation on the plurality of disks; wherein the pre-estimated snapshot time is pre-estimated snapshot time required by an unexecuted disk which does not execute the snapshot operation in the plurality of disks; the minimum predicted silence time is the minimum predicted silence time in the predicted silence time corresponding to each unexecuted disk; the predicted silence time is the time from the predicted disk to the next write operation under the condition that the snapshot generation instruction is not received.

Description

TECHNICAL FIELD

[0001] Embodiments of the present application relate to the technical field of server, and particularly relate to a snapshot generation method and a computing device. BACKGROUND

[0002] In some scenarios, it is necessary to retain the state of data in a disk at a certain time for subsequent quick recovery. For example, before upgrading an operating system, installing new software or patches, creating a snapshot can quickly roll back to a stable state when the change fails, reducing the operation risk. However, the consistency snapshot technology in the related art mainly adopts a synchronous processing mechanism of "suspend-snapshot-resume": when a snapshot command is received, the write operation of all application programs is immediately suspended to ensure that the memory and disk data are in a consistent state. After waiting for the snapshot task of all disks to be completed, the normal operation of the system is resumed to make the business service available again. This way uses a synchronous waiting mechanism, which causes the business interruption time to completely depend on the snapshot time of the slowest disk, resulting in too long service unavailable time. SUMMARY

[0003] Embodiments of the present application provide a snapshot generation method and a computing device, which are used to reduce the snapshot time of multiple disks and improve the overall operation efficiency.

[0004] In a first aspect, the embodiments of the present application provide a snapshot generation method, which includes: in response to receiving a snapshot generation instruction, suspending the write operation on multiple disks; sequentially performing snapshot operation on each disk to obtain snapshots corresponding to the multiple disks; during the snapshot operation on the multiple disks, if the estimated snapshot time is less than or equal to the minimum predicted silence time, resuming the write operation on the multiple disks; wherein the estimated snapshot time is the estimated snapshot time required by a non-executed disk in the multiple disks; the non-executed disk is a disk that has not performed snapshot operation; the minimum predicted silence time is the minimum predicted silence time among the predicted silence times corresponding to each non-executed disk; and the predicted silence time is the time predicted for the disk to the next write operation without suspending the write operation on the multiple disks.

[0005] The snapshot generation method provided in the embodiments of the present application can determine whether to resume the write operation by comparing the estimated snapshot time and the minimum predicted silence time during the process of generating the snapshot after receiving the snapshot generation instruction. Specifically, the estimated snapshot time refers to the sum of the snapshot time required by all the disks that have not performed the snapshot operation, i.e., the sum of the time required for all these disks to complete the snapshot operation from the current time point. The minimum silence time refers to the minimum value of the predicted silence time corresponding to all the disks that have not performed the snapshot operation. The predicted silence time refers to the remaining time length of each disk from the next write operation without suspending the write operation on the multiple disks.

[0006] It can be seen that the minimum silence time is actually the remaining time of the disk with the closest predicted next write operation time among all the disks that have not performed the snapshot operation. When the estimated snapshot time is less than or equal to the minimum value of the predicted silence time of each disk that has not performed the snapshot operation, the subsequent write operation on the disk that has not performed the snapshot operation will not usually occur during the process of performing the snapshot on the disk, and thus the write operation of all the disks can be resumed. Therefore, the time consumed by the multiple disks for generating the snapshot can be reduced, and the overall operation efficiency can be further improved.

[0007] In a possible implementation, the snapshot operation is sequentially performed on each disk, including: sequentially performing the snapshot operation on the multiple disks in the order of the predicted silence time corresponding to the disk from small to large.

[0008] In a possible implementation, the snapshot operation is sequentially performed on each disk, including: determining the non-active disk in the multiple disks with the predicted silence time greater than or equal to the preset silence time; and performing the snapshot operation on the non-active disk in an asynchronous or parallel processing manner.

[0009] In a possible implementation, the method further includes: in the case that the write operation on the multiple disks is resumed and the snapshot operation on the multiple disks is not completed, detecting whether there is a write operation on the disk that has not completed the snapshot operation; the disk that has not completed the snapshot operation is the disk in the multiple disks that has not completed the snapshot operation.

[0010] In the case that there is a write operation on any disk that has not completed the snapshot operation, outputting prompt information; the prompt information is used to prompt the user to select a target operation in at least one of the following operations: retaining the snapshot, deleting the snapshot, re-creating the snapshot, or a difference merging operation; the difference merging operation is used to merge the snapshot content of the disk that has not completed the snapshot operation with the snapshot content of the other disks; and in response to receiving an input signal, performing the target operation indicated by the input signal.

[0011] In one possible implementation, when the target operation includes a difference merging operation, the method further includes: marking the difference content based on the timestamp of the incomplete disk write operation; the difference content is the write content corresponding to the incomplete disk write operation.

[0012] In one possible implementation, the estimated snapshot time is the average time of the N most recent disk snapshot operations.

[0013] In one possible implementation, the predicted quiet time is determined as follows: for each disk, the most recent write time and the average time interval are determined; the most recent write time is the time corresponding to the most recent write operation on the disk, and the average time interval is the average of the time intervals of multiple write operations on the disk; based on the most recent write time, the current time, and the average time interval, the predicted quiet time for the disk is determined.

[0014] In one possible implementation, the predicted quiet time is determined as follows: for each disk, historical data corresponding to the disk is obtained; the historical data includes the write times of multiple write operations on the disk; the historical data of the disk is input into the quiet time prediction model to obtain the predicted quiet time of the disk.

[0015] In one possible implementation, the method further includes: in response to receiving a snapshot generation instruction, determining an initial predicted quiet time for each disk; during the snapshot operation on multiple disks, if the estimated snapshot time is less than or equal to the minimum predicted quiet time, resuming write operations on the multiple disks, including: in response to the completion of a snapshot operation on any disk, determining a target snapshot time based on the actual snapshot time of the completed disks and the estimated snapshot time of the unexecuted disks; the target snapshot time is used to represent the required snapshot time for the multiple disks; when the target snapshot time is less than or equal to the minimum initial predicted quiet time among the initial predicted quiet times corresponding to the unexecuted disks, determining that the estimated snapshot time is less than or equal to the minimum predicted quiet time; and resuming write operations on the multiple disks.

[0016] Secondly, embodiments of this application provide a snapshot generation apparatus for executing any of the snapshot generation methods provided in the first aspect above.

[0017] Thirdly, embodiments of this application provide a computing device including a processor and a memory; the processor is coupled to the memory; the memory is used to store computer instructions, which are loaded and executed by the processor to enable the computing device to implement the methods provided in the first aspect and its possible implementations described above.

[0018] Fourthly, embodiments of this application provide a computer-readable storage medium comprising: computer software instructions; and, when the computer software instructions are executed in a computing device, causing the computing device to implement the method provided by the first aspect and its possible implementations described above.

[0019] Fifthly, embodiments of this application provide a computer program product that, when run on a computing device, causes the computing device to execute the steps of the relevant method described in the first aspect above, so as to implement the method of the first aspect above.

[0020] The beneficial effects of the second to fifth aspects mentioned above can be referred to the corresponding description of the first aspect, and will not be repeated here. Attached Figure Description

[0021] Figure 1 A schematic diagram illustrating a snapshot generation process provided in an embodiment of this application;

[0022] Figure 2 A scenario diagram provided for an embodiment of this application;

[0023] Figure 3 This application provides a schematic diagram of the architecture of a computing device.

[0024] Figure 4 A flowchart illustrating a snapshot generation method provided in this application embodiment. Figure 1 ;

[0025] Figure 5 A flowchart illustrating a snapshot generation method provided in this application embodiment. Figure 2 ;

[0026] Figure 6 A schematic diagram of the software architecture of a computing device provided in an embodiment of this application;

[0027] Figure 7 A schematic diagram illustrating another snapshot generation process provided in an embodiment of this application;

[0028] Figure 8 This is a schematic diagram of the architecture of a snapshot generation device provided in an embodiment of this application. Detailed Implementation

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

[0030] It should be noted that in the embodiments of this application, the words "exemplarily" or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design scheme described as "exemplarily" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design schemes. Specifically, the use of the words "exemplarily" or "for example" is intended to present the relevant concepts in a specific manner.

[0031] To facilitate a clear description of the technical solutions of the embodiments of this application, the terms "first" and "second" are used in the embodiments of this application to distinguish the same or similar items with essentially the same function and effect. Those skilled in the art can understand that the terms "first" and "second" are not intended to limit the quantity or execution order.

[0032] This application provides a snapshot generation method. During the snapshot generation process upon receiving a snapshot generation instruction, the method compares the estimated snapshot time and the minimum predicted quiet time to determine whether write operations need to be resumed. Specifically, the estimated snapshot time is the sum of the snapshot times required for all disks that have not yet undergone snapshot operations; that is, the total time required from the current time until all disks have completed their snapshot operations. The minimum quiet time is the minimum of the predicted quiet times for all disks that have not yet undergone snapshot operations. The predicted quiet time refers to the remaining time before the next write operation for each disk without pausing write operations on multiple disks.

[0033] As can be seen, the minimum quiet time is actually the remaining time of the disk closest to the predicted next write operation among all disks that have not yet undergone snapshot operations. When the estimated snapshot time is less than or equal to the minimum predicted quiet time of all disks that have not yet undergone snapshot operations, subsequent write operations to these disks usually will not occur during the snapshot process. Therefore, write operations on all disks can be resumed, avoiding time wastage caused by excessive waiting. This reduces the time consumed in generating snapshots for multiple disks, thereby further improving overall operational efficiency.

[0034] Figure 2 This illustration shows a scenario provided by an embodiment of this application. Figure 2As shown in the illustration, the snapshot generation method provided in this application embodiment can be executed by a computing device 100. The computing device 100 can be a device with a virtual machine deployed, a storage array integrating multiple disk drives, or a server; this application embodiment does not impose any limitations on this. That is, this application embodiment does not limit the object of the snapshot operation; it can be performed on a virtual machine, a file system, or a database. For ease of description, this application embodiment uses the execution of a snapshot operation on a virtual machine as an example for illustration.

[0035] In some embodiments, the display device 200 may be a device with an interface display function. For example, the display device 200 may display a management tool's display page for the user to operate and generate a snapshot generation request. Optionally, the display device 110 may be a smartphone, tablet computer, personal portable computer, etc., and is not limited thereto.

[0036] Figure 3 This is a schematic diagram of a system architecture for a computing device provided in an embodiment of this application. Figure 3 As shown, the computing device 100 includes: one or more memories 120, one or more processors 110, a communication bus 140, and a communication interface 130. The processors 110 and memories 120 are connected via a bus 113; the one or more memories 120 are used to store computer program code, which includes computer instructions; when the one or more processors 110 execute the computer instructions, the computing device 100 performs the snapshot generation method provided in this application embodiment.

[0037] Optionally, the memory 120 may be a non-transitory computer-readable storage medium, such as a read-only memory (ROM), random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device, etc., and the embodiments of this application do not impose any limitations on this.

[0038] The processor 110 may be a central processing unit (CPU), a general-purpose processor, a network processor (NP), a digital signal processor (DSP), a microprocessor, a microcontroller, a programmable logic device (PLD), or any combination thereof, and the embodiments of this application do not impose any limitations on this.

[0039] The communication bus 140 can be an industry standard architecture (ISA) bus, a peripheral component interconnect (PCI) bus, or an extended industry standard architecture (EISA) bus, etc. This communication bus 140 can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 3 It is represented by a single thick line, but this does not mean that there is only one bus or one type of communication bus.

[0040] Communication interface 130 uses any transceiver-like device for communicating with other devices or communication networks, such as control systems, radio access networks (RAN), wireless local area networks (WLAN), etc.

[0041] The snapshot generation method provided in this application embodiment can be applied to... Figure 3 In the processor shown.

[0042] It should be noted that the system architecture and application scenarios described in the embodiments of this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided in the embodiments of this application. As those skilled in the art will know, with the evolution of system architecture and the emergence of new business scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0043] Figure 4 This is a schematic flowchart illustrating a snapshot generation method provided in an embodiment of this application. Figure 4 As shown, the snapshot generation method provided in this application embodiment may include the following steps:

[0044] S101. In response to receiving a snapshot generation command, suspend write operations on multiple disks.

[0045] In this context, a snapshot generation command refers to a command used to trigger the creation of a snapshot. A snapshot is a complete copy or record of the data state of a storage device (such as a disk) at a specific point in time, and can be used for data backup, recovery, and other scenarios. For example, in cloud storage services, the "create disk snapshot" command issued by a user through the console falls into this category. Snapshot generation commands can be triggered by the user or by the computing device according to preset rules; this application embodiment does not impose any limitations on this.

[0046] A disk refers to multiple physical or virtual storage devices in a computing device used to store data. They are responsible for storing various types of data, such as operating system files and user documents. A write operation is the process of storing or modifying data on the disk. For example, creating a new file or saving an edited document will trigger a write operation on the disk.

[0047] When a snapshot is generated, if disk write operations are in progress, the data may be dynamically changing, and the resulting snapshot may contain incomplete or incorrect data. Therefore, upon receiving a snapshot generation command, to ensure data consistency across all disks at a given point in time, write operations on multiple disks need to be paused. Pausing write operations brings the disk data to a relatively stable state, ensuring consistency between memory and disk data. The resulting snapshot accurately reflects the disk data status at that point in time and the complete association between virtual machine memory and disk data, providing a reliable foundation for subsequent data recovery, backup, and other operations.

[0048] As one implementation method, the virtual machine can be suspended upon receiving a snapshot generation command. Suspending the virtual machine ensures the consistency and integrity of the snapshot data. During virtual machine runtime, memory data is dynamically updated (e.g., process cache, temporary variables), and disk I / O operations are ongoing. Snapshots taken at this time may contain unsynchronized intermediate state data (e.g., partially written files, incomplete memory images). Suspension freezes all process and resource states, keeping memory data and disk layout static, thus ensuring the snapshot accurately captures the complete system state at that moment, preventing data corruption or application anomalies during subsequent recovery. It should be understood that after all disk snapshot operations are completed, the virtual machine can be restored to resume its processes and business services; this application will not elaborate further on this.

[0049] S102. Perform snapshot operations on each disk in sequence to obtain snapshots for multiple disks.

[0050] After pausing write operations on multiple disks, snapshot operations are performed on each disk sequentially according to a preset order. First, for the first disk, the snapshot program is launched, meticulously capturing all data information of the disk in its current quiescent state, from the underlying sector data to the upper-level file structure, copying and recording everything without omission, ultimately generating a snapshot for the first disk. Next, the same rigorous process is repeated for the second disk, ensuring its data state is accurately captured at the same time frame, resulting in a dedicated snapshot for the second disk; and so on, until all disks requiring snapshots have been processed, ultimately obtaining complete snapshots corresponding to each of the multiple disks. These snapshots each fully preserve the complete data overview of their respective disk at a specific point in time, laying a solid and reliable foundation for subsequent data analysis, data recovery, or system backup needs.

[0051] It should be understood that the embodiments of this application do not restrict the order in which snapshot operations are performed on multiple disks. For example, as one implementation, snapshot operations can be performed on all associated disks sequentially according to the disk mount order or a random order. As another feasible implementation, the order in which the disk snapshot operations are performed can be determined based on the predicted quiet time corresponding to the disk; specific implementation methods can be found in the following embodiments, and will not be repeated here.

[0052] S103. During the snapshot operation on multiple disks, if the estimated snapshot time is less than or equal to the minimum predicted quiet time, resume the write operation on the multiple disks.

[0053] The estimated snapshot time is the estimated snapshot time required for the disks that have not yet undergone snapshot operations among a plurality of disks. As one feasible implementation, the estimated snapshot time is the average time of the N most recent disk snapshot operations. N is a positive integer, and this application embodiment does not limit the value of N; for example, as one implementation, N is 20.

[0054] Disk snapshot operation time is typically affected by factors such as disk capacity, data fragmentation level, and hardware performance, exhibiting a certain degree of stability in the short term. The average time of the most recent N operations can filter out individual, accidental fluctuations (such as abnormal time consumption due to background process interference during a snapshot), providing a more accurate representation of the disk's snapshot time under normal conditions and offering a reliable reference for disks that haven't undergone snapshots. As disk usage increases, its data volume and performance may gradually change (e.g., increased capacity, increased fragmentation), causing snapshot times to fluctuate slowly. By using a rolling calculation of the "most recent N" times (e.g., updating the average after each snapshot and removing the earliest record), the estimated time can gradually adapt to these changes, avoiding excessive estimation deviations caused by using fixed values ​​over a long period.

[0055] In this embodiment, the predicted idle time is the time remaining until the next write operation on a disk, without pausing write operations on multiple disks. The predicted idle time directly reflects the current data write activity of the disks without pausing write operations on multiple disks. A short predicted idle time indicates that the disk is about to receive a new write operation, suggesting that the disk is in a high-frequency data interaction state and may be handling tasks with high real-time requirements, such as online transaction records or real-time data monitoring. Conversely, a long predicted idle time indicates that the disk has low data write demand in the near future and is in a relatively "idle" state, possibly corresponding to some periodically updated or low-frequency data storage tasks.

[0056] After obtaining the predicted quiet time for each disk, the smallest predicted quiet time can be selected from the predicted quiet times for multiple disks that have not yet undergone snapshot operations. This determines the closest point in time for a write operation to occur among the disks that have not yet performed a snapshot operation in the current state. When the estimated snapshot time is less than or equal to the minimum predicted quiet time, it indicates that there is insufficient time for subsequent write operations to occur during the snapshot generation process on the disks that have not yet undergone snapshot operations. Therefore, write operations on all disks can be resumed without affecting subsequent snapshot generation. It should be noted that after resuming write operations on multiple disks, the disks that have not yet completed snapshot operations still need to undergo snapshot operations. Because the estimated snapshot time is less than or equal to the minimum quiet time, the likelihood of data write operations occurring during the snapshot operation is low. This reduces the total time consumed in generating snapshots for multiple disks and improves overall operational efficiency, thus significantly optimizing system performance.

[0057] In related snapshot generation methods, it is usually necessary to wait for all disks to complete the snapshot operation before resuming write operations. This "wait until everything is complete before resuming" approach leads to excessively long waiting times. The solution provided in this application, however, compares the estimated snapshot time with the minimum predicted quiet time. This method can determine in advance whether write operations can be resumed. When the estimated snapshot time is less than or equal to the minimum predicted quiet time, write operations can be resumed immediately without waiting for all disks to complete the snapshot, thus avoiding wasted time due to excessive waiting.

[0058] In some embodiments, if the disk is currently undergoing a snapshot, it indicates that its data is in the "dynamic capture" phase. When resuming write operations on the disk at this time, the data on the disk may change in real time, potentially causing "tears" in the data captured during the snapshot process (e.g., some sectors have been updated while others remain old data). The resulting snapshot will contain inconsistent information and lose its reference value. Therefore, it is advisable to determine whether to resume write operations prematurely after the current disk has completed its snapshot operation.

[0059] The current disk snapshot has just been completed, meaning the previous phase of the task has ended, but the next disk snapshot has not yet started. Obtaining the estimated snapshot time for the unexecuted disk at this point allows us to use the current disk snapshot time as the basis for determining the estimated snapshot time, making the determined estimated snapshot time more accurate. Furthermore, this point in time falls within the "gap period" between two snapshots; the current disk has released its "snapshot lock," and the next disk has not yet occupied system resources. Evaluating data at this time minimizes interference with the snapshot process and provides a clear reference for "resumption of write" or "continued pause," achieving a balance between data consistency and system efficiency.

[0060] As a feasible implementation method, S103 can be specifically implemented as follows: in response to the completion of the snapshot operation of any disk, determine the estimated snapshot time and predicted silent time of the unexecuted disk; if the estimated snapshot time is less than or equal to the minimum predicted silent time, resume the write operation on the multiple disks.

[0061] When no snapshot operations have started on any disk, the estimated snapshot time for all disks can be uniformly adopted as the average value of the historical pool. After the snapshot operation on any disk is completed, the time taken to perform the snapshot operation can be added to the historical pool, and then the estimated snapshot time for the unexecuted disks can be re-determined using the average value of the new pool. Furthermore, this implementation method, by re-determining the predicted quiet time of the unexecuted disks based on the snapshot times of completed snapshots and historical snapshot times after the snapshot operation on each disk is completed, can more accurately determine the predicted quiet time.

[0062] As another feasible implementation, the method provided in this application embodiment further includes: in response to receiving a snapshot generation command, determining the initial predicted quiet time for each disk. That is, the initial predicted quiet time is the time required for the disk to perform its next write operation, determined from the time the snapshot generation command is received. Based on this, S103 can be implemented as follows:

[0063] S1031. In response to the completion of a snapshot operation on any disk, determine the target snapshot time based on the actual snapshot time of the completed disk and the estimated snapshot time of the unexecuted disk.

[0064] The target snapshot time represents the required snapshot time for the multiple disks. When snapshots are performed on multiple disks, the target snapshot time is dynamically updated as the operation progresses. When none of the disks have started snapshot operations, the target snapshot time is the sum of the estimated snapshot times for each disk. When a snapshot operation on any disk is completed, the target snapshot time is the sum of the actual snapshot times of the completed disks and the estimated snapshot times of the unexecuted disks.

[0065] S1032. When the target snapshot time is less than or equal to the smallest initial predicted silent time among the initial predicted silent times corresponding to the unexecuted disk, determine that the estimated snapshot time is less than or equal to the smallest predicted silent time.

[0066] The initial predicted quiet time is generated upon receiving the snapshot generation command. It is the predicted time from the disk to the next write operation, starting from the time the command is received. The target snapshot time can also be used to represent the time required to execute snapshots on multiple disks, starting from the time the command is received. In other words, in the process of determining whether the target snapshot time is less than or equal to the minimum initial predicted quiet time, the starting point of all times is "the time when the snapshot generation command is received (denoted as T0)".

[0067] When the current time (T1) is introduced, the elapsed Δt (T1-T0) becomes the calibration bridge: the remaining window of the initial predicted silent time is "minimum initial predicted silent time - Δt" (i.e., minimum predicted silent time); the remaining time of the target snapshot time is "target snapshot time - Δt" (i.e., estimated snapshot time). At this time, "target snapshot time ≤ minimum initial predicted silent time" and "estimated snapshot time ≤ minimum remaining silent time" are essentially the same. The former uses T0 as a benchmark to determine whether the total elapsed time is within the initial safe window, while the latter uses T1 as a benchmark to determine whether the remaining elapsed time is within the contracted window. The two can be logically unified through dynamic calibration based on the elapsed time.

[0068] S1033, Resume write operations on multiple disks.

[0069] When the estimated snapshot time is less than or equal to the minimum predicted quiet time, it can be determined that the conditions for early recovery are met, and write operations to multiple disks can be resumed.

[0070] In this implementation, the time of receiving the snapshot generation command is used as a unified starting point to calculate the target snapshot time and the initial predicted quiet time. This ensures that parameters such as the quiet time window and total snapshot time for each disk are calculated based on the same benchmark during subsequent judgments. It eliminates the need to calculate the predicted quiet time every time, reducing computational load and preventing parameter misalignment caused by benchmark inconsistencies. Furthermore, it avoids repeatedly calculating the initial predicted quiet time for each disk, significantly reducing computational load. Simultaneously, dynamic calibration of the remaining time can be achieved through simple derivation, ensuring that multi-disk collaborative snapshot operations are completed before the next write operation on all disks, fundamentally guaranteeing data consistency and improving the efficiency and stability of snapshot recovery.

[0071] In some embodiments, since the predicted quiet time is the time until the next write operation on a disk when write operations on multiple disks are not paused, the predicted quiet time can be determined based on historical write operation data of the disks in the state of not pausing write operations.

[0072] As a feasible implementation method, the predicted silence time is determined in the following way:

[0073] S201. For each disk, determine the most recent write time and the average time interval for that disk.

[0074] Among them, the most recent write time is the time corresponding to the most recent write operation on the disk, and the average time interval is the average time interval of multiple write operations on the disk.

[0075] The most recent write time is the exact moment of the last write operation on the disk, marking the most recent node in disk write activity. The average time interval, on the other hand, is the average value calculated by statistically analyzing the time differences between multiple disk write operations, reflecting the approximate cyclical pattern of disk write operations. These two parameters, combined with the current time, form the basis for calculating and predicting the silent time.

[0076] S202. Based on the most recent write time, the current time, and the average time interval, determine the predicted silent time corresponding to the disk.

[0077] Starting with the most recent write time and combining it with the average time interval, the estimated time of the next write operation can be calculated. In other words, the predicted time of the next write equals the most recent write time plus the average time interval. Then, subtracting the current time from this predicted time gives the predicted idle time. For example, if a disk's most recent write occurred at 10:00, the average time interval is 10 minutes, and the current time is 10:03, then the predicted time of the next write is 10:10, and the predicted idle time is 7 minutes, meaning that the disk will experience its next write operation approximately 7 minutes from the current time.

[0078] As can be seen, this implementation method utilizes the historical patterns of disk write operations. For disks with a certain periodicity in write behavior, such as periodically generated log files and periodically updated databases, the average time interval can reflect the write rhythm well. Based on this, the predicted quiet time is relatively accurate and has high reference value.

[0079] In other embodiments, the timing of disk write operations may not be highly regular. Relying solely on the most recent write time and the average time interval to determine the predicted quiet time may lead to bias due to the limitations of historical patterns. Therefore, combining models to calculate the predicted quiet time can better address the randomness and complexity of write behavior and improve prediction accuracy.

[0080] As another feasible approach, the predicted quiet period is determined as follows:

[0081] S301. For each disk, obtain the historical data corresponding to the disk. The historical data includes the write times of multiple write operations on the disk.

[0082] For each disk, its historical data forms the basis for subsequent predictions. Historical data can include the write times of multiple disk write operations. These write times record the specific points in the past when data was written to the disk. For example, a disk might have write operations at 8:10 AM, 8:35 AM, and 9:02 AM. This time information collectively constitutes historical data reflecting the disk's write patterns. By collecting this historical data, we can provide data support for subsequent analysis of the characteristics and patterns of disk write behavior. After all, only by mastering sufficient past write time records can we uncover potential patterns or anomalies, laying the data foundation for accurate prediction of silent periods.

[0083] S302. Input the historical data of the disk into the silent time prediction model to obtain the predicted silent time of the disk.

[0084] After acquiring historical disk data, it is input into a silent time prediction model to obtain the predicted silent time for that disk. This step is crucial in transforming historical data into predictive results. The silent time prediction model performs in-depth analysis of multiple write times, such as identifying trends in write intervals and differences in write frequency across different time periods. Then, combined with its own algorithmic logic, it calculates the predicted time from the disk's current state to the next write operation—that is, the predicted silent time. This process transforms fragmented historical data into practically meaningful predictive results, providing a scientific time reference for operations such as disk snapshots.

[0085] It should be understood that the embodiments of this application do not limit the specific type of silent time prediction model. It can be a time series model (such as ARIMA, SARIMA), a machine learning model (such as random forest, gradient boosting tree), or a deep learning model (such as LSTM, GRU). The embodiments of this application do not impose any restrictions on this. Taking time series models as an example, they are good at capturing the linear trend and periodicity of data, and are suitable for scenarios where write operations have obvious time periods (such as high-frequency writes at fixed times every day). ARIMA eliminates the non-stationarity of data by differentiating historical write time series, and then predicts the next write time based on the principles of autoregression and moving average. If the write operation has seasonal fluctuations (such as concentrated writes every Monday morning), SARIMA can introduce a seasonal term to further improve the prediction accuracy.

[0086] As can be seen, this implementation uses a silent time prediction model to predict silent time. The model exhibits strong adaptability and flexibility, capable of handling diverse write scenarios. Different disks have significantly different write patterns; some show obvious periodicity, while others fluctuate randomly. Therefore, different silent time prediction models can be selected based on different application scenarios to adapt to different scenario characteristics. By adjusting parameters or structure, changes in write patterns can be flexibly addressed. This adaptability means that the determination of prediction time is no longer limited to a fixed pattern, maintaining stable prediction results in complex environments. Simultaneously, the model's efficient computing power can quickly process large amounts of historical data and output prediction results promptly, meeting the needs of scenarios with high real-time requirements.

[0087] In some embodiments, the solution provided in this application will resume write operations on multiple disks when the estimated snapshot time is less than or equal to the minimum predicted quiet time; therefore, to ensure that writes can be resumed in advance, disks with smaller predicted quiet times can be processed first.

[0088] As a feasible implementation method, S102 performs snapshot operations on each disk in sequence, including: performing snapshot operations on multiple disks in sequence according to the predicted silent time corresponding to the disks that have not been snapshotted, from smallest to largest.

[0089] Snapshots are performed on disks with predicted idle times from shortest to longest. The core principle is to prioritize disks with "more pressing time windows" (i.e., disks closer to their next write operation). This ensures that the disk with the shortest idle time completes its snapshot first, causing the minimum predicted idle time to increase over time during the snapshot process. This allows the opportunity for the "estimated snapshot time to be less than or equal to the minimum predicted idle time" to arrive sooner, thus improving the overall efficiency and reliability of multi-disk collaborative snapshots.

[0090] As a feasible implementation method, snapshot operations are performed on each disk sequentially in S102, including:

[0091] S1021. Identify inactive disks among multiple disks whose predicted silent time is greater than or equal to the preset silent time.

[0092] If the predicted quiet time is greater than or equal to the preset quiet time, it indicates that there will be no write operations on the disk for a relatively long period of time in the future, and therefore it can be called an inactive disk.

[0093] S1022. For inactive disks, perform snapshot operations using asynchronous or parallel processing methods.

[0094] During the quiet period (after pausing read / write operations), the data state of inactive disks has stabilized, and their predicted quiet time meets the preset value, indicating that snapshot operations do not require strict synchronous execution. Since these disks currently have no business I / O load, even asynchronous or parallel processing will not compromise data consistency. In contrast, active disks need to have snapshot operations performed as early as possible because their quiet windows may be short, and delayed processing could lead to business recovery blockage.

[0095] As an implementation approach, asynchronous processing prioritizes active disks with shorter predicted idle times, while inactive disks can be processed later. This reduces the main thread's waiting time, allowing the system to continue subsequent tasks (such as restoring business I / O) immediately after initiating a snapshot of inactive disks, with the snapshot being completed by a background thread, thus improving overall response speed.

[0096] As an implementation method, parallel processing involves simultaneously handling snapshot operations on multiple inactive disks. Parallel processing fully utilizes storage bandwidth and multi-core CPUs, allowing snapshots of multiple inactive disks to be executed concurrently, significantly reducing the overall processing time. For example, when creating virtual machine snapshots in batches, parallel snapshots of inactive disks can compress the total time to near the operation time of the slowest single disk, while active disks still exclusively occupy high-priority resources, avoiding contention.

[0097] In some embodiments, although the predicted quiet time is estimated based on historical data and has a high degree of reliability, uncertainties may still exist in real-world environments. For example, new write requests may be generated immediately after a write operation is resumed. This can impact the data consistency of the snapshot.

[0098] As one feasible approach, please refer to Figure 5 The snapshot generation method provided in this application embodiment further includes:

[0099] S401. When resuming write operations on multiple disks, and multiple disks have not completed snapshot operations, detect whether there are write operations on the disks that have not completed snapshot operations. The disks that have not completed snapshot operations are those among the multiple disks.

[0100] When performing snapshot operations on multiple disks, if some disks fail to complete the snapshot, it is necessary to check whether these incomplete disks are still receiving write operations. Because snapshots require data to remain consistent at a certain point in time, incomplete disks may still accept new writes, leading to data inconsistency.

[0101] One implementation approach is to detect whether there are incomplete disk write operations based on the disk's write status. For example, checking active disk I / O requests or file system logs can confirm whether incomplete disk write operations exist.

[0102] S402. If any disk write operation is incomplete, output a prompt message.

[0103] The prompt message is used to prompt the user to select the target operation from at least one of the following: keep the current snapshot, delete the current snapshot, recreate the snapshot, or perform a difference merge operation.

[0104] When write operations are detected on a disk where a snapshot has not yet been completed, it indicates that there is data inconsistency. Therefore, in order to ensure the consistency of snapshot data, a prompt message can be output so that the user can select the target operation.

[0105] As one implementation method, the current snapshot is retained to maintain the existing snapshot state. Users can choose this operation in scenarios where data consistency requirements are not high or some data differences are acceptable. The computing device can record any abnormal states of this snapshot for subsequent verification.

[0106] As one implementation method, deleting the current snapshot completely removes the snapshot created this time. Users can choose this operation when absolute data consistency is required. The computing device can release relevant storage resources and generate an operation log.

[0107] As one implementation method, recreating a snapshot is used to abort the current snapshot process and immediately start a new round of snapshot operations, ensuring that all disks complete the snapshot in a write-free state.

[0108] As one implementation, the difference merging operation is used to merge the snapshot content of incomplete disks with write operations with the snapshot content of other disks. The computing device automatically compares the write differences of incomplete disks and intelligently merges them with the data of completed snapshots to generate an eventually consistent snapshot.

[0109] One approach is to compare the current data on the incomplete disk with the baseline state at the time of snapshot initiation to identify all data changes (difference data) that occurred during the snapshot process. These differences are then merged into the data on the completed disk in chronological order. For example, subsequent changes to the incomplete disk (such as writes between 10:00 and 10:05) can be realigned to the snapshot trigger time (10:00), bringing all disk data back to the logically consistent point in time. This ensures the consistency of the entire snapshot's timeline.

[0110] This embodiment does not limit the way of outputting prompts. Depending on the actual application scenario, various forms can be used to deliver snapshot anomaly information to the user, including but not limited to: graphical interface pop-up prompts, command line terminal alarms, email / SMS notifications, system log records, or API callback notifications.

[0111] S403. In response to receiving an input signal, execute the target operation indicated by the input signal.

[0112] After outputting the prompt message, the computing device can continuously monitor user input signals to determine the target operation selected by the user. Users can trigger the target operation command through various interactive methods (such as command-line input, graphical interface operation, API calls, or preset automation rules). The system does not restrict the input method, only ensuring the explicitness and executability of the command. Upon detecting valid input, the computing device can immediately terminate the current anomaly detection process and execute the user-specified operation (such as difference merging, snapshot deletion, etc.), while simultaneously feeding back the operation status to the log and user interface, ensuring the auditability and controllability of the processing.

[0113] As can be seen from S401-S403, the solution provided in this embodiment synchronously detects the I / O status of the disk with incomplete snapshots during the write recovery operation to determine whether there is any write behavior that may disrupt snapshot consistency. Upon detecting an incomplete disk write operation, a prompt is proactively triggered, effectively preventing data inconsistencies that may arise from prematurely resuming the write operation.

[0114] In some embodiments, since the above-mentioned difference merging operation needs to retain the current abnormal snapshot, in order to avoid the inability to trace the source of the abnormality, as a feasible implementation, when the target operation includes a difference merging operation, the snapshot generation method provided in this application embodiment further includes: marking the difference content based on the timestamp of the incomplete disk write operation; the difference content is the write content corresponding to the incomplete disk write operation.

[0115] When the target operation includes a differential merge operation, it is necessary to record the timestamps of all write operations performed on the disk during the snapshot process, and use these timestamps to version-mark the differential content. These differential content specifically refer to the data changes corresponding to write operations that occurred after the snapshot was initiated but before the disk was completed. By establishing an operation log along the time dimension, the differential content can be accurately logically aligned with the data in the completed snapshot according to the time sequence during differential merge. This enables both "point-in-time rollback" consistency repair (restoring the data to the unified state at the time the snapshot was triggered) and "selective fusion" (retaining valid changes within a specific time window), thus providing a flexible recovery strategy while ensuring data consistency.

[0116] In some embodiments, to illustrate the snapshot invocation method provided in this application, the software architecture of the computing device in this application will be analyzed below with reference to the accompanying drawings. Please refer to... Figure 6 The computing device may include: a virtualization platform 61, a consistent snapshot acceleration module 62, and a storage system 63. It should be understood that both the consistent snapshot acceleration module 62 and the storage system 63 can work together with the virtualization platform 61. The functionality of some modules may depend on the interfaces and mechanisms provided by the virtualization platform 61, but strictly speaking, they are not necessarily included in the virtualization platform 61. Instead, they are integrated with the virtualization platform 61 in the form of plug-ins, components, or independent services.

[0117] The virtualization platform 61 is the foundation of the entire architecture. It abstracts and virtualizes physical resources (such as servers, storage, and networks) through software technology, creating multiple virtual resources (such as virtual machines and virtual storage) to achieve flexible allocation, efficient utilization, and isolated management of resources. As the upper-level management entity, the virtualization platform 61 is responsible for the lifecycle management of virtual machines (creation, pause, and resumption). It also calls the interface of the consistent snapshot acceleration module 62 via API (such as triggering snapshots, querying progress, and resuming virtual machines), and provides the VM Tools interface to the disk I / O monitoring module 63 to support I / O data collection.

[0118] The consistent snapshot acceleration module 62 is the core execution unit of the snapshot generation method. It can be used to: collect IO data from the virtual machine side, analyze and predict the disk silent window, dynamically sort snapshot priorities, decide when to restore the virtual machine, and ensure the consistency of incomplete snapshots.

[0119] As the underlying data carrier, storage system 63 has absolute control over the physical media and performs I / O operations according to the original logic. It can also provide persistent storage (local disk, SAN, NAS or cloud storage) for virtual machine disks and receive snapshot instructions (create, read, merge) from the consistency snapshot acceleration module 62 to ensure reliable storage and access to snapshot data.

[0120] In some embodiments, please continue reading Figure 6 The consistent snapshot acceleration module 62 may include: a disk I / O monitoring module 621, a disk I / O model analysis module 622, a snapshot priority sorting module 623, a virtual machine early recovery algorithm module 624, and a write fault tolerance and consistency guarantee module 625. Through clear division of responsibilities and interface interaction, each module works together to solve problems such as long business interruption time and low resource utilization in snapshot technology.

[0121] The disk I / O monitoring module 621 (data awareness layer) serves as the data acquisition hub on the virtual machine side. This module can be embedded into the virtual machine environment through VM Tools provided by the virtualization platform 61 to capture raw data of write I / O operations of each disk in real time (including key metadata such as operation type, timestamp, and data volume), thus constructing the system's data awareness entry point. Its core value lies in providing a high-fidelity input source for upper-layer predictive analysis. By transmitting standardized I / O data streams to the upstream disk I / O model analysis module 622, it achieves the transformation from physical storage behavior to computable characteristics.

[0122] The disk I / O model analysis module 622 (intelligent prediction layer) serves as the decision engine for snapshot acceleration. This module uses time series analysis algorithms (such as LSTM or ARIMA) to model the received raw I / O data, dynamically predicting the predicted idle time and idle probability of each disk. This transforms discrete I / O events into continuous, schedulable opportunity windows. For example, by identifying the fixed refresh cycle of the database log disk (such as a batch write interval every 200ms), it provides quantitative decision-making basis for the snapshot priority ranking module.

[0123] The snapshot priority sorting module 623 (scheduling decision layer) is used to dynamically adjust the snapshot execution order based on the output of the disk I / O model analysis module 622, minimizing the total time spent in the synchronous snapshot phase. It can allocate high priority (priority processing) to active disks with short predicted idle times (such as database data disks) and low priority (delayed processing or parallel processing) to inactive disks with long predicted idle times (such as read-only backup disks), based on a "short window priority processing" strategy, thereby reducing overall scheduling time.

[0124] The virtual machine early recovery algorithm module 624 (control center layer) is used to recalculate T1 (target snapshot time) and T2 (minimum predicted quiet time) when each disk snapshot is completed. When T1 ≤ T2 (for example, the remaining snapshot time is 80ms and the minimum predicted quiet time is 100ms), virtual machine recovery is immediately triggered through the virtualization platform 61 API, reducing service interruption time from seconds to milliseconds.

[0125] The write fault tolerance and consistency guarantee module 625 (exception handling layer) is used to receive write IO requests for incomplete snapshot disks after virtual machine recovery through the notification interface of virtualization platform 61. When an incomplete snapshot disk is detected to be written, the following responses are automatically triggered: real-time recording of the timestamp and range of conflicting data blocks; retention of a copy of the original snapshot data in storage system 63; and generation of prompt information containing repair options (such as difference merging / rollback) so that the user can choose the processing method.

[0126] In some embodiments, it is assumed that the virtual machine contains three disks: Disk A (system disk): runs web services, with active write I / O (an average write operation every 30ms); Disk B (file storage disk): stores user-uploaded files, with moderate write I / O (an average write operation every 200ms); Disk C (log disk): stores storage service logs, with sparse write I / O (an average write operation every 5 seconds). Taking the entire process of virtual machine snapshot triggering as an example, the snapshot generation method provided in this application embodiment is illustrated as follows:

[0127] S1, Snapshot Triggering and Module Initialization.

[0128] Users can trigger virtual machine snapshot operations through the cloud platform console, which sends snapshot commands to the consistent snapshot acceleration module 62. The snapshot execution module initializes the snapshot task list (including disks A, B, and C); the disk IO monitoring module 63 starts immediately (in continuous running state) and begins collecting data such as write IO timestamps and operation types from the three disks (with an accuracy of 10ms); the disk IO model analysis module reads historical IO data (the last 30 days), initializes the time series prediction model parameters, and initializes a unified historical time consumption pool (assuming N=20, storing the actual time consumption of the last 20 snapshots).

[0129] S2, IO behavior monitoring and silent window prediction.

[0130] The disk I / O monitoring module 63 performs real-time I / O acquisition: Disk A (system disk): acquires write I / O timestamps t1 = 10:00:00.000, t2 = 10:00:00.030, t3 = 10:00:00.060 (interval 30ms); Disk B (file disk): acquires write I / O timestamps t1 = 10:00:00.000, t2 = 10:00:00.200 (interval 200ms); Disk C (log disk): acquires write I / O timestamps t1 = 10:00:00.000, t2 = 10:00:05.000 (interval 5 seconds).

[0131] The disk I / O model analysis module performs silent window prediction:

[0132] Assuming the average time for the last 20 snapshots is 150ms, the estimated snapshot time for each disk is 150ms. The predicted quiet time (Y_i, where i is the disk identifier) ​​for each disk is calculated based on the disk I / O interval: Disk A: Adjacent I / O interval Δt = [30ms, 30ms], average interval Xi = 30ms; current quiet time T_current = 0ms (no new I / O after snapshot trigger), predicted remaining quiet time Yi = max(30ms - 0ms, 0) = 30ms; Disk B: Adjacent I / O interval Δt = [200ms], average interval Xi = 200ms; current quiet time T_current = 0ms, predicted remaining quiet time Yi = max(200ms - 0ms, 0) = 200ms; Disk C: Adjacent I / O interval Δt = [5000ms], average interval Xi = 5000ms; current quiet time T_current = 0ms, predicted remaining quiet time Yi = max(5000ms - 0ms, 0) = 5000ms.

[0133] Therefore, the prediction results are: Y_A = 30ms, Y_B = 200ms, Y_C = 5000ms.

[0134] S3, Snapshot Priority Sorting and T1 / T2 Initialization.

[0135] The snapshot priority sorting module sorts the snapshots by priority from smallest to largest according to the Y_i value. The snapshot generation execution order is: disk A (Y=30ms) → disk B (Y=200ms) → disk C (Y=5000ms).

[0136] The virtual machine early recovery algorithm module initializes the calculations for T1 (target snapshot time) and T2 (minimum predicted silent time): Initial T1 = estimated time of disk A (150ms) + estimated time of disk B (150ms) + estimated time of disk C (150ms) = 450ms; T2: take the minimum Y_i value of the disks that have not yet completed, i.e., T2 = min(30ms, 200ms, 5000ms) = 30ms; at this time, T1 = 450ms > T2 = 30ms, the early recovery condition is not met, and the snapshot continues to be executed.

[0137] S4. Snapshot Execution and Dynamic Updates (Continuous Disk I / O Monitoring)

[0138] The snapshot execution module performs a snapshot of disk A: it calls the virtualization platform 61 interface to perform a snapshot of disk A, which takes 160ms (the actual time may be slightly higher than the historical average due to the activity of the system disk).

[0139] The virtual machine early recovery algorithm module dynamically updates T1 and T2: Update the historical time-consuming pool: Add the actual time-consuming of disk A, 160 ms, to the pool (the pool capacity is 20 and there is no overflow); Update the estimated time-consuming of the remaining disks: Reset the estimated time-consuming of disks B and C to 155 ms each using the new pool average (assuming the average is 155 ms after update); Recalculate T1: The time-consuming of the processed disk is 160 ms + the estimated time-consuming of the unprocessed disks (155 ms + 155 ms) = 470 ms; Recalculate T2: The unfinished disks are disks B and C, and Y_i remains 200 ms and 5000 ms (since there is no new I / O on disks B and C during snapshot execution), so T2 = 200 ms.

[0140] At this time, T1 = 470 ms > T2 = 200 ms, still not meeting the early recovery condition, and continue to execute.

[0141] S5. Execute the snapshot of disk B and update T1 / T2 again.

[0142] The snapshot execution module executes the snapshot of disk B: Call the interface to execute the snapshot of disk B, which takes 150 ms (the same as the historical average).

[0143] The virtual machine early recovery algorithm module dynamically updates T1 and T2: Update the historical time-consuming pool: Add the actual time-consuming of disk B, 150 ms, to the pool (the pool capacity is 20 and there is no overflow); Update the estimated time-consuming of the remaining disks: Reset the estimated time-consuming of disk C to 153 ms using the new pool average (assuming the average is 153 ms after update); Recalculate T1: The time-consuming of the processed disks is (160 ms + 150 ms) + the estimated time-consuming of the unprocessed disk (153 ms) = 463 ms; Recalculate T2: The unfinished disk is disk C, and Y_i remains 5000 ms (since there is no new I / O on disk C during snapshot execution), so T2 = 5000 ms.

[0144] At this time, T1 = 463 ms < T2 = 5000 ms, meeting the early recovery condition.

[0145] S6. Early recovery of the virtual machine.

[0146] The virtual machine early recovery algorithm module triggers the recovery of the virtual machine: Send a recovery instruction to the virtualization platform 61, and the virtual machine resumes running from the suspended state, and the business service becomes available again (the interruption time is only 463 ms, while the traditional solution needs to wait for all disks to complete, about 450 ms + potential latency).

[0147] Unfinished snapshot processing: The snapshot of disk C is not completed and is marked as "asynchronous processing", and will be continued by the background task later (without affecting the operation of the virtual machine).

[0148] Exemplarily, in combination with Figure 1 please refer to Figure 7In the above embodiment, after disk B completes its snapshot operation and meets the snapshot recovery conditions, the virtual machine can resume operation ahead of schedule, enabling the virtual machine to resume business operations earlier. The snapshot is then saved after disk C's snapshot is completed. This shortens business interruption time and ensures business continuity. Simultaneously, the system monitors the snapshot progress of disk C and, upon completion, properly saves the newly generated snapshot according to the storage policy, ensuring data traceability and recoverability.

[0149] S7. Post-recovery anomaly monitoring and fault tolerance assurance.

[0150] After the virtual machine resumes operation, the disk I / O monitoring module 63 continues to run (remains running), monitoring the write I / O activity of all disks (including recovered disks A and B, and disk C whose snapshot is not yet complete) in real time. Depending on whether disk C triggers new I / O after recovery, the following two scenarios apply:

[0151] Scenario 1: No I / O scenario.

[0152] The disk I / O monitoring module 63 continuously collects write I / O data from disk C, but detects no new write operations (timestamp not updated). The write fault tolerance and consistency assurance module checks the snapshot status of disk C (marked as "asynchronous processing"), and combined with the I / O monitoring data (no new I / O), determines that the disk currently has no write risk. The background task continues to execute the snapshot operation of disk C (no need to wait for the silent window due to no active writes); the snapshot execution module calls the virtualization platform 61 interface to perform a snapshot of disk C (taking approximately 155ms, consistent with the estimated time); after completion, the snapshot status of disk C is marked as "completed," and the snapshot progress record in the log management module is updated. At this point, all disk snapshots are completed, the virtual machine remains running, and data consistency is risk-free.

[0153] Scenario 2: IO scenarios.

[0154] In this scenario, the disk I / O monitoring module 63 detects a new write operation (such as appending to a service log) triggered on disk C at timestamp t = 10:00:05.000, and records the timestamp, data size (e.g., 512 bytes), and data block range (e.g., 0x2000-0x3000) of this I / O operation. The write fault tolerance and consistency guarantee module checks the snapshot status of disk C (marked as "asynchronous processing") and, combined with the I / O monitoring data (new I / O exists), determines that the snapshot of this disk is "partially inconsistent," meaning that the data was modified before the snapshot was completed, resulting in a difference between the generated snapshot and the current actual state of the disk.

[0155] The write fault tolerance and consistency guarantee module outputs an alarm to the user interface and provides the following three remediation options:

[0156] Retain Abnormal Snapshots (Partial Consistency): If the user chooses to retain a currently generated abnormal snapshot, mark it as "Partially Consistent". The user needs to manually verify the availability of this snapshot.

[0157] Delete all snapshots from this consistent snapshot (task failed): If the user chooses to terminate this consistent snapshot task, the system automatically deletes all generated partial snapshots (including completed snapshots of disks A and B, and abnormal snapshots of disk C). The virtual machine remains running, but this snapshot task has failed; the user needs to re-trigger the snapshot operation to generate a new, complete, consistent snapshot.

[0158] Task Retry (Delete all snapshots in this consistent snapshot and recreate the consistent snapshot): If the user chooses to re-execute the consistent snapshot task, first delete all snapshots related to this task (including completed disk A and B snapshots and incomplete disk C snapshots), and then re-trigger the snapshot process. The virtual machine needs to re-enter the suspended state, and the snapshot execution module re-executes the snapshot operations of all disks (A, B, C) in priority order.

[0159] In an exemplary embodiment, this application also provides a snapshot generation apparatus. The snapshot generation apparatus may be the aforementioned computing device or a processor within the computing device. The snapshot generation apparatus may include one or more functional modules for implementing the snapshot generation method of the above method embodiments.

[0160] For example, Figure 8 This is a schematic diagram of a snapshot generation apparatus provided in an embodiment of this application. Figure 8 As shown, the snapshot generation device 80 includes: a pause module 81, an execution module 82, and a recovery module 83.

[0161] The pause module 81 is used to pause write operations on multiple disks in response to receiving a snapshot generation command; the execution module 82 is used to perform snapshot operations on each disk sequentially to obtain snapshots corresponding to multiple disks; the recovery module 83 is used to resume write operations on multiple disks if the estimated snapshot time is less than or equal to the minimum predicted quiet time during the snapshot operation on multiple disks; wherein, the estimated snapshot time is the estimated snapshot time required for the non-executed disks among the multiple disks that have not yet undergone snapshot operations; the minimum predicted quiet time is the smallest predicted quiet time among the predicted quiet times corresponding to each non-executed disk; the predicted quiet time is the predicted time between the disk and the next write operation without pausing write operations on multiple disks.

[0162] In one possible implementation, the execution module 82 is specifically used to perform snapshot operations on multiple disks in ascending order of the predicted silent time corresponding to the unexecuted disks.

[0163] In one possible implementation, the execution module 82 is specifically used to identify inactive disks among multiple disks whose predicted quiet time is greater than or equal to a preset quiet time; and to perform snapshot operations on inactive disks using asynchronous or parallel processing methods.

[0164] In one possible implementation, the snapshot generation device 80 further includes: a detection module, used to detect whether there is a write operation on an incomplete disk when resuming write operations on multiple disks and multiple disks have not completed snapshot operations; the incomplete disk is the disk among the multiple disks that has not completed snapshot operations; an output module, used to output a prompt message when there is a write operation on any incomplete disk; the prompt message is used to prompt the user to select a target operation from at least one of the following operations: retain the current snapshot, delete the current snapshot, recreate the snapshot, or perform a difference merging operation; wherein, the difference merging operation is used to merge the snapshot content of the incomplete disk with write operations with the snapshot content of other disks; the execution module 82 is further used to execute the target operation indicated by the input signal in response to receiving an input signal.

[0165] In one possible implementation, the snapshot generation device 80 further includes: a marking module, used to mark the difference content based on the timestamp of the incomplete disk write operation when the target operation includes a difference merging operation; the difference content is the write content corresponding to the incomplete disk write operation.

[0166] In one possible implementation, the estimated snapshot time is the average time of the N most recent disk snapshot operations.

[0167] In one possible implementation, the predicted quiet time is determined as follows: for each disk, the most recent write time and the average time interval are determined; the most recent write time is the time corresponding to the most recent write operation on the disk, and the average time interval is the average of the time intervals of multiple write operations on the disk; based on the most recent write time, the current time, and the average time interval, the predicted quiet time for the disk is determined.

[0168] In one possible implementation, the predicted quiet time is determined as follows: for each disk, historical data corresponding to the disk is obtained; the historical data includes the write times of multiple write operations on the disk; the historical data of the disk is input into the quiet time prediction model to obtain the predicted quiet time of the disk.

[0169] In one possible implementation, the snapshot generation apparatus 80 further includes: a determining module, configured to determine the initial predicted quiet time for each disk in response to receiving a snapshot generation instruction; and a recovery module, specifically configured to, in response to the completion of a snapshot operation on any disk, determine a target snapshot time based on the actual snapshot time of the completed disks and the estimated snapshot time of the unexecuted disks; the target snapshot time represents the required snapshot time for multiple disks; when the target snapshot time is less than or equal to the minimum initial predicted quiet time among the initial predicted quiet times corresponding to the unexecuted disks, determine that the estimated snapshot time is less than or equal to the minimum predicted quiet time; and recover write operations on the multiple disks.

[0170] For a detailed description of the above-mentioned optional methods, please refer to the foregoing method embodiments, which will not be repeated here. Furthermore, the explanation of any of the snapshot generation apparatuses provided above and the description of their beneficial effects can be found in the corresponding method embodiments described above, which will not be repeated here.

[0171] This application also provides a computer-readable storage medium. All or part of the processes in the above method embodiments can be executed by computer instructions instructing related hardware; for example, the related hardware can be a processor of a computing device. The program instructions can be stored in the above-described computer-readable storage medium, and when executed, they can implement the processes of the above method embodiments. The computer-readable storage medium can be memory. The above-described computer-readable storage medium can also be an external storage device, such as a hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc. Further, the above-described computer-readable storage medium can include both memory and external storage devices. The above-described computer-readable storage medium is used to store the above-described computer program instructions and other programs and data required by the above-described snapshot generation method.

[0172] This application also provides a computer program product comprising a computer program that, when run on a computing device, causes the computing device to execute any of the snapshot generation methods provided in the above embodiments.

[0173] Although this application has been described herein in conjunction with various embodiments, those skilled in the art, by reviewing the accompanying drawings, disclosure, and appended claims, will understand and implement other variations of the disclosed embodiments in carrying out the claimed application. In the claims, the word "comprising" does not exclude other components or steps, and "a" or "an" does not exclude multiple components. A single processor or other unit can implement several functions listed in the claims. While different dependent claims may recite certain measures, this does not mean that these measures cannot be combined to produce good results.

[0174] Although this application has been described in conjunction with specific features and embodiments, it is obvious that various modifications and combinations can be made thereto without departing from the spirit and scope of this application. Accordingly, this specification and drawings are merely exemplary illustrations of this application as defined by the appended claims, and are considered to cover any and all modifications, variations, combinations, or equivalents within the scope of this application. Clearly, those skilled in the art can make various alterations and modifications to this application without departing from the spirit and scope of this application. Thus, if such modifications and modifications of this application fall within the scope of the claims of this application and their equivalents, this application is also intended to include such modifications and modifications.

[0175] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A snapshot generation method, characterized in that, include: In response to receiving a snapshot generation command, write operations to multiple disks are paused; Snapshot operations are performed on each of the disks in sequence to obtain snapshots corresponding to the plurality of disks; During the snapshot operation on the multiple disks, if the estimated snapshot time is less than or equal to the minimum predicted quiet time, the write operation on the multiple disks is resumed. The estimated snapshot time is the estimated snapshot time required for the disks that have not been executed among the plurality of disks; The unexecuted disk is the disk for which no snapshot operation has been performed; the minimum predicted quiet time is the minimum predicted quiet time among the predicted quiet times corresponding to each unexecuted disk; the predicted quiet time is the time between the disk and the next write operation, without pausing write operations on multiple disks.

2. The snapshot generation method according to claim 1, characterized in that, The step of sequentially performing snapshot operations on each of the disks includes: Snapshot operations are performed on the multiple disks in ascending order of the predicted silent time corresponding to the unexecuted disks.

3. The snapshot generation method according to claim 1, characterized in that, The step of sequentially performing snapshot operations on each of the disks includes: Identify inactive disks among the plurality of disks whose predicted inactivity time is greater than or equal to a preset inactivity time; For the inactive disks, snapshot operations are performed using asynchronous or parallel processing methods.

4. The snapshot generation method according to any one of claims 1 to 3, characterized in that, The method further includes: If write operations to the plurality of disks are resumed, and the plurality of disks have not completed the snapshot operation, it is detected whether there are write operations on the disks that have not completed the snapshot operation; the disks that have not completed the snapshot operation are the disks among the plurality of disks. If any of the incomplete disks have write operations, a prompt message is output; the prompt message is used to prompt the user to select a target operation from at least one of the following: keep the current snapshot, delete the current snapshot, recreate the snapshot, or perform a difference merge operation; wherein, the difference merge operation is used to merge the snapshot content of the incomplete disk with write operations with the snapshot content of other disks; In response to receiving an input signal, the target operation indicated by the input signal is executed.

5. The snapshot generation method according to claim 4, characterized in that, If the target operation includes the difference merging operation, the method further includes: The differences are marked based on the timestamps of the incomplete disk write operations; the differences are the write content corresponding to the incomplete disk write operations.

6. The snapshot generation method according to any one of claims 1 to 5, characterized in that, The estimated snapshot time is the average time of the N most recent snapshot operations performed on the disk.

7. The snapshot generation method according to any one of claims 1 to 6, characterized in that, The predicted silence time is determined in the following way: For each disk, determine the most recent write time and the average time interval corresponding to the disk; the most recent write time is the time corresponding to the most recent write operation of the disk, and the average time interval is the average of the time intervals of multiple write operations of the disk; Based on the most recent write time, the current time, and the average time interval, the predicted silent time corresponding to the disk is determined.

8. The snapshot generation method according to any one of claims 1 to 6, characterized in that, The predicted silence time is determined in the following way: For each disk, obtain the historical data corresponding to the disk; the historical data includes the write time of multiple write operations on the disk; The historical data of the disk is input into the silent time prediction model to obtain the predicted silent time corresponding to the disk.

9. The snapshot generation method according to claim 1, characterized in that, The method further includes: In response to receiving the snapshot generation instruction, determine the initial predicted quiet time for each of the disks; During the snapshot operation on the plurality of disks, if the estimated snapshot time is less than or equal to the minimum predicted quiet time, resuming the write operation on the plurality of disks includes: In response to the completion of a snapshot operation on any disk, a target snapshot time is determined based on the actual snapshot time of the completed disks and the estimated snapshot time of the unexecuted disks; the target snapshot time is used to represent the required snapshot time for the plurality of disks. When the target snapshot time is less than or equal to the minimum initial predicted silent time among the initial predicted silent times corresponding to the unexecuted disks, the estimated snapshot time is determined to be less than or equal to the minimum predicted silent time. Resume write operations on the plurality of disks.

10. A computing device, characterized in that, The computing device includes a processor and a memory; the processor is coupled to the memory. The memory is used to store computer instructions; The computer instructions are loaded and executed by the processor to enable the computing device to perform the method as described in any one of claims 1-9.

Images