1.3 Supported Transfer Methods

Depending on the selected workload and the conversion type, Portability Suite enables you to select different methods for transferring workload data from the source to the target.

For a list of workload types and conversions arranged by supported transfer method, see Knowledge Base Article Q20002.

For information on how to select a transfer method, see Specifying Transfer Options.

For information on how to fine-tune data transfer performance, see Fine-Tuning Data Transfer Performance in your Configuration Guide.

1.3.1 Offline Transfer with the Take Control Mechanism

Offline Take Control Transfer of Windows and Linux Workloads

This method enables Portability Suite to boot your source machine into a temporary pre-execution environment and transfer the data while the source is offline.

The mechanism of the pre-execution environment underlying the Take Control transfer method depends on the source workload’s operating system:

  • For Windows workloads, Portability Suite uses the Microsoft Windows Preinstallation Environment (WinPE).

  • For Linux workloads, Portability Suite uses a Linux Ramdisk.

To ensure that the source operating system loads the temporary pre-execution environment on reboot, Portability Suite temporarily modifies its boot files and restores them to their original state after the Take Control environment has successfully loaded. For a list of files being changed on the source, see Knowledge Base Article Q20349.

Use Take Control transfer to migrate Windows NT 4.0, Windows Server 2000, Windows Server 2003, and Linux workloads, or in other cases where you can afford source workload downtime.

Offline Take Control Transfer of Solaris Workloads

For Solaris workloads, Portability Suite uses a different Take Control mechanism from the one it uses for Windows and Linux workloads; there is no temporary pre-execution environment involved in the preparation of the workload for a migration. Instead, Portability Suite changes the source workload’s run level while the migration is underway.

NOTE:If you have customized services on your Solaris source workload, the system might fail to shut them down during data transfer, and this might result in a failure of the migration job. Ensure that customized services on your source are shut down before setting up the migration job.

1.3.2 Live Transfer (File-Based)

The File-based Live Transfer method copies data and replicates changes at the file level. During File-based Live Transfer, Portability Suite transfers all files from the source volumes while monitoring them for changes. When the transfer is complete, files that have changed are resent. If present, Microsoft SQL Server* or Microsoft Exchange Server services are stopped and their respective database files are transferred to the target.

You can configure your job to stop these services when you are using the File-based Live Transfer method (see Handling Services During Live Transfer (Windows Source Workloads)). However, if there are other tools present that manage the backup of these databases, consider leaving services running during the transfer. When the transfer completes, verify that the copied database is the up-to-date.

If file system changes are constant, data transfer is stopped and a job progress warning is shown.

When the initial transfer is complete for a workload protection job, the target is powered off and is powered on again during the next scheduled incremental transfer.

File-level Live Transfer is appropriate for moderately active Windows.

1.3.3 Live Transfer (VSS Block-Based)

This Live Transfer method transfers data at the block level and leverages the Microsoft Volume Snapshot Service (VSS), for Windows workloads (Windows 2003 SP1 and later) with applications and services that support VSS. The VSS Block-based Live Transfer method offers an exact point-in-time copy of the source workload.

During VSS Block-Based Live Transfer, Portability Suite takes a VSS snapshot of the volumes on the source machine and transfers any changed data block by block.

The source workload remains online throughout the transfer except for protection jobs, during which the source requires a single reboot for the initial transfer (if the component is not pre-installed).

The VSS Block-Based Live Transfer method is the preferred data transfer method for Windows workloads that support the VSS feature. Database servers, mail servers, and application servers that would otherwise require a temporary service stoppage can be protected by using this Live Transfer method. This method is also recommended for workload protection jobs in networks with high latency.

1.3.4 Live Transfer (Block-Based)

The Block-based Live Transfer method copies data and replicates changes at the block level instead of replicating an entire file.

During data transfer to the target, changes on the source volumes are monitored and continuously retransferred to the target at the block level until full synchronization is achieved.

Because the Block-based Live Transfer method transmits only changed blocks rather than entire files, it transfers significantly less data.

When the initial transfer is complete for a workload protection job, the target is booted into the Take Control pre-execution environment and awaits the next scheduled incremental transfer.

Use the Block-based Live Transfer method to reduce the service downtime when you are converting Windows workloads that do not support the Microsoft Volume Snapshot Service (VSS) feature. Using the Block-based Live Transfer method, you can protect critical database servers, mail servers, and application servers with large databases and with high disk activity. In addition, the Block-based Live Transfer method is recommended for networks with high latency because the size of block-level changes is significantly smaller than the size of file-level changes; when file-level changes are detected during file-level data transfer, the changed files are transferred in their entirety.

If your source workload is running Microsoft Exchange Server 2000 and 2003, and Microsoft SQL Server 2000, Portability Suite automatically detects the Windows services of these applications. You can configure your job to stop these services when you are using the Block-based Live Transfer method. However, if there are other tools present that manage the backup of these databases, consider leaving services running during the transfer. When the transfer completes, verify that the copied database is up-to-date.

1.3.5 Live Transfer (VSS File-Based)

This Live Transfer method transfers data at the file level and uses the Microsoft Volume Snapshot Service (VSS) feature, also known as Shadow Copy, for Windows workloads (Windows 2003 SP1 and later) with applications and services that support VSS. The VSS File-based Live Transfer method offers an exact point-in-time copy of the source workload.

During VSS File-based Live Transfer, Portability Suite takes a VSS snapshot of the volumes on the source machine and transfers the data file-by-file.

When the initial transfer is complete for a workload protection job, the target is powered off; it powers on again during the next scheduled incremental transfer.

Use the VSS File-based Live Transfer method to reduce service downtime when you are converting Windows workloads that support the VSS feature. Database servers, mail servers, and application servers that would otherwise require extended service stoppage can be protected by using this Live Transfer method. This method is also recommended for workload protection jobs in networks with high latency. Because this is a point-in-time solution, data does not need to be retransmitted as it does with other methods.

1.3.6 Installing Live Transfer Components

During the execution of a migration job the appropriate Live Transfer components are automatically installed on source and target workloads.

For block-based transfer components (the Block-based Transfer Component and the VSS Block-based Transfer Component) you have the additional option to manually install or uninstall a component on the appropriate source workload. This enables you to:

The following topics provide more details:

Checking Whether the Block-Based Component is Up to Date

If the Block-based Transfer Component on a source workload is obsolete, selecting the Block-level Live Transfer method for a conversion job causes Portability Suite to display a warning.

A warning message is also shown for existing synchronization schedules in the Synchronization Schedules window, so you can choose to upgrade the block-level transfer component on the source by right-clicking the applicable schedule and selecting Upgrade Block-based Components.

To check if the Block-based Transfer Component on a source is current:

  1. In the Servers view, right-click the source. If the menu includes Upgrade Block Based Component, the Block-based Transfer Component is obsolete.

This applies to the Block-based Transfer Component only. The VSS Block-based Transfer Component is new in version 8.1.

Manually Installing and Uninstalling Block-Based Components

You can manually install and uninstall both block-based components included with Portability Suite. Use this option to eliminate or reduce the impact of component installation on the operational continuity of your source workloads. See Continuity of Source Workloads Impacted by Transfer Method Selection.

To manually install or uninstall Block-based Transfer Components:

  1. In the Servers view, right-click the required source and select the required action:

    • Install Block Based Component or Install VSS Block Based Component: To install either component.

    • Uninstall Block Based Component or Uninstall Block Based Component: To uninstall either component.

  2. Provide valid credentials for the source machine, then click Uninstall.