2.2 Supported Data Transfer Methods

Depending on the selected workload and the migration type, PlateSpin Migrate supports file-level or block-level data transfer methods for transferring workload data from the source to the target. Source servers are online during the data transfer.

For information on how to select a transfer method, see Conversion (Data Transfer Method).

2.2.1 File-Level Data Transfer

The File-Based Transfer (FBT) method copies data and replicates changes at the file level. File-based transfer might be appropriate for moderately active systems. It also provides the capability to resize your volumes on the target workload.

File-Based Transfer for Windows

For Windows workloads, PlateSpin Migrate supports file-based transfer.

NOTE:PlateSpin Migrate does not support file-based transfer for Windows Clusters. See Block-Based Transfer for Windows Clusters.

To ensure data consistency, the file-based transfer method leverages the Microsoft Volume Shadow Copy Service (VSS) if it is available. For enterprise applications that are integrated with VSS, VSS captures and copies data in a consistent state while services are running. For applications that are not integrated with VSS, PlateSpin Migrate provides the capability to briefly pause those services while it captures the VSS snapshot to ensure that their data is captured in a consistent state.

If VSS unavailable, PlateSpin Migrate monitors source volumes for file changes while it transfers data. When the initial transfer is complete, migrate re-sends any files that have changed. If the rate of file system changes is consistently high, data transfer is stopped and a job progress warning is shown.

You can configure your migration job to stop high-transaction services, such as Microsoft SQL Server or Microsoft Exchange Server, during the transfer. See Services or Daemons to Stop before Replication or Cutover. Pausing services has two benefits:

  • It ensures that the databases of these applications are transferred in a more consistent state.

  • It reduces the rate of file system changes so that PlateSpin Migrate is able to keep up with them and complete the transfer.

File-Based Transfer for Linux

For Linux workloads, PlateSpin Migrate supports file-based transfer only in the Migrate Client.

2.2.2 Block-Level Data Transfer

The Block-Based Transfer (BBT) method enables PlateSpin Migrate to transfer data at the block level, providing an exact copy of the source workload. Migrate supports block-based transfer for Windows workloads, Windows Clusters, and Linux workloads.

NOTE:The Block-Based Transfer method is the preferred data transfer method for both Windows and Linux workloads.

Block-Based Transfer for Windows

For Windows workloads, PlateSpin Migrate supports block-based data transfer.

To ensure data consistency, PlateSpin Migrate leverages the Microsoft Volume Snapshot Service (VSS) with applications and services that support VSS. BBT drivers can be used with standalone and cluster workloads.

NOTE:Before you install block-based transfer drivers on source Windows workloads, ensure that you have applied the latest Windows updates on the workload.

Block-Based Transfer for Windows Clusters

For Windows Clusters, PlateSpin Migrate provides driverless block-based transfer and driver-based block-based transfer methods. These methods work differently than for standalone workloads. For information about the purpose and usage of driverless and driver-based block-based transfer, see Block-Based Transfer for Clusters.

Block-Based Transfer for Linux

For Linux workloads, PlateSpin Migrate supports block-based transfer by using block-based Linux Kernel drivers, called block watch (blkwatch) drivers.

To ensure data consistency, the blkwatch driver leverages LVM snapshots if they are available. Copying data from the snapshot helps avoid potential open file conflicts. See Knowledgebase Article 7005872 Using LVM Snapshots for Migrating and Protecting Linux Workloads. If LVM snapshots are not available, Migrate locks and releases each block in turn for data transfer.

The driver must be built for the specific kernel running on the source Linux workload.

NOTE:Deployment or removal of the blkwatch driver is transparent, has no continuity impact, and requires no intervention and no reboot.