Data migration method and device, electronic equipment, storage medium and program product

Abstract

The invention discloses a data migration method and device, electronic equipment, a storage medium and a program product, and relates to the technical field of computers, the data migration method actively identifies a target volume corresponding to each snapshot, extracts a snapshot data block set to be migrated from the target volume, ensures that historical snapshot contents can be systematically incorporated into a migration process, and improves the migration efficiency. And the snapshots are migrated in sequence from morning to evening according to the creation time, so that data recovery abnormity caused by disordered snapshot migration sequence is avoided. According to the method and the device, the current generation value is introduced, and the snapshots which are not migrated are processed one by one according to the snapshot creation time sequence, so that the technical problem that snapshot data cannot be synchronously migrated during cross-storage-pool migration in a mirror image volume technology is solved, and the common snapshots are associated with the generation value in the migration process and are continuously written into the target storage space; and conversion to a continuous data protection mechanism is realized. After migration is completed, resources occupied by the data protection function of the source volume in the new pool are fewer, and the method has more advantages.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computers, and in particular to a data migration method and device, an electronic device, a storage medium, and a program product. BACKGROUND

[0002] Volume migration is a technology for changing the physical location of the back-end storage space of a volume. In a storage device, multiple hard disks are usually used to build a RAID, and multiple RAIDs are combined to form a storage pool. A user can create a volume on the storage pool and map it to a host for use. The storage space used by the volume is provided by the storage pool in which the volume is located. Multiple storage pools can be created on a storage device, and each storage pool can be based on different RAID configurations. Volume migration technology is to migrate the data of a volume from its current storage pool to another storage pool, so that the volume uses the storage space provided by the target pool.

[0003] When performing cross-pool data migration on a volume that has created a snapshot (i.e., a source volume), the mirror volume-based migration function can usually only migrate the data of the source volume itself to the target pool. Since snapshot data at different times is stored in separate snapshot volumes, these snapshot volumes remain in the original storage pool, so this migration method cannot migrate other snapshot data outside the source volume to the target pool, resulting in the snapshot data not being able to be migrated synchronously with the source volume. SUMMARY

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

[0005] The present application provides a data migration method, comprising: obtaining a current generation value; determining whether there is a snapshot that has not been migrated, wherein the source volume has snapshots, and each snapshot corresponds to a target volume; when there is a snapshot that has not been migrated, selecting a first snapshot with the earliest creation time among all un-migrated snapshots, and determining a first target volume corresponding to the first snapshot; determining a first data block set that needs to be migrated from the first target volume according to the first snapshot; reading the to-be-migrated snapshot data in the first target volume according to the first data block set, and writing the to-be-migrated snapshot data to a first storage space after associating the to-be-migrated snapshot data with the current generation value; when all to-be-migrated snapshot data in the first target volume is migrated, incrementing the current generation value, and returning to the step of determining whether there is a snapshot that has not been migrated, until all un-migrated snapshots are written to the first storage space.

[0006] The present application also provides a data migration device, including an acquisition module, a judgment module, a selection module, a range determination module, a write module and a loop module; the acquisition module is used to obtain the current generation value; the judgment module is used to determine whether there is a snapshot that has 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 among all the unmigrated snapshots when there is a snapshot that has 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 data block set that needs to be migrated from the first target volume based on the first snapshot; the write module is used to read the snapshot data to be migrated in the first target volume based on the first data block set, associate the snapshot data to be migrated with the current generation value, and then write it to the first storage space; the loop module is used to increment the current generation value after all the snapshot data to be migrated in the first target volume are migrated, and return to the step of determining whether there is a snapshot that has not yet been migrated, until all the unmigrated snapshots are written to the first storage space.

[0007] The present 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-mentioned data migration methods when executing the computer program.

[0008] The present application also provides a computer-readable storage medium, in which a computer program is stored. When the computer program is executed by a processor, the steps of any of the above-mentioned data migration methods are implemented.

[0009] The present application also provides a computer program product, including a computer program, which implements the steps of any of the above-mentioned data migration methods when executed by a processor.

[0010] The data migration method, device, electronic device, storage medium and program product provided by the present application effectively solve the technical problem that traditional mirror volume technology cannot synchronously migrate snapshot data when migrating across storage pools by introducing the current generation value and processing the unmigrated snapshots one by one in the order of snapshot creation time. This solution is no longer limited to migrating only the source volume master data, but 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 therefrom, ensuring that the historical snapshot content can be systematically incorporated into the migration process. By migrating snapshots in sequence from early to late according to the creation time, the temporal consistency of the data version is guaranteed, and data recovery anomalies caused by the disorder of the snapshot migration order are avoided. More importantly, during the migration process, the snapshot data is associated with the current generation value and then written to the first storage space of the target end, realizing the complete transfer of snapshot data from the original storage pool to the target pool, completely breaking the limitation that the snapshot data must rely on the original pool. This solution not only achieves the integrated migration of the source volume and all its historical snapshots, ensuring that the target pool contains a complete data chain after migration, supports point-in-time snapshot recovery, and improves data integrity and availability, but also uniformly marks the migrated data with a generation value, laying the foundation for the subsequent implementation of a data organization method similar to continuous data protection (CDP) on the target side, thereby enhancing data protection capabilities. At the same time, the migration process has clear logic and strong controllability, facilitating status tracking and error recovery, and is compatible with the existing mirror volume migration architecture. It can be implemented by simply enhancing the control logic without requiring large-scale modifications to the underlying structure. It has good feasibility and promotion value, thus not only solving the fundamental problem of snapshots being unable to migrate with the volume, but also providing strong support for building a more efficient and flexible data protection system. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] In order to more clearly illustrate the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0012] Figure 1 A flowchart of a data migration method provided in an embodiment of the present application; Figure 2 A flowchart of another data migration method provided in an embodiment of the present application; Figure 3 A flowchart of another data migration method provided in an embodiment of the present application; Figure 4 This is a schematic diagram of the first process of taking a snapshot of LUN_A provided in an embodiment of the present application; Figure 5This is a second schematic diagram of the process of taking a snapshot of LUN_A provided in an embodiment of the present application; Figure 6 The third process diagram of taking a snapshot of LUN_A provided in the embodiment of the present application; Figure 7 The fourth process diagram of taking a snapshot of LUN_A provided in an embodiment of the present application; Figure 8 The fifth process diagram of taking a snapshot of LUN_A provided in an embodiment of the present application; Figure 9 The sixth process diagram of taking a snapshot of LUN_A provided in an embodiment of the present application; Figure 10 A flowchart of an example of a data migration method provided in an embodiment of the present application; Figure 11 A schematic diagram of the result after data migration is completed in an example of the data migration method provided in an embodiment of the present application; Figure 12 A schematic diagram of the structure of a data migration device provided in an embodiment of the present application; Figure 13 It is a schematic diagram of the hardware structure of the computer device of an embodiment of the present application. DETAILED DESCRIPTION

[0013] The following will be combined with the accompanying drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

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

[0015] In order to enable those skilled in the art to better understand the present application, the present application is further described in detail below with reference to the accompanying drawings and specific implementation methods.

[0016] Mirrored volume technology is a high-availability technology. For a standard volume, a single volume is mapped to the host. Similarly, the underlying storage pool has only one storage space for that volume. All data written to that volume has only one copy. If a storage pool failure occurs (for example, a software failure causes the RAID in the storage pool to cease service, or a hardware failure causes the number of hard drives in the RAID to exceed the RAID tolerance limit), that volume, or even all volumes in the entire storage pool, becomes unavailable. If the failure cannot be corrected, the business data in those volumes cannot be recovered. Mirrored volume technology provides an additional layer of data security. For a mirrored volume, a single volume is mapped to the host, but two storage spaces exist in the underlying storage pool. When a write I / O arrives at the mirrored volume module, it copies the data identically into both storage spaces. This is known as mirrored volume dual-write mode. When reading data, only one of the storage spaces is needed, as the two copies are identical. When creating a mirrored volume, it's generally recommended to create two storage spaces in two different storage pools. This way, if one storage space fails, the original data can be retrieved from the other space. Even if the failed space cannot be recovered, the business data of the volume will not be lost. Furthermore, if the failed space is recovered, the thin pool module also provides data resynchronization, copying the differential data written during the failure from the healthy space to the newly recovered space. Once the differential data synchronization is complete, high data availability can be maintained.

[0017] Existing cross-pool volume migration technology is based on mirrored volume technology: An existing volume is converted to a mirrored volume. When converting the mirrored volume, the new data space is specified to use the space of the pool to which the volume is being migrated. After the conversion, the mirrored volume module automatically synchronizes the data in the old space with the new space. Once all data is synchronized, the old data space is deleted, converting the mirrored volume back to a regular volume. Once the conversion is complete, the volume's data space uses the storage space of the new pool, completing the migration of the volume's data space.

[0018] When migrating data across storage pools for a snapshotted volume (i.e., the source volume), mirrored volume-based migration typically only migrates the source volume's data to the target pool. Because snapshot data at different times is stored in separate snapshot volumes, which remain within the original storage pool, this migration method cannot migrate other snapshot data besides the source volume to the target pool, resulting in the snapshot data not being migrated synchronously with the source volume.

[0019] One solution is to also migrate the data on the target volume, migrating all of it to the new pool. However, data migration based on mirror volumes is not aware of the existence of snapshot relationships. After the migration is complete, the original target volumes will become independent volumes in the new pool and will no longer be associated with the newly migrated source volumes. The end result is that after the migration is complete, the volumes that have snapshot relationships with each other become independent volumes. When modifying the migrated source volume, the COW action of the snapshot will no longer be performed. When using the target volume to roll back and repair the source volume data, it is impossible to identify which data is copied to the target volume because of modifying the source volume, and which data is the original initialization data of the target volume. Since the data cannot be distinguished, the target volume data will be copied back to the source volume during the rollback, resulting in data errors in the source volume.

[0020] On the other hand, since CDP can be used in thin pools to implement point-in-time data protection, and CDP offers advantages over regular snapshots, such as reduced resource usage and lower performance degradation, migrating snapshots from a regular pool to a thin pool using regular COW snapshots—where each snapshot target volume occupies a volume resource and data is copied using COW—does not offer any advantages in the thin pool. The advantages of volume migration are even more pronounced if the conversion from regular snapshots to CDP can be completed during migration.

[0021] Based on this, the embodiment of the present application provides a data migration method, combined with Figure 1 The execution process of the data migration method in the .

[0022] like Figure 1 As shown, the data migration method includes the following steps: Step S101: Get the current generation value.

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

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

[0025] For example, for a volume, before a CDP snapshot is created, the generation value of all data written by IO is 0. When a CDP snapshot is created for the first time, the snapshot is a generation 0 snapshot, and its data consists of all data blocks with a generation value of 0 in the source volume. After the snapshot is created, the current generation value of the source volume increments to 1, and all subsequent newly written data blocks have a generation value of 1. When a CDP snapshot is created again, the new snapshot is a generation 1 snapshot, corresponding to all data with a generation value of 1. After that, the current generation value increments again to 2, and the generation value of subsequent IO becomes 2, and so on.

[0026] Due to uneven host I / O distribution, certain areas of the volume (hotspots) are frequently written to, causing their data blocks to have constantly updated generation values, tending to be higher. Meanwhile, the generation values ​​of less frequently accessed areas (cold data areas) may remain unchanged for long periods of time. When reading the latest data, only the data block with the largest generation value at each location is read. When reading a specific generation of CDP snapshots (e.g., the nth generation), the search is performed for data with a generation value equal to n at the specified location. If no data exists, the search proceeds to generations n-1, n-2, and so on until the corresponding data is found. This generation-based version tracing mechanism enables efficient and fine-grained recovery of historical data.

[0027] Step S102: determining whether there is a snapshot for which data migration has not been performed, wherein the source volume has snapshots, and each snapshot corresponds to a target volume.

[0028] Among them, snapshot technology is a data protection technology based on a point in time. It can save the data of a volume at a certain moment. Even if the data of the volume changes later, the data in the snapshot is still the data at the moment of taking the snapshot and will not be affected by the data written to the volume subsequently. When taking a snapshot of a volume, a new volume (called the target volume) will be created for the volume (called the source volume), and an association relationship (called the snapshot relationship) will be established between the two volumes. The target volume will store the data of the original volume at the moment of taking the snapshot. When the snapshot is just taken, the target volume is still empty and has no data. When the data at a certain location in the source volume is modified for the first time, the snapshot module will first copy the data at that location in the source volume to the target volume, and then write the new data. This is the COW technology (copy on write) in the snapshot. The snapshot module uses bitmap technology to record the data status of the source and target volumes, that is, the data at those locations has been copied to the target volume, and the data at those locations has not been copied. When the host modifies the source volume data, it can use the bitmap to determine whether the write at that location is the first write and whether it needs to be copied to the target volume. Similarly, when reading the data of the target volume, the bitmap can also be used to confirm whether the real data at that location is stored on the target volume or the source volume, so as to confirm the actual read location. Taking snapshots of the source volume is usually used to protect the historical data of the source volume. Taking snapshots of the source volume at different times can achieve finer time granularity protection of the source volume data. The target volume of the snapshot is usually not mapped to the host for modification to prevent the snapshot data from being modified and then causing data errors when the modified data is rolled back.

[0029] Step S103: When there are snapshots that have not been migrated, a first snapshot with the earliest creation time is selected from all the snapshots that have not been migrated, and a first target volume corresponding to the first snapshot is determined.

[0030] In traditional snapshot mechanisms, when a snapshot is created for a source volume, the system typically allocates a separate storage space for the snapshot, namely a target volume (also called a snapshot volume or COW volume). This volume is used to store a copy of the source volume's data at the time the snapshot was created, or to preserve the original data if the source volume's data is overwritten (for example, using copy-on-write (COW) technology). Therefore, each snapshot is associated with a specific target volume at the storage level, which serves as the data carrier.

[0031] Step S104: determining a first data block set that needs to be migrated from the first target volume according to the first snapshot.

[0032] Because snapshots typically use copy-on-write (COW) or similar mechanisms, the first target volume stores data blocks from the source volume that were modified at or after the snapshot was created. Therefore, based on the first snapshot, it's possible to determine which data blocks are valid and haven't yet been migrated in the first target volume. This helps construct the first set of data blocks to be read and migrated from the target volume, ensuring that only necessary data is migrated, improving migration efficiency.

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

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

[0035] When the primary storage space is a thin pool, physical storage space is dynamically allocated only when the snapshot data to be migrated is actually written, avoiding waste caused by pre-allocation and further improving storage resource utilization. Furthermore, bitmaps are used to precisely manage the data blocks to be migrated, ensuring on-demand allocation and efficient writing, effectively reducing thin pool space usage and write amplification.

[0036] Step S106: When the migration of all snapshot data to be migrated in the first target volume is completed, the current generation value is incremented, and the process returns to step S102 until all unmigrated snapshots are written into the first storage space.

[0037] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus the necessary general hardware platform, and of course it can also be implemented by hardware, but in many cases the former is a better implementation method.

[0038] The embodiment of the present application effectively solves the technical problem that traditional mirror volume technology cannot synchronously migrate snapshot data when migrating across storage pools by introducing the current generation value and processing the unmigrated snapshots one by one in the order of snapshot creation time. This solution is no longer limited to migrating only the source volume master data, but 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 the historical snapshot content can be systematically incorporated into the migration process. By migrating snapshots in sequence from early to late according to the creation time, the temporal consistency of the data version is guaranteed, and data recovery anomalies caused by the disorder of the snapshot migration order are avoided. More importantly, during the migration process, the snapshot data is associated with the current generation value and then written to the first storage space of the target end, realizing the complete transfer of snapshot data from the original storage pool to the target pool, completely breaking the limitation that the snapshot data must rely on the original pool. This solution not only achieves the integrated migration of the source volume and all its historical snapshots, ensuring that the target pool contains a complete data chain after migration, supports point-in-time snapshot recovery, and improves data integrity and availability, but also uniformly marks the migrated data with a generation value, laying the foundation for the subsequent implementation of a data organization method similar to continuous data protection (CDP) on the target side, thereby enhancing data protection capabilities. At the same time, the migration process has clear logic and strong controllability, facilitating status tracking and error recovery, and is compatible with the existing mirror volume migration architecture. It can be implemented by simply enhancing the control logic without requiring large-scale modifications to the underlying structure. It has good feasibility and promotion value, thus not only solving the fundamental problem of snapshots being unable to migrate with the volume, but also providing strong support for building a more efficient and flexible data protection system.

[0039] The embodiment of the present application also provides a data migration method, combining Figure 2 The execution process of the data migration method in the .

[0040] like Figure 2 As shown, the data migration method includes the following steps: Step S201: Get the current generation value.

[0041] Step S202: determining whether there is a snapshot for which data migration has not been performed, wherein the source volume has snapshots, and each snapshot corresponds to a target volume.

[0042] Step S203: When there are snapshots that have not been migrated, a first snapshot with the earliest creation time is selected from all the snapshots that have not been migrated, and a first target volume corresponding to the first snapshot is determined.

[0043] Step S204: determining a first data block set that needs to be migrated from the first target volume according to the first snapshot.

[0044] In an optional implementation, determining the first data block set that needs to be migrated from the first target volume according to the first snapshot includes the following steps S2041 and S2042.

[0045] Step S2041: If the first snapshot is the earliest snapshot created among all snapshots of the source volume, a first snapshot bitmap corresponding to the first snapshot is obtained, and all data blocks corresponding to the first snapshot bitmap are used as a first data block set; Step S2042: If the first snapshot is not the earliest snapshot among all snapshots of the source volume, obtain a second snapshot bitmap corresponding to the previous snapshot of the first snapshot, and use the data blocks marked as "source volume data copied" in the second snapshot bitmap as the first data block set.

[0046] 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 the migration set to establish the basic image; for subsequent snapshots, since their data depends on the copy status of the previous snapshot, it is only necessary to migrate the data blocks marked as "source volume data copied" in the previous snapshot to reflect the incremental data content that the current snapshot needs to inherit.

[0047] The above steps S2041 to S2042 make full use of the timing 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 at the same time ensuring the data consistency and correctness of the dependency logic in the snapshot chain, realizing accurate and efficient incremental data migration.

[0048] Furthermore, in the snapshot technology, bitmap technology is used to record the data status of the source volume and the target volume, that is, the data at those locations has been copied to the target volume, and the data at those locations has not been copied. For example, a bit position 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 been copied to the target volume, and a bit position of 1 indicates that the source volume data in the corresponding data block has been copied to the target volume. On this basis, determining the first data block set that needs to be migrated from the first target volume based on the first snapshot includes: if the first snapshot is the earliest snapshot created 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 earliest snapshot created 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 bits of 1 in the second snapshot bitmap as the first data block set.

[0049] 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, the overall migration time is greatly shortened, and the resource utilization and execution efficiency of the migration process are improved.

[0050] Furthermore, before determining the first data block set that needs 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 the data blocks to be migrated to the first storage space. The mirror volume bitmap adopts the following marking method: a bit position of 0 indicates that the data in the corresponding data block has been synchronized to the first storage space; a bit position of 1 indicates that the data in the corresponding data block has not been synchronized to the first storage space. Based on this, taking all data blocks corresponding to the first snapshot bitmap as the first data block set includes: in the mirror volume bitmap, setting all data block positions corresponding to the first snapshot bitmap to 1; taking data blocks with bits 1 in the second snapshot bitmap as the first data block set includes: in the mirror volume bitmap, setting the positions corresponding to the data blocks with bits 1 in the second snapshot bitmap to 1.

[0051] This is because the data migration process requires unified tracking and management of the synchronization status of the data blocks to be migrated. By pre-allocating a mirror volume bitmap and using a marking mechanism of "1 for unsynchronized and 0 for 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 the snapshot bitmaps. When determining the first set of data blocks, the positions of the data blocks marked as "copied" in the first or second snapshot bitmap are set to "1" (unsynchronized) in the mirror volume bitmap. This effectively registers these data blocks to be migrated with the global migration task, facilitating the subsequent unified scheduling and execution of migration operations according to the bitmap.

[0052] Through the above-mentioned 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, through bitmap bit operations, efficient data block-level management is supported, metadata overhead is reduced, the efficiency of migration scheduling is improved, and a reliable status basis is provided for breakpoint resumption, status query and data consistency verification.

[0053] 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 bitmap space, improves memory utilization, 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.

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

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

[0056] In an optional embodiment, 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 the data to the first storage space includes the following steps: Step S2051: Search the first bit with a value of 1 in the mirror volume bitmap and use it as the current bit.

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

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

[0059] Step S2054: writing the snapshot data to be migrated after the generation update to the corresponding data block location in the first storage space.

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

[0061] Step S2056: Determine whether there is still a bit with a value of 1 in the mirror volume bitmap. If so, return to step S2051; if not, determine that all the snapshot data to be migrated in the first target volume has been migrated.

[0062] The above steps S2051 to S2056 accurately mark the location of the data blocks to be migrated through the mirror volume bitmap, and ensure the accuracy and consistency of the snapshot data migration by searching, reading, updating the generation and writing one by one; during the migration process, the bitmap status is updated every time a data block is processed, which effectively tracks the migration progress, avoids omissions or repeated migrations, and improves the reliability and efficiency of data migration. At the same time, the correctness of the snapshot data version is guaranteed through the associated update of the generation value. Finally, when there is no bit marked as 1 in the bitmap, the migration is accurately determined to be completed, realizing an automated and controllable snapshot data migration process.

[0063] Step S206: When all snapshots to be migrated in the first target volume are migrated, the current generation value is incremented, and the process returns to the step of determining whether there are snapshots that have not been migrated, until all unmigrated snapshots are written to the first storage space.

[0064] The embodiment of the present application also provides a data migration method, combining Figure 3 The execution process of the data migration method in the .

[0065] like Figure 3 As shown, the data migration method includes the following steps: Step S301: Get the current generation value.

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

[0067] Step S303: When there are snapshots that have not been migrated, a first snapshot with the earliest creation time is selected from all the snapshots that have not been migrated, and a first target volume corresponding to the first snapshot is determined.

[0068] Step S304: determining a first data block set that needs to be migrated from the first target volume according to the first snapshot.

[0069] Step S305: Read the snapshot data to be migrated from the first target volume according to the first data block set, associate the snapshot data to be migrated with the current generation value, and then write the data into the first storage space. Step S306: When the migration of all snapshot data to be migrated in the first target volume is completed, the current generation value is incremented, and the process returns to step 302 until all unmigrated snapshots are written into the first storage space.

[0070] Step S307: when there is no snapshot for which data migration has not been performed, the latest snapshot created among all the snapshots of the source volume is obtained, and the corresponding snapshot bitmap is recorded as the third snapshot bitmap.

[0071] Step S308: Determine the second data block set that needs to be migrated from the primary space of the source volume according to the third snapshot bitmap.

[0072] In an optional implementation, determining the second data block set that needs to be migrated from the primary space of the source volume according to the third snapshot bitmap includes steps S3081 and S3082.

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

[0074] Step S3082: The identified data blocks are used as a second set of data blocks that need to be migrated from the primary space of the source volume.

[0075] Steps S3081 and S3082 above use the third snapshot bitmap to accurately identify the copied source volume data blocks and quickly determine the second set of data blocks to be migrated, avoiding full disk scans or duplicate copies and significantly improving migration efficiency. Using bitmap marking status enables fine-grained management at the data block level, ensuring the accuracy and consistency of the migration process while reducing system resource usage and accelerating the release of source volume space.

[0076] Furthermore, a bit position 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 position of 1 indicates that the source volume data in the corresponding data block has been copied to the target volume; identifying the data block marked as "source volume data has been copied" in the third snapshot bitmap includes: in the mirror volume bitmap, setting the position corresponding to the data block with a bit position of 1 in the third snapshot bitmap to 1; the mirror volume bitmap adopts the following marking method: a bit position of 0 indicates that the data in the corresponding data block has been synchronized to the first storage space; a bit position of 1 indicates that the data in the corresponding data block has not been synchronized to the first storage space.

[0077] Synchronizing the "Copied" bit (value 1) in the third snapshot bitmap to the mirror volume bitmap directly identifies the data to be migrated to the primary storage space, enabling seamless migration. This mechanism, through bitmap status transfer, enhances the visibility and controllability of the data synchronization process, ensuring consistent status at each stage and improving system reliability and migration efficiency.

[0078] Step S309: reading the source data to be migrated from the primary space of 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 the data into the first storage space.

[0079] In an optional implementation, reading the source data to be migrated in 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 the data into the first storage space includes the following steps a1 to a6.

[0080] Step a1: Find the first bit with a value of 1 in the mirror volume bitmap and use it as the current bit; Step a2: Read the data block corresponding to the current bit position in the source volume's main space as the current source data to be migrated; Step a3: Update the generation value of the source data to be migrated to the current generation value; Step a4: writing the current source data to be migrated after the generation update to the corresponding data block location in the first storage space; Step a5: Change the current bit in the mirror volume bitmap from 1 to 0; Step a6: Determine whether there is still a bit with a value of 1 in the mirror volume bitmap. If so, return to the step of "selecting a current bit with a value of 1 in the mirror volume bitmap"; if not, determine that all source data to be migrated in the source volume has been migrated.

[0081] The above steps a1 to a6 accurately track the data blocks to be migrated through the mirror volume bitmap, and iteratively read, update the generation and write them to the target storage space one by one, ensuring the orderliness and integrity of the source volume data migration; the bitmap status is updated every time the migration of a data block is completed, effectively recording the migration progress, preventing omissions or repeated operations, and improving the reliability and controllability of the migration process; combined with the unified update of the generation value, the consistency of the snapshot data version is guaranteed, and finally the migration completion is accurately judged by the all-0 status of the bitmap, realizing efficient, secure and automated synchronization of target data.

[0082] Step S310: Promote the first storage space to a primary storage space, and downgrade the storage space where the source volume is located to a secondary storage space.

[0083] Step S311: Delete the auxiliary storage space and convert the mirror volume into a normal volume.

[0084] Step S312: Release resources related to all snapshots of the source volume.

[0085] In order to explain the data migration method of the present application in more detail, a specific example is given. In this example, it is assumed that there are 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 in the storage pool Pool_A. N snapshots have been taken of LUN_A. Based on the order of the snapshots, the target volumes corresponding to each snapshot are: LUN_A_1, LUN_A_2, ..., LUN_A_N. When the user wants to migrate LUN_A and all its snapshots LUN_A_1 to LUN_A_N to the storage pool Pool_B, the specific steps are as follows: Assume that the initial data of LUN_A is all A. Figure 4 As shown in the figure, a snapshot was taken at time T0, with the snapshot target volume being LUN_A_0. It's important to note that a snapshot bitmap value of 0 indicates that the data at that location has not been copied to the target volume, while a value of 1 indicates that it has been copied. The mirror volume bitmap is the opposite: a 0 indicates that the data has been synchronized to the secondary volume, while a 1 indicates that the data has not been copied to the secondary volume.

[0086] Then the host modifies the LUN_A data. Figure 5 shown.

[0087] At time T1, a snapshot is taken of LUN_A, and the target volume of the snapshot is LUN_A_1. Figure 6 shown.

[0088] Then the host modifies the LUN_A data. Figure 7 shown.

[0089] At time T2, another snapshot is taken of LUN_A, and the snapshot target volume is LUN_A_2. Figure 8 shown.

[0090] Then the host modifies the LUN_A data. Figure 9 shown.

[0091] On this basis, the Figure 10 The method shown in the figure performs data migration, which specifically includes the following steps: 1) Set the initial value of current_generation to 0.

[0092] 2) Allocate space in storage pool Pool_B for volume LUN_A as its secondary space, converting LUN_A into a mirrored volume. Because Pool_B is a thin pool, initial allocation does not require allocating space equal to LUN_A's capacity. Only the space required to store the volume metadata and a small amount of initial data is allocated. If data is subsequently written and space becomes insufficient, additional space can be dynamically requested from Pool_B as needed.

[0093] 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 each data block processed at a time): Divide the capacity of LUN_A by the copy granularity to obtain the total number of data blocks to be managed. Each data block corresponds to a bit in the bitmap. For example, if LUN_A has a capacity of 100GB and a copy granularity of 256KB, the number of bits required is 100GB ÷ 256KB = 409,600, resulting in a bitmap size of 51,200 bytes (i.e., 50KB).

[0094] 4) Check whether LUN_A has any snapshots that have not yet been migrated. If no snapshots exist, skip to step 13; if so, skip to step 5.

[0095] 5) Find the oldest snapshot created among all unmigrated snapshots of LUN_A and determine its corresponding target volume (the volume used to store the snapshot data). Assume that the target volume is LUN_A_X.

[0096] 6) Determine whether the snapshot corresponding to LUN_A_X is the earliest snapshot among all snapshots. If it is the earliest snapshot, reset the mirror volume bitmap to all 1s (indicating that all data blocks of the snapshot need to be migrated). If it is not the earliest snapshot, obtain the snapshot bitmap corresponding to the snapshot before this snapshot and copy the value of the bitmap to the mirror volume bitmap (for identifying incremental data).

[0097] 7) Search for 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), the data of the current snapshot has been completely migrated, and skip to step 12.

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

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

[0100] 10) The bit corresponding to the processed data block in the mirror volume bitmap is changed from 1 to 0, indicating that the data block has been successfully migrated.

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

[0102] 12) At this point, all data in the current snapshot (LUN_A_X) has been successfully synchronized to the target storage space. Next, process the next snapshot. Increase the value of current_generation by 1, then return to step 4 to determine if there are any unmigrated snapshots.

[0103] 13) At this point, all historical snapshot data for LUN_A has been migrated. Next, you need to migrate the latest data for the source volume LUN_A.

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

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

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

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

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

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

[0110] 20) At this point, all snapshot data and source volume data have been successfully synchronized. The process now moves to the finalization phase, and no further updates to current_generation are required.

[0111] 21) Traverse all historical snapshots of LUN_A and delete the relationship information, corresponding target volume, and snapshot bitmap of each snapshot in descending order of creation time to completely release the snapshot resources in the original storage pool.

[0112] 22) After all snapshot resources are deleted, downgrade the original primary storage space of the mirror volume LUN_A (located in the original pool) to a secondary space, and promote the secondary storage space created in Pool_B in step 2 to the new primary storage space.

[0113] 23) Delete the original primary storage space (that is, the old secondary space), reclaim the occupied resources, and restore LUN_A from a mirrored volume to a normal volume.

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

[0115] 25) The entire data migration process is completed.

[0116] During the snapshot data synchronization phase before step 12, when the host wants to modify the data in LUN_A, the historical data in the secondary space (that is, the data in the snapshot) has not yet been synchronized. Therefore, the IO does not need to pay attention to the bitmap value at this time and can directly write to the primary space.

[0117] In the 12th to 21st stages, the snapshot data synchronization is completed, and the latest data is being synchronized (i.e., the LUN_A primary space synchronizes data to the secondary space), at this time, if the host wants to modify the data in LUN_A, it needs to be processed according to the bitmap value: if the bitmap value is 0, it indicates that the primary and secondary space synchronization has been completed, and the IO needs to be double-written, i.e., the primary and secondary spaces are written; if the bitmap value is 1, it indicates that the primary and secondary synchronization task has not reached this position, and the host only writes the primary space, and when the synchronization task reaches this position, the latest data in the primary space is synchronized to the secondary space.

[0118] In the 22nd and subsequent steps, since all data synchronization has been completed, the original primary storage space resources need to be released, so at this time the host IO only writes to the new space created in the second step.

[0119] After the migration is completed, the data distribution of LUN_A in Pool_B is as shown in Figure 11 The data of LUN_A and all snapshot data are transferred to Pool_B, and are all located in LUN_A, and are distinguished by generation (GEN) to distinguish the data of different snapshots.

[0120] After step 25) is completed, the volume LUN_A is converted from the mirror volume to the ordinary volume. After this action is completed, the attribute information (such as UUID, volume path identifier, and the like) displayed by LUN_A to the host layer does not change, only the storage space of the storage is replaced by the mirror volume module, so at this time the host does not need to do any rescan action, and can be completely non-perceptual, and the volume can continue to be used.

[0121] As can be seen, this application implements the function of migrating the data of volumes in the normal pool, along with the data of snapshots of the volumes, to the thin pool. After the migration, the normal snapshots can be converted into more efficient CDP snapshots. The migration process is transparent to the host; the host is unaware of the volume changes and no additional host configuration is required. After the migration is complete, the data of the volumes and snapshots in the original normal pool exist together in the new thin pool. The data of the volumes and snapshots in the new pool are stored in the same volume, distinguished by different generations. The original normal pool can be completely released and deleted without causing data loss. After the normal pool is released, its corresponding disks can continue to be used elsewhere, improving resource utilization. If this solution is not used, after the migration is complete, only the source volume data is migrated to the thin pool, while the snapshot data remains in the normal pool. On the one hand, the resources occupied by the normal 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 source volume data to the snapshot in the normal pool. In other words, at this time, the performance of the source volume is still limited by the performance of the normal pool and cannot achieve the higher performance indicators of the thin pool. In contrast, in this solution, after the migration is completed, the ordinary snapshot is converted into a CDP snapshot. All data is in the thin pool. The host performance is not affected by the ordinary pool performance, nor is it affected by the COW mechanism of the ordinary snapshot. It has lower performance loss, occupies fewer resources, and has more advantages.

[0122] The embodiment of the present application also provides a data migration device, such as Figure 12 Shown, including: The acquisition module 1201 is used to obtain the current generation value.

[0123] The judgment module 1202 is used to judge whether there is a snapshot for which data migration has not been performed, wherein the source volume has snapshots, and each snapshot corresponds to a target volume.

[0124] The selection module 1203 is configured to select a first snapshot with the earliest creation time from all the snapshots that have not been migrated, when there is a snapshot that has not been migrated, and determine a first target volume corresponding to the first snapshot.

[0125] The range determination module 1204 is configured to determine a first set of data blocks that need to be migrated from the first target volume according to the first snapshot.

[0126] The writing module 1205 is configured to read the snapshot data to be migrated from the first target volume according to the first data block set, associate the snapshot data to be migrated with the current generation value, and then write the data into the first storage space.

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

[0128] In some optional embodiments, the range determining module 1204 is specifically configured to: if the first snapshot is the snapshot with the earliest creation time among all the snapshots of the source volume, obtain a first snapshot bitmap corresponding to the first snapshot, and take all the 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 the snapshots of the source volume, obtain a second snapshot bitmap corresponding to the previous snapshot of the first snapshot, and take the data blocks in the second snapshot bitmap that are marked as having been copied as the first data block set.

[0129] In some optional embodiments, a bit 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 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 determining module 1204 is specifically configured to: if the first snapshot is the snapshot with the earliest creation time among all the snapshots of the source volume, obtain a first snapshot bitmap corresponding to the first snapshot, and take all the 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 the snapshots of the source volume, obtain a second snapshot bitmap corresponding to the previous snapshot of the first snapshot, and take the data blocks in the second snapshot bitmap that are marked as having been copied as the first data block set.

[0130] In some optional embodiments, the data migration apparatus further comprises a mirror volume bitmap assigning module. Before the first data block set that needs to be migrated from the first target volume is determined according to the first snapshot, the mirror volume bitmap assigning module is configured to assign a mirror volume bitmap, wherein the mirror volume bitmap is used to record the state of the data block to be migrated to the first storage space.

[0131] In some optional embodiments, the mirror volume bitmap adopts the following marking manner: a bit of 0 indicates that the data in the corresponding data block has been synchronized to the first storage space; and a bit of 1 indicates that the data in the corresponding data block has not been synchronized to the first storage space. The range determining module 1204 is specifically configured to: if the first snapshot is the snapshot with the earliest creation time among all the snapshots of the source volume, obtain a first snapshot bitmap corresponding to the first snapshot, and set all the positions of the data blocks corresponding to the first snapshot bitmap in the mirror volume bitmap to 1; if the first snapshot is not the snapshot with the earliest creation time among all the snapshots of the source volume, obtain a second snapshot bitmap corresponding to the previous snapshot of the first snapshot, and set the positions corresponding to the data blocks with a bit of 1 in the second snapshot bitmap to 1 in the mirror volume bitmap.

[0132] In some optional implementations, the write module 1205 is specifically used to: search for the first bit with a value of 1 in the mirror volume bitmap as the current bit; read the data block corresponding to the current bit in the first target volume 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 current snapshot data to be migrated after the generation update to the corresponding data block position in the first storage space; change the current bit in the mirror volume bitmap from 1 to 0; determine whether there is still a bit with a value of 1 in the mirror volume bitmap, and if so, return to the step of selecting a current bit with a value of 1 in the mirror volume bitmap; if not, determine that all the snapshot data to be migrated in the first target volume have been migrated.

[0133] In some optional embodiments, when there is no snapshot for which data migration has not yet been performed, the selection module 1203 is further used to obtain the latest snapshot created 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 used to determine the second data block set that needs to be migrated from the main space of the source volume based on the third snapshot bitmap; the writing module 1205 is further used to read the source data to be migrated in the main space of the source volume based on the second data block set, associate the source data to be migrated with the current generation value, and then write it to the first storage space.

[0134] In some optional implementations, the range determination module 1204 is specifically configured to: identify data blocks in the third snapshot bitmap that are marked as copied source volume data; and use the identified data blocks as a second set of data blocks that need to be migrated from the source volume primary space.

[0135] In some optional implementations, a bit position 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 position 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 mirror volume bitmap, set the position corresponding to the data block with a bit position of 1 in the third snapshot bitmap to 1; the mirror volume bitmap adopts the following marking method: a bit position of 0 indicates that the data in the corresponding data block has been synchronized to the first storage space; a bit position of 1 indicates that the data in the corresponding data block has not been synchronized to the first storage space.

[0136] In some optional embodiments, the writing module 1205 is specifically configured to: find a first bit with a value of 1 in the mirror volume bitmap as a current bit; read a data block corresponding to the current bit in the source volume main space as current to-be-migrated source data; update a generation value of the current to-be-migrated source data to a current generation value; write the current to-be-migrated source data with the updated generation value into a corresponding data block position in the first storage space; modify the current bit in the mirror volume bitmap from 1 to 0; determine whether there is still a bit with a value of 1 in the mirror volume bitmap, and if yes, return to perform the step of selecting a current bit with a value of 1 in the mirror volume bitmap; and if no, determine that all to-be-migrated source data in the source volume has been migrated.

[0137] In some optional embodiments, the mirror volume bitmap allocation module is specifically configured to: calculate the number of required bits according to the total capacity of the source volume; and allocate the mirror volume bitmap according to the number of bits.

[0138] In some optional embodiments, the size of the data block is determined according to the copy granularity.

[0139] In some optional embodiments, the data migration device further comprises a post-processing module. After all to-be-migrated snapshot data and to-be-migrated source data are written into the first storage space, the post-processing module is configured to: promote the first storage space to a main storage space, and degrade the storage space where the source volume is located to a secondary storage space.

[0140] In some optional embodiments, after the first storage space is promoted to the main storage space and the storage space where the source volume is located is degraded to the secondary storage space, the post-processing module is further configured to: delete the secondary storage space, and convert the mirror volume to a normal volume.

[0141] In some optional embodiments, the post-processing module is further configured to: release resources related to all snapshots of the source volume.

[0142] The features of the embodiments of the data migration device can be referred to the related descriptions of the embodiments of the data migration method, which will not be repeated here.

[0143] The embodiments of the present application also provide an electronic device, as shown in the figure, comprising 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 data migration method embodiments. Figure 13

[0144] The embodiments of the present application also provide a computer readable storage medium, which stores a computer program, wherein the computer program is configured to perform the steps in any of the above data migration method embodiments when running. ​

[0145] In an exemplary embodiment, the computer-readable storage medium may include, but is not limited to, various media that can store computer programs, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk, or an optical disk.

[0146] An embodiment of the present application further provides a computer program product, which includes a computer program. When the computer program is executed by a processor, the steps in any of the above-mentioned data migration method embodiments are implemented.

[0147] An embodiment of the present application also provides another computer program product, including a non-volatile computer-readable storage medium, wherein the non-volatile computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps in any of the above-mentioned data migration method embodiments are implemented.

[0148] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the components and steps of each example according to their functions. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may 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.

[0149] The above is a detailed introduction to a data migration method, device, electronic device, storage medium and program product provided by the present application. Specific examples are used herein to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only applicable to help understand the method and core ideas of the present application. It should be pointed out that for ordinary technicians in this technical field, without departing from the principles of the present application, several improvements and modifications can be made to the present application, and these improvements and modifications also fall within the scope of protection of the claims of the present application.

Claims

1. A data migration method, characterized in that: include: Get the current generation value; Determining whether there are snapshots for which data migration has not yet been performed, wherein the source volume has the snapshots, and each of the snapshots corresponds to a target volume; When there is a snapshot for which data migration has not been performed, selecting a first snapshot with the earliest creation time from all the snapshots that have not been migrated, and determining a first target volume corresponding to the first snapshot; determining a first set of data blocks that need to be migrated from the first target volume according to the first snapshot; Reading 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 the data into the first storage space; When all snapshots to be migrated in the first target volume are migrated, the current generation value is incremented, and the process returns to the step of determining whether there are snapshots that have not been migrated, until all unmigrated snapshots are written to the first storage space.

2. The method according to claim 1, characterized in that Determining the first data block set that needs to be migrated from the first target volume according to the first snapshot includes: If the first snapshot is the earliest snapshot created among all snapshots of the source volume, obtaining a first snapshot bitmap corresponding to the first snapshot, and using all data blocks corresponding to the first snapshot bitmap as the first data block set; If the first snapshot is not the earliest snapshot among all snapshots of the source volume, a second snapshot bitmap corresponding to the snapshot previous to the first snapshot is obtained, and data blocks marked in the second snapshot bitmap as copied source volume data are used as the first data block set.

3. The method according to claim 2, characterized in that In the first snapshot bitmap and the second snapshot bitmap, a bit position of 0 indicates that the source volume data in the corresponding data block has not been copied to the target volume, and a bit position of 1 indicates that the source volume data in the corresponding data block has been copied to the target volume; Determining the first data block set that needs to be migrated from the first target volume according to the first snapshot includes: If the first snapshot is the earliest snapshot created among all snapshots of the source volume, obtaining a first snapshot bitmap corresponding to the first snapshot, and using all data blocks corresponding to the first snapshot bitmap as the first data block set; If the first snapshot is not the earliest snapshot among all snapshots of the source volume, a second snapshot bitmap corresponding to the previous snapshot of the first snapshot is obtained, and data blocks with bits 1 in the second snapshot bitmap are used as the first data block set.

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

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

6. The method according to claim 3, 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 the data into the first storage space comprises: Find the first bit in the mirror volume bitmap that has a value of 1 and use it as the current bit. Reading a data block corresponding to the current bit in the first target volume 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 updated snapshot data to be migrated into the corresponding data block position in the first storage space; Modify the current bit in the mirror volume bitmap from 1 to 0; Determine whether there is still a bit with a value of 1 in the mirror volume bitmap. If so, return to the step of searching for the first bit with a value of 1 in the mirror volume bitmap as the current bit; if not, determine that all the snapshot data to be migrated in the first target volume has been migrated.

7. The method according to claim 1, characterized in that Also includes: When there is no snapshot for which data migration has not been performed, obtaining the latest snapshot created among all the snapshots of the source volume, and recording the snapshot bitmap corresponding to the snapshot bitmap as the third snapshot bitmap; determining a second data block set that needs to be migrated from the primary space of the source volume according to the third snapshot bitmap; The source data to be migrated is read from the primary 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.

8. The method according to claim 7, characterized in that Determining the second data block set that needs to be migrated from the primary space of the source volume according to the third snapshot bitmap includes: Identifying data blocks in the third snapshot bitmap that are marked as copied source volume data; The identified data blocks are used as a second data block set that needs to be migrated from the primary space of the source volume.

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

10. The method according to claim 7, 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 the data into the first storage space comprises: Find the first bit in the mirror volume bitmap that has a value of 1 and use it as the current bit. Reading a data block corresponding to the current bit position in the main space of the source volume 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 updated source data to be migrated into the corresponding data block position in the first storage space; Modify the current bit in the mirror volume bitmap from 1 to 0; Determine whether there is still a bit with a value of 1 in the mirror volume bitmap. If so, return to the step of searching for the first bit with a value of 1 in the mirror volume bitmap as the current bit; if not, determine that all source data to be migrated in the source volume has been migrated.

11. The method according to claim 4, characterized in that The allocation mirror volume bitmap includes: Calculating the required number of bits based on the total capacity of the source volume; The mirror volume bitmap is allocated according to the number of bits.

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

13. The method according to claim 7, characterized in that Also includes: After all the snapshot data to be migrated and the source data to be migrated are written into the first storage space, the first storage space is promoted to a primary storage space, and the storage space where the source volume is located is downgraded to a secondary storage space.

14. The method according to claim 13, characterized in that Also includes: The auxiliary storage space is deleted, and the mirror volume is converted into a normal volume.

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

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

17. A data migration device, characterized in that: The device comprises: Get module, used to get the current generation value; a determination module, configured to determine whether there are snapshots for which data migration has not yet been performed, wherein the source volume has the snapshots, and each of the snapshots corresponds to a target volume; a selection module configured to, when there is a snapshot for which data migration has not yet been performed, select a first snapshot with the earliest creation time from among all the snapshots that have not been migrated, and determine a first target volume corresponding to the first snapshot; a range determination module, configured to determine a first set of data blocks that need to be migrated from the first target volume according to the first snapshot; a writing module, configured to read the snapshot data to be migrated from the first target volume according to the first data block set, associate the snapshot data to be migrated with the current generation value, and then write the data into the first storage space; The loop module is used to increment the current generation value after all snapshot data to be migrated in the first target volume is migrated, and return to the step of determining whether there are snapshots that have not been migrated, until all unmigrated snapshots are written to the first storage space.

18. An electronic device, characterized in that: include: Memory for storing computer programs; A processor, configured to implement the steps of the data migration method according to any one of claims 1 to 16 when executing the computer program.

19. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, wherein when the computer program is executed by a processor, the steps of the data migration method according to any one of claims 1 to 16 are implemented.

20. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the data migration method according to any one of claims 1 to 16 are implemented.

Images