A data migration method, device, electronic equipment, storage medium and program product

Abstract

The application discloses a data migration method and device, electronic equipment, a storage medium and a program product, relates to the technical field of computers, and actively identifies a target volume corresponding to each snapshot, and extracts a set of to-be-migrated snapshot data blocks therefrom, so that historical snapshot content can be systematically included in a migration process, and by migrating snapshots in turn from early to late according to creation time, data recovery abnormalities caused by disordered migration order of snapshots are avoided. The application introduces a current generation value and processes the un-migrated snapshots in turn according to the snapshot creation time sequence, solves the technical problem that the mirror volume technology cannot synchronously migrate snapshot data during cross-storage pool migration, and associates the ordinary snapshots with the generation value and continuously writes the snapshots into a target storage space during the migration process, so that conversion to a continuous data protection mechanism is realized. After the migration is completed, the data protection function of the source volume in the new pool occupies less resources and is more advantageous.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a data migration method, apparatus, electronic device, storage medium, and program product. Background Technology

[0002] Volume migration is a technique used to change the physical location of the backend storage space of a volume. In storage devices, multiple hard drives are typically used to form a RAID array, and these RAID arrays are combined to form a storage pool. Users can create volumes on this storage pool and map them to the host for use. The storage space used by a volume is provided by its respective storage pool. Multiple storage pools can be created on a single storage device, each based on a different RAID configuration. Volume migration technology moves the data of a volume from its current storage pool to another storage pool, allowing it to use the storage space provided by the target pool.

[0003] When performing cross-storage pool data migration on a volume with an existing snapshot (i.e., the source volume), mirrored volume-based migration typically only migrates the data from the source volume itself to the target pool. Since snapshot data from different times is stored in separate snapshot volumes, which remain within their original storage pools, this migration method cannot migrate snapshot data from other volumes besides the source volume to the target pool, resulting in snapshot data not being migrated synchronously with the source volume. Summary of the Invention

[0004] This application provides a data migration method, apparatus, electronic device, storage medium, and program product to at least solve the problem in the related art that, when performing cross-pool data migration on a snapshotted volume, the data migration function based on the mirrored volume cannot migrate other snapshot data outside the source volume to the target pool.

[0005] This application provides a data migration method, including: obtaining the current generation value; determining whether there are snapshots that have not yet been migrated, wherein the source volume has snapshots, and each snapshot corresponds to a target volume; when there are snapshots that have not yet been migrated, selecting the first snapshot with the earliest creation time from all unmigrated snapshots, and determining the first target volume corresponding to the first snapshot; determining the first set of data blocks to be migrated from the first target volume based on the first snapshot; reading the snapshot data to be migrated from the first target volume based on the first set of data blocks, associating the snapshot data to be migrated with the current generation value, and writing it into the first storage space; after all the snapshot data to be migrated in the first target volume has been migrated, incrementing the current generation value, and returning to the step of determining whether there are snapshots that have not yet been migrated, until all unmigrated snapshots have been written into the first storage space.

[0006] This application also provides a data migration apparatus, including an acquisition module, a judgment module, a selection module, a range determination module, a writing module, and a looping module; the acquisition module is used to acquire the current generation value; the judgment module is used to determine whether there are snapshots that have not yet been migrated, wherein the source volume has snapshots, and each snapshot corresponds to a target volume; the selection module is used to select the first snapshot with the earliest creation time from all unmigrated snapshots when there are snapshots that have not yet been migrated, and determine the first target volume corresponding to the first snapshot; the range determination module is used to determine the first set of data blocks that need to be migrated from the first target volume based on the first snapshot; the writing module is used to read the snapshot data to be migrated in the first target volume according to the first set of data blocks, associate the snapshot data to be migrated with the current generation value, and write it into the first storage space; the looping module is used to increment the current generation value and return to the step of judging whether there are snapshots that have not yet been migrated after all the snapshot data to be migrated in the first target volume has been migrated, until all the unmigrated snapshots have been written into the first storage space.

[0007] This application also provides an electronic device, comprising: a memory for storing a computer program; and a processor for implementing the steps of any of the above-described data migration methods when executing the computer program.

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

[0009] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the above-described data migration methods.

[0010] The data migration method, apparatus, electronic device, storage medium, and program products provided in this application effectively solve the technical problem of traditional mirrored volume technology's inability to synchronously migrate snapshot data during cross-storage pool migration by introducing the current generation value and processing unmigrated snapshots one by one according to their creation time order. This solution is no longer limited to migrating only the source volume's primary data; instead, it actively identifies the target volume (i.e., the first target volume) corresponding to each snapshot and extracts the set of snapshot data blocks to be migrated from it, ensuring that historical snapshot content can be systematically incorporated into the migration process. By migrating snapshots sequentially from earliest to latest creation time, the temporal consistency of data versions is guaranteed, avoiding data recovery anomalies caused by disordered snapshot migration order. More importantly, by associating snapshot data with the current generation value and writing it to the first storage space of the target end during the migration process, a complete transfer of snapshot data from the original storage pool to the target pool is achieved, completely breaking the limitation that snapshot data must depend on the original pool. This solution not only achieves integrated migration of the source volume and all its historical snapshots, ensuring a complete data chain in the target pool after migration and supporting point-in-time snapshot recovery, thus improving data integrity and availability, but also lays the foundation for implementing a data organization method similar to Continuous Data Protection (CDP) on the target end through generational values, enhancing data protection capabilities. Furthermore, the migration process is logically clear and highly controllable, facilitating state tracking and error recovery, and is compatible with existing mirrored volume migration architectures. It only requires enhanced control logic and does not require large-scale modifications to the underlying structure, demonstrating good feasibility and promotional value. Therefore, it not only solves the fundamental problem of snapshots not being able to migrate with volumes, but also provides strong support for building a more efficient and flexible data protection system. Attached Figure Description

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

[0012] Figure 1 A flowchart illustrating a data migration method provided in an embodiment of this application;

[0013] Figure 2 A flowchart illustrating another data migration method provided in an embodiment of this application;

[0014] Figure 3 A flowchart illustrating another data migration method provided in an embodiment of this application;

[0015] Figure 4 This is a schematic diagram illustrating the process of taking a snapshot of LUN_A as provided in an embodiment of this application.

[0016] Figure 5 The second schematic diagram of the process of taking a snapshot of LUN_A is provided for an embodiment of this application;

[0017] Figure 6 The third schematic diagram illustrating the process of taking a snapshot of LUN_A is provided for an embodiment of this application;

[0018] Figure 7 The fourth schematic diagram illustrating the process of taking a snapshot of LUN_A is provided for an embodiment of this application;

[0019] Figure 8 The fifth schematic diagram illustrating the process of taking a snapshot of LUN_A provided in this application embodiment;

[0020] Figure 9 The sixth schematic diagram illustrating the process of taking a snapshot of LUN_A provided for an embodiment of this application;

[0021] Figure 10 A flowchart illustrating an example of a data migration method provided in an embodiment of this application;

[0022] Figure 11 This is a schematic diagram illustrating the result after data migration is completed in an example of the data migration method provided in this application embodiment;

[0023] Figure 12 This is a schematic diagram of the structure of the data migration device provided in the embodiments of this application;

[0024] Figure 13 This is a schematic diagram of the hardware structure of a computer device according to an embodiment of this application. Detailed Implementation

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

[0026] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

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

[0028] Mirrored volume technology is a high-availability data technology. For a regular volume, only one volume is mapped to the host, and similarly, there is only one volume's storage space in the underlying storage pool. All data written to this volume is copied only once. When the storage pool space containing this volume fails (e.g., a software failure causing the RAID in the storage pool to become unavailable, or a hardware failure causing the hard drives comprising the RAID to fail and the number of failed disks exceeds the RAID's tolerance), the volume and even all volumes in the entire storage pool become unusable. Furthermore, if the corresponding error cannot be repaired, all business data in these volumes will be unrecoverable. Mirrored volume technology provides an additional layer of protection for the data within the volume. For a mirrored volume, only one volume is mapped to the host, but there are two volumes' storage spaces in the underlying storage pool. When write I / O reaches the mirrored volume module, the module copies an identical copy of the data and writes it to both storage spaces—this is the so-called mirrored volume dual-write mode. When reading data, it only needs to be read from one of the storage spaces because the two copies of the data are identical. Furthermore, when creating a mirrored volume, it is generally recommended to create the two storage spaces in two different storage pools. This way, if one storage space fails, the original data can still be retrieved from the other space, ensuring that the business data for that volume will not be lost even if the failed space cannot be recovered. Moreover, if the failed space recovers, the thin pool module provides a data resynchronization function, copying the differing data written during the failure period from the healthy space to the newly recovered space. Once the differing data synchronization is complete, high data availability can continue to be guaranteed.

[0029] Existing cross-pool volume migration technology is based on mirrored volume technology: An existing volume is converted into a mirrored volume. During the conversion, the new data space is specified to use the space of the pool to which it is to be migrated. After conversion, the mirrored volume module automatically synchronizes the data from the old space to the new space. Once all data is synchronized, the old data space is deleted, and the mirrored volume is converted back to a regular volume. After the conversion, the volume's data space uses the storage space of the new pool. This method enables the migration of volume data space.

[0030] When performing cross-storage pool data migration on a volume with an existing snapshot (i.e., the source volume), mirrored volume-based migration typically only migrates the data from the source volume itself to the target pool. Since snapshot data from different times is stored in separate snapshot volumes, which remain within their original storage pools, this migration method cannot migrate snapshot data from other volumes besides the source volume to the target pool, resulting in snapshot data not being migrated synchronously with the source volume.

[0031] One solution is to also migrate the target volume, moving all data to the new pool. However, data migration based on mirrored volumes doesn't recognize snapshot relationships. After migration, the original target volume becomes an independent volume in the new pool, no longer associated with the newly migrated source volume. The end result is that after migration, volumes with snapshot relationships become independent volumes. When modifying the migrated source volume, a snapshot copy-and-write (COW) operation is no longer performed. When using the target volume to roll back and repair data on the source volume, it's impossible to distinguish which data was copied to the target volume due to source volume modifications and which is the target volume's original initialization data. Because of this inability to differentiate data, during rollback, all target volume data is copied back to the source volume, leading to data errors on the source volume.

[0032] On the other hand, since CDP (Content Dependency Protocol) can be used to implement point-in-time data protection in thin pools, and CDP has advantages over ordinary snapshots such as lower resource consumption and lower performance overhead, when migrating snapshots from ordinary pools to thin pools, if ordinary COW (Copy-on-Write) snapshots are still used—that is, each snapshot target volume occupies one volume resource and data is copied through COW technology—then there is no advantage in thin pools. If the conversion from ordinary snapshots to CDP can be completed during the migration, the advantages of this volume migration are more obvious.

[0033] Based on this, embodiments of this application provide a data migration method, combined with Figure 1 The execution flow of the data migration method is described in detail.

[0034] like Figure 1 As shown, the data migration method includes the following steps:

[0035] Step S101: Obtain the current generation value.

[0036] Generation ID (gen_id) is a core concept in CDP (Continuous Data Protection) used to identify the time version of data. CDP is a point-in-time advanced data protection technology that associates a generation ID with each I / O operation on a volume, precisely recording the snapshot generation at which the data was written. Each generation ID is equivalent to a timestamp, identifying which CDP snapshot generation the data belongs to.

[0037] Under the CDP mechanism, the data corresponding to snapshots created at different times all belong to the source volume itself and are distinguished by their generation value in its underlying storage space. The system ensures that older data with lower generation values ​​are not mistakenly considered invalid and prematurely reclaimed, thus preserving historical data intact. Compared to traditional non-CDP snapshots (which typically require creating a separate target volume for each snapshot and using a copy-on-write (COW) mechanism), CDP does not require the additional generation of a target volume. It can quickly locate any historical version of data using only the generation value, eliminating the data copying overhead of the COW process. This means that the creation of CDP snapshots has almost no performance loss and provides stronger data protection capabilities, supporting recovery to almost any past point in time.

[0038] For example, for a volume, before a CDP snapshot is created, the generation value of all data written by I / O is 0. When a CDP snapshot is created for the first time, this snapshot is generation 0, and its data consists of all data blocks in the source volume with a generation value of 0. After the snapshot is created, the current generation value of the source volume increments to 1, and the generation value of subsequent newly written data blocks is also 1. When a CDP snapshot is created again, the new snapshot is generation 1, corresponding to all data with a generation value of 1. The current generation value then increments to 2 again, and the generation value of subsequent I / Os becomes 2, and so on.

[0039] Due to uneven host I / O distribution, certain areas of the volume (hot spots) are frequently written to, causing their data block generation values ​​to continuously update and tend to be higher; while less accessed areas (cold data areas) may have generation values ​​that remain unchanged for a long time. When reading the latest data, only the data block with the largest generation value at each location needs to be read; however, when reading a CDP snapshot of a certain generation (e.g., generation n), it is necessary to search for data with a generation value equal to n at a specified location. If it does not exist, the search continues backwards for generation values ​​n-1, n-2, and so on until the corresponding data is found. This generation-value-based version tracing mechanism enables efficient and fine-grained historical data recovery.

[0040] Step S102: Determine whether there are snapshots that have not yet been migrated, where the source volume has snapshots and each snapshot corresponds to a target volume.

[0041] Snapshot technology is a point-in-time data protection technique that saves data from a volume at a specific moment. Even if the data on the volume changes subsequently, the data in the snapshot remains the same as it was at the time the snapshot was taken, unaffected by subsequent writes. When a volume is snapshotted, a new volume (called the target volume) is created from the original volume (the source volume), and a relationship (called a snapshot relationship) is established between the two volumes. The target volume stores the data from the original volume at the time the snapshot was taken. Immediately after a snapshot is taken, the target volume is empty. When data at a certain location in the source volume is modified for the first time, the snapshot module copies that data from the source volume to the target volume before writing the new data. This is the Copy-on-Write (COW) technique used in snapshots. The snapshot module uses bitmap technology to record the data status of the source and target volumes, indicating which locations have been copied to the target volume and which have not. When the host modifies data on the source volume, it can use the bitmap to determine if a write to that location is the first write and whether a copy to the target volume is necessary. Similarly, when reading data from the target volume, the bitmap can confirm whether the actual data at that location is stored on the target volume or the source volume, thus identifying the actual location to be read. Taking snapshots of the source volume is typically used to protect its historical data. Taking snapshots of the source volume at different times allows for finer-grained protection of the source volume data. The target volume of the snapshot is usually not mapped to the host for modification to prevent data errors during rollback if the snapshot data is modified.

[0042] Step S103: When there are snapshots that have not yet been migrated, select the first snapshot with the earliest creation time from all the unmigrated snapshots and determine the first target volume corresponding to the first snapshot.

[0043] In traditional snapshot mechanisms, when a snapshot is created on a source volume, the system typically allocates a separate storage space for that snapshot, namely the target volume (also called a snapshot volume or COW volume), to store a copy of the data from the source volume at the time the snapshot was created, or to save the original data when the source volume data is overwritten (such as using copy-on-write technology). Therefore, each snapshot is associated with a specific target volume at the storage level, serving as the entity that carries its data.

[0044] Step S104: Determine the first set of data blocks that need to be migrated from the first target volume based on the first snapshot.

[0045] Since snapshots typically employ copy-on-write (COW) or similar mechanisms, the first target volume stores source volume data blocks that were modified at or after the snapshot creation time. Therefore, based on the first snapshot, it is possible to determine which data blocks are valid in the first target volume and have not yet been migrated. This allows for the construction of the first set of data blocks that need to be read from and migrated from that target volume, ensuring that only necessary data is migrated and improving migration efficiency.

[0046] Step S105: Read the snapshot data to be migrated in the first target volume according to the first data block set, associate the snapshot data to be migrated with the current generation value and write it into the first storage space.

[0047] The first storage space is the thin pool. A thin pool is a storage resource management technology that pre-creates a shared storage resource pool in the storage system and dynamically allocates storage space to multiple storage volumes (such as thin volumes) on demand. Unlike traditional thick provisioning, a thin pool does not allocate all physical storage space when the volume is created; instead, it allocates the required data blocks from the pool only when data is actually written, thus significantly improving storage space utilization and avoiding resource waste.

[0048] When the first storage space is a thin pool, physical storage space is dynamically allocated only when the snapshot data to be migrated is actually written, avoiding the waste caused by pre-allocation and further improving the utilization of storage resources. At the same time, combined with bitmap-based precise management of the data blocks to be migrated, on-demand allocation and efficient writing are ensured, effectively reducing the space occupation and write amplification of the thin pool.

[0049] Step S106: After all the snapshot data to be migrated in the first target volume has been migrated, increment the current generation value and return to step S102 until all unmigrated snapshots have been written to the first storage space.

[0050] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0051] This application's embodiments effectively solve the technical problem of traditional mirrored volume technology's inability to synchronously migrate snapshot data during cross-storage pool migration by introducing the current generation value and processing unmigrated snapshots one by one according to their creation time order. This solution is no longer limited to migrating only the source volume's primary data; instead, it proactively identifies the target volume (i.e., the first target volume) corresponding to each snapshot and extracts the set of snapshot data blocks to be migrated from it, ensuring that historical snapshot content can be systematically incorporated into the migration process. By migrating snapshots sequentially from earliest to latest creation time, the temporal consistency of data versions is guaranteed, avoiding data recovery anomalies caused by disordered snapshot migration order. More importantly, during the migration process, the snapshot data is associated with the current generation value and written to the first storage space on the target end, achieving a complete transfer of snapshot data from the original storage pool to the target pool, completely breaking the limitation that snapshot data must depend on the original pool. This solution not only achieves integrated migration of the source volume and all its historical snapshots, ensuring a complete data chain in the target pool after migration and supporting point-in-time snapshot recovery, thus improving data integrity and availability, but also lays the foundation for implementing a data organization method similar to Continuous Data Protection (CDP) on the target end through generational values, enhancing data protection capabilities. Furthermore, the migration process is logically clear and highly controllable, facilitating state tracking and error recovery, and is compatible with existing mirrored volume migration architectures. It only requires enhanced control logic and does not require large-scale modifications to the underlying structure, demonstrating good feasibility and promotional value. Therefore, it not only solves the fundamental problem of snapshots not being able to migrate with volumes, but also provides strong support for building a more efficient and flexible data protection system.

[0052] Embodiments of this application also provide a data migration method, combined with Figure 2 The execution flow of the data migration method is described in detail.

[0053] like Figure 2 As shown, the data migration method includes the following steps:

[0054] Step S201: Obtain the current generation value.

[0055] Step S202: Determine whether there are snapshots that have not yet been migrated, where the source volume has snapshots and each snapshot corresponds to a target volume.

[0056] Step S203: When there are snapshots that have not yet been migrated, select the first snapshot with the earliest creation time from all the unmigrated snapshots, and determine the first target volume corresponding to the first snapshot.

[0057] Step S204: Determine the first set of data blocks that need to be migrated from the first target volume based on the first snapshot.

[0058] In one alternative implementation, determining the first set of data blocks that need to be migrated from the first target volume based on the first snapshot includes the following steps S2041 to S2042.

[0059] Step S2041: If the first snapshot is the snapshot with the earliest creation time among all snapshots of the source volume, then obtain the first snapshot bitmap corresponding to the first snapshot, and take all data blocks corresponding to the first snapshot bitmap as the first data block set;

[0060] Step S2042: If the first snapshot is not the earliest created snapshot among all snapshots of the source volume, then obtain the second snapshot bitmap corresponding to the previous snapshot of the first snapshot, and take the data blocks marked as "source volume data has been copied" in the second snapshot bitmap as the first data block set.

[0061] This is because in the data migration process based on snapshot technology, the earliest snapshot contains the initial complete data of the source volume, so all its corresponding data blocks need to be used as a migration set to build the base image; while for subsequent snapshots, since their data depends on the copy status of the previous snapshot, only the data blocks in the previous snapshot that have been marked as "source volume data has been copied" need to be migrated to reflect the incremental data content that the current snapshot needs to inherit.

[0062] Steps S2041 to S2042 fully utilize the temporal relationship between snapshots and the precise copy status of bitmap records, avoiding repeated migration of existing data, effectively reducing data transmission volume and I / O overhead, improving migration efficiency, and ensuring the consistency of data and the correctness of dependency logic in the snapshot chain, thus achieving accurate and efficient incremental data migration.

[0063] Furthermore, snapshot technology uses bitmap technology to record the data status of the source and target volumes, i.e., which locations of data have been copied to the target volume and which locations have not yet been copied. For example, in the first and second snapshot bitmaps, a bit of 0 indicates that the source volume data in the corresponding data block has not yet been copied to the target volume, and a bit of 1 indicates that the source volume data in the corresponding data block has been copied to the target volume. Based on this, the first set of data blocks to be migrated from the first target volume is determined according to the first snapshot. This includes: if the first snapshot is the earliest created snapshot among all snapshots of the source volume, then the first snapshot bitmap corresponding to the first snapshot is obtained, and all data blocks corresponding to the first snapshot bitmap are used as the first data block set; if the first snapshot is not the earliest created snapshot among all snapshots of the source volume, then the second snapshot bitmap corresponding to the previous snapshot of the first snapshot is obtained, and the data blocks with a bit of 1 in the second snapshot bitmap are used as the first data block set.

[0064] By reusing the bitmap state of the previous snapshot, the incremental data blocks that only need to be migrated can be accurately identified, avoiding repeated reading and writing of migrated data. This significantly reduces the I / O pressure and data transmission overhead of the source storage. Especially in scenarios with long snapshot chains or intensive data changes, it greatly shortens the overall migration time and improves the resource utilization efficiency and execution efficiency of the migration process.

[0065] Furthermore, before determining the first set of data blocks to be migrated from the first target volume based on the first snapshot, the method further includes: allocating a mirror volume bitmap, wherein the mirror volume bitmap is used to record the status of data blocks to be migrated to the first storage space. The mirror volume bitmap uses the following marking method: a bit of 0 indicates that the data in the corresponding data block has been synchronized to the first storage space; a bit of 1 indicates that the data in the corresponding data block has not been synchronized to the first storage space. Based on this, including all data blocks corresponding to the first snapshot bitmap as the first data block set includes: in the mirror volume bitmap, setting all positions of the data blocks corresponding to the first snapshot bitmap to 1; including the data blocks with a bit of 1 in the second snapshot bitmap as the first data block set includes: in the mirror volume bitmap, setting the position corresponding to the data block with a bit of 1 in the second snapshot bitmap to 1.

[0066] This is because the synchronization status of data blocks to be migrated needs to be tracked and managed uniformly during the data migration process. By pre-allocating mirror volume bitmaps and using a marking mechanism of "1 indicates unsynchronized and 0 indicates synchronized", the status of all data blocks to be migrated to the target storage space can be centrally recorded, avoiding confusion with the status information of each snapshot bitmap. When determining the first set of data blocks, the positions of data blocks marked as "copied" in the first or second snapshot bitmap are set to "1" (unsynchronized) in the mirror volume bitmap. In essence, this registers these data blocks to be migrated in the global migration task, facilitating subsequent unified scheduling and execution of migration operations according to the bitmap.

[0067] Through the above-described further implementation methods, centralized management and status tracking of migration tasks are achieved, improving the controllability and recoverability of the migration process. At the same time, bitmap bitwise operations support efficient data block-level management, reduce metadata overhead, improve the efficiency of migration scheduling, and provide reliable status information for breakpoint resume, status query, and data consistency verification.

[0068] Specifically, allocating a mirror volume bitmap involves the following steps: calculating the required number of bits based on the total capacity of the source volume; and allocating the mirror volume bitmap based on the number of bits. This allocation method enables on-demand and precise configuration of the bitmap space, improves memory utilization efficiency, and ensures complete coverage of all data blocks in the source volume, providing a reliable foundation for accurate tracking and migration of subsequent snapshot data.

[0069] Furthermore, the data block size is determined based on the copy granularity. By determining the data block size according to the copy granularity, the migration operation can be aligned with the I / O granularity of the underlying storage system, improving data read and write efficiency. This approach helps reduce fragmentation, optimize storage access performance, and enhance the flexibility and accuracy of bitmap management, ensuring that resource allocation matches actual migration needs.

[0070] Step S205: Read the snapshot data to be migrated in the first target volume according to the first data block set, associate the snapshot data to be migrated with the current generation value and write it into the first storage space.

[0071] In one optional implementation, reading the snapshot data to be migrated from the first target volume according to the first data block set, associating the snapshot data to be migrated with the current generation value, and writing it into the first storage space includes the following steps:

[0072] Step S2051: Find the first bit with a value of 1 in the mirrored volume bitmap and use it as the current bit.

[0073] Step S2052: Read the data block corresponding to the current bit in the first target volume as the current snapshot data to be migrated.

[0074] Step S2053: Update the generation value of the current snapshot data to be migrated to the current generation value.

[0075] Step S2054: Write the updated current snapshot migration data to the corresponding data block location in the first storage space.

[0076] Step S2055: Change the current bit in the mirrored volume bitmap from 1 to 0.

[0077] Step S2056: Determine whether there are still bits with a value of 1 in the mirror volume bitmap. If yes, return to step S2051; if no, determine that all snapshot data to be migrated in the first target volume has been migrated.

[0078] Steps S2051 to S2056 above accurately mark the location of the data blocks to be migrated using the mirrored volume bitmap. By searching, reading, updating the generation, and writing one by one, the accuracy and consistency of the snapshot data migration are ensured. During the migration process, the bitmap state is updated after each data block is processed, effectively tracking the migration progress, avoiding omissions or duplicate migrations, and improving the reliability and efficiency of data migration. At the same time, the correctness of the snapshot data version is ensured by the correlation update of the generation value. Finally, the migration is accurately determined to be complete when there are no bits marked as 1 in the bitmap, realizing an automated and controllable snapshot data migration process.

[0079] Step S206: After all the snapshot data to be migrated in the first target volume has been migrated, increment the current generation value and return to the step of determining whether there are snapshots that have not yet been migrated, until all unmigrated snapshots are written to the first storage space.

[0080] Embodiments of this application also provide a data migration method, combined with Figure 3 The execution flow of the data migration method is described in detail.

[0081] like Figure 3 As shown, the data migration method includes the following steps:

[0082] Step S301: Obtain the current generation value.

[0083] Step S302: Determine if there are any snapshots that have not yet been migrated, where the source volume has snapshots, and each snapshot corresponds to a target volume. If there are snapshots that have not yet been migrated, proceed to step S303; otherwise, proceed to step S307.

[0084] Step S303: When there are snapshots that have not yet been migrated, select the first snapshot with the earliest creation time from all the unmigrated snapshots, and determine the first target volume corresponding to the first snapshot.

[0085] Step S304: Determine the first set of data blocks that need to be migrated from the first target volume based on the first snapshot.

[0086] Step S305: Read the snapshot data to be migrated in the first target volume according to the first data block set, associate the snapshot data to be migrated with the current generation value and write it into the first storage space.

[0087] Step S306: After all the snapshot data to be migrated in the first target volume has been migrated, increment the current generation value and return to step 302 until all unmigrated snapshots have been written to the first storage space.

[0088] Step S307: When there is no snapshot that has not yet been migrated, obtain the snapshot with the latest creation time among all snapshots of the source volume, and record its corresponding snapshot bitmap as the third snapshot bitmap.

[0089] Step S308: Determine the set of second data blocks that need to be migrated out of the source volume main space based on the third snapshot bitmap.

[0090] In one alternative implementation, determining the set of second data blocks that need to be migrated out of the source volume main space based on the third snapshot bitmap includes steps S3081 to S3082.

[0091] Step S3081: Identify the data blocks marked as source volume data copied in the third snapshot bitmap.

[0092] Step S3082: The identified data blocks are used as the second set of data blocks that need to be migrated out of the source volume main space.

[0093] Steps S3081 to S3082 above accurately identify the copied source volume data blocks using the third snapshot bitmap, quickly determining the second set of data blocks to be migrated out. This avoids full disk scanning or repeated copying, significantly improving migration efficiency. Utilizing bitmap-marked status enables fine-grained management at the data block level, ensuring the accuracy and consistency of the migration process while reducing system resource consumption and accelerating the release of source volume space.

[0094] Furthermore, in the third snapshot bitmap, a bit of 0 indicates that the source volume data in the corresponding data block has not yet been copied to the target volume, and a bit of 1 indicates that the source volume data in the corresponding data block has been copied to the target volume. Identifying data blocks marked as "source volume data copied" in the third snapshot bitmap includes: in the mirrored volume bitmap, setting the position corresponding to the data block with a bit of 1 in the third snapshot bitmap to 1. The mirrored volume bitmap uses the following marking method: a bit of 0 indicates that the data in the corresponding data block has been synchronized to the first storage space; a bit of 1 indicates that the data in the corresponding data block has not been synchronized to the first storage space.

[0095] Synchronizing the "copied" (value 1) bits in the third snapshot bitmap to the mirror volume bitmap directly identifies the data to be migrated to the first storage space, enabling seamless transition of the migration task. This mechanism, through bitmap state transmission, enhances the visualization and controllability of the data synchronization process, ensures consistency of states at each stage, and improves system reliability and migration efficiency.

[0096] Step S309: Read the source data to be migrated in the main space of the source volume according to the second data block set, associate the source data to be migrated with the current generation value and write it into the first storage space.

[0097] In one optional implementation, reading the source data to be migrated from the source volume according to the second data block set, associating the source data to be migrated with the current generation value, and then writing it into the first storage space includes the following steps a1 to a6.

[0098] Step a1: Find the first bit with a value of 1 in the mirrored volume bitmap and use it as the current bit;

[0099] Step a2: Read the data block corresponding to the current bit in the main space of the source volume, and use it as the current source data to be migrated;

[0100] Step a3: Update the generation value of the current source data to be migrated to the current generation value;

[0101] Step a4: Write the updated source data to be migrated to the corresponding data block location in the first storage space;

[0102] Step a5: Change the current bit in the mirrored volume bitmap from 1 to 0;

[0103] Step a6: Determine if there are still bits with a value of 1 in the mirror volume bitmap. If yes, return to the step of "selecting a current bit with a value of 1 in the mirror volume bitmap"; if no, determine that all source data to be migrated in the source volume has been migrated.

[0104] Steps a1 to a6 above accurately track the data blocks to be migrated using the mirrored volume bitmap, iteratively reading, updating generations, and writing to the target storage space one by one, ensuring the orderliness and integrity of the source volume data migration; the bitmap state is updated after each data block migration is completed, effectively recording the migration progress, preventing omissions or duplicate operations, and improving the reliability and controllability of the migration process; combined with the unified update of generation values, the consistency of snapshot data versions is ensured, and finally, the migration completion is accurately determined by the bitmap's all-zero state, achieving efficient, safe, and automated target data synchronization.

[0105] Step S310: Promote the first storage space to the primary storage space and demote the storage space where the source volume is located to the secondary storage space.

[0106] Step S311: Delete the secondary storage space and convert the mirrored volume to a normal volume.

[0107] Step S312: Release all resources associated with the source volume snapshot.

[0108] To illustrate the data migration method in this application in more detail, a specific example is provided. This example assumes two storage pools: Pool_A and Pool_B, where Pool_A is a normal pool and Pool_B is a thin pool. There is a volume LUN_A on storage pool Pool_A. N snapshots have been taken of LUN_A, and based on the snapshot time, the target volumes corresponding to each snapshot are: LUN_A_1, LUN_A_2, ..., LUN_A_N. When a user wants to migrate LUN_A and all its snapshots LUN_A_1 to LUN_A_N to storage pool Pool_B, the process is as follows:

[0109] Assuming LUN_A is initially composed of all A's, such as Figure 4As shown, a snapshot was taken at time T0, with the target volume being LUN_A_0. It's important to emphasize that a snapshot bitmap of 0 indicates that data at that location has not been copied to the target volume, while a bitmap of 1 indicates that it has been copied. Conversely, the bitmap of a mirrored volume shows a bitmap of 0 indicating that data has been synchronized to the secondary space, and a bitmap of 1 indicating that data has not been copied to the secondary space.

[0110] Then the host modifies the LUN_A data, and the modified data is as follows: Figure 5 As shown.

[0111] At time T1, another snapshot is taken of LUN_A, with the target volume being LUN_A_1, such as... Figure 6 As shown.

[0112] Then the host modifies the LUN_A data, and the modified data is as follows: Figure 7 As shown.

[0113] At time T2, another snapshot is taken of LUN_A, with the target volume being LUN_A_2, such as... Figure 8 As shown.

[0114] Then the host modifies the LUN_A data, and the modified data is as follows: Figure 9 As shown.

[0115] Based on this, adopt such Figure 10 The method shown involves data migration, specifically including the following steps:

[0116] 1) Set the initial value of current_generation to 0.

[0117] 2) Allocate a space within storage pool Pool_B for volume LUN_A as its secondary space, thus converting LUN_A into a mirrored volume. Since Pool_B is a thin pool, the initial allocation does not require allocating the entire capacity equal to LUN_A; only the space needed for storing volume metadata and a small amount of initial data is allocated. Subsequently, when data writing causes insufficient space, more space is dynamically requested from Pool_B as needed.

[0118] 3) The mirror volume module allocates a dedicated bitmap (called the mirror volume bitmap) for the mirror volume to accurately track the migration or synchronization status of each data block. The size of this bitmap is determined by the total capacity of the source volume LUN_A and the copy granularity of the mirror volume module (i.e., the size of the data block processed each time): dividing the capacity of LUN_A by the copy granularity yields the total number of data blocks to be managed, with each data block corresponding to one bit in the bitmap. For example, if the capacity of LUN_A is 100GB and the copy granularity is 256KB, then the required number of bits is 100GB ÷ 256KB = 409,600 bits, which translates to a bitmap size of 51,200 bytes (i.e., 50KB).

[0119] 4) Check if there is a snapshot in LUN_A that has not yet been migrated. If there is no unmigrated snapshot, proceed to step 13; if there is, proceed to step 5.

[0120] 5) Among all the snapshots in LUN_A that have not yet been migrated, find the snapshot with the earliest creation time and determine its corresponding target volume (i.e. the volume used to store the snapshot data). Let's assume that the target volume is LUN_A_X.

[0121] 6) Determine if the snapshot corresponding to LUN_A_X is the earliest created snapshot among all snapshots: If it is the earliest snapshot, reset the mirror volume bitmap to all 1s (indicating that all data blocks of this snapshot need to be migrated); if it is not the earliest snapshot, obtain the snapshot bitmap corresponding to the previous snapshot of this snapshot, and copy the value of the bitmap to the mirror volume bitmap (to identify incremental data).

[0122] 7) Locate the first bit with a value of 1 in the mirror volume bitmap (i.e., the first data block to be processed): If found, read the data in the data block corresponding to that bit from the target volume LUN_A_X; if not found (i.e. there is no 1 in the bitmap), it means that the data of the current snapshot has been completely migrated, and jump to step 12.

[0123] 8) Update the metadata information in the read data and modify the recorded generation ID to the current current_generation value.

[0124] 9) Write the updated data to the corresponding data block location in the new Pool_B space allocated in step 2.

[0125] 10) Change the bit corresponding to the processed data block in the mirrored volume bitmap from 1 to 0 to indicate that the data block has been successfully migrated.

[0126] 11) Jump back to step 7 and continue to search for and process the next bit with a value of 1.

[0127] 12) Reaching this step indicates that all data in the current snapshot (LUN_A_X) has been successfully synchronized to the target storage space. The next snapshot needs to be processed. Increment the value of current_generation by 1, then jump back to step 4 to re-evaluate whether there are any unmigrated snapshots.

[0128] 13) Reaching this step indicates that all historical snapshot data for LUN_A has been migrated. The next step is to migrate the latest data from the LUN_A source volume itself.

[0129] 14) Obtain the snapshot bitmap of the latest snapshot of LUN_A and assign its contents to the mirror volume bitmap to determine which data blocks need to be migrated from the primary space.

[0130] 15) Locate the first bit with a value of 1 in the mirror volume bitmap: If found, read the data block corresponding to that bit from the main space of LUN_A; if not found, it means that the source volume data has also been fully synchronized, and jump to step 20.

[0131] 16) Update the metadata information of the read source volume data and modify its generation value to the current_generation value.

[0132] 17) Write the updated source volume data to the corresponding location in the new Pool_B space.

[0133] 18) Change the bit corresponding to this position in the mirrored volume bitmap from 1 to 0.

[0134] 19) Jump back to step 15 and continue processing the next data block to be migrated.

[0135] 20) Reaching this step indicates that all snapshot data and source volume data have been successfully synchronized. The process is now in its final stages; updating current_generation is no longer necessary.

[0136] 21) Traverse all historical snapshots of LUN_A, and delete the relationship information of each snapshot, its corresponding target volume, and the snapshot bitmap in order of creation time from oldest to newest, so as to completely release the snapshot resources in the original storage pool.

[0137] 22) After all snapshot resources are deleted, the original primary storage space (located in the original pool) of the mirror volume LUN_A is downgraded to a secondary space, while the secondary storage space created in Pool_B in step 2 is promoted to a new primary storage space.

[0138] 23) Delete the original primary storage space (i.e., the old secondary space), reclaim the resources it occupies, and restore LUN_A from the mirror volume to a normal volume.

[0139] 24) Delete the image volume bitmap created in step 3 to release memory resources.

[0140] 25) The entire data migration process has been completed.

[0141] In the synchronization snapshot data stage before step 12, when the host needs to modify the data in LUN_A, since the historical data in the secondary space (that is, the data in the snapshot) has not yet been synchronized, the IO does not need to pay attention to the bitmap value at this time, and can directly write to the main space.

[0142] In phases 12-21, snapshot data synchronization is complete, and the latest data is being synchronized (i.e., data is being synchronized from the main space to the secondary space in LUN_A). If the host needs to modify the data in LUN_A at this time, it needs to be handled differently based on the bitmap value: if the bitmap value is 0, it indicates that the main and secondary space synchronization has been completed at this position, and the IO needs to be double-written, that is, written to both the main and secondary spaces; if the bitmap value is 1, it indicates that the main and secondary synchronization task has not yet reached this position, and the host only needs to write to the main space. When the synchronization task reaches this position, the latest data in the main space will be synchronized to the secondary space.

[0143] In steps 22 and onwards, since all data synchronization has been completed, it is necessary to release the original main storage space resources. Therefore, at this point, host I / O only needs to write to the new space created in step 2.

[0144] After the migration is complete, the data distribution of LUN_A in Pool_B is as follows: Figure 11 As shown: all data in LUN_A and all snapshot data are transferred to Pool_B, and all are located in LUN_A, with data from snapshots at different times distinguished by generation (GEN).

[0145] After step 25) is completed, volume LUN_A is converted from a mirror volume to a regular volume. After this action is completed, the attribute information of LUN_A displayed to the host (such as UUID, volume path identifier, etc.) does not change. Only the location of its storage space is changed by the mirror volume module inside the storage. Therefore, the host does not need to perform any rescanning action at this time and can continue to use the volume without any awareness.

[0146] Therefore, this application implements the function of migrating the data of the volume in the ordinary pool, along with the data of the snapshot of that volume, to the thin pool. Furthermore, after migration, the ordinary snapshot can be converted into a more efficient CDP snapshot. The migration process is transparent to the host; the host is unaware of the volume changes and requires no additional configuration. After migration, the data of the original ordinary pool volume and snapshot coexist in the new thin pool. The volume and snapshot data in the new pool are stored in the same volume, distinguished by different generations. The original ordinary pool can be completely released and deleted without data loss. After the ordinary pool is released, its corresponding disk can continue to be used elsewhere, improving resource utilization. Without this solution, after migration, only the source volume data is migrated to the thin pool, while the snapshot data remains in the ordinary pool. On the one hand, the resources occupied by the ordinary pool cannot be released; on the other hand, when the host modifies the source volume in the thin pool, the snapshot's COW process still needs to be triggered to copy the old data of the source volume to the snapshot in the ordinary pool. In other words, the performance of the source volume is still limited by the performance of the ordinary pool and cannot achieve the higher performance of the thin pool. In contrast, this solution converts ordinary snapshots into CDP snapshots after migration, with all data residing in a thin pool. Host performance is neither affected by the performance of the ordinary pool nor by the COW mechanism of ordinary snapshots, resulting in lower performance overhead and less resource consumption, making it more advantageous.

[0147] Embodiments of this application also provide a data migration apparatus, such as... Figure 12 As shown, it includes:

[0148] The acquisition module 1201 is used to obtain the current generation value.

[0149] The judgment module 1202 is used to determine whether there are snapshots that have not yet been migrated, wherein the source volume has snapshots, and each snapshot corresponds to a target volume.

[0150] Module 1203 is selected to select the first snapshot with the earliest creation time from all unmigrated snapshots when there are snapshots that have not yet been migrated, and to determine the first target volume corresponding to the first snapshot.

[0151] The range determination module 1204 is used to determine the first set of data blocks that need to be migrated out from the first target volume based on the first snapshot.

[0152] The write module 1205 is used to read the snapshot data to be migrated in the first target volume according to the first data block set, associate the snapshot data to be migrated with the current generation value, and write it into the first storage space.

[0153] The loop module 1206 is used to increment the current generation value and return to the step of determining whether there are any snapshots that have not yet been migrated after all the snapshot data to be migrated in the first target volume has been migrated, until all unmigrated snapshots have been written to the first storage space.

[0154] In some optional implementations, the range determination module 1204 is specifically used to: if the first snapshot is the snapshot with the earliest creation time among all snapshots of the source volume, then obtain the first snapshot bitmap corresponding to the first snapshot, and take all data blocks corresponding to the first snapshot bitmap as the first data block set; if the first snapshot is not the snapshot with the earliest creation time among all snapshots of the source volume, then obtain the second snapshot bitmap corresponding to the previous snapshot of the first snapshot, and take the data blocks marked as source volume data copied in the second snapshot bitmap as the first data block set.

[0155] In some optional implementations, a bit value of 0 in the first snapshot bitmap and the second snapshot bitmap indicates that the source volume data in the corresponding data block has not yet been copied to the target volume, and a bit value of 1 indicates that the source volume data in the corresponding data block has been copied to the target volume. The range determination module 1204 is specifically used for: if the first snapshot is the snapshot with the earliest creation time among all snapshots of the source volume, then obtaining the first snapshot bitmap corresponding to the first snapshot, and taking all data blocks corresponding to the first snapshot bitmap as the first data block set; if the first snapshot is not the snapshot with the earliest creation time among all snapshots of the source volume, then obtaining the second snapshot bitmap corresponding to the previous snapshot of the first snapshot, and taking the data blocks with a bit value of 1 in the second snapshot bitmap as the first data block set.

[0156] In some optional implementations, the data migration apparatus further includes a mirrored volume bitmap allocation module. Before determining the first set of data blocks to be migrated from the first target volume based on the first snapshot, the mirrored volume bitmap allocation module is used to: allocate a mirrored volume bitmap, wherein the mirrored volume bitmap is used to record the state of the data blocks to be migrated to the first storage space.

[0157] In some optional implementations, the mirrored volume bitmap uses the following marking method: a bit of 0 indicates that the data in the corresponding data block has been synchronized to the first storage space; a bit of 1 indicates that the data in the corresponding data block has not been synchronized to the first storage space; the range determination module 1204 is specifically used to obtain the first snapshot bitmap corresponding to the first snapshot if the first snapshot is the snapshot with the earliest creation time among all snapshots of the source volume, and set all data block positions corresponding to the first snapshot bitmap to 1 in the mirrored volume bitmap; if the first snapshot is not the snapshot with the earliest creation time among all snapshots of the source volume, then obtain the second snapshot bitmap corresponding to the previous snapshot of the first snapshot, and set the positions corresponding to the data blocks with bits of 1 in the second snapshot bitmap to 1 in the mirrored volume bitmap.

[0158] In some optional implementations, the write module 1205 is specifically used for: finding the first bit with a value of 1 in the mirror volume bitmap and using it as the current bit; reading the data block corresponding to the current bit in the first target volume and using it as the current snapshot data to be migrated; updating the generation value of the current snapshot data to be migrated to the current generation value; writing the generation-updated current snapshot data to be migrated to the corresponding data block location in the first storage space; changing the current bit in the mirror volume bitmap from 1 to 0; determining whether there is still a bit with a value of 1 in the mirror volume bitmap; if so, returning to the step of selecting a current bit with a value of 1 in the mirror volume bitmap; if not, determining that all the snapshot data to be migrated in the first target volume has been migrated.

[0159] In some optional implementations, when there is no snapshot that has not yet been migrated, the selection module 1203 is further configured to obtain the snapshot with the latest creation time among all snapshots of the source volume, and record its corresponding snapshot bitmap as the third snapshot bitmap; the range determination module 1204 is further configured to determine the second set of data blocks that need to be migrated from the main space of the source volume according to the third snapshot bitmap; the writing module 1205 is further configured to read the source data to be migrated in the main space of the source volume according to the second set of data blocks, associate the source data to be migrated with the current generation value, and write it into the first storage space.

[0160] In some alternative implementations, the range determination module 1204 is specifically used to: identify data blocks marked as source volume data copied in the third snapshot bitmap; and use the identified data blocks as a second set of data blocks that need to be migrated out of the source volume main space.

[0161] In some optional implementations, a bit of 0 in the third snapshot bitmap indicates that the source volume data in the corresponding data block has not yet been copied to the target volume, and a bit of 1 indicates that the source volume data in the corresponding data block has been copied to the target volume; the range determination module 1204 is specifically used to: in the mirrored volume bitmap, set the position corresponding to the data block with a bit of 1 in the third snapshot bitmap to 1; the mirrored volume bitmap adopts the following marking method: a bit of 0 indicates that the data in the corresponding data block has been synchronized to the first storage space; a bit of 1 indicates that the data in the corresponding data block has not been synchronized to the first storage space.

[0162] In some optional implementations, the write module 1205 is specifically used for: finding the first bit with a value of 1 in the mirror volume bitmap and using it as the current bit; reading the data block corresponding to the current bit in the main space of the source volume and using it as the current source data to be migrated; updating the generation value of the current source data to be migrated to the current generation value; writing the generation-updated current source data to be migrated to the corresponding data block position in the first storage space; changing the current bit in the mirror volume bitmap from 1 to 0; determining whether there is still a bit with a value of 1 in the mirror volume bitmap; if so, returning to the step of "selecting a current bit with a value of 1 in the mirror volume bitmap"; if not, determining that all source data to be migrated in the source volume has been migrated.

[0163] In some optional implementations, the mirror volume bitmap allocation module is specifically used to: calculate the required number of bits based on the total capacity of the source volume; and allocate the mirror volume bitmap based on the number of bits.

[0164] In some alternative implementations, the size of the data block is determined based on the copy granularity.

[0165] In some optional implementations, the data migration apparatus further includes a post-processing module. After all the snapshot data to be migrated and the source data to be migrated have been written to the first storage space, the post-processing module is used to: promote the first storage space to the primary storage space and demote the storage space where the source volume is located to the secondary storage space.

[0166] In some alternative implementations, after promoting the first storage space to primary storage space and demoting the storage space where the source volume is located to secondary storage space, the post-processing module is further configured to: delete the secondary storage space and convert the mirror volume into a normal volume.

[0167] In some optional implementations, the post-processing module is also used to: release resources associated with all snapshots of the source volume.

[0168] For a description of the features in the embodiments corresponding to the data migration device, please refer to the relevant descriptions in the embodiments corresponding to the data migration method, which will not be repeated here.

[0169] Embodiments of this application also provide an electronic device, such as... Figure 13 As shown, it includes a memory 10 and a processor 20. The memory 10 stores a computer program, and the processor 20 is configured to run the computer program to perform the steps in any of the above-described data migration method embodiments.

[0170] Embodiments of this application also provide a computer-readable storage medium storing a computer program configured to execute the steps in any of the above-described data migration method embodiments at runtime.

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

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

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

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

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

Claims

1. A data migration method, characterized in that, include: Get the current generation value, where the generation value is used to identify the time version to which the data belongs; Determine whether there are snapshots that have not yet been migrated, wherein the source volume has the snapshots, and each snapshot corresponds to a target volume; When there are snapshots that have not yet been migrated, select the first snapshot with the earliest creation time from all the snapshots that have not been migrated, and determine the first target volume corresponding to the first snapshot; Based on the first snapshot, determine the first set of data blocks that need to be migrated from the first target volume; In the first target volume, read the snapshot data to be migrated according to the first data block set, associate the snapshot data to be migrated with the current generation value, and write it into the first storage space; After all the snapshot data to be migrated in the first target volume has been migrated, the current generation value is incremented, and the step of determining whether there are snapshots that have not yet been migrated is returned until all the unmigrated snapshots are written to the first storage space. The step of determining the first set of data blocks that need to be migrated from the first target volume based on the first snapshot includes: If the first snapshot is the snapshot with the earliest creation time among all snapshots of the source volume, then obtain the first snapshot bitmap corresponding to the first snapshot, and take all data blocks corresponding to the first snapshot bitmap as the first data block set; If the first snapshot is not the earliest created snapshot among all snapshots of the source volume, then the second snapshot bitmap corresponding to the previous snapshot of the first snapshot is obtained, and the data blocks marked as source volume data copied in the second snapshot bitmap are used as the first data block set.

2. The method according to claim 1, characterized in that, In the first snapshot bitmap and the second snapshot bitmap, a bit of 0 indicates that the source volume data in the corresponding data block has not yet been copied to the target volume, and a bit of 1 indicates that the source volume data in the corresponding data block has been copied to the target volume; The step of determining the first set of data blocks that need to be migrated from the first target volume based on the first snapshot includes: If the first snapshot is the snapshot with the earliest creation time among all snapshots of the source volume, then obtain the first snapshot bitmap corresponding to the first snapshot, and take all data blocks corresponding to the first snapshot bitmap as the first data block set; If the first snapshot is not the earliest created snapshot among all snapshots of the source volume, then the second snapshot bitmap corresponding to the previous snapshot of the first snapshot is obtained, and the data blocks with bits set to 1 in the second snapshot bitmap are used as the first data block set.

3. The method according to claim 2, characterized in that, Before determining the first set of data blocks that need to be migrated from the first target volume based on the first snapshot, the method further includes: allocating a mirrored volume bitmap, wherein the mirrored volume bitmap is used to record the status of data blocks to be migrated to the first storage space.

4. The method according to claim 3, characterized in that: The mirrored volume bitmap uses the following marking method: a bit of 0 indicates that the data in the corresponding data block has been synchronized to the first storage space; a bit of 1 indicates that the data in the corresponding data block has not been synchronized to the first storage space. The step of taking all data blocks corresponding to the first snapshot bitmap as the first data block set includes: in the mirrored volume bitmap, setting all data block positions corresponding to the first snapshot bitmap to 1; Using the data block with bit 1 in the second snapshot bitmap as the first data block set includes: in the mirrored volume bitmap, setting the position corresponding to the data block with bit 1 in the second snapshot bitmap to 1.

5. The method according to claim 2, characterized in that, The step of reading the snapshot data to be migrated from the first target volume according to the first data block set, associating the snapshot data to be migrated with the current generation value, and then writing it into the first storage space includes: Find the first bit with a value of 1 in the mirrored volume bitmap and use it as the current bit. Read the data block corresponding to the current bit in the first target volume and use it as the current snapshot data to be migrated; Update the generation value of the current snapshot data to be migrated to the current generation value; Write the updated snapshot data to be migrated to the corresponding data block location in the first storage space. Change the current bit in the mirrored volume bitmap from 1 to 0; Determine whether there is still a bit with a value of 1 in the mirrored volume bitmap. If so, return to the step of finding the first bit with a value of 1 in the mirrored volume bitmap and using it as the current bit. If not, determine that all the snapshot data to be migrated in the first target volume has been migrated.

6. The method according to claim 1, characterized in that, Also includes: When there is no snapshot that has not yet been migrated, obtain the snapshot with the latest creation time among all snapshots of the source volume, and record its corresponding snapshot bitmap as the third snapshot bitmap; The set of second data blocks that need to be migrated out of the source volume's main space is determined based on the third snapshot bitmap. The source data to be migrated is read from the main space of the source volume according to the second data block set, and the source data to be migrated is associated with the current generation value and then written into the first storage space.

7. The method according to claim 6, characterized in that, The step of determining the second set of data blocks that need to be migrated out of the source volume main space based on the third snapshot bitmap includes: Identify the data blocks in the third snapshot bitmap that are marked as having been copied from the source volume; The identified data blocks are used as the second set of data blocks that need to be migrated out of the source volume's main space.

8. The method according to claim 7, characterized in that, In the third snapshot bitmap, a bit of 0 indicates that the source volume data in the corresponding data block has not yet been copied to the target volume, and a bit of 1 indicates that the source volume data in the corresponding data block has been copied to the target volume. The step of identifying the data blocks marked as source volume data copied in the third snapshot bitmap includes: in the mirrored volume bitmap, setting the position corresponding to the data block with a bit of 1 in the third snapshot bitmap to 1; The mirrored volume bitmap uses the following marking method: a bit of 0 indicates that the data in the corresponding data block has been synchronized to the first storage space; a bit of 1 indicates that the data in the corresponding data block has not been synchronized to the first storage space.

9. The method according to claim 6, characterized in that, The step of reading the source data to be migrated from the source volume according to the second data block set, associating the source data to be migrated with the current generation value, and then writing it into the first storage space includes: Find the first bit with a value of 1 in the mirrored volume bitmap and use it as the current bit. Read the data block corresponding to the current bit in the main space of the source volume and use it as the current source data to be migrated. Update the generation value of the current source data to be migrated to the current generation value; Write the updated source data to be migrated to the corresponding data block location in the first storage space. Change the current bit in the mirrored volume bitmap from 1 to 0; Determine whether there is still a bit with a value of 1 in the mirrored volume bitmap. If so, return to the step of finding the first bit with a value of 1 in the mirrored volume bitmap and using it as the current bit. If not, determine that all source data to be migrated in the source volume has been migrated.

10. The method according to claim 3, characterized in that, The allocated mirrored volume bitmap includes: Calculate the required number of bits based on the total capacity of the source volume; The mirrored volume bitmap is allocated according to the number of bits.

11. The method according to claim 10, characterized in that, The size of the data block is determined based on the copy granularity.

12. The method according to claim 6, characterized in that, Also includes: After all the snapshot data to be migrated and the source data to be migrated have been written to the first storage space, the first storage space is promoted to the primary storage space, and the storage space where the source volume is located is demoted to the secondary storage space.

13. The method according to claim 12, characterized in that, Also includes: Delete the secondary storage space and convert the mirror volume to a regular volume.

14. The method according to claim 13, characterized in that, Also includes: Release all resources associated with the source volume and all snapshots therein.

15. The method according to any one of claims 1 to 14, characterized in that, The first storage space is a thin pool.

16. A data migration device, characterized in that, The device includes: The acquisition module is used to obtain the current generation value, where the generation value is used to identify the time version to which the data belongs; The determination module is used to determine whether there are snapshots that have not yet been migrated, wherein the source volume has the snapshots, and each snapshot corresponds to a target volume; The selection module is used to select the first snapshot with the earliest creation time from all the snapshots that have not yet been migrated when there are snapshots that have not yet been migrated, and to determine the first target volume corresponding to the first snapshot; The scope determination module is used to determine, based on the first snapshot, a set of first data blocks that need to be migrated from the first target volume; The writing module is used to read the snapshot data to be migrated in the first target volume according to the first data block set, associate the snapshot data to be migrated with the current generation value, and write it into the first storage space. The loop module is used to increment the current generation value and return to the step of determining whether there are any snapshots that have not yet been migrated after all the snapshot data to be migrated in the first target volume has been migrated, until all the unmigrated snapshots are written to the first storage space. The range determination module is specifically used for: if the first snapshot is the snapshot with the earliest creation time among all snapshots of the source volume, then obtaining the first snapshot bitmap corresponding to the first snapshot, and taking all data blocks corresponding to the first snapshot bitmap as the first data block set; if the first snapshot is not the snapshot with the earliest creation time among all snapshots of the source volume, then obtaining the second snapshot bitmap corresponding to the previous snapshot of the first snapshot, and taking the data blocks in the second snapshot bitmap that are marked as source volume data copied as the first data block set.

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

18. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein the computer program, when executed by a processor, implements the steps of the data migration method as described in any one of claims 1 to 15.

19. 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 data migration method as described in any one of claims 1 to 15.

Images