Carbonite Migrate for Linux

User's Guide
 Notices
Carbonite Migrate for Linux User's Guide, version 8.4.2, Thursday, October 21, 2021
If you need technical assistance, you can contact CustomerCare. All basic configurations outlined in the
online documentation will be supported through CustomerCare. Assistance and support for advanced
configurations may be referred to a Pre-Sales Systems Engineer or to Professional Services.
Man pages are installed and available on Carbonite Availability and Carbonite Migrate Linux servers. These
documents are bound by the same license agreement as the software installation.
This documentation is subject to the following: (1) Change without notice; (2) Furnished pursuant to a
license agreement; (3) Proprietary to the respective owner; (4) Not to be copied or reproduced unless
authorized pursuant to the license agreement; (5) Provided without any expressed or implied warranties, (6)
Does not entitle Licensee, End User or any other party to the source code or source code documentation of
anything within the documentation or otherwise provided that is proprietary to Carbonite; and (7) All Open
Source and Third-Party Components (“OSTPC”) are provided “AS IS” pursuant to that OSTPC’s license
agreement and disclaimers of warranties and liability.
Carbonite and/or its affiliates and subsidiaries in the United States and/or other countries own/hold rights to
certain trademarks, registered trademarks, and logos. Hyper-V and Windows are registered trademarks of
Microsoft Corporation in the United States and/or other countries. Linux is a registered trademark of Linus
Torvalds. vSphere is a registered trademark of VMware. All other trademarks are the property of their
respective companies. For a complete list of trademarks registered to other companies, please visit that
company’s website.
© 2021 Carbonite. All rights reserved.
Contents
Chapter 1 Carbonite Migrate overview 5
Chapter 2 Requirements 6
Replication capabilities 7
Chapter 3 Carbonite Replication Console 9
Carbonite Replication Console requirements 11
Console options 12
Chapter 4 Managing servers 15
Adding servers 24
Providing server credentials 26
Viewing server details 27
Editing server properties 29
General server properties 30
Server licensing 31
Server setup properties 33
Carbonite Migrate queue 36
Source server properties 40
Target server properties 41
Log file properties 42
E-mail notification configuration 44
Viewing server logs 46
Managing VMware servers 48
Chapter 5 Files and folders migration 49
Files and folders migration requirements 50
Creating a files and folders migration job 55
Managing and controlling files and folders migration jobs 66
Viewing files and folders migration job details 76
Validating a files and folders migration job 80
Editing a files and folders migration job 81
Viewing a files and folders migration job log 83
Cutting over files and folders migration jobs 85
Chapter 6 Full server migration 86
Full server migration requirements 87
Creating a full server migration job 94
Managing and controlling full server migration jobs 105
Viewing full server migration job details 115
Validating a full server migration job 119
Editing a full server migration job 120
Viewing a full server migration job log 122
Cutting over full server migration jobs 124
Chapter 7 Full server to ESX migration 125
Full server to ESX migration requirements 126
Creating a full server to ESX migration job 133
Managing and controlling full server to ESX migration jobs 152
Viewing full server to ESX migration job details 162

Contents 3
 Validating a full server to ESX migration job 166
Editing a full server to ESX migration job 167
Viewing a full server to ESX migration job log 169
Cutting over full server to ESX migration jobs 171
Chapter 8 DTSetup 172
Running DTSetup 173
Setup tasks 174
Activating your server 175
Modifying security groups 176
Configuring server settings 177
Configuring driver performance settings 178
Starting and stopping the service 179
Starting DTCL 180
Viewing documentation and troubleshooting tools 181
DTSetup menus 182
Chapter 9 Security 183
Adding users to the security groups 184
Chapter 10 Special network configurations 185
Firewalls 186
NAT 187

Contents 4
Chapter 1 Carbonite Migrate overview
Carbonite Migrate is a comprehensive migration solution. It allows you to move an entire server, known
as a source, by mirroring an image of that source to another server, known as the target. The source and
target servers can be physical or virtual. The image of the source contains the server's system state (the
server's configured operating system and applications) and all of the source server’s data. You can also
migrate just a source's data, in which case the target's system state (the target's configured operating
system and applications) will be used with the source's data.
Carbonite Migrate uses patented data replication technology that allows users to continue accessing
and changing data during the migration. As changes are made on the source, replication keeps the
image of the source stored on the target up-to-date. Carbonite Migrate replicates, in real-time, only the
file changes, not the entire file, allowing you to more efficiently use resources. When you are ready to
cutover to the new server, Carbonite Migrate applies the source system state and after a reboot, the
source is available and running on what was the target server hardware.

Chapter 1 Carbonite Migrate overview 5

Chapter 2 Requirements
Your source and target servers must meet certain requirements, however, they depend on the type of
migration job you will be using. See the specific requirements for each migration type for requirements
specific to that job type.
l Files and folders migration requirements on page 50
l Full server migration requirements on page 87
l Full server to ESX migration requirements on page 126
Additionally, verify the machine where you are running the console meets the Carbonite Replication
Console requirements on page 11.

Chapter 2 Requirements 6
Replication capabilities
Carbonite Migrate replicates all file and directory data in the supported Linux file systems. Carbonite
Migrate does not replicate extended attributes (xattr), ACLs, or items that are not stored on the file
system, such as pseudo-file systems like /proc and /sys. In addition, note the following.
l Carbonite Migrate is compatible with NFS and Samba services as long as they are mounted on
top of Carbonite Migrate. (The mount must be at the origination point, not a remote mounted
point.) Additionally, NFS and Samba should be started after the Double-Take service.
l If you select data stored on a recursive mount point for replication, a mirror will never finish.
Carbonite Migrate does not check for data stored on recursive mount points.
l If any directory or file contained in your replication set specifically denies permission to the account
running the Double-Take service, the attributes of the file on the target will not be updated
because of the lack of access.
l Sparse files will become full size, zero filled files on the target.
l If you are using soft links, keep in mind the following.
l If a soft link to a directory is part of a replication set rule’s path above the entry point to the

replication set data, that link will be created on the target as a regular directory if it must be
created as part of the target path.
l If a soft link exists in a replication set (or is moved into a replication set) and points to a file or

directory inside the replication set, Carbonite Migrate will remap the path contained in that
link based on the Carbonite Migrate target path when the option RemapLink is set to the
default value (1). If RemapLink is set to zero (0), the path contained in the link will retain its
original mapping.
l If a soft link exists in a replication set (or is moved into a replication set) and points to a file or

directory outside the replication set, the path contained in that link will retain its original
mapping and is not affected by the RemapLink option.
l If a soft link is moved out of or deleted from a replication set on the source, that link will be

deleted from the target.

l If a soft link to a file is copied into a replication set on the source and the operating system

copies the file that the link pointed to rather than the link itself, then Carbonite Migrate
replicates the file copied by the operating system to the target. If the operating system does
not follow the link, only the link is copied.
l If a soft link to a directory is copied into a replication set on the source and the operating

system copies the directory and all of its contents that the link pointed to rather than the link
itself, then Carbonite Migrate replicates the directory and its contents copied by the
operating system to the target. If the operating system does not follow the link, only the link
is copied.
l If any operating system commands, such as chmod or chown, is directed at a soft link on

the source and the operating system redirects the action to the file or directory which the
link references, then if the file or directory referenced by the link is in a replication set, the
operation will be replicated for that file to the target.
l The operating system redirects all writes to soft links to the file referenced by the link.

Therefore, if the file referenced by the symbolic link is in a replication set, the write operation
will be replicated to the target.

Chapter 2 Requirements 7
 l If you are using hard links, keep in mind the following.
l If a hard link exists (or is created) only inside the replication set on the source, having no

locations outside the replication set, the linked file will be mirrored to the target for all
locations and those locations will be linked if all link locations on the target exist on the same
partition.
l If a hard link crosses the boundaries of a replication set on the source, having locations both

inside and outside the replication set, the linked file will be mirrored to the target for only
those locations inside the replication set on the source, and those locations will be linked on
the target if all link locations exist on the same partition.
l If a hard link is created on the source linking a file outside the replication set to a location

inside the replication set, the linked file will be created on the target in the location defined
by the link inside the replication set and will be linked to any other locations for that file which
exist inside the replication set.
l If any hard link location is moved from outside the replication set into the replication set on

the source, the link will not be replicated to the target even if other link locations already
exist inside the replication set, but the linked file will be created on the target in the location
defined by the link.
l If any hard link location existing inside the replication set is moved within the replication set

on the source, the move will be replicated to the target and the link will be maintained if the
new link location does not cross partitions in the target path.
l If any hard link location existing inside the replication set is moved out of the replication set,

that file or linked location will be deleted on the target.

l If a hard linked file is copied from any location inside or outside the replication set to a

location inside the replication set on the source, the copy will be replicated to the target.
l If a hard linked file has a location in the replication set and any of the operating system

commands, such as chmod or chown, are directed at that file from a location inside the
replication set, the modification to the file will be replicated to the target. Operations on hard
links outside of the replication set are not replicated.
l If a hard linked file has a location in the replication set and a write operation is directed at

that file from inside the replication set, the write operation will be replicated to the target.
Operations on hard links outside of the replication set are not replicated.
l If any hard link location existing inside the replication set is deleted on the source, that file or

linked location will be deleted from the target.

Chapter 2 Requirements 8
Chapter 3 Carbonite Replication Console
After you have installed the console, you can launch it by selecting Carbonite, Replication, Carbonite
Replication Console from your Programs, All Programs, or Apps, depending on your operating
system.
The Carbonite Replication Console is used to protect and monitor your servers and jobs. Each time you
open the Carbonite Replication Console, you start at the Servers page which allows you to view, edit,
add, remove, or manage the servers in your console. You can also create a new job from this page.

At the bottom of the Carbonite Replication Console, you will see a status bar. At the right side, you will
find links for Jobs with warnings and Jobs with errors. This lets you see quickly, no matter which
page of the console you are on, if you have any jobs that need your attention. Select this link to go to the
Jobs page, where the appropriate Filter: Jobs with warnings or Filter: Jobs with errors will
automatically be applied.

The first time you start the console, you will see the getting started screen tips on the Servers
page. These tips walk you through the basic steps of adding a server to your console, installing
Carbonite Migrate on that server, and creating a job on that server. If you do not want to see the
tips, close them. If you want to reopen the tips after you have closed them, select Help, Show
Getting Started Tips.

You can manually check for Carbonite Migrate updates by selecting Help, Check for Updates.

Chapter 3 Carbonite Replication Console 9

 l Update available—If there is an update available, click Get Update. The dialog box will
close and your web browser will open to the Carbonite web site where you can download and
install the update.
l No update available—If you are using the most recent console software, that will be
indicated. Click Close.
l No connection available—If the console cannot contact the update server of if there is an
error, the console will report that information. The console log contains a more detailed
explanation of the error. Click Check using Browser if you want to open your browser to
check for console software updates. You will need to use your browser if your Internet access
is through a proxy server.

Chapter 3 Carbonite Replication Console 10

Carbonite Replication Console requirements
You must meet the following requirements for the Carbonite Replication Console.
l Operating system—The Carbonite Replication Console can be run from a Windows source or
target. It can also be run from a 64-bit, physical or virtual machine running Windows 10, Windows
8, or Windows 7 Service Pack 1 or later.
l Microsoft .NET Framework—Microsoft .NET Framework version 4.5.1 is required.
l Screen resolution—For best results, use a 1024x768 or higher screen resolution.

The Carbonite Migrate installation prohibits the console from being installed on Server Core.
Because Windows 2012 allows you to switch back and forth between Server Core and a full
installation, you may have the console files available on Server Core, if you installed Carbonite
Migrate while running in full operating system mode. In any case, you cannot run the Carbonite
Replication Console on Server Core.

Chapter 3 Carbonite Replication Console 11

Console options
There are several options that you can set that are specific to the Carbonite Replication Console. To
access these console options, select Options from the toolbar.
l Monitoring—This section is used to determine how the console monitors your Carbonite Migrate
servers.
l Monitoring interval—Specifies how often, in seconds, the console refreshes the
monitoring data. The servers will be polled at the specified interval for information to refresh
the console.
l Automatic retry—This option will have the console automatically retry server login

credentials, after the specified retry interval, if the server login credentials are not accepted.
Keep in mind the following caveats when using this option.
l This is only for server credentials, not job credentials.

l A set of credentials provided for or used by multiple servers will not be retried for the

specified retry interval on any server if it fails on any of the servers using it.
l Verify your environment's security policy when using this option. Check your policies

for failed login lock outs and resets. For example, if your policy is to reset the failed
login attempt count after 30 minutes, set this auto-retry option to the same or a
slightly larger value as the 30 minute security policy to decrease the chance of a
lockout.
l Restarting the Carbonite Replication Console will automatically initiate an immediate

login.
l Entering new credentials will initiate an immediate login using the new credentials.

l Retry on this interval—If you have enabled the automatic retry, specify the length of time,

in minutes, to retry the login.

l Server Communication—This section is used to determine how the console communicates
with your Carbonite Migrate servers.
lDefault port for XML web services protocol—Specifies the port that the console will
use when sending and receiving data to Carbonite Migrate servers. By default, the port is
6325. Changes to the console port will not take effect until the console is restarted.
l Default port for legacy protocol—If you are using an older Carbonite Migrate version,

you will need to use the legacy protocol port. This applies to Carbonite Migrate versions 5.1
or earlier.
l Diagnostics—This section assists with console troubleshooting.
l Export Diagnostic Data—This button creates a raw data file that can be used for
debugging errors in the Carbonite Replication Console. Use this button as directed by
technical support.
l View Log File—This button opens the Carbonite Replication Console log file. Use this
button as directed by technical support. You can also select View, View Console Log File
to open the Carbonite Replication Console log file.
l View Data File—This button opens the Carbonite Replication Console data file. Use this
button as directed by technical support. You can also select View, View Console Data
File to open the Carbonite Replication Console data file.

Chapter 3 Carbonite Replication Console 12

 l License Inventory—This section controls if the console contains a license inventory. This
feature may not appear in your console if your service provider has restricted access to it.
l Enable license inventory—This option allows you to use this console to manage the
Carbonite Migrate licenses assigned to your organization. When this option is enabled, the
License Inventory page is also enabled.
l Default Installation Options—All of the fields under the Default Installation Options section
are used by the push installation on the Install page. The values specified here will be the default
options used for the push installation.
l Activate online after install completes—Specify if you want to activate your Carbonite
Migrate licenses at the end of the installation. The activation requires Internet access from
the console machine or the machine you are installing to. Activation will be attempted from
the console machine first and if that fails, it wil be attempted from the machine you are
installing to. If you choose not to have the installation activate your licenses, you will have to
activate them through the console license inventory or the server's properties page.
l Location of install folders—Specify the parent directory location where the installation

files are located. The parent directory can be local on your console machine or a UNC path.
l Windows—Specify the parent directory where the Windows installation file is

located. The default location is where the Carbonite Replication Console is installed,
which is \Program Files\Carbonite\Replication. The console will automatically use
the \x64 subdirectory which is populated with the Windows installation files when you
installed the console. If you want to use a different location, you must copy the \x64
folder and its installation file to the different parent directory that you specify.
l Linux—Specify the parent directory where the Linux installation files are located.

The default location is where the Carbonite Replication Console is installed, which is
\Program Files\Carbonite\Replication. The console will automatically use the \Linux
subdirectory, however that location will not be populated with the Linux installation
files when you installed the console. You must copy the Linux .deb or .rpm files from
your download to the \Linux subdirectory in your Carbonite Replication Console
installation location. Make sure you only have a single version of Linux installation
files. The push installation cannot determine which version to install if there are
multiple versions in the \Linux subdirectory. If you want to use a different location, you
must copy the \Linux folder and its installation files to the different parent directory
that you specify.
l Default Windows Installation Options—All of the fields under the Default Installation
Options section are used by the push installation on the Install page. The values specified here
will be the default options used for the push installation.
l Temporary folder for installation package—Specify a temporary location on the server
where you are installing Carbonite Migrate where the installation files will be copied and
run.
l Installation folder—Specify the location where you want to install Carbonite Migrate on
each server. This field is not used if you are upgrading an existing version of Carbonite
Migrate. In that case, the existing installation folder will be used.
l Queue folder—Specify the location where you want to store the Carbonite Migrate disk
queue on each server.
l Amount of system memory to use—Specify the maximum amount of memory, in MB,
that can be used for Carbonite Migrate processing.

Chapter 3 Carbonite Replication Console 13

 l Minimum free disk space—This is the minimum amount of disk space in the specified
Queue folder that must be available at all times. This amount should be less than the
amount of physical disk space minus the disk size specified for Limit disk space for
queue.
l Do not use disk queue—This option will disable disk queuing. When system memory has
been exhausted, Carbonite Migrate will automatically begin the auto-disconnect process.
l Unlimited disk queue—Carbonite Migrate will use an unlimited amount of disk space in
the specified Queue folder for disk queuing, which will allow the queue usage to
automatically expand whenever the available disk space expands. When the available disk
space has been used, Carbonite Migrate will automatically begin the auto-disconnect
process.
l Limit disk space for queue—This option will allow you to specify a fixed amount of disk
space, in MB, in the specified Queue folder that can be used for Carbonite Migrate disk
queuing. When the disk space limit is reached, Carbonite Migrate will automatically begin
the auto-disconnect process.

If the servers you are pushing to do not have a C drive, make sure you update the folder
fields because the Carbonite Replication Console will not validate that the fields are set to
a volume that does not exist and the installation will not start.

l Default Linux Installation Options—All of the fields under the Default Installation Options
section are used by the push installation on the Install page. The values specified here will be the
default options used for the push installation.
l Temporary folder for installation package—Specify a temporary location on the server
where you are installing Carbonite Migrate where the installation files will be copied and
run.

Chapter 3 Carbonite Replication Console 14

Chapter 4 Managing servers
To manage the servers in your console, select Servers from the toolbar. The Servers page is for server
management and job creation.
l Add and remove servers—You can add servers to and remove servers from the console.
l View and edit—You can view server details and edit Carbonite Migrate server properties.
l Create job—You can create a protection or migration job for a selected server.
l Server organization—You can organize the servers that are in your console into groups,
allowing you to filter the servers you are viewing based on your organization.
Review the following sections to understand the information and controls available on the Servers
page.

If you have uninstalled and reinstalled Carbonite Migrate on a server, you may see the server
twice on the Servers page because the reinstall assigns a new unique identifier to the server.
One of the servers (the original version) will show with the red X icon. You can safely remove
that server from the console.

Left pane
You can expand or collapse the left pane by clicking on the Server Highlights heading. This pane
allows you to organize your servers into folders. The servers displayed in the top right pane will change
depending on the server group folder selected in the left pane. Every server in your console session is
displayed when the All Servers group is selected. If you have created and populated server groups
under My Servers, then only the servers in the selected group will be displayed in the right pane.
Between the main toolbar and the left pane is a smaller toolbar. These toolbar options control the server
groups in the left pane.

Create New Server Group

Creates a new server group below the selected group

Rename Server Group

Allows you to rename the selected server group

Delete Server Group

Deletes the selected server group. This will not delete the servers in the group, only the
group itself.

Chapter 4 Managing servers 15

Overflow Chevron
Displays any toolbar buttons that are hidden from view when the window size is
reduced.

Top right pane

The top pane displays high-level overview information about your servers. You can sort the data within a
column in ascending and descending order. You can also move the columns to the left or right of each
other to create your desired column order. The list below shows the columns in their default left to right
order.

Column 1 (Blank)
The first blank column indicates the machine type.

Carbonite Migrate source or target server which could be a physical server, virtual
machine, or a cluster node

Carbonite Migrate source or target server which is a Windows cluster

vCenter server

ESX server

Carbonite Migrate Reporting Service server

Offline server which means the console cannot communicate with this machine.

Any server icon with a red circle with white X overlay is an error which means the
console can communicate with the machine, but it cannot communicate with Carbonite
Migrate on it.
Column 2 (Blank)
The second blank column indicates the security level

Processing—The console is attempting to communicate with machine.

Administrator access—This level grants full control.

Monitor only access—This level grants monitoring privileges only.
No security access—This level does not allow monitoring or control.

Chapter 4 Managing servers 16

Server
The name or IP address of the server. If you have specified a reserved IP address, it
will be displayed in parenthesis.
Activity
There are many different Activity messages that keep you informed of the server
activity. Most of the activity messages are informational and do not require any
administrator interaction. If you see error messages, check the server details. See
Viewing server details on page 27.
Version
The Carbonite Migrate product version information, if any.
Licensing Status
The status of the license, if any, on the server. If your license is expired, any jobs using
that server will be in an error state. If you have multiple licenses, the status will indicate
the license that requires the soonest action. For example, if you have a Carbonite
Migrate license that expires in two days and a Carbonite Availability license that must
be activated within 10 days, the status will be for the Carbonite Migrate license.
Product
The Carbonite Migrate products, if any, licensed for the server

Bottom right pane

The details displayed in the bottom pane provide additional information for the server highlighted in the
top pane. You can expand or collapse the bottom pane by clicking on the Server Highlights heading.

Name
The name or IP address of the server.
Operating system
The operating system of the server. This field will not be displayed if the console cannot
connect to Carbonite Migrate on the server.
Product
The Carbonite Migrate products, if any, licensed for the server
Version
The product version information, if any

Chapter 4 Managing servers 17

Serial Number
The serial number associated with the Carbonite Migrate license

Chapter 4 Managing servers 18

Toolbar
The following options are available on the main toolbar of the Servers page. Some options are only
available for a single selected server and others are available for multiple selected servers.

Create a New Job

The available job creation choices depend on the Carbonite Migrate licenses applied to
your server.
l Protect—If you are licensed for Carbonite Availability, use the Protect option to
create a protection job for the selected server.
l Migrate—If you are licensed for Carbonite Migrate or certain Carbonite Availability
licenses, use the Migrate option to create a migration job for the selected server.

Add Servers
Adds a new server. This button leaves the Servers page and opens the Add Servers
page. See Adding servers on page 24.

View Server Details

Views detailed information about a server. This button leaves the Servers page and
opens the View Server Details page. See Viewing server details on page 27.

Edit Server Properties

Edits the server's properties and options. This button leaves the Servers page and
opens the Edit Server Properties page. See Editing server properties on page 29.

Remove Server
Removes the server from the console.

Provide Credentials
Changes the login credentials that the Carbonite Replication Console use to
authenticate to a server. This button opens the Provide Credentials dialog box where
you can specify the new account information. See Providing server credentials on page
26. You will remain on the Servers page after updating the server credentials.

Manage Group Assignments

Allows you to assign, move, and remove the selected server from specific server
groups. This buttons opens the Manage Group Assignments dialog box where you can
assign and unassign the server to specific server groups. The server will appear in

Chapter 4 Managing servers 19

 server groups marked with a checkmark, and will not appear in groups without a
checkmark. Servers assigned to a server group will automatically appear in parent
server groups.

Install
Installs or upgrades Carbonite Migrate on the selected server. This button opens the
Install page where you can specify installation options.

Uninstall
Uninstalls Carbonite Migrate on the selected server.

View Server Events

Views Windows application event messages for a server. This option is not available
for Linux sources or appliances.

View Server Logs

Views the Carbonite Migrate logs messages for a server. This button opens the Logs
window. This separate window allows you to continue working in the Carbonite
Replication Console while monitoring log messages. You can open multiple logging
windows for multiple servers. When the Carbonite Replication Console is closed, all
logging windows will automatically close.

Launch Reporting
Launches the Reporting Service report viewer.

Activate Online
Activates licenses and applies the activation keys to servers in one step. You must have
Internet access for this process. You will not be able to activate a license that has
already been activated.

Refresh
Refreshes the status of the selected servers.
Search
Allows you to search the product or server name for items in the list that match the
criteria you have entered.

Overflow Chevron
Displays any toolbar buttons that are hidden from view when the window size is
reduced.

Chapter 4 Managing servers 20

Right-click menu
The following options are available on the right-click menu of the Servers page. Some options are only
available for a single selected server and others are available for multiple selected servers.

Protect
If you are licensed for Carbonite Availability, use the Protect option to create a
protection job for the selected server.

Migrate
If you are licensed for Carbonite Migrate or certain Carbonite Availability licenses, use
the Migrate option to create a migration job for the selected server.

View Server Details

Views detailed information about a server. This button leaves the Servers page and
opens the View Server Details page. See Viewing server details on page 27.

Edit Server Properties

Edits the server's properties and options. This button leaves the Servers page and
opens the Edit Server Properties page. See Editing server properties on page 29.

Remove Server
Removes the server from the console.

Provide Credentials
Changes the login credentials that the Carbonite Replication Console use to
authenticate to a server. This button opens the Provide Credentials dialog box where
you can specify the new account information. See Providing server credentials on page
26. You will remain on the Servers page after updating the server credentials.

Manage Group Assignments

Allows you to assign, move, and remove the selected server from specific server
groups. This buttons opens the Manage Group Assignments dialog box where you can
assign and unassign the server to specific server groups. The server will appear in
server groups marked with a checkmark, and will not appear in groups without a
checkmark. Servers assigned to a server group will automatically appear in parent
server groups.

Chapter 4 Managing servers 21

Install
Installs or upgrades Carbonite Migrate on the selected server. This button opens the
Install page where you can specify installation options.

Uninstall
Uninstalls Carbonite Migrate on the selected server.

Copy
Copies the information for the selected servers. You can then paste the server
information as needed. Each server is pasted on a new line, with the server information
being comma-separated.

Paste
Pastes a new-line separated list of servers into the console. Your copied list of servers
must be entered on individual lines with only server names or IP addresses on each
line.

View Server Events

Views Windows event messages for a server. This option is not available for Linux
sources or appliances.

View Server Logs

Views the Carbonite Migrate logs messages for a server. This button opens the Logs
window. This separate window allows you to continue working in the Carbonite
Replication Console while monitoring log messages. You can open multiple logging
windows for multiple servers. When the Carbonite Replication Console is closed, all
logging windows will automatically close.

Launch Reporting
Launches the Reporting Service report viewer.

Activate Online
Activates licenses and applies the activation keys to servers in one step. You must have
Internet access for this process. You will not be able to activate a license that has
already been activated.

Gather Support Diagnostics

Executes the diagnostic DTInfo utility which collects configuration data for use when
reporting problems to technical support. It gathers Carbonite Migrate log files;
Carbonite Migrate and system settings; network configuration information such as IP,

Chapter 4 Managing servers 22

 WINS, and DNS addresses; and other data which may be necessary for technical
support to troubleshoot issues. You will be prompted for a location to save the resulting
file which is created with the information gathered. Because this utility is gathering
several pieces of information, across the network to your console machine, it may take
several minutes to complete the information gathering and sending the resulting file to
the console machine.

View Replication Service Details

Views the replication service details for a server. This button opens the Replication
service view window. This separate window allows you to continue working in the
Carbonite Replication Console while monitoring the replication service details. You can
open multiple Replication service view windows for multiple servers. When the
Carbonite Replication Console is closed, all Replication service view windows will
automatically close. If you do not want to open separate windows, you can switch
between servers that are in your Carbonite Replication Console from within the
Replication service view window. See the Reference Guide for a complete list of
replication details.

Refresh
Refreshes the status of the selected servers.

Chapter 4 Managing servers 23

Adding servers
The first time you start the console, the Servers page is empty. In order to migrate and monitor your
servers, you must insert your servers and/or appliances in the console.

Inserting servers manually

1. Click Servers from the main toolbar.
2. Click Add servers from the Servers page toolbar.
3. On the Manual Entry tab, specify the server information.
l Server—This is the name or IP address of the server or appliance to be added to the

console.

If you enter the source server's fully-qualified domain name, the Carbonite
Replication Console will resolve the entry to the server short name. If that short
name resides in two different domains, this could result in name resolution issues.
In this case, enter the IP address of the server.

If you are using a NAT environment, make sure you add your server to the
Carbonite Replication Console using the correct public or private IP address. The
name or IP address you use to add a server to the console is dependent on where
you are running the console. Specify the private IP address of any servers on the
same side of the router as the console. Specify the public IP address of any servers
on the other side of the router as the console.

l User name—Specify a local user that is a member of the dtadmin or dtmon security
group on the server.
l Password—Specify the password associated with the User name you entered.

l Domain—If you are working in a domain environment, specify the Domain.

l Management Service port—If you want to change the port used by the Double-Take

Management Service, disable Use default port and specify the port number you want to
use. This option is useful in a NAT environment where the console needs to be able to
communicate with the server using a specific port number. Use the public or private port
depending on where the console is running in relation to the server you are adding.
4. After you have specified the server or appliance information, click Add.
5. Repeat steps 3 and 4 for any other servers or appliances you want to add.
6. If you need to remove servers or appliances from the list of Servers to be added, highlight a
server and click Remove. You can also remove all of them with the Remove All button.
7. When your list of Servers to be added is complete, click OK.

Importing and exporting servers from a server and group configuration file
You can share the console server and group configuration between machines that have the Carbonite
Replication Console installed. The console server configuration includes the server group configuration,
server name, server communications ports, and other internal processing information.

Chapter 4 Managing servers 24

To export a server and group configuration file, select File, Export Servers. Specify a file name and
click Save. After the configuration file is exported, you can import it to another console.
When you are importing a console server and group configuration file from another console, you will not
lose or overwrite any servers that already exist in the console. For example, if you have server alpha in
your console and you insert a server configuration file that contains servers alpha and beta, only the
server beta will be inserted. Existing group names will not be merged, so you may see duplicate server
groups that you will have to manually update as desired.
To import a server and group configuration file, select File, Import Servers. Locate the console
configuration file saved from the other machine and click Open.

Chapter 4 Managing servers 25

Providing server credentials
To update the security credentials used for a specific server, select Provide Credentials from the
toolbar on the Servers page. When prompted, specify the User name, Password, and Domain of the
account you want to use for this server. Click OK to save the changes.

Chapter 4 Managing servers 26

Viewing server details
Highlight a server on the Servers page and click View Server Details from the toolbar. The View
Server Details page allows you to view details about that particular server. The server details vary
depending on the type of server or appliance you are viewing.

Server name
The name or IP address of the server. If you have specified a reserved IP address, it
will be displayed in parenthesis.
Operating system
The server's operating system version
Roles
The role of this server in your Carbonite Migrate environment. In some cases, a server
can have more than one role.
l Engine Role—Source or target server
l Reporting Service—Reporting Service server
Status
There are many different Status messages that keep you informed of the server
activity. Most of the status messages are informational and do not require any
administrator interaction. If you see error messages, check the rest of the server
details.
Activity
There are many different Activity messages that keep you informed of the server
activity. Most of the activity messages are informational and do not require any
administrator interaction. If you see error messages, check the rest of the server
details.
Connected via
The IP address and port the server is using for communcations. You will also see the
Carbonite Migrate protocol being used to communicate with server. The protocol will
be XML web services protocol (for servers running Carbonite Migrate version 5.2 or
later) or Legacy protocol (for servers running version 5.1 or earlier).
Version
The product version information
Access
The security level granted to the specified user
User name
The user account used to access the server

Chapter 4 Managing servers 27

Licensing
Licensing information for the server
Source jobs
A list of any jobs from this server. Double-clicking on a job in this list will automatically
open the View Job Details page.
Target jobs
A list of any jobs to this server. Double-clicking on a job in this list will automatically open
the View Job Details page.

Chapter 4 Managing servers 28

Editing server properties
Right-click a server on the Servers page and select Edit server properties. The Edit Server
Properties page allows you to view and edit properties for that server. Click on a heading on the Edit
Server Properties page to expand or collapse a section of properties.
l General server properties on page 30—Identifies the server and configures encryption
l Server licensing on page 31—Views, adds, and removes license keys
l Server setup properties on page 33—Indicates how the server will act on startup and shutdown
l Carbonite Migrate queue on page 36—Configures the Carbonite Migrate queues
l Source server properties on page 40—Configures the source server
l Target server properties on page 41—Configures the target server
l Log file properties on page 42—Configures log files
l E-mail notification configuration on page 44—Configures e-mail notification

Chapter 4 Managing servers 29

General server properties
The general server properties identify the server and allow you to set encryption.

l Default address—On a server with multiple NICs, you can specify which address Carbonite
Migrate traffic will use. It can also be used on servers with multiple IP addresses on a single NIC. If
you change this setting, you must restart the Double-Take service for this change to take effect.
l Port—The server uses this port to send and receive commands and operations between
Carbonite Migrate servers. If you change the port, you must stop and restart the Double-Take
service.
l Encrypt network data—Use this option to encrypt your data before it is sent from the source to
the target. Both the source and target must be encryption capable ( version 7.0.1 or later),
however this option only needs to be enabled on the source or target in order to encrypt data.
Keep in mind that all jobs from a source with this option enabled or to a target with this option
enabled will have the same encryption setting. Changing this option will cause jobs to auto-
reconnect and possibly remirror. The encryption method used is AES-256.

Chapter 4 Managing servers 30

Server licensing
Licensing identifies your Carbonite Migrate license keys.

The fields and buttons in the Licensing section will vary depending on your Carbonite
Replication Console configuration and the type of license keys you are using.

Click the FAQ link if you want more information about licensing and activation.

l Add license keys and activation keys—Your license key or activation key is a 24 character,
alpha-numeric key. You can change your license key without reinstalling, if your license changes.
To add a license key or activation key, type in the key or click Choose from inventory and select
a key from your console's license inventory. Then click Add.

The license inventory feature cannot be enabled if your service provider has restricted
access to it.

l Current license keys—The server's current license key information is displayed. To remove a
key, highlight it and click Remove. To copy a key, highlight it and click Copy. To replace a key,
enter a new key and click Add. If you are replacing an unexpired key with the same version and
serial number, you should not have to reactivate it and any existing jobs will continue

Chapter 4 Managing servers 31

 uninterrupted. If you are replacing an unexpired key with a new version or new serial number or
replacing an expired key, you will have to reactivate and remirror.
l Activation—If your license key needs to be activated, you will see an additional Activation
section at the bottom of the Licensing section. To activate your key, use one of the following
procedures.
l Activate online—If you have Internet access, you can activate your license and apply the
activated license to the server in one step by selecting Activate Online.

You will not be able to activate a license that has already been activated.

l Obtain activation key online, then activate—If you have Internet access, click the
hyperlink in the Activation section to take you to the web so that you can submit your
activation information. Complete and submit the activation form, and you will receive an e-
mail with the activation key. Activate your server by entering the activation key in the Add
license keys and activations keys field and clicking Add.
l Obtain activation key offline, then activate—If you do not have Internet access, go to

https://activate.doubletake.com from another machine that has Internet access. Complete

and submit the activation form, and you will receive an e-mail with the activation key.
Activate your server by entering the activation key in the Add license keys and
activations keys field and clicking Add.
The activation key is specific to this server. It cannot be used on any other server. If the activation
key and server do not match, Carbonite Migrate will not run.

For Carbonite Migrate, license keys do not have a grace period and must be activated in
order to be used. Once the license has been activated, you will have a specific number of
days (generally 30 days) to complete your migration process, depending on your license
type.

l On Demand Licensing—If you are a service provider participating in the On Demand licensing
program, you can configure the subscription license for your target servers here. If you are not in
this program, you can skip this section. For the latest and complete details on On Demand, see
the help link in the On Demand web portal.
1. Specify your Service provider account number. The account number is displayed in the
upper right corner of the On Demand web portal.
2. Specify the Customer name. Use the customer name configured on the Customers list in
the On Demand web portal.
3. Select the appropriate Product that corresponds with the Carbonite Migrate product being
used.
4. If you are using a proxy server, select Enable On Demand Proxy and specify the Proxy
address using the value http://xxx.xxx.xxx.xxx:yyyy where xxx.xxx.xxx.xxx is the IP
address of your proxy server and yyyy is the port number.
5. Click Submit to activate the subscription license on the target.

Chapter 4 Managing servers 32

Server setup properties
Server setup properties indicate how the server will act on startup and shutdown.

l Log statistics automatically—If enabled, Carbonite Migrate statistics logging will start
automatically when Carbonite Migrate is started.
l Enable task command processing—Task command processing is a Carbonite Migrate
feature that allows you to insert and run tasks at various points during the replication of data.
Because the tasks are user-defined, you can achieve a wide variety of goals with this feature. For
example, you might insert a task to create a snapshot or run a backup on the target after a certain
segment of data from the source has been applied on the target. This allows you to coordinate a
point-in-time backup with real-time replication. Enable this option to enable task command
processing, however to insert your tasks, you must use the Carbonite Migrate scripting language.
See the Scripting Guide for more information. If you disable this option on a source server, you
can still submit tasks to be processed on a target, although task command processing must be
enabled on the target.
l Automatically reconnect during source initialization—Disk queues are user configurable
and can be extensive, but they are limited. If the amount of disk space specified for disk queuing is
met, additional data would not be added to the queue and data would be lost. To avoid any data
loss, Carbonite Migrate will automatically disconnect jobs when necessary. If this option is
enabled, Carbonite Migrate will automatically reconnect any jobs that it automatically
disconnected. These processes are called auto-disconnect and auto-reconnect and can happen
in the following scenarios.
l Source server restart—If your source server is restarted, Carbonite Migrate will
automatically reconnect any jobs that were previously connected. Then, if configured,
Carbonite Migrate will automatically remirror the data. This process is called auto-remirror.
The remirror re-establishes the target baseline to ensure data integrity, so disabling auto-
remirror is not advised.
l Exhausted queues on the source—If disk queuing is exhausted on the source,
Carbonite Migrate will automatically start disconnecting jobs. This is called auto-disconnect.
The transaction logs and system memory are flushed allowing Carbonite Migrate to begin
processing anew. The auto-reconnect process ensures that any jobs that were auto-
disconnected are automatically reconnected. Then, if configured, Carbonite Migrate will
automatically remirror the data. This process is called auto-remirror. The remirror re-
establishes the target baseline to ensure data integrity, so disabling auto-remirror is not
advised.
l Exhausted queues on the target—If disk queuing is exhausted on the target, the target
instructs the source to pause. The source will automatically stop transmitting data to the
target and will queue the data changes. When the target recovers, it will automatically tell
the source to resume sending data. If the target does not recover by the time the source
queues are exhausted, the source will auto-disconnect as described above. The

Chapter 4 Managing servers 33

 transaction logs and system memory from the source will be flushed then Carbonite
Migrate will auto-reconnect. If configured, Carbonite Migrate will auto-remirror. The
remirror re-establishes the target baseline to ensure data integrity, so disabling auto-
remirror is not advised.
l Queuing errors—If there are errors during disk queuing on either the source or target, for
example, Carbonite Migrate cannot read from or write to the transaction log file, the data
integrity cannot be guaranteed. To prevent any loss of data, the source will auto-disconnect
and auto-reconnect. If configured, Carbonite Migrate will auto-remirror. The remirror re-
establishes the target baseline to ensure data integrity, so disabling auto-remirror is not
advised.
l Target server interruption—If a target machine experiences an interruption (such as a
cable or NIC failure), the source/target network connection is physically broken but both the
source and target maintain the connection information. The Carbonite Migrate source, not
being able to communicate with the Carbonite Migrate target, stops transmitting data to the
target and queues the data changes, similar to the exhausted target queues described
above. When the interruption is resolved and the physical source/target connection is
reestablished, the source begins sending the queued data to the target. If the source/target
connection is not reestablished by the time the source queues are exhausted, the source
will auto-disconnect as described above.
l Target service shutdown—If the target service is stopped and restarted, there could
have been data in the target queue when the service was stopped. To prevent any loss of
data, the Double-Take service will attempt to persist to disk important target connection
information (such as the source and target IP addresses for the connection, various target
queue information, the last acknowledged operation, data in memory moved to disk, and so
on) before the service is stopped. If Carbonite Migrate is able to successfully persist this
information, when the Double-Take service on the target is restarted, Carbonite Migrate
will pick up where it left off, without requiring an auto-disconnect, auto-reconnect, or auto-
remirror. If Carbonite Migrate cannot successfully persist this information prior to the restart
(for example, a server crash or power failure where the target service cannot shutdown
gracefully), the source will auto-reconnect when the target is available, and if configured,
Carbonite Migrate will auto-remirror. The remirror re-establishes the target baseline to
ensure data integrity, so disabling auto-remirror is not advised.

If you are experiencing frequent auto-disconnects, you may want to increase the amount
of disk space on the volume where the Carbonite Migrate queue is located or move the
disk queue to a larger volume.

If you have manually changed data on the target, for example if you were testing data on
the target, Carbonite Migrate is unaware of the target data changes. You must manually
remirror your data from the source to the target, overwriting the target data changes that
you caused, to ensure data integrity between your source and target.

l Behavior when automatically remirroring—Specify how Carbonite Migrate will perform the
mirror when it is automatically remirroring.

If you are using a database application or are protecting a domain controller, do not use
the compare file attributes only options unless you know for certain that you need it. With
database applications and because domain controllers store their data in a database, it is

Chapter 4 Managing servers 34

 critical that all files, not just some of the files, are mirrored. In this case, you should
compare both the attributes and the data.

l Do not compare files. Send the entire file.—Carbonite Migrate will not perform any
comparisons between the files on the source and target. All files will be mirrored to the
target, sending the entire file.
l Compare file attributes. Send the entire file.—Carbonite Migrate will compare file
attributes and will mirror those files that have different attributes, sending the entire file.
l Compare file attributes. Send the attributes and bytes that differ.—Carbonite
Migrate will compare file attributes and will mirror only the attributes and bytes that are
different.
l Compare file attributes and data. Send the attributes and bytes that differ.—
Carbonite Migrate will compare file attributes and the file data and will mirror only the
attributes and bytes that are different.

Chapter 4 Managing servers 35

Carbonite Migrate queue
During the Carbonite Migrate installation, you identified the amount of disk space that can be used for
Carbonite Migrate queuing. Queuing to disk allows Carbonite Migrate to accommodate high volume
processing that might otherwise exhaust system memory. For example, on the source, this may occur if
the data is changing faster than it can be transmitted to the target, or on the target, a locked file might
cause processing to back up.

Carbonite Migrate Queuing Diagram

The following diagram will help you understand how queuing works. Each numbered step is described
after the diagram.

1. If data cannot immediately be transmitted to the target, it is stored in system memory. You can
configure how much system memory you want Carbonite Migrate to use for all of its processing.
2. When the allocated amount of system memory is full, new changed data bypasses the full system
memory and is queued directly to disk. Data queued to disk is written to a transaction log. Each
transaction log can store 5 MB worth of data. Once the log file limit has been reached, a new
transaction log is created. The logs can be distinguished by the file name which includes the target
IP address, the Carbonite Migrate port, the connection ID, and an incrementing sequence
number.

You may notice transaction log files that are not the defined size limit. This is because data
operations are not split. For example, if a transaction log has 10 KB left until the limit and
the next operation to be applied to that file is greater than 10 KB, a new transaction log file
will be created to store that next operation. Also, if one operation is larger than the defined
size limit, the entire operation will be written to one transaction log.

3. When system memory is full, the most recent changed data is added to the disk queue, as
described in step 2. This means that system memory contains the oldest data. Therefore, when
data is transmitted to the target, Carbonite Migrate pulls the data from system memory and sends

Chapter 4 Managing servers 36

 it. This ensures that the data is transmitted to the target in the same order it was changed on the
source. Carbonite Migrate automatically reads operations from the oldest transaction log file into
system memory. As a transaction log is depleted, it is deleted. When all of the transaction log files
are deleted, data is again written directly to system memory (step 1).
4. To ensure the integrity of the data on the target, the information must be applied in the same order
as it was on the source. If there are any delays in processing, for example because of a locked file,
a similar queuing process occurs on the target. Data that cannot immediately be applied is stored
in system memory.
5. When the allocated amount of system memory on the target is full, new incoming data bypasses
the full system memory and is queued directly to disk. Data queued to disk is written to a
transaction log. On the target, the transaction logs are identified with the source IP address, the
Carbonite Migrate port, the connection ID, and an incrementing sequence number.
Like the source, system memory on the target contains the oldest data so when data is applied to
the target, Carbonite Migrate pulls the data from system memory. Carbonite Migrate
automatically moves operations from the oldest transaction log file to system memory. As a
transaction log is depleted, it is deleted. When all of the transaction log files are deleted, data is
again written directly to system memory (step 4).
The following memory and queue options are available for each Carbonite Migrate server.

l Queue folder—This is the location where the disk queue will be stored. Any changes made to the
queue location will not take effect until the Double-Take service has been restarted on the server.
When selecting the queue location, keep in mind the following caveats.
l Select a dedicated, non-boot volume.
l Do not select the same physical or logical volume as the data being replicated.

l Do not select the root of a volume.

Although the read/write ratio on queue files will be 1:1, optimizing the disk for write activity will
benefit performance because the writes will typically be occurring when the server is under a high
load, and more reads will be occurring after the load is reduced. Accordingly, use a standalone
disk, mirrored (RAID 1) or non-parity striped (RAID 0) RAID set, and allocate more I/O adapter
cache memory to writes for best performance. A RAID 5 array will not perform as well as a
mirrored or non-parity striped set because writing to a RAID 5 array incurs the overhead of

Chapter 4 Managing servers 37

 generating and writing parity data. RAID 5 write performance can be up to 50% less than the write
performance of a single disk, depending on the adapter and disk.

Scanning the Carbonite Migrate queue files for viruses can cause unexpected results. If
anti-virus software detects a virus in a queue file and deletes or moves it, data integrity on
the target cannot be guaranteed. As long as you have your anti-virus software configured
to protect the actual production data, the anti-virus software can clean, delete, or move an
infected file and the clean, delete, or move will be replicated to the target. This will keep
the target from becoming infected and will not impact the Carbonite Migrate queues.

l Amount of system memory to use—This is the maximum amount of Windows system

memory, in MB, that Carbonite Migrate will use. When this limit is reached, queuing to disk will be
triggered. The minimum amount of system memory is 512 MB. The maximum amount is
dependent on the server hardware and operating system. If you set this value lower, Carbonite
Migrate will use less system memory, but you will queue to disk sooner which may impact system
performance. If you set it higher, Carbonite Migrate will maximize system performance by not
queuing to disk as soon, but the system may have to swap the memory to disk if the system
memory is not available.
Since the source is typically running a production application, it is important that the amount of
memory Carbonite Migrate and the other applications use does not exceed the amount of RAM in
the system. If the applications are configured to use more memory than there is RAM, the system
will begin to swap pages of memory to disk and the system performance will degrade. For
example, by default an application may be configured to use all of the available system memory
when needed, and this may happen during high-load operations. These high-load operations
cause Carbonite Migrate to need memory to queue the data being changed by the application. In
this case, you would need to configure the applications so that they collectively do not exceed the
amount of RAM on the server. Perhaps on a server with 4 GB of RAM running the application and
Carbonite Migrate, you might configure the application to use 1 GB and Carbonite Migrate to use
1 GB, leaving 2 GB for the operating system and other applications on the system. Many server
applications default to using all available system memory, so it is important to check and configure
applications appropriately, particularly on high-capacity servers.
Any changes to the memory usage will not take effect until the Double-Take service has been
restarted on the server.
l Do not use disk queue—This option will disable disk queuing. When system memory has been
exhausted, Carbonite Migrate will automatically begin the auto-disconnect process.
l Unlimited disk queue—Carbonite Migrate will use an unlimited amount of disk space in the
specified Queue folder for disk queuing, which will allow the queue usage to automatically
expand whenever the available disk space expands. When the available disk space has been
used, Carbonite Migrate will automatically begin the auto-disconnect process.
l Limit disk space for queue—This option will allow you to specify a fixed amount of disk space,
in MB, in the specified Queue folder that can be used for Carbonite Migrate disk queuing. When
the disk space limit is reached, Carbonite Migrate will automatically begin the auto-disconnect
process.
l Minimum free disk space—This is the minimum amount of disk space in the specified Queue
folder that must be available at all times. This amount should be less than the amount of physical
disk space minus the disk size specified for Limit disk space for queue.

Chapter 4 Managing servers 38

 The Limit disk space for queue and Minimum free disk space settings work in
conjunction with each other. For example, assume your queue is stored on a 10 GB disk
with the Limit disk space for queue set to 10 GB and the Minimum free disk space
set to 500 MB. If another program uses 5 GB, Carbonite Migrate will only be able to use
4.5 GB so that 500 MB remains free.

l Alert at this queue usage—This is the percentage of the disk queue that must be in use to
trigger an alert message. By default, the alert will be generated when the queue reaches 50%.

Chapter 4 Managing servers 39

Source server properties
These properties are specific to the source server role.

l Number of replication packets per one mirror packet—You can specify the ratio of
replication packets to mirror packets that are placed in the source queue. The default value (5)
allows Carbonite Migrate to dynamically change the ratio as needed based on the amount of
replication data in queue. If you set a specific value other than the default (other than 5), the
specified value will be used. Changes to this setting will take effect for future jobs. Existing jobs will
have to be stopped and restarted to pick up the new ratio.
l Maximum pending mirror operations—This option is the maximum number of mirror
operations that are queued on the source. The default setting is 1000. If, during mirroring, the
mirror queued statistic regularly shows low numbers, for example, less than 50, this value can be
increased to allow Carbonite Migrate to queue more data for transfer.
l Size of mirror packets—This option determines the size of the mirror packets, in bytes, that
Carbonite Migrate transmits. The default setting is 65536 bytes. You may want to consider
increasing this value in a high latency environment (greater than 100 ms response times), or if
your data set contains mainly larger files, like databases.
l Calculate size of protected data upon connection—Specify if you want Carbonite Migrate to
determine the mirroring percentage calculation based on the amount of data being protected. If
you enable this option, the calculation will begin when mirroring begins. For the initial mirror, the
percentage will display after the calculation is complete, adjusting to the amount of the mirror that
has completed during the time it took to complete the calculation. Subsequent mirrors will initially
use the last calculated size and display an approximate percentage. Once the calculation is
complete, the percentage will automatically adjust down or up to indicate the amount that has
been completed. Disabling calculation will result in the mirror status not showing the percentage
complete or the number of bytes remaining to be mirrored.

The calculated amount of protected data may be slightly off if your data set contains
compressed or sparse files.

Chapter 4 Managing servers 40

Target server properties
These properties are specific to the target server role.

l Pause mirroring at this level—You can specify the maximum percentage of Windows system
memory that can contain mirror data before the target signals the source to pause the sending of
mirror operations. The default setting is 20.
l Resume mirroring at this level—You can specify the minimum percentage of Windows system
memory that can contain mirror data before the target signals the source to resume the sending of
mirror operations. The default setting is 15. You cannot set the resume value higher than the
pause value.
l Retry delay for incomplete operations—This option specifies the amount of time, in seconds,
before retrying a failed operation on the target. The default setting is 3.

Chapter 4 Managing servers 41

Log file properties
These settings allow you to specify your log file configuration.

l Logging folder—Specify the directory where each of the log files in this section are stored. The
default location is the directory where the Carbonite Migrate program files are installed.
l Messages & Alerts—These settings apply to the service log file.
l Maximum size—Specify the maximum size, in bytes, of the log file. The default size is

10485760 bytes (10 MB). Once the maximum has been reached, a new log file will be
created.
l Maximum number of files—Specify the maximum number of log files that are

maintained. The default is 5, and the maximum is 999. Once the maximum has been
reached, the oldest file will be overwritten.
l Verification—The verification log is created during the verification process and details which files
were verified as well as the files that are synchronized.
l File name—This field contains the base log file name for the verification process. The job

type and a unique identifier will be prefixed to the base log file name. For example, since the
default is DTVerify.log, the verification log for a files and folders job will be Files and
Folders_123456abcdef DTVerify.log.
l Maximum size—Specify the maximum size, in bytes, of the verification log file. The default

is 1048576 bytes (1 MB).

l Append—Enable the Append check box if you want to append each verification process

to the same log file. If this check box is disabled, each verification process that is logged will
overwrite the previous log file. By default, this option is enabled.
l Statistics—The statistics log maintains connection statistics such as mirror bytes in queue or
replication bytes sent. This file is a binary file that is read by the DTStat utility. See the Reference
Guide for details on DTStat.

Chapter 4 Managing servers 42

 l File name—This is the name of the statistics log file. The default file name is statistic.sts.
l Maximum size—Specify the maximum size, in bytes, of the statistics log file. The default is
10485760 bytes (10 MB). Once this maximum has been reached, the oldest data will be
overwritten.
l Write interval—Specify how often, in minutes, Carbonite Migrate writes to the statistics
log file. The default is every 5 minutes.

Chapter 4 Managing servers 43

E-mail notification configuration
You can email Carbonite Migrate event messages to specific addresses using an SMTP mail server.
The subject of the e-mail will contain an optional prefix, the server name where the message was
logged, the message ID, and the severity level (information, warning, or error). The text of the event
message will be displayed in the body of the e-mail message.

l Enable e-mail notification—This option enables the e-mail notification feature. Any specified
notification settings will be retained if this option is disabled.
l E-mail server—Specify the name of your SMTP mail server.
l Log on to e-mail server—If your SMTP server requires authentication, enable this option and
specify the User name and Password to be used for authentication. Your SMTP server must
support the LOGIN authentication method to use this feature. If your server supports a different
authentication method or does not support authentication, you may need to add the Carbonite
Migrate server as an authorized host for relaying e-mail messages. This option is not necessary if
you are sending exclusively to e-mail addresses that the SMTP server is responsible for.
l From address—Specify the e-mail address that you want to appear in the From field of each
Carbonite Migrate e-mail message. The address is limited to 256 characters.
l Send to—Specify the e-mail addresses that each Carbonite Migrate e-mail message should be
sent to. Enter the addresses as a comma or semicolon separated list. Each address is limited to
256 characters. You can add up to 256 e-mail addresses.

Chapter 4 Managing servers 44

 l Subject prefix and Add event description to subject—The subject of each e-mail notification
will be in the format Subject Prefix : Server Name : Message Severity : Message ID : Message
Description. The first and last components (Subject Prefix and Message Description) are optional.
The subject line is limited to 100 characters.
If desired, enter unique text for the Subject prefix which will be inserted at the front of the subject
line for each Carbonite Migrate e-mail message. This will help distinguish Carbonite Migrate
messages from other messages. This field is optional.
If desired, enable Add event description to subject to have the description of the message
appended to the end of the subject line. This field is optional.

When you modify your e-mail notification settings, you will receive a test e-mail
summarizing your new settings. You can also test e-mail notification by clicking Test. By
default, the test will be run from the machine where the console is running. If desired, you
can send the test message to a different e-mail address by selecting Send To and
entering a comma or semicolon separated list of addresses. Modify the Message Text up
to 1024 characters, if necessary. Click Send to test the e-mail notification. The results will
be displayed in a message box.

If an error occurs while sending an e-mail, a message will be generated. This message
will not trigger another e-mail. Subsequent e-mail errors will not generate additional
messages. When an e-mail is sent successfully, a message will then be generated. If
another e-mail fails, one message will again be generated. This is a cyclical process
where one message will be generated for each group of failed e-mail messages, one for
each group of successful e-mail messages, one for the next group of failed messages,
and so on.
If you start and then immediately stop the Double-Take service, you may not get e-mail
notifications for the log entries that occur during startup.
By default, most anti-virus software blocks unknown processes from sending traffic on
port 25. You need to modify the blocking rule so that Carbonite Migrate e-mail messages
are not blocked.

Chapter 4 Managing servers 45

Viewing server logs
You can view the engine and Management Service logs using either of these two methods.
l On the Servers page, highlight a server in the list and click View Server Logs from the toolbar.
l On the Jobs page, right-click a job and select View Logs. Select either the source server log or
the target server log.
Separate logging windows allow you to continue working in the Carbonite Replication Console while
monitoring log messages. You can open multiple logging windows for multiple servers. When the
Carbonite Replication Console is closed, all logging windows will automatically close.

Chapter 4 Managing servers 46

The following table identifies the controls and the table columns in the Server logs window.

Start
This button starts the addition and scrolling of new messages in the window.

Pause
This button pauses the addition and scrolling of new messages in the window. This is
only for the Server logs window. The messages are still logged to their respective files
on the server.

Copy
This button copies the messages selected in the Server logs window to the Windows
clipboard.

Clear
This button clears the Server logs window. The messages are not cleared from the
respective files on the server. If you want to view all of the messages again, close and
reopen the Server logs window.
Filter
From the drop-down list, you can select to view all log messages or only those
messages from the Double-Take log or the Management Service log.
Time
This column in the table indicates the date and time when the message was logged.
Description
This column in the table displays the actual message that was logged.
Service
This column in the table indicates if the message is from the Double-Take log or the
Management Service log.

Chapter 4 Managing servers 47

Managing VMware servers
To manage your VMware servers, select Go, Manage VMware Servers. The Manage VMware
Server page allows you to view, add, remove, or edit credentials for your VMware servers available in
the console.

VMware Server
The name of the VMware server
Full Name
The full name of the VMware server
User Name
The user account being used to access the VMware server

Add VMware Server

Add a new VMware server. When prompted, specify the VMware server and a user
account. If you are using a non-default port for your server, specify the server followed
by a colon and then the port number, for example, 112.47.12.7:85. If your server name
does not match the security certificate or the security certificate has expired, you will be
prompted if you want to install the untrusted security certificate.

Remove Server
Remove the VMware server from the console.

Provide Credentials
Edit credentials for the selected VMware server. When prompted, specify a user
account to access the VMware server.

Chapter 4 Managing servers 48

Chapter 5 Files and folders migration
Create a files and folders migration job when you want to migrate data or file shares. This job type does
not migrate a server's system state.
l Files and folders migration requirements on page 50—Files and folders migration includes
specific requirements for this type of migration.
l Creating a files and folders migration job on page 55—This section includes step-by-step
instructions for creating a files and folders migration job.
l Managing and controlling files and folders migration jobs on page 66—You can view status
information about your files and folders migration job.
l Cutting over files and folders migration jobs on page 85—Use this section when you are ready to
cutover from your source to your target, which contains the data you migrated from your source.

Chapter 5 Files and folders migration 49

Files and folders migration requirements
Use these requirements for files and folder migration.
l Operating system—The servers can be a 64-bit physical or virtual server running any of the
following operating systems.
l Operating system—Red Hat Enterprise Linux, Oracle Enterprise Linux, and CentOS
l Version—6.8 through 6.10

l Kernel type—Default, Unbreakable Enterprise Kernel (UEK)

l File system—Ext3, Ext4, XFS

l Operating system—Red Hat Enterprise Linux, Oracle Enterprise Linux, and CentOS
l Version—7.7 through 7.9

l Kernel type—Default, Unbreakable Enterprise Kernel (UEK)

l File system—Ext3, Ext4, XFS

l Operating system—Red Hat Enterprise Linux, Oracle Enterprise Linux, and CentOS
l Version—8.2 through 8.4

l Kernel type—Default, Unbreakable Enterprise Kernel (UEK)

l File system—Ext3, Ext4, XFS

l Operating system—CloudLinux
l Version—7.9

l Kernel type—Default

l File system—Ext3, Ext4, XFS

l Operating system—SUSE Linux Enterprise

l Version—11.2 through 11.4

l Kernel type—Default, Xen

l File system—Ext3, XFS

l Operating system—SUSE Linux Enterprise

l Version—12.3 through 12.5

l Kernel type—Default

l File system—Ext3, Ext4, XFS, Btrfs

l Notes—If you are planning to convert an existing file system to Btrfs, you must

delete any existing Carbonite Migrate jobs and re-create them after converting to
Btrfs.
l Operating system—SUSE Linux Enterprise
l Version—15.0 through 15.2

l Kernel type—Default

l File system—Ext3, Ext4, XFS, Btrfs

l Notes—If you are planning to convert an existing file system to Btrfs, you must

delete any existing Carbonite Migrate jobs and re-create them after converting to
Btrfs.

Chapter 5 Files and folders migration 50

 l Operating system—Ubuntu
l Version—16.04.5 through 16.04.7

l Kernel type—Generic

l File system—Ext2, Ext3, Ext4, XFS

l Operating system—Ubuntu
l Version—18.04.1 through 18.04.3

l Kernel type—Generic

l File system—Ext2, Ext3, Ext4, XFS

l Operating system—Ubuntu
l Version—20.04.0

l Kernel type—Generic

l File system—Ext2, Ext3, Ext4, XFS

For all operating systems except Ubuntu, the kernel version must match the expected
kernel for the specified release version. For example, if /etc/redhat-release declares the
system to be a Redhat 7.5 system, the kernel that is installed must match that.

Carbonite Migrate does not support stacking filesystems, like eCryptFS.

If Carbonite Migrate does not have the driver binary files for the kernel you are using, they
can be compiled automatically, but you need the build-essential package for them to be
installed. Run apt-get install build-essential to install the build tools and then restart the DT
service. This will build the driver from the source and load it.

l Packages and services—Each Linux server must have the following packages and services
installed before you can install and use Carbonite Migrate. See your operating system
documentation for details on these packages and utilities.
l sshd (or the package that installs sshd)
l lsb

l parted

l dmidecode

l scp

l which

l libnsl (only required for Red Hat Enterprise Linux, Oracle Enterprise Linux, and CentOS

version 8.0 and later)

l System memory—The minimum system memory on each server is 1 GB.
l Disk space for program files—This is the amount of disk space needed for the Carbonite
Migrate program files. This is approximately 400 MB on each Linux server.

Make sure you have additional disk space for Carbonite Migrate queuing, logging, and so
on.

Chapter 5 Files and folders migration 51

 l Server name—Carbonite Migrate includes Unicode file system support, but your server name
must still be in ASCII format. Additionally, all Carbonite Migrate servers must have a unique
server name.
l Protocols and networking—Your servers must meet the following protocol and networking
requirements.
lYour servers must have TCP/IP with static IP addressing.
l IPv4 only configurations are supported, IPv4 and IPv6 are supported in combination,

however IPv6 only configurations are not supported.

l If you are using IPv6 on your servers, your console must be run from an IPv6 capable

machine.
l In order to properly resolve IPv6 addresses to a hostname, a reverse lookup entry should

be made in DNS.
l If you are using Carbonite Migrate over a WAN and do not have DNS name resolution, you

will need to add the host names to the local hosts file on each server running Carbonite
Migrate.
l Because of limitations in the way the Linux kernel handles IP address aliases, do not mix

subnets on the eth0 network interface. Failover should not cause problems in this
configuration, but you will lose IP addresses during failback. Therefore, if you must mix
subnets on a single interface, use eth1 or higher.
l Ubuntu Netplan is supported, however the network configuration on the source and target

should match. If you have a mix of network types (traditional, NetworkManager, or Netplan)
on the source and target, you may have to configure the networking on the target after
cutover.
l NAT support—Carbonite Migrate supports NAT environments with the following caveats.
l Only IPv4 is supported.
l Only standalone servers are supported.

l Make sure you have added your server to the Carbonite Replication Console using the

correct public or private IP address. The name or IP address you use to add a server to the
console is dependent on where you are running the console. Specify the private IP address
of any servers on the same side of the router as the console. Specify the public IP address
of any servers on the other side of the router as the console.
l DNS failover and updates will depend on your configuration

l Only the source or target can be behind a router, not both.

l The DNS server must be routable from the target

l Ports—Port 1501 is used for localhost communication between the engine and management
service and should be opened inbound and outbound for both TCP and UDP in iptables. Ports
1500, 1505, 1506, 6325, and 6326 are used for component communication and must be opened
inbound and outbound for both TCP and UDP on any firewall that might be in use.
l Name resolution—Your servers must have name resolution or DNS. The Carbonite Replication
Console must be able to resolve the target, and the target must be able to resolve all source
servers. For details on name resolution options, see your Linux documentation or online Linux
resources.

Chapter 5 Files and folders migration 52

 l Security—Carbonite Migrate security is granted through membership in user groups. The
groups can be local or LDAP (Lightweight Directory Access Protocol). You must provide a valid
local account or LDAP account that is a member of the Carbonite Migrate security groups.
l Docker—Your source cannot be a Docker host.
l VMware Tools—Any VMWare guest running Carbonite Migrate should have the appropriate
VMWare Tools package installed.
l Hard links—If you have hard links outside of the data set you are migrating, and they link to files
inside the data set you are migrating, Carbonite Migrate will not mirror or replicate the hard links
which could lead to differences on the target.
l Supported configurations—The following table identifies the supported configurations for a
files and folder migration job.

Server Not
Description Supported
Configuration Supported

You can migrate a single source to a

One to one single target. The target has no
X
active/standby production activity. The source is the only
server actively replicating data.
You cannot migrate a single source to a
One to one single target where each server acts as
X
active/active both a source and target actively
replicating data to each other.
You can migrate many source servers to
one target. Replication occurs from each
Many to one source to the one target. This will X
consolidate your source servers to a
single server.
You can migrate a single source to
One to many X
multiple target servers.
You cannot migrate a single source to a
single target, where the target then acts
Chained X
as a source, sending the same data from
the original source to a final target server.
You can migrate a single source to itself
allowing data to be replicated from one
Single server location to another on the same volume X
or to a separate volume on the same
server.
Standalone to Your servers can be in a standalone to
X
standalone standalone configuration.

Chapter 5 Files and folders migration 53

 Server Not
Description Supported
Configuration Supported

Standalone to Your servers cannot be in a standalone to

X
cluster cluster configuration.
Cluster to Your servers cannot be in a cluster to
X
standalone standalone configuration.
Your servers cannot be in a cluster to
Cluster to cluster X
cluster configuration.

Chapter 5 Files and folders migration 54

Creating a files and folders migration job
Use the following instructions to create a files and folders migration job.
1. From the Servers page, right-click the server you want to migrate and select Migrate. You can
also highlight a server, click Create a New Job in the toolbar, then select Migrate.
2. Choose the type of workload that you want to migrate. Under Server Workloads, in the
Workload types pane, select Files and Folders Migration. In the Workload items pane, you
will see the volumes for your source. Select the volumes on the source that you want to migrate.
You can select your files and folders in more detail in the Replication Rules section.

Unsupported file systems will be displayed but will not be accessible.

Chapter 5 Files and folders migration 55

 3. To select your files and folders in more detail, click the Replication Rules heading and expand
the volumes under Folders.

Volumes and folders with a green highlight are included completely. Volumes and folders
highlighted in light yellow are included partially, with individual files or folders included. If there is
no highlight, no part of the volume or folder is included. To modify the items selected, highlight a
volume, folder, or file and click Add Rule. Specify if you want to Include or Exclude the item.
Also, specify if you want the rule to be recursive, which indicates the rule should automatically be
applied to the subdirectories of the specified path. If you do not select Recursive, the rule will not
be applied to subdirectories.
You can also enter wildcard rules, however you should do so carefully. Rules are applied to files
that are closest in the directory tree to them. If you have rules that include multiple folders, an
exclusion rule with a wild card will need to be added for each folder that it needs applied to. For
example, if you want to exclude all .log files from /home and your rules include /home,
/home/folder1, and /home/folder2, you would need to add the exclusion rule for the root and each
subfolder rule. So you will need to add exclude rules for /home/*.log , /home/folder1/*.log, and
/home/folder2/*.log.
If you need to remove a rule, highlight it in the list at the bottom and click Remove Rule. Be
careful when removing rules. Carbonite Migrate may create multiple rules when you are adding
directories. For example, if you add /home/admin to be included in protection, then /home will be
excluded. If you remove the /home exclusion rule, then the /home/admin rule will be removed
also.

If you return to this page using the Back button in the job creation workflow, your
Workload Types selection will be rebuilt, potentially overwriting any manual replication
rules that you specified. If you do return to this page, confirm your Workload Types and
Replication Rules are set to your desired settings before proceeding forward again.

Chapter 5 Files and folders migration 56

 4. Click Next to continue.
5. Choose your target server. This is the server that will receive the migrated data from the source.

l Current Servers—This list contains the servers currently available in your console
session. Servers that are not licensed for the workflow you have selected and those not
applicable to the workload type you have selected will be filtered out of the list. Select your
target server from the list. If the server you are looking for is not displayed, enable Show all
servers. The servers in red are not available for the source server or workload type you
have selected. Hover your mouse over an unavailable server to see a reason why this
server is unavailable.
l Find a New Server—If the server you need is not in the Current Servers list, click the
Find a New Server heading. From here, you can specify a server along with credentials
for logging in to the server. If necessary, you can click Browse to select a server from a
network drill-down list.

If you enter the target server's fully-qualified domain name, the Carbonite Replication
Console will resolve the entry to the server short name. If that short name resides in two
different domains, this could result in name resolution issues. In this case, enter the IP
address of the server.

When specifying credentials for a new server, specify a user that is a member of the local
dtadmin security group.

6. Click Next to continue.

You may be prompted for a route from the target to the source. This route is used so the
target can communicate with the source to build job options. This dialog box will be
displayed only if needed.

Chapter 5 Files and folders migration 57

 7. You have many options available for your files and folders migration job. Configure those options
that are applicable to your environment.
Go to each page identified below to see the options available for that section of the Set Options
page. After you have configured your options, continue with the next step on page 64.
l General on page 58
l Failover Options on page 58
l Mirror, Verify & Orphaned Files on page 59
l Network Route on page 60
l Path Mapping on page 61
l Compression on page 62
l Bandwidth on page 63

General

For the Job name, specify a unique name for your job.

Failover Options

l Wait for user to initiate failover—The cutover process can wait for you to initiate it,
allowing you to control when cutover occurs. When a cutover occurs, the job will wait in the
Protecting state for you to manually initiate the cutover process. Disable this option if you
want cutover to occur immediately after the mirror is complete.
l Shutdown source server—Specify if you want to shut down the source server, if it is still
running, before the source is cutover to the target, This option prevents identity conflicts on
the network in those cases where the source and target are still both running and
communicating.
l Target Scripts—You can customize cutover by running scripts on the target. Scripts may
contain any valid Linux command, executable, or shell script file. The scripts are processed
using the same account running the Double-Take Management service. Examples of
functions specified in scripts include stopping services on the target before cutover because
they may not be necessary, stopping services on the target that need to be restarted with

Chapter 5 Files and folders migration 58

 the source’s machine name and/or IP address, starting services or loading applications that
are in an idle, standby mode waiting for cutover to occur, notifying the administrator before
and after cutover occurs, and so on. There are two types of cutover scripts.
l Pre-failover script—This script runs on the target at the beginning of the cutover
process. Specify the full path and name of the script file.
l Delay until script completes—Enable this option if you want to delay the cutover
process until the associated script has completed. If you select this option, make sure
your script handles errors, otherwise the cutover process may never complete if the
process is waiting on a script that cannot complete.
l Post-failover script—This script runs on the target at the end of the cutover
process. Specify the full path and name of the script file.
l Arguments—Specify a comma-separated list of valid arguments required to
execute the script.

Mirror, Verify & Orphaned Files

l Mirror Options—Choose a comparison method and whether to mirror the entire file or
only the bytes that differ in each file.
l Do not compare files. Send the entire file.—Carbonite Migrate will not perform
any comparisons between the files on the source and target. All files will be mirrored
to the target, sending the entire file. This option requires no time for comparison, but
the mirror time can be slower because it sends the entire file. However, it is useful for
configurations that have large data sets with millions of small files that are frequently
changing and it is more efficient to send the entire file. You may also need to use this
option if configuration management policies require sending the entire file.
l Compare file attributes. Send the entire file.—Carbonite Migrate will compare
file attributes and will mirror those files that have different attributes, sending the
entire file. This option is the fastest comparison method, but the mirror time can be
slower because it sends the entire file. However, it is useful for configurations that
have large data sets with millions of small files that are mostly static and not
changing. You may also need to use this option if configuration management policies
require sending the entire file.
l Compare file attributes. Send the attributes and bytes that differ.—Carbonite
Migrate will compare file attributes and will mirror only the attributes and bytes that
are different. This option is the fastest comparison method and fastest mirror speed.
Files that have not changed can be easily skipped. Also files that are open and
require a checksum mirror can be compared.
l Compare file attributes and data. Send the attributes and bytes that differ.—
Carbonite Migrate will compare file attributes and the file data and will mirror only the
attributes and bytes that are different. This comparison method is not as fast because

Chapter 5 Files and folders migration 59

 every file is compared, regardless of whether the file has changed or is open.
However, sending only the attributes and bytes that differ is the fastest mirror speed.

If a file is small enough that mirroring the entire file is faster than comparing it and
then mirroring it, Carbonite Availability will automatically mirror the entire file.

l General Options—Choose your general mirroring options.

l Delete orphaned files—An orphaned file is a file that exists in the replica data on
the target, but does not exist in the protected data on the source. This option
specifies if orphaned files should be deleted on the target.

Orphaned file configuration is a per target configuration. All jobs to the same
target will have the same orphaned file configuration.

If delete orphaned files is enabled, carefully review any replication rules that
use wildcard definitions. If you have specified wildcards to be excluded from
protection, files matching those wildcards will also be excluded from
orphaned file processing and will not be deleted from the target. However, if
you have specified wildcards to be included in your protection, those files that
fall outside the wildcard inclusion rule will be considered orphaned files and
will be deleted from the target.

Network Route

By default, Carbonite Migrate will select an IP address on the target for transmissions. If desired,
specify an alternate route on the target that the data will be transmitted through. This allows you to
select a different route for Carbonite Migrate traffic. For example, you can separate regular
network traffic and Carbonite Migrate traffic on a machine with multiple IP addresses. You can
also select or manually enter a public IP address (which is the public IP address of the server's
router) if you are using a NAT environment.

If you change the IP address on the target which is used for the target route, you will be
unable to edit the job. If you need to make any modifications to the job, it will have to be
deleted and re-created.

Chapter 5 Files and folders migration 60

 Path Mapping

l Mappings—Specify the location on the target where the replica of the source data will be
stored. By default, the replica source data will be stored in the same directory structure on
the target. Make sure you update this location if you are protecting multiple sources or jobs
to the same target. You have two pre-defined locations as well as a custom option that
allows you to set your path.

l All To One—Click this button to set the mapping so that the replica source data will
be stored on a single volume on the target. The pre-defined path is /source_
name/volume_name. If you are protecting multiple volumes on the source, each
volume would be stored on the same volume on the target.
l One To One—Click this button to set the mapping so that the replica source data will
be stored in the same directory structure on the target. For example, /data and /home
will be stored in /data and /home, respectively, on the target.
l Custom Location—If the pre-defined options do not store the data in a location that
is appropriate for your network operations, you can specify your own custom location
where the replica source data will be stored. Click the Target Path and edit it,
selecting the appropriate location.

If you are protecting system state data , you must select the All to One mapping or
specify a customized location in order to avoid sharing violations. Keep in mind that
this mapping will avoid sharing violations on the target, however during a
restoration, you will get sharing violations on the source because the restoration
mapping is one to one and your system state files will be in use on the source you
are restoring to. In this case, restoration will never complete. If you will need to
restore data and you must protect system state data, you should use a full server
job.

Chapter 5 Files and folders migration 61

 Compression

To help reduce the amount of bandwidth needed to transmit Carbonite Migrate data, compression
allows you to compress data prior to transmitting it across the network. In a WAN environment this
provides optimal use of your network resources. If compression is enabled, the data is
compressed before it is transmitted from the source. When the target receives the compressed
data, it decompresses it and then writes it to disk. You can set the level from Minimum to
Maximum to suit your needs.
Keep in mind that the process of compressing data impacts processor usage on the source. If you
notice an impact on performance while compression is enabled in your environment, either adjust
to a lower level of compression, or leave compression disabled. Use the following guidelines to
determine whether you should enable compression.
l If data is being queued on the source at any time, consider enabling compression.
l If the server CPU utilization is averaging over 85%, be cautious about enabling
compression.
l The higher the level of compression, the higher the CPU utilization will be.
l Do not enable compression if most of the data is inherently compressed. Many image (.jpg,
.gif) and media (.wmv, .mp3, .mpg) files, for example, are already compressed. Some
images files, such as .bmp and .tif, are decompressed, so enabling compression would be
beneficial for those types.
l Compression may improve performance even in high-bandwidth environments.
l Do not enable compression in conjunction with a WAN Accelerator. Use one or the other to
compress Carbonite Migrate data.

All jobs from a single source connected to the same IP address on a target will share the
same compression configuration.

Chapter 5 Files and folders migration 62

 Bandwidth

Bandwidth limitations are available to restrict the amount of network bandwidth used for
Carbonite Migrate data transmissions. When a bandwidth limit is specified, Carbonite Migrate
never exceeds that allotted amount. The bandwidth not in use by Carbonite Migrate is available
for all other network traffic.

All jobs from a single source connected to the same IP address on a target will share the
same bandwidth configuration.

l Do not limit bandwidth—Carbonite Migrate will transmit data using 100% bandwidth
availability.
l Use a fixed limit—Carbonite Migrate will transmit data using a limited, fixed bandwidth.
Select a Preset bandwidth limit rate from the common bandwidth limit values. The
Bandwidth field will automatically update to the bytes per second value for your selected
bandwidth. This is the maximum amount of data that will be transmitted per second. If
desired, modify the bandwidth using a bytes per second value. The minimum limit should be
3500 bytes per second.
l Use scheduled limits—Carbonite Migrate will transmit data using a dynamic bandwidth
based on the schedule you configure. Bandwidth will not be limited during unscheduled
times.
l New—Click New to create a new scheduled bandwidth limit. Specify the following

information.
l Daytime entry—Select this option if the start and end times of the bandwidth

window occur in the same day (between 12:01 AM and midnight). The start
time must occur before the end time.
l Overnight entry—Select this option if the bandwidth window begins on one

day and continues past midnight into the next day. The start time must be later
than the end time, for example 6 PM to 6 AM.
l Day—Enter the day on which the bandwidth limiting should occur. You can

pick a specific day of the week, Weekdays to have the limiting occur Monday
through Friday, Weekends to have the limiting occur Saturday and Sunday, or
Every day to have the limiting repeat on all days of the week.
l Start time—Enter the time to begin bandwidth limiting.

l End time—Enter the time to end bandwidth limiting.

l Preset bandwidth—Select a bandwidth limit rate from the common

bandwidth limit values. The Bandwidth field will automatically update to the
bytes per second value for your select bandwidth.
l Bandwidth—If desired, modify the bandwidth using a bytes per second value.

The minimum limit should be 3500 bytes per second.

Chapter 5 Files and folders migration 63

 l Edit—Click Edit to modify an existing scheduled bandwidth limit.
l Delete—Click Delete to remove a scheduled bandwidth limit.

If you change your job option from Use scheduled limits to Do not limit
bandwidth or Use a fixed limit, any schedule that you created will be preserved.
That schedule will be reused if you change your job option back to Use scheduled
limits.

You can manually override a schedule after a job is established by selecting Other
Job Options, Set Bandwidth. If you select No bandwidth limit or Fixed
bandwidth limit, that manual override will be used until you go back to your
schedule by selecting Other Job Options, Set Bandwidth, Scheduled
bandwidth limit. For example, if your job is configured to use a daytime limit, you
would be limited during the day, but not at night. But if you override that, your
override setting will continue both day and night, until you go back to your schedule.
See the Managing and controlling jobs section for your job type for more
information on the Other Job Options.

8. Click Next to continue.

9. Carbonite Migrate validates that your source and target are compatible. The Summary page
displays your options and validation items.
Errors are designated by a white X inside a red circle. Warnings are designated by a black
exclamation point (!) inside a yellow triangle. A successful validation is designated by a white
checkmark inside a green circle. Errors are sorted at the top of the list, then warnings, then
success messages. Click on any of the validation items to see details. You must correct any errors
before you can continue. Depending on the error, you may be able to click Fix or Fix All and let
Carbonite Migrate correct the problem for you. For those errors that Carbonite Migrate cannot
correct automatically, you will need to modify the source or target to correct the error, or you can
select a different target. You must revalidate the selected servers, by clicking Recheck, until the
validation check passes without errors. Click the Common Job Validation Warnings and
Errors link to open a web browser and view solutions to common validation warnings and errors.
If you receive a path transformation error during job validation indicating a volume does not exist
on the target server, even though there is no corresponding data being protected on the source,
you will need to manually modify your replication rules. Go back to the Choose Data page and
under the Replication Rules, locate the volume from the error message. Remove any rules
associated with that volume. Complete the rest of the workflow and the validation should pass.
After a job is created, the results of the validation checks are logged to the job log. See the
Carbonite Availability and Carbonite Migrate Reference Guide for details on the various
Carbonite Migrate log files.
10. Once your servers have passed validation and you are ready to begin migration, click Finish, and
you will automatically be taken to the Jobs page.

Jobs in a NAT environment may take longer to start.

Once a job is created, do not change the name of underlying hardware components used in the
job. For example, volume names, network adapter names, or virtual switch names. Any
component used by name in your job must continue to use that name throughout the lifetime of

Chapter 5 Files and folders migration 64

 job. If you must change a name, you will need to delete the job and re-create it using the new
component name.

Chapter 5 Files and folders migration 65

Managing and controlling files and folders migration
jobs
Click Jobs from the main Carbonite Replication Console toolbar. The Jobs page allows you to view
status information about your jobs. You can also control your jobs from this page.
The jobs displayed in the right pane depend on the server group folder selected in the left pane. Every
job for each server in your console session is displayed when the Jobs on All Servers group is
selected. If you have created and populated server groups (see Managing servers on page 15), then
only the jobs associated with the server or target servers in that server group will be displayed in the right
pane.
l Overview job information displayed in the top right pane on page 66
l Detailed job information displayed in the bottom right pane on page 69
l Job controls on page 71

Overview job information displayed in the top right pane

The top pane displays high-level overview information about your jobs. You can sort the data within a
column in ascending and descending order. You can also move the columns to the left or right of each
other to create your desired column order. The list below shows the columns in their default left to right
order.
If you are using server groups, you can filter the jobs displayed in the top right pane by expanding the
Server Groups heading and selecting a server group.

Column 1 (Blank)
The first blank column indicates the state of the job.

A green circle with a white checkmark indicates the job is in a healthy state. No
action is required.

A yellow triangle with a black exclamation point indicates the job is in a pending or
warning state. This icon is also displayed on any server groups that you have created
that contain a job in a pending or warning state. Carbonite Migrate is working or waiting
on a pending process or attempting to resolve the warning state.

A red circle with a white X indicates the job is in an error state. This icon is also
displayed on any server groups that you have created that contain a job in an error
state. You will need to investigate and resolve the error.

The job is in an unknown state.

Job
The name of the job

Chapter 5 Files and folders migration 66

Source Server
The name of the source. This could be the name or IP address of your source.
Target Server
The name of the target. This could be the name or IP address of your target.
Job Type
Each job type has a unique job type name. This job is a Files and Folders Migration job.
For a complete list of all job type names, press F1 to view the Carbonite Replication
Console online help.
Activity
There are many different Activity messages that keep you informed of the job activity.
Most of the activity messages are informational and do not require any administrator
interaction. If you see error messages, check the job details. Keep in mind that Idle
indicates console to server activity is idle, not that your servers are idle.
Mirror Status
l Calculating—The amount of data to be mirrored is being calculated.
l In Progress—Data is currently being mirrored.
l Waiting—Mirroring is complete, but data is still being written to the target.
l Idle—Data is not being mirrored.
l Paused—Mirroring has been paused.
l Stopped—Mirroring has been stopped.
l Removing Orphans—Orphan files on the target are being removed or deleted
depending on the configuration.
l Verifying—Data is being verified between the source and target.
l Unknown—The console cannot determine the status.
Replication Status
l Replicating—Data is being replicated to the target.
l Ready—There is no data to replicate.
l Pending—Replication is pending.
l Stopped—Replication has been stopped.
l Out of Memory—Replication memory has been exhausted.
l Failed—The Double-Take service is not receiving replication operations from the
Carbonite Migrate driver. Check the Event Viewer for driver related issues.
l Unknown—The console cannot determine the status.
Transmit Mode
l Active—Data is being transmitted to the target.
l Paused—Data transmission has been paused.
l Scheduled—Data transmission is waiting on schedule criteria.
l Stopped—Data is not being transmitted to the target.

Chapter 5 Files and folders migration 67

 l Error—There is a transmission error.
l Unknown—The console cannot determine the status.
Operating System
The job type operating system

Chapter 5 Files and folders migration 68

Detailed job information displayed in the bottom right pane
The details displayed in the bottom pane provide additional information for the job highlighted in the top
pane. You can expand or collapse the bottom pane by clicking on the Job Highlights heading.

Name
The name of the job
Target data state
l OK—The data on the target is in a good state.
l Mirroring—The target is in the middle of a mirror process. The data will not be in a
good state until the mirror is complete.
l Mirror Required—The data on the target is not in a good state because a remirror
is required. This may be caused by an incomplete or stopped mirror or an operation
may have been dropped on the target.
l Busy—The source is low on memory causing a delay in getting the state of the data
on the target.
l Not Loaded—Carbonite Migrate target functionality is not loaded on the target
server. This may be caused by a license key error.
l Not Ready—The Linux drivers have not yet completed loading on the target.
l Unknown—The console cannot determine the status.
Mirror remaining
The total number of mirror bytes that are remaining to be sent from the source to the
target.
Mirror skipped
The total number of bytes that have been skipped when performing a difference mirror.
These bytes are skipped because the data is not different on the source and target.
Replication queue
The total number of replication bytes in the source queue
Disk queue
The amount of disk space being used to queue data on the source
Recovery point latency
The length of time replication is behind on the target compared to the source. This is the
time period of replication data that would be lost if a failure were to occur at the current
time. This value represents replication data only and does not include mirroring data. If
you are mirroring and failover, the data on the target will be at least as far behind as the
recovery point latency. It could potentially be further behind depending on the
circumstances of the mirror. If mirroring is idle and you failover, the data will only be as
far behind as the recovery point latency time.

Chapter 5 Files and folders migration 69

Bytes sent
The total number of mirror and replication bytes that have been transmitted to the
target
Bytes sent (compressed)
The total number of compressed mirror and replication bytes that have been
transmitted to the target. If compression is disabled, this statistic will be the same as
Bytes sent.
Connected since
The date and time indicating when the current job was started. This is the current time
where the console is running.
Recent activity
Displays the most recent activity for the selected job, along with an icon indicating the
success or failure of the last initiated activity. Click the link to see a list of recent activities
for the selected job. You can highlight an activity in the list to display additional details
about the activity.
Additional information
Depending on the current state of your job, you may see additional information
displayed to keep you informed about the progress and status of your job. If there is no
additional information, you will see (None) displayed. Click the Why are file write
operations retrying link to open a web browser and view solutions to common
causes of retrying file write operations.

Chapter 5 Files and folders migration 70

Job controls
You can control your job through the toolbar buttons available on the Jobs page. If you select multiple
jobs, some of the controls will apply only to the first selected job, while others will apply to all of the
selected jobs. For example, View Job Details will only show details for the first selected job, while Stop
will stop protection for all of the selected jobs.
If you want to control just one job, you can also right click on that job and access the controls from the
pop-up menu.

View Job Details

This button leaves the Jobs page and opens the View Job Details page.

Edit Job Properties

This button leaves the Jobs page and opens the Edit Job Properties page.

Delete
Stops (if running) and deletes the selected jobs.

Provide Credentials
Changes the login credentials that the job (which is on the target machine) uses to
authenticate to the servers in the job. This button opens the Provide Credentials dialog
box where you can specify the new account information and which servers you want to
update.

View Recent Activity

Displays the recent activity list for the selected job. Highlight an activity in the list to
display additional details about the activity.

Start
Starts or resumes the selected jobs.
If you have previously stopped protection, the job will restart mirroring and replication.
If you have previously paused protection, the job will continue mirroring and replication
from where it left off, as long as the Carbonite Migrate queue was not exhausted during
the time the job was paused. If the Carbonite Migrate queue was exhausted during the
time the job was paused, the job will restart mirroring and replication.
Also if you have previously paused protection, all jobs from the same source to the
same IP address on the target will be resumed.

Chapter 5 Files and folders migration 71

Pause
Pauses the selected jobs. Data will be queued on the source while the job is paused.
All jobs from the same source to the same IP address on the target will be paused.

Stop
Stops the selected jobs. The jobs remain available in the console, but there will be no
mirroring or replication data transmitted from the source to the target. Mirroring and
replication data will not be queued on the source while the job is stopped, requiring a
remirror when the job is restarted. The type of remirror will depend on your job settings.

Take Snapshot
Snapshots are not applicable to migration jobs.

Manage Snapshots
Snapshots are not applicable to migration jobs.

Failover or Cutover
Starts the cutover process. See Cutting over files and folders migration jobs on page 85
for the process and details of cutting over a files and folders migration job.

Failback

Restore

Reverse
Reverses protection. Reverse protection does not apply to migration jobs.

Undo Failover or Cutover

Cancels a test cutover by undoing it. Undo failover does not apply to files and folders
migration jobs.

View Job Log

Opens the job log. On the right-click menu, this option is called View Logs, and you
have the option of opening the job log, source server log, or target server log.

Other Job Actions

Opens a small menu of other job actions. These job actions will be started immediately,
but keep in mind that if you stop and restart your job, the job's configured settings will

Chapter 5 Files and folders migration 72

 override any other job actions you may have initiated.
l Mirroring—You can start, stop, pause and resume mirroring for any job that is
running.
When pausing a mirror, Carbonite Migrate stops queuing mirror data on the source
but maintains a pointer to determine what information still needs to be mirrored to
the target. Therefore, when resuming a paused mirror, the process continues where
it left off.
When stopping a mirror, Carbonite Migrate stops queuing mirror data on the source
and does not maintain a pointer to determine what information still needs to be
mirrored to the target. Therefore, when starting a mirror that has been stopped, you
will need to decide what type of mirror to perform.
l Mirror Options—Choose a comparison method and whether to mirror the
entire file or only the bytes that differ in each file.
l Do not compare files. Send the entire file.—Carbonite Migrate will
not perform any comparisons between the files on the source and
target. All files will be mirrored to the target, sending the entire file. This
option requires no time for comparison, but the mirror time can be
slower because it sends the entire file. However, it is useful for
configurations that have large data sets with millions of small files that
are frequently changing and it is more efficient to send the entire file.
You may also need to use this option if configuration management
policies require sending the entire file.
l Compare file attributes. Send the entire file.—Carbonite Migrate
will compare file attributes and will mirror those files that have different
attributes, sending the entire file. This option is the fastest comparison
method, but the mirror time can be slower because it sends the entire
file. However, it is useful for configurations that have large data sets
with millions of small files that are mostly static and not changing. You
may also need to use this option if configuration management policies
require sending the entire file.
l Compare file attributes. Send the attributes and bytes that
differ.—Carbonite Migrate will compare file attributes and will mirror
only the attributes and bytes that are different. This option is the fastest
comparison method and fastest mirror speed. Files that have not
changed can be easily skipped. Also files that are open and require a
checksum mirror can be compared.
l Compare file attributes and data. Send the attributes and bytes
that differ.—Carbonite Migrate will compare file attributes and the file
data and will mirror only the attributes and bytes that are different. This
comparison method is not as fast because every file is compared,
regardless of whether the file has changed or is open. However,
sending only the attributes and bytes that differ is the fastest mirror
speed.

Chapter 5 Files and folders migration 73

 If a file is small enough that mirroring the entire file is faster than
comparing it and then mirroring it, Carbonite Availability will
automatically mirror the entire file.

l Calculate size of protected data before mirroring—Specify if you want

Carbonite Migrate to determine the mirroring percentage calculation based
on the amount of data being protected. If you enable this option, the
calculation will begin when mirroring begins. For the initial mirror, the
percentage will display after the calculation is complete, adjusting to the
amount of the mirror that has completed during the time it took to complete the
calculation. Subsequent mirrors will initially use the last calculated size and
display an approximate percentage. Once the calculation is complete, the
percentage will automatically adjust down or up to indicate the amount that
has been completed. Disabling calculation will result in the mirror status not
showing the percentage complete or the number of bytes remaining to be
mirrored.

The calculated amount of protected data may be slightly off if your

data set contains compressed or sparse files.

l Verify—Even if you have scheduled the verification process, you can run it manually
any time a mirror is not in progress.
l Report only—Select this option if you only want to generate a verification

report. With this option, no data that is found to be different will be mirrored to
the target. Choose how you want the verification to compare the files.
l Report and mirror files—Select this option if you want to generate a
verification report and mirror data that is different to the target. Select the
comparison method and type of mirroring you want to use. See the previous
mirroring methods described under Mirror Options.
l Set Bandwidth—You can manually override bandwidth limiting settings configured
for your job at any time.
l No bandwidth limit—Carbonite Migrate will transmit data using 100%

bandwidth availability.
l Fixed bandwidth limit—Carbonite Migrate will transmit data using a limited,

fixed bandwidth. Select a Preset bandwidth limit rate from the common
bandwidth limit values. The Bandwidth field will automatically update to the
bytes per second value for your selected bandwidth. This is the maximum
amount of data that will be transmitted per second. If desired, modify the
bandwidth using a bytes per second value. The minimum limit should be 3500
bytes per second.
l Scheduled bandwidth limit—If your job has a configured scheduled

bandwidth limit, you can enable that schedule with this option.
l Delete Orphans—Even if you have enabled orphan file removal during your mirror
and verification processes, you can manually remove them at any time.

Chapter 5 Files and folders migration 74

 l Target—You can pause the target, which queues any incoming Carbonite Migrate
data from the source on the target. All active jobs to that target will complete the
operations already in progress. Any new operations will be queued on the target
until the target is resumed. The data will not be committed until the target is
resumed. Pausing the target only pauses Carbonite Migrate processing, not the
entire server.
While the target is paused, the Carbonite Migrate target cannot queue data
indefinitely. If the target queue is filled, data will start to queue on the source. If the
source queue is filled, Carbonite Migrate will automatically disconnect the
connections and attempt to reconnect them.
If you have multiple jobs to the same target, all jobs from the same source will be
paused and resumed.
l Refresh Status—Refreshes the job status immediately.
Filter
Select a filter option from the drop-down list to only display certain jobs. You can display
Healthy jobs, Jobs with warnings, or Jobs with errors. To clear the filter, select
All jobs. If you have created and populated server groups, then the filter will only apply
to the jobs associated with the server or target servers in that server group. See
Managing servers on page 15.
Search
Allows you to search the source or target server name for items in the list that match the
criteria you have entered.

Overflow Chevron
Displays any toolbar buttons that are hidden from view when the window size is
reduced.

Chapter 5 Files and folders migration 75

Viewing files and folders migration job details
From the Jobs page, highlight the job and click View Job Details in the toolbar.
Review the following table to understand the detailed information about your job displayed on the View
Job Details page.

Job name
The name of the job
Job type
Each job type has a unique job type name. This job is a Files and Folders Migration job.
For a complete list of all job type names, press F1 to view the Carbonite Replication
Console online help.
Health

The job is in a healthy state.

The job is in a warning state.

The job is in an error state.

The job is in an unknown state.

Activity
There are many different Activity messages that keep you informed of the job activity.
Most of the activity messages are informational and do not require any administrator
interaction. If you see error messages, check the rest of the job details.
Connection ID
The incremental counter used to number connections. The number is incremented
when a connection is created. The counter is reset if there are no existing jobs and the
Double-Take service is restarted.
Transmit mode
l Active—Data is being transmitted to the target.
l Paused—Data transmission has been paused.
l Scheduled—Data transmission is waiting on schedule criteria.
l Stopped—Data is not being transmitted to the target.
l Error—There is a transmission error.
l Unknown—The console cannot determine the status.

Chapter 5 Files and folders migration 76

Target data state
l OK—The data on the target is in a good state.
l Mirroring—The target is in the middle of a mirror process. The data will not be in a
good state until the mirror is complete.
l Mirror Required—The data on the target is not in a good state because a remirror
is required. This may be caused by an incomplete or stopped mirror or an operation
may have been dropped on the target.
l Busy—The source is low on memory causing a delay in getting the state of the data
on the target.
l Not Loaded—Carbonite Migrate target functionality is not loaded on the target
server. This may be caused by a license key error.
l Not Ready—The Linux drivers have not yet completed loading on the target.
l Unknown—The console cannot determine the status.
Target route
The IP address on the target used for Carbonite Migrate transmissions.
Compression
l On / Level—Data is compressed at the level specified.
l Off—Data is not compressed.
Encryption
l On—Data is being encrypted before it is sent from the source to the target.
l Off—Data is not being encrypted before it is sent from the source to the target.
Bandwidth limit
If bandwidth limiting has been set, this statistic identifies the limit. The keyword
Unlimited means there is no bandwidth limit set for the job.
Connected since
The source server date and time indicating when the current job was started. This field
is blank, indicating that a TCP/IP socket is not present, when the job is waiting on
transmit options or if the transmission has been stopped. This field will maintain the
date and time, indicating that a TCP/IP socket is present, when transmission has been
paused.
Additional information
Depending on the current state of your job, you may see additional information
displayed to keep you informed about the progress and status of your job. If there is no
additional information, you will see (None) displayed. Click the Why are file write
operations retrying link to open a web browser and view solutions to common
causes of retrying file write operations.

Chapter 5 Files and folders migration 77

Mirror status
l Calculating—The amount of data to be mirrored is being calculated.
l In Progress—Data is currently being mirrored.
l Waiting—Mirroring is complete, but data is still being written to the target.
l Idle—Data is not being mirrored.
l Paused—Mirroring has been paused.
l Stopped—Mirroring has been stopped.
l Removing Orphans—Orphan files on the target are being removed or deleted
depending on the configuration.
l Verifying—Data is being verified between the source and target.
l Unknown—The console cannot determine the status.
Mirror percent complete
The percentage of the mirror that has been completed
Mirror remaining
The total number of mirror bytes that are remaining to be sent from the source to the
target.
Mirror skipped
The total number of bytes that have been skipped when performing a difference mirror.
These bytes are skipped because the data is not different on the source and target.
Replication status
l Replicating—Data is being replicated to the target.
l Ready—There is no data to replicate.
l Pending—Replication is pending.
l Stopped—Replication has been stopped.
l Out of Memory—Replication memory has been exhausted.
l Failed—The Double-Take service is not receiving replication operations from the
Carbonite Migrate driver. Check the Event Viewer for driver related issues.
l Unknown—The console cannot determine the status.
Replication queue
The total number of replication bytes in the source queue
Disk queue
The amount of disk space being used to queue data on the source
Bytes sent
The total number of mirror and replication bytes that have been transmitted to the
target

Chapter 5 Files and folders migration 78

Bytes sent compressed
The total number of compressed mirror and replication bytes that have been
transmitted to the target. If compression is disabled, this statistic will be the same as
Bytes sent.
Recovery point latency
The length of time replication is behind on the target compared to the source. This is the
time period of replication data that would be lost if a failure were to occur at the current
time. This value represents replication data only and does not include mirroring data. If
you are mirroring and failover, the data on the target will be at least as far behind as the
recovery point latency. It could potentially be further behind depending on the
circumstances of the mirror. If mirroring is idle and you failover, the data will only be as
far behind as the recovery point latency time.
Mirror start time
The UTC time when mirroring started
Mirror end time
The UTC time when mirroring ended
Total time for last mirror
The length of time it took to complete the last mirror process

Chapter 5 Files and folders migration 79

Validating a files and folders migration job
Over time, you may want to confirm that any changes in your network or environment have not impacted
your Carbonite Migrate job. Use these instructions to validate an existing job.
1. From the Jobs page, highlight the job and click View Job Details in the toolbar.
2. In the Tasks area on the right on the View Job Details page, click Validate job properties.
3. Carbonite Migrate validates that your source and target are compatible. The Summary page
displays your options and validation items.
Errors are designated by a white X inside a red circle. Warnings are designated by a black
exclamation point (!) inside a yellow triangle. A successful validation is designated by a white
checkmark inside a green circle. Errors are sorted at the top of the list, then warnings, then
success messages. Click on any of the validation items to see details. You must correct any errors
before you can continue. Depending on the error, you may be able to click Fix or Fix All and let
Carbonite Migrate correct the problem for you. For those errors that Carbonite Migrate cannot
correct automatically, you will need to modify the source or target to correct the error, or you can
select a different target. You must revalidate the selected servers, by clicking Recheck, until the
validation check passes without errors. Click the Common Job Validation Warnings and
Errors link to open a web browser and view solutions to common validation warnings and errors.
Validation checks for an existing job are logged to the job log on the target server.
4. Once your servers have passed validation, click Close.

Chapter 5 Files and folders migration 80

Editing a files and folders migration job
Use these instructions to edit a files and folders migration job.
1. From the Jobs page, highlight the job and click Edit Job Properties in the toolbar. (You will not
be able to edit a job if you have removed the source of that job from your Carbonite Replication
Console session or if you only have Carbonite Migrate monitor security access.)
2.
Changing some options may require Carbonite Migrate to automatically disconnect,
reconnect, and remirror the job.

If you have specified replication rules that exclude a volume at the root, that volume will be
incorrectly added as an inclusion if you edit the job after it has been established. If you
need to edit your job, modify the replication rules to make sure they include the proper
inclusion and exclusion rules that you want.

3. If you want to modify the workload items or replication rules for the job, click Edit workload or
replication rules. Modify the Workload item you are protecting, if desired. Additionally, you can
modify the specific Replication Rules for your job.
Click OK to return to the Edit Job Properties page.

If you remove data from your workload and that data has already been sent to the target,
you will need to manually remove that data from the target. Because the data you
removed is no longer included in the replication rules, Carbonite Migrate orphan file
detection cannot remove the data for you. Therefore, you have to remove it manually.

4. Click Next to continue.

5. Carbonite Migrate validates that your source and target are compatible. The Summary page
displays your options and validation items.
Errors are designated by a white X inside a red circle. Warnings are designated by a black
exclamation point (!) inside a yellow triangle. A successful validation is designated by a white
checkmark inside a green circle. Errors are sorted at the top of the list, then warnings, then
success messages. Click on any of the validation items to see details. You must correct any errors
before you can continue. Depending on the error, you may be able to click Fix or Fix All and let
Carbonite Migrate correct the problem for you. For those errors that Carbonite Migrate cannot
correct automatically, you will need to modify the source or target to correct the error, or you can
select a different target. You must revalidate the selected servers, by clicking Recheck, until the
validation check passes without errors. Click the Common Job Validation Warnings and
Errors link to open a web browser and view solutions to common validation warnings and errors.
If you receive a path transformation error during job validation indicating a volume does not exist
on the target server, even though there is no corresponding data being protected on the source,
you will need to manually modify your replication rules. Go back to the Choose Data page and
under the Replication Rules, locate the volume from the error message. Remove any rules
associated with that volume. Complete the rest of the workflow and the validation should pass.

Chapter 5 Files and folders migration 81

 After a job is created, the results of the validation checks are logged to the job log. See the
Carbonite Availability and Carbonite Migrate Reference Guide for details on the various
Carbonite Migrate log files.
6. Once your servers have passed validation and you are ready to update your job, click Finish.

Chapter 5 Files and folders migration 82

Viewing a files and folders migration job log
You can view a job log file through the Carbonite Replication Console by selecting View Job Log from
the toolbar on the Jobs page. Separate logging windows allow you to continue working in the Carbonite
Replication Console while monitoring log messages. You can open multiple logging windows for
multiple jobs. When the Carbonite Replication Console is closed, all logging windows will automatically
close.

Because the job log window communicates with the target server, if the console loses
communication with the target server after the job log window has already been opened, the job
log window will display an error.

The following table identifies the controls and the table columns in the Job logs window.

Start
This button starts the addition and scrolling of new messages in the window.

Pause
This button pauses the addition and scrolling of new messages in the window. This is
only for the Job logs window. The messages are still logged to their respective files on
the server.

Chapter 5 Files and folders migration 83

Copy
This button copies the messages selected in the Job logs window to the Windows
clipboard.

Clear
This button clears the Job logs window. The messages are not cleared from the
respective files on the server. If you want to view all of the messages again, close and
reopen the Job logs window.
Time
This column in the table indicates the date and time when the message was logged.
Description
This column in the table displays the actual message that was logged.

Chapter 5 Files and folders migration 84

Cutting over files and folders migration jobs
When the migration mirror has completed, the migration job may or may not terminate automatically
depending on your selection for user intervention. If you disabled user intervention, the migration job will
automatically terminate to complete the migration process. If you enabled user intervention, when the
migration mirror is complete, the status will change to Protecting. Use this time to complete any
necessary tasks. When you are ready to complete the migration, use the following instructions to
cutover.
1. On the Jobs page, highlight the job that you want to cutover and click Failover or Cutover in the
toolbar.
2. Select the type of cutover to perform.
l Cutover live data—Select this option to initiate a full, live cutover using the current data on

the target. The source may be automatically shut down if it is still running, depending on
your job configuration.
l Perform test cutover—This option is not applicable to files and folders migration jobs.

l Cutover to a snapshot—This option is not available for migration jobs.

3. Select how you want to handle the data in the target queue.
l Apply data in target queues before failover or cutover—All of the data in the target

queue will be applied before cutover begins. The advantage to this option is that all of the
data that the target has received will be applied before cutover begins. The disadvantage to
this option is depending on the amount of data in queue, the amount of time to apply all of
the data could be lengthy.
l Discard data in the target queues and failover or cutover immediately—All of the

data in the target queue will be discarded and cutover will begin immediately. The
advantage to this option is that cutover will occur immediately. The disadvantage is that any
data in the target queue will be lost.
4. When you are ready to begin cutover, click Failover.

Chapter 5 Files and folders migration 85

Chapter 6 Full server migration
Create a full server migration job when you want to migrate the entire source, including the server's
system state and applications.
l Full server migration requirements on page 87—Full server migration includes specific
requirements for this type of migration.
l Creating a full server migration job on page 94—This section includes step-by-step instructions
for creating a full server migration job.
l Managing and controlling full server migration jobs on page 105—You can view status information
about your full server migration job.
l Cutting over full server migration jobs on page 124—Use this section when you are ready to
cutover from your source to your target, which will become your new source.

Chapter 6 Full server migration 86

Full server migration requirements
Use these requirements for Linux full server migration. Keep in mind that a target server may meet these
requirements but may not be suitable to stand-in for a source after cutover. See Target compatibility on
page 92 for additional information regarding an appropriate target server for your particular source.
l Operating system—The source and target can be a 64-bit physical or virtual server running any
of the following operating systems.
l Operating system—Red Hat Enterprise Linux, Oracle Enterprise Linux, and CentOS
l Version—6.8 through 6.10

l Kernel type—Default, Unbreakable Enterprise Kernel (UEK)

l File system—Ext3, Ext4, XFS

l Operating system—Red Hat Enterprise Linux, Oracle Enterprise Linux, and CentOS
l Version—7.7 through 7.9

l Kernel type—Default, Unbreakable Enterprise Kernel (UEK)

l File system—Ext3, Ext4, XFS

l Operating system—Red Hat Enterprise Linux, Oracle Enterprise Linux, and CentOS
l Version—8.2 through 8.4

l Kernel type—Default, Unbreakable Enterprise Kernel (UEK)

l File system—Ext3, Ext4, XFS

l Operating system—CloudLinux
l Version—7.9

l Kernel type—Default

l File system—Ext3, Ext4, XFS

l Operating system—SUSE Linux Enterprise

l Version—11.2 through 11.4

l Kernel type—Default, Xen

l File system—Ext3, XFS

l Operating system—SUSE Linux Enterprise

l Version—12.3 through 12.5

l Kernel type—Default

l File system—Ext3, Ext4, XFS, Btrfs

l Notes—If you are planning to convert an existing file system to Btrfs, you must

delete any existing Carbonite Migrate jobs and re-create them after converting to
Btrfs.
l Operating system—SUSE Linux Enterprise
l Version—15.0 through 15.2

l Kernel type—Default

l File system—Ext3, Ext4, XFS, Btrfs

l Notes—If you are planning to convert an existing file system to Btrfs, you must

delete any existing Carbonite Migrate jobs and re-create them after converting to
Btrfs.

Chapter 6 Full server migration 87

 l Operating system—Ubuntu
l Version—16.04.5 through 16.04.7

l Kernel type—Generic

l File system—Ext2, Ext3, Ext4, XFS

l Operating system—Ubuntu
l Version—18.04.1 through 18.04.3

l Kernel type—Generic

l File system—Ext2, Ext3, Ext4, XFS

l Operating system—Ubuntu
l Version—20.04.0

l Kernel type—Generic

l File system—Ext2, Ext3, Ext4, XFS

For all operating systems except Ubuntu, the kernel version must match the expected
kernel for the specified release version. For example, if /etc/redhat-release declares the
system to be a Redhat 7.5 system, the kernel that is installed must match that.

Carbonite Migrate does not support stacking filesystems, like eCryptFS.

If Carbonite Migrate does not have the driver binary files for the kernel you are using, they
can be compiled automatically, but you need the build-essential package for them to be
installed. Run apt-get install build-essential to install the build tools and then restart the DT
service. This will build the driver from the source and load it.

l Packages and services—Each Linux server must have the following packages and services
installed before you can install and use Carbonite Migrate. See your operating system
documentation for details on these packages and utilities.
l sshd (or the package that installs sshd)
l lsb
l parted

l dmidecode

l scp

l which

l libnsl (only required for Red Hat Enterprise Linux, Oracle Enterprise Linux, and CentOS

version 8.0 and later)

l Google Cloud Platform—If your target is hosted in Google Cloud, the target must have Internet
access. Additionally, Google Cloud requires specific installation packages from the Google Cloud
Repository in order to successfully migrate. There is not a concise list of packages required
because the list is dependent on multiple factors including the source operating system and
configuration and your Google Cloud project. Rather than try to pre-install every possible
package, it is generally easier to complete the migration and if there are package issues, address
them post-migration. If the migration fails to cutover, review the job log and then modify the
/opt/dbtk/etc/management-service.properties files to include any missing packages. See the
knowledge base article Full Server to Google Cloud Platform (GCP) Fails Updating Packages at

Chapter 6 Full server migration 88

 https://support.carbonite.com/doubletake/articles/Full-Server-to-Google-Cloud-Platform-GCP-
Fails-Updating-Packages for details on how to update the properties file.
l System memory—The minimum system memory on each server is 1 GB.
l Disk space for program files—This is the amount of disk space needed for the Carbonite
Migrate program files. This is approximately 400 MB on each Linux server.

Make sure you have additional disk space for Carbonite Migrate queuing, logging, and so
on.

l Server name—Carbonite Migrate includes Unicode file system support, but your server name
must still be in ASCII format. Additionally, all Carbonite Migrate servers must have a unique
server name.
l Protocols and networking—Your servers must meet the following protocol and networking
requirements.
lYour servers must have TCP/IP with static IP addressing.
l IPv4 only configurations are supported, IPv4 and IPv6 are supported in combination,

however IPv6 only configurations are not supported.

l If you are using IPv6 on your servers, your console must be run from an IPv6 capable

machine.
l In order to properly resolve IPv6 addresses to a hostname, a reverse lookup entry should

be made in DNS.
l If you are using Carbonite Migrate over a WAN and do not have DNS name resolution, you

will need to add the host names to the local hosts file on each server running Carbonite
Migrate.
l Ubuntu Netplan is supported, however the network configuration on the source and target

should match. If you have a mix of network types (traditional, NetworkManager, or Netplan)
on the source and target, you may have to configure the networking on the target after
cutover.
l NAT support—Carbonite Migrate supports NAT environments with the following caveats.
l Only IPv4 is supported.
l Only standalone servers are supported.

l Make sure you have added your server to the Carbonite Replication Console using the

correct public or private IP address. The name or IP address you use to add a server to the
console is dependent on where you are running the console. Specify the private IP address
of any servers on the same side of the router as the console. Specify the public IP address
of any servers on the other side of the router as the console.
l DNS failover and updates will depend on your configuration

l Only the source or target can be behind a router, not both.

l The DNS server must be routable from the target

l Name resolution—Your servers must have name resolution or DNS. The Carbonite Replication
Console must be able to resolve the target, and the target must be able to resolve all source
servers. For details on name resolution options, see your Linux documentation or online Linux
resources.

Chapter 6 Full server migration 89

 l Ports—Port 1501 is used for localhost communication between the engine and management
service and should be opened inbound and outbound for both TCP and UDP in iptables. Ports
1500, 1505, 1506, 6325, and 6326 are used for component communication and must be opened
inbound and outbound for both TCP and UDP on any firewall that might be in use.
l Security—Carbonite Migrate security is granted through membership in user groups. The
groups can be local or LDAP (Lightweight Directory Access Protocol). You must provide a valid
local account or LDAP account that is a member of the Carbonite Migrate security groups.
l SELinux policy—The SELinux configuration should match on the source and target. For
example, if the SELinux configuration is permissive on the source, it should be permissive on the
target.
l UEFI, trusted boot, secure boot—UEFI (Unified Extensible Firmware Interface) is supported
on the source and target, however, trusted boot (tboot), secure boot, or other volume blocking
mechanisms are not supported on the source and target.
l Docker—Your source cannot be a Docker host.
l Mount option—The mount option noexec is not supported on the /tmp filesystem.
l Kernel—Paravirtualized kernels are not supported on the source and target.
l VMware Tools—Any VMWare guest running Carbonite Migrate should have the appropriate
VMWare Tools package installed.
l Snapshots—Carbonite Migrate snapshots are not supported with migration jobs.
l Supported configurations—The following table identifies the supported configurations for a full
server migration job.

Server Not
Description Supported
Configuration Supported

You can migrate a single source to a

One to one single target. The target has no
X
active/standby production activity. The source is the only
server actively replicating data.
You cannot migrate a single source to a
One to one single target where each server acts as
X
active/active both a source and target actively
replicating data to each other.
You cannot migrate many source servers
Many to one X
to one target server.

You cannot migrate a single source to

One to many X
multiple target servers.

Chapter 6 Full server migration 90

 Server Not
Description Supported
Configuration Supported

You cannot migrate a single source to a

single target, where the target then acts
Chained X
as a source, sending the same data from
the original source to a final target server.
You cannot migrate a single source to
Single server X
itself.
Standalone to Your servers can be in a standalone to
X
standalone standalone configuration.
Standalone to Your servers cannot be in a standalone to
X
cluster cluster configuration.
Cluster to Your servers cannot be in a cluster to
X
standalone standalone configuration.
Your servers cannot be in a cluster to
Cluster to cluster X
cluster configuration.

Chapter 6 Full server migration 91

Target compatibility
l Operating system version—The source and target must have the same distribution and major
version. For example, you cannot have a Red Hat version 6.x source failing over to a Red Hat
version 7.x target. The two servers do not have to have the same minor version. For example, you
can failover Red Hat version 7.5 to Red Hat version 7.7.
l Source and target preparation—Make sure your source and target servers are prepared for
mirroring, replication, and cutover by following these guidelines.
l Uninstall any applications or operating system features that are not needed from both your
source and target. Ideally, your target should be as clean and simple a configuration as
possible.
l Install on the source any drivers that are required on the target after failover. For example,

you need to install on the source any NIC drivers that will be required on the target after
failover.
l Resolve any maintenance updates on the source that may require the server to be

rebooted before cutover.

l Do not cutover if the target is waiting on a reboot after applying maintenance. If cutover

occurs before the required reboot, the target may not operate properly or it may not boot.
l Processors—There are no limits on the number or speed of the processors, but the source and
the target should have at least the same number of processors. If the target has fewer processors
or slower speeds than the source, there will be performance impacts for the users after cutover.
l Memory—The target memory should be within 25% (plus or minus) of the source. If the target
has much less memory than the source, there will be performance impacts for the users after
cutover.
l Network adapters—You must map at least one NIC from the source to one NIC on the target. If
you have NICs on the source that are not being used, it is best to disable them. If the source has
more NICs than the target, some of the source NICs will not be mapped to the target. Therefore,
the IP addresses associated with those NICs will not be available after cutover. If there are more
NICs on the target than the source, the additional NICs will still be available after cutover and will
retain their pre-cutover network settings.
l File system format—The source and the target must have the file system format on each
server. For example, if you have Ext3 on the source, you cannot have XFS on the target. In that
case, the target must also be Ext3.
l Volumes—There are no limits to the number of volumes you can migrate on the source, although
you are bound by operating system limits.
For each non-system volume you are migrating on the source, the target must have a matching
volume. For example, if you are migrating /data and /home on the source, the target must also
have /data and /home. Additional target volumes are preserved and available after cutover with all
data still accessible.
The system volumes / and /boot do not have this matching volume limitation. If you have / and
/boot on different volumes on the source, they can exist on a single volume on the target. If you
have / and /boot on the same volume on the source, they can exist on different volumes on the
target.

Chapter 6 Full server migration 92

 l Disk space—The target must have enough space to store the data from the source. This amount
of disk space will depend on the applications and data files you are migrating. The more data you
are migrating, the more disk space you will need. The target must also have enough space to
store, process, and apply the source's system state data.
A copy of the source data and system state will be staged on the target in a /dtstaging location for
each mount point. For example, / will be staged in /dtstaging and /boot will be staged in
/boot/dtstaging. You can predict how much space you will need in the staging folders by the
amount of used space on the source.
Keep in mind you should have extra space available on each server for any data growth.
l Services—Ideally, you should have the same services and run levels on the source and target.
l GRUB version—The source and target must have the same major version of GRUB installed.
The minor version can be different.

Chapter 6 Full server migration 93

Creating a full server migration job
Use the following instructions to migrate an entire server.
1. From the Servers page, right-click the server you want to migrate and select Migrate. You can
also highlight a server, click Create a New Job in the toolbar, then select Migrate.
2. Choose the type of workload that you want to migrate. Under Server Workloads, in the
Workload types pane, select Full Server Migration. In the Workload items pane, select the
volumes on the source that you want to migrate.

Unsupported file systems will be displayed but will not be accessible.

3. By default, Carbonite Migrate selects the system and boot volumes for migration. You will be
unable to deselect these volumes. Select any other volumes on the source that you want to
migrate.
If desired, click the Replication Rules heading and expand the volumes under Folders. You will
see that Carbonite Migrate automatically excludes particular files that cannot be used during the
migration. If desired, you can exclude other files that you do not want to migrate, but be careful
when excluding data. Excluded volumes, folders, and/or files may compromise the integrity of
your installed applications.
Volumes and folders with a green highlight are included completely. Volumes and folders
highlighted in light yellow are included partially, with individual files or folders included. If there is
no highlight, no part of the volume or folder is included. To modify the items selected, highlight a
volume, folder, or file and click Add Rule. Specify if you want to Include or Exclude the item.
Also, specify if you want the rule to be recursive, which indicates the rule should automatically be

Chapter 6 Full server migration 94

 applied to the subdirectories of the specified path. If you do not select Recursive, the rule will not
be applied to subdirectories.
You can also enter wildcard rules, however you should do so carefully. Rules are applied to files
that are closest in the directory tree to them. If you have rules that include multiple folders, an
exclusion rule with a wild card will need to be added for each folder that it needs applied to. For
example, if you want to exclude all .log files from /home and your rules include /home,
/home/folder1, and /home/folder2, you would need to add the exclusion rule for the root and each
subfolder rule. So you will need to add exclude rules for /home/*.log , /home/folder1/*.log, and
/home/folder2/*.log.
If you need to remove a rule, highlight it in the list at the bottom and click Remove Rule. Be
careful when removing rules. Carbonite Migrate may create multiple rules when you are adding
directories. For example, if you add /home/admin to be included in protection, then /home will be
excluded. If you remove the /home exclusion rule, then the /home/admin rule will be removed
also.

If you return to this page using the Back button in the job creation workflow, your
Workload Types selection will be rebuilt, potentially overwriting any manual replication
rules that you specified. If you do return to this page, confirm your Workload Types and
Replication Rules are set to your desired settings before proceeding forward again.

4. Click Next to continue.

5. Choose your target server. This is the server that, after the migration, will become your source.

l Current Servers—This list contains the servers currently available in your console
session. Servers that are not licensed for the workflow you have selected and those not
applicable to the workload type you have selected will be filtered out of the list. Select your
target server from the list. If the server you are looking for is not displayed, enable Show all
servers. The servers in red are not available for the source server or workload type you

Chapter 6 Full server migration 95

 have selected. Hover your mouse over an unavailable server to see a reason why this
server is unavailable.
l Find a New Server—If the server you need is not in the Current Servers list, click the
Find a New Server heading. From here, you can specify a server along with credentials
for logging in to the server. If necessary, you can click Browse to select a server from a
network drill-down list.

If you enter the target server's fully-qualified domain name, the Carbonite Replication
Console will resolve the entry to the server short name. If that short name resides in two
different domains, this could result in name resolution issues. In this case, enter the IP
address of the server.

When specifying credentials for a new server, specify a user that is a member of the local
dtadmin security group.

6. Click Next to continue.

You may be prompted for a route from the target to the source. This route is used so the
target can communicate with the source to build job options. This dialog box will be
displayed only if needed.

7. You have many options available for your server migration job. Configure those options that are
applicable to your environment.
Go to each page identified below to see the options available for that section of the Set Options
page. After you have configured your options, continue with the next step on page 103.
l General on page 96
l Failover Options on page 97
l Failover Identity on page 98
l Network Adapter Options on page 99
l Mirror, Verify & Orphaned Files on page 99
l Network Route on page 100
l Compression on page 101
l Bandwidth on page 102

General

For the Job name, specify a unique name for your job.

Chapter 6 Full server migration 96

 Failover Options

l Wait for user to initiate failover—The cutover process can wait for you to initiate it,
allowing you to control when cutover occurs. When a cutover occurs, the job will wait in the
Protecting state for you to manually initiate the cutover process. Disable this option if you
want cutover to occur immediately after the mirror is complete.
l Shutdown source server—Specify if you want to shut down the source server, if it is still
running, before the source is cutover to the target, This option prevents identity conflicts on
the network in those cases where the source and target are still both running and
communicating.
l Target Scripts—You can customize cutover by running scripts on the target. Scripts may
contain any valid Linux command, executable, or shell script file. The scripts are processed
using the same account running the Double-Take Management service. Examples of
functions specified in scripts include stopping services on the target before cutover because
they may not be necessary, stopping services on the target that need to be restarted with
the source’s machine name and/or IP address, starting services or loading applications that
are in an idle, standby mode waiting for cutover to occur, notifying the administrator before
and after cutover occurs, and so on. There are two types of cutover scripts.
l Pre-failover script—This script runs on the target at the beginning of the cutover
process. Specify the full path and name of the script file.
l Delay until script completes—Enable this option if you want to delay the cutover
process until the associated script has completed. If you select this option, make sure
your script handles errors, otherwise the cutover process may never complete if the
process is waiting on a script that cannot complete.
l Post-failover script—This script runs on the target at the end of the cutover
process. Specify the full path and name of the script file.
l Arguments—Specify a comma-separated list of valid arguments required to
execute the script.

Chapter 6 Full server migration 97

 Failover Identity

l Apply source network configuration to the target—If you select this option, your
source IP addresses will cut over to the target. If your target is on the same subnet as the
source (typical of a LAN environment), you should select this option.

Do not apply the source network configuration to the target in a WAN environment
unless you have a VPN infrastructure so that the source and target can be on the
same subnet, in which case IP address failover will work the same as a LAN
configuration. If you do not have a VPN, you will have to reconfigure the routers by
moving the source's subnet from the source's physical network to the target's
physical network. There are a number of issues to consider when designing a
solution that requires router configuration to achieve IP address failover. Since the
route to the source's subnet will be changed at failover, the source server must be
the only system on that subnet, which in turn requires all server communications to
pass through a router. Additionally, it may take several minutes or even hours for
routing tables on other routers throughout the network to converge.

l Retain target network configuration—If you select this option, the target will retain all of
its original IP addresses. If your target is on a different subnet (typical of a WAN or
NAT environment), you should select this option.

Chapter 6 Full server migration 98

 Network Adapter Options

For Map source network adapters to target network adapters, specify how you want the IP
addresses associated with each NIC on the source to be mapped to a NIC on the target. Do not
mix public and private networks.

Mirror, Verify & Orphaned Files

l Mirror Options—Choose a comparison method and whether to mirror the entire file or
only the bytes that differ in each file.
l Do not compare files. Send the entire file.—Carbonite Migrate will not perform
any comparisons between the files on the source and target. All files will be mirrored
to the target, sending the entire file. This option requires no time for comparison, but
the mirror time can be slower because it sends the entire file. However, it is useful for
configurations that have large data sets with millions of small files that are frequently
changing and it is more efficient to send the entire file. You may also need to use this
option if configuration management policies require sending the entire file.
l Compare file attributes. Send the attributes and bytes that differ.—Carbonite
Migrate will compare file attributes and will mirror only the attributes and bytes that
are different. This option is the fastest comparison method and fastest mirror speed.
Files that have not changed can be easily skipped. Also files that are open and
require a checksum mirror can be compared.
l Compare file attributes and data. Send the attributes and bytes that differ.—
Carbonite Migrate will compare file attributes and the file data and will mirror only the
attributes and bytes that are different. This comparison method is not as fast because
every file is compared, regardless of whether the file has changed or is open.
However, sending only the attributes and bytes that differ is the fastest mirror speed.

If a file is small enough that mirroring the entire file is faster than comparing it and
then mirroring it, Carbonite Availability will automatically mirror the entire file.

l General Options—Choose your general mirroring options.

Chapter 6 Full server migration 99

 l Delete orphaned files—An orphaned file is a file that exists in the replica data on
the target, but does not exist in the protected data on the source. This option
specifies if orphaned files should be deleted on the target, however it is not available
for full server jobs.

Network Route

By default, Carbonite Migrate will select an IP address on the target for transmissions. If desired,
specify an alternate route on the target that the data will be transmitted through. This allows you to
select a different route for Carbonite Migrate traffic. For example, you can separate regular
network traffic and Carbonite Migrate traffic on a machine with multiple IP addresses. You can
also select or manually enter a public IP address (which is the public IP address of the server's
router) if you are using a NAT environment.

Chapter 6 Full server migration 100

 Compression

To help reduce the amount of bandwidth needed to transmit Carbonite Migrate data, compression
allows you to compress data prior to transmitting it across the network. In a WAN environment this
provides optimal use of your network resources. If compression is enabled, the data is
compressed before it is transmitted from the source. When the target receives the compressed
data, it decompresses it and then writes it to disk. You can set the level from Minimum to
Maximum to suit your needs.
Keep in mind that the process of compressing data impacts processor usage on the source. If you
notice an impact on performance while compression is enabled in your environment, either adjust
to a lower level of compression, or leave compression disabled. Use the following guidelines to
determine whether you should enable compression.
l If data is being queued on the source at any time, consider enabling compression.
l If the server CPU utilization is averaging over 85%, be cautious about enabling
compression.
l The higher the level of compression, the higher the CPU utilization will be.
l Do not enable compression if most of the data is inherently compressed. Many image (.jpg,
.gif) and media (.wmv, .mp3, .mpg) files, for example, are already compressed. Some
images files, such as .bmp and .tif, are decompressed, so enabling compression would be
beneficial for those types.
l Compression may improve performance even in high-bandwidth environments.
l Do not enable compression in conjunction with a WAN Accelerator. Use one or the other to
compress Carbonite Migrate data.

All jobs from a single source connected to the same IP address on a target will share the
same compression configuration.

Chapter 6 Full server migration 101

 Bandwidth

Bandwidth limitations are available to restrict the amount of network bandwidth used for
Carbonite Migrate data transmissions. When a bandwidth limit is specified, Carbonite Migrate
never exceeds that allotted amount. The bandwidth not in use by Carbonite Migrate is available
for all other network traffic.

All jobs from a single source connected to the same IP address on a target will share the
same bandwidth configuration.

l Do not limit bandwidth—Carbonite Migrate will transmit data using 100% bandwidth
availability.
l Use a fixed limit—Carbonite Migrate will transmit data using a limited, fixed bandwidth.
Select a Preset bandwidth limit rate from the common bandwidth limit values. The
Bandwidth field will automatically update to the bytes per second value for your selected
bandwidth. This is the maximum amount of data that will be transmitted per second. If
desired, modify the bandwidth using a bytes per second value. The minimum limit should be
3500 bytes per second.
l Use scheduled limits—Carbonite Migrate will transmit data using a dynamic bandwidth
based on the schedule you configure. Bandwidth will not be limited during unscheduled
times.
l New—Click New to create a new scheduled bandwidth limit. Specify the following

information.
l Daytime entry—Select this option if the start and end times of the bandwidth

window occur in the same day (between 12:01 AM and midnight). The start
time must occur before the end time.
l Overnight entry—Select this option if the bandwidth window begins on one

day and continues past midnight into the next day. The start time must be later
than the end time, for example 6 PM to 6 AM.
l Day—Enter the day on which the bandwidth limiting should occur. You can

pick a specific day of the week, Weekdays to have the limiting occur Monday
through Friday, Weekends to have the limiting occur Saturday and Sunday, or
Every day to have the limiting repeat on all days of the week.
l Start time—Enter the time to begin bandwidth limiting.

l End time—Enter the time to end bandwidth limiting.

l Preset bandwidth—Select a bandwidth limit rate from the common

bandwidth limit values. The Bandwidth field will automatically update to the
bytes per second value for your select bandwidth.
l Bandwidth—If desired, modify the bandwidth using a bytes per second value.

The minimum limit should be 3500 bytes per second.

Chapter 6 Full server migration 102

 l Edit—Click Edit to modify an existing scheduled bandwidth limit.
l Delete—Click Delete to remove a scheduled bandwidth limit.

If you change your job option from Use scheduled limits to Do not limit
bandwidth or Use a fixed limit, any schedule that you created will be preserved.
That schedule will be reused if you change your job option back to Use scheduled
limits.

You can manually override a schedule after a job is established by selecting Other
Job Options, Set Bandwidth. If you select No bandwidth limit or Fixed
bandwidth limit, that manual override will be used until you go back to your
schedule by selecting Other Job Options, Set Bandwidth, Scheduled
bandwidth limit. For example, if your job is configured to use a daytime limit, you
would be limited during the day, but not at night. But if you override that, your
override setting will continue both day and night, until you go back to your schedule.
See the Managing and controlling jobs section for your job type for more
information on the Other Job Options.

8. Click Next to continue.

9. Carbonite Migrate validates that your source and target are compatible. The Summary page
displays your options and validation items.
Errors are designated by a white X inside a red circle. Warnings are designated by a black
exclamation point (!) inside a yellow triangle. A successful validation is designated by a white
checkmark inside a green circle. Errors are sorted at the top of the list, then warnings, then
success messages. Click on any of the validation items to see details. You must correct any errors
before you can continue. Depending on the error, you may be able to click Fix or Fix All and let
Carbonite Migrate correct the problem for you. For those errors that Carbonite Migrate cannot
correct automatically, you will need to modify the source or target to correct the error, or you can
select a different target. You must revalidate the selected servers, by clicking Recheck, until the
validation check passes without errors. Click the Common Job Validation Warnings and
Errors link to open a web browser and view solutions to common validation warnings and errors.
If you receive a path transformation error during job validation indicating a volume does not exist
on the target server, even though there is no corresponding data being protected on the source,
you will need to manually modify your replication rules. Go back to the Choose Data page and
under the Replication Rules, locate the volume from the error message. Remove any rules
associated with that volume. Complete the rest of the workflow and the validation should pass.
After a job is created, the results of the validation checks are logged to the job log. See the
Carbonite Availability and Carbonite Migrate Reference Guide for details on the various
Carbonite Migrate log files.
10. Once your servers have passed validation and you are ready to begin migration, click Finish, and
you will automatically be taken to the Jobs page.

Jobs in a NAT environment may take longer to start.

Once a job is created, do not change the name of underlying hardware components used in the
job. For example, volume names, network adapter names, or virtual switch names. Any
component used by name in your job must continue to use that name throughout the lifetime of

Chapter 6 Full server migration 103

 job. If you must change a name, you will need to delete the job and re-create it using the new
component name.

Chapter 6 Full server migration 104

Managing and controlling full server migration jobs
Click Jobs from the main Carbonite Replication Console toolbar. The Jobs page allows you to view
status information about your jobs. You can also control your jobs from this page.
The jobs displayed in the right pane depend on the server group folder selected in the left pane. Every
job for each server in your console session is displayed when the Jobs on All Servers group is
selected. If you have created and populated server groups (see Managing servers on page 15), then
only the jobs associated with the server or target servers in that server group will be displayed in the right
pane.
l Overview job information displayed in the top right pane on page 105
l Detailed job information displayed in the bottom right pane on page 108
l Job controls on page 110

Overview job information displayed in the top right pane

The top pane displays high-level overview information about your jobs. You can sort the data within a
column in ascending and descending order. You can also move the columns to the left or right of each
other to create your desired column order. The list below shows the columns in their default left to right
order.
If you are using server groups, you can filter the jobs displayed in the top right pane by expanding the
Server Groups heading and selecting a server group.

Column 1 (Blank)
The first blank column indicates the state of the job.

A green circle with a white checkmark indicates the job is in a healthy state. No
action is required.

A yellow triangle with a black exclamation point indicates the job is in a pending or
warning state. This icon is also displayed on any server groups that you have created
that contain a job in a pending or warning state. Carbonite Migrate is working or waiting
on a pending process or attempting to resolve the warning state.

A red circle with a white X indicates the job is in an error state. This icon is also
displayed on any server groups that you have created that contain a job in an error
state. You will need to investigate and resolve the error.

The job is in an unknown state.

Job
The name of the job
Source Server
The name of the source.

Chapter 6 Full server migration 105

Target Server
The name of the target.
Job Type
Each job type has a unique job type name. This job is a Full Server Migration job. For a
complete list of all job type names, press F1 to view the Carbonite Replication Console
online help.
Activity
There are many different Activity messages that keep you informed of the job activity.
Most of the activity messages are informational and do not require any administrator
interaction. If you see error messages, check the job details. Keep in mind that Idle
indicates console to server activity is idle, not that your servers are idle.
Mirror Status
l Calculating—The amount of data to be mirrored is being calculated.
l In Progress—Data is currently being mirrored.
l Waiting—Mirroring is complete, but data is still being written to the target.
l Idle—Data is not being mirrored.
l Paused—Mirroring has been paused.
l Stopped—Mirroring has been stopped.
l Removing Orphans—Orphan files on the target are being removed or deleted
depending on the configuration.
l Verifying—Data is being verified between the source and target.
l Unknown—The console cannot determine the status.
Replication Status
l Replicating—Data is being replicated to the target.
l Ready—There is no data to replicate.
l Pending—Replication is pending.
l Stopped—Replication has been stopped.
l Out of Memory—Replication memory has been exhausted.
l Failed—The Double-Take service is not receiving replication operations from the
Carbonite Migrate driver. Check the Event Viewer for driver related issues.
l Unknown—The console cannot determine the status.
Transmit Mode
l Active—Data is being transmitted to the target.
l Paused—Data transmission has been paused.
l Scheduled—Data transmission is waiting on schedule criteria.
l Stopped—Data is not being transmitted to the target.
l Error—There is a transmission error.
l Unknown—The console cannot determine the status.

Chapter 6 Full server migration 106

Operating System
The job type operating system

Chapter 6 Full server migration 107

Detailed job information displayed in the bottom right pane
The details displayed in the bottom pane provide additional information for the job highlighted in the top
pane. You can expand or collapse the bottom pane by clicking on the Job Highlights heading.

Name
The name of the job
Target data state
l OK—The data on the target is in a good state.
l Mirroring—The target is in the middle of a mirror process. The data will not be in a
good state until the mirror is complete.
l Mirror Required—The data on the target is not in a good state because a remirror
is required. This may be caused by an incomplete or stopped mirror or an operation
may have been dropped on the target.
l Busy—The source is low on memory causing a delay in getting the state of the data
on the target.
l Not Loaded—Carbonite Migrate target functionality is not loaded on the target
server. This may be caused by a license key error.
l Not Ready—The Linux drivers have not yet completed loading on the target.
l Unknown—The console cannot determine the status.
Mirror remaining
The total number of mirror bytes that are remaining to be sent from the source to the
target.
Mirror skipped
The total number of bytes that have been skipped when performing a difference mirror.
These bytes are skipped because the data is not different on the source and target.
Replication queue
The total number of replication bytes in the source queue
Disk queue
The amount of disk space being used to queue data on the source
Recovery point latency
The length of time replication is behind on the target compared to the source. This is the
time period of replication data that would be lost if a failure were to occur at the current
time. This value represents replication data only and does not include mirroring data. If
you are mirroring and failover, the data on the target will be at least as far behind as the
recovery point latency. It could potentially be further behind depending on the
circumstances of the mirror. If mirroring is idle and you failover, the data will only be as
far behind as the recovery point latency time.

Chapter 6 Full server migration 108

Bytes sent
The total number of mirror and replication bytes that have been transmitted to the
target
Bytes sent (compressed)
The total number of compressed mirror and replication bytes that have been
transmitted to the target. If compression is disabled, this statistic will be the same as
Bytes sent.
Connected since
The date and time indicating when the current job was started. This is the current time
where the console is running.
Recent activity
Displays the most recent activity for the selected job, along with an icon indicating the
success or failure of the last initiated activity. Click the link to see a list of recent activities
for the selected job. You can highlight an activity in the list to display additional details
about the activity.
Additional information
Depending on the current state of your job, you may see additional information
displayed to keep you informed about the progress and status of your job. If there is no
additional information, you will see (None) displayed. Click the Why are file write
operations retrying link to open a web browser and view solutions to common
causes of retrying file write operations.

Chapter 6 Full server migration 109

Job controls
You can control your job through the toolbar buttons available on the Jobs page. If you select multiple
jobs, some of the controls will apply only to the first selected job, while others will apply to all of the
selected jobs. For example, View Job Details will only show details for the first selected job, while Stop
will stop protection for all of the selected jobs.
If you want to control just one job, you can also right click on that job and access the controls from the
pop-up menu.

View Job Details

This button leaves the Jobs page and opens the View Job Details page.

Edit Job Properties

This button leaves the Jobs page and opens the Edit Job Properties page.

Delete
Stops (if running) and deletes the selected jobs.

Provide Credentials
Changes the login credentials that the job (which is on the target machine) uses to
authenticate to the servers in the job. This button opens the Provide Credentials dialog
box where you can specify the new account information and which servers you want to
update.

View Recent Activity

Displays the recent activity list for the selected job. Highlight an activity in the list to
display additional details about the activity.

Start
Starts or resumes the selected jobs.
If you have previously stopped protection, the job will restart mirroring and replication.
If you have previously paused protection, the job will continue mirroring and replication
from where it left off, as long as the Carbonite Migrate queue was not exhausted during
the time the job was paused. If the Carbonite Migrate queue was exhausted during the
time the job was paused, the job will restart mirroring and replication.
Also if you have previously paused protection, all jobs from the same source to the
same IP address on the target will be resumed.

Chapter 6 Full server migration 110

Pause
Pauses the selected jobs. Data will be queued on the source while the job is paused.
All jobs from the same source to the same IP address on the target will be paused.

Stop
Stops the selected jobs. The jobs remain available in the console, but there will be no
mirroring or replication data transmitted from the source to the target. Mirroring and
replication data will not be queued on the source while the job is stopped, requiring a
remirror when the job is restarted. The type of remirror will depend on your job settings.

Take Snapshot
Snapshots are not applicable to migration jobs.

Manage Snapshots
Snapshots are not applicable to migration jobs.

Failover or Cutover
Starts the cutover process. See Cutting over full server migration jobs on page 124 for
the process and details of cutting over a full server migration job.

Failback
Starts the failback process. Failback does not apply to migration jobs.

Restore
Starts the restoration process. Restore does not apply to migration jobs.

Reverse
Reverses protection. Reverse protection does not apply to migration jobs.

Undo Failover or Cutover

Cancels a test cutover by undoing it. Undo failover does not apply to full server
migration jobs.

View Job Log

Opens the job log. On the right-click menu, this option is called View Logs, and you
have the option of opening the job log, source server log, or target server log.

Chapter 6 Full server migration 111

Other Job Actions
Opens a small menu of other job actions. These job actions will be started immediately,
but keep in mind that if you stop and restart your job, the job's configured settings will
override any other job actions you may have initiated.
l Mirroring—You can start, stop, pause and resume mirroring for any job that is
running.
When pausing a mirror, Carbonite Migrate stops queuing mirror data on the source
but maintains a pointer to determine what information still needs to be mirrored to
the target. Therefore, when resuming a paused mirror, the process continues where
it left off.
When stopping a mirror, Carbonite Migrate stops queuing mirror data on the source
and does not maintain a pointer to determine what information still needs to be
mirrored to the target. Therefore, when starting a mirror that has been stopped, you
will need to decide what type of mirror to perform.
l Mirror Options—Choose a comparison method and whether to mirror the
entire file or only the bytes that differ in each file.
l Do not compare files. Send the entire file.—Carbonite Migrate will
not perform any comparisons between the files on the source and
target. All files will be mirrored to the target, sending the entire file. This
option requires no time for comparison, but the mirror time can be
slower because it sends the entire file. However, it is useful for
configurations that have large data sets with millions of small files that
are frequently changing and it is more efficient to send the entire file.
You may also need to use this option if configuration management
policies require sending the entire file.
l Compare file attributes. Send the attributes and bytes that
differ.—Carbonite Migrate will compare file attributes and will mirror
only the attributes and bytes that are different. This option is the fastest
comparison method and fastest mirror speed. Files that have not
changed can be easily skipped. Also files that are open and require a
checksum mirror can be compared.
l Compare file attributes and data. Send the attributes and bytes
that differ.—Carbonite Migrate will compare file attributes and the file
data and will mirror only the attributes and bytes that are different. This
comparison method is not as fast because every file is compared,
regardless of whether the file has changed or is open. However,
sending only the attributes and bytes that differ is the fastest mirror
speed.

If a file is small enough that mirroring the entire file is faster than
comparing it and then mirroring it, Carbonite Availability will
automatically mirror the entire file.

Chapter 6 Full server migration 112

 l Calculate size of protected data before mirroring—Specify if you want
Carbonite Migrate to determine the mirroring percentage calculation based
on the amount of data being protected. If you enable this option, the
calculation will begin when mirroring begins. For the initial mirror, the
percentage will display after the calculation is complete, adjusting to the
amount of the mirror that has completed during the time it took to complete the
calculation. Subsequent mirrors will initially use the last calculated size and
display an approximate percentage. Once the calculation is complete, the
percentage will automatically adjust down or up to indicate the amount that
has been completed. Disabling calculation will result in the mirror status not
showing the percentage complete or the number of bytes remaining to be
mirrored.

The calculated amount of protected data may be slightly off if your

data set contains compressed or sparse files.

l Verify—Even if you have scheduled the verification process, you can run it manually
any time a mirror is not in progress.
l Report only—Select this option if you only want to generate a verification

report. With this option, no data that is found to be different will be mirrored to
the target. Choose how you want the verification to compare the files.
l Report and mirror files—Select this option if you want to generate a
verification report and mirror data that is different to the target. Select the
comparison method and type of mirroring you want to use. See the previous
mirroring methods described under Mirror Options.
l Set Bandwidth—You can manually override bandwidth limiting settings configured
for your job at any time.
l No bandwidth limit—Carbonite Migrate will transmit data using 100%

bandwidth availability.
l Fixed bandwidth limit—Carbonite Migrate will transmit data using a limited,

fixed bandwidth. Select a Preset bandwidth limit rate from the common
bandwidth limit values. The Bandwidth field will automatically update to the
bytes per second value for your selected bandwidth. This is the maximum
amount of data that will be transmitted per second. If desired, modify the
bandwidth using a bytes per second value. The minimum limit should be 3500
bytes per second.
l Scheduled bandwidth limit—If your job has a configured scheduled

bandwidth limit, you can enable that schedule with this option.
l Delete Orphans—Even if you have enabled orphan file removal during your mirror
and verification processes, you can manually remove them at any time.
l Target—You can pause the target, which queues any incoming Carbonite Migrate
data from the source on the target. All active jobs to that target will complete the
operations already in progress. Any new operations will be queued on the target
until the target is resumed. The data will not be committed until the target is
resumed. Pausing the target only pauses Carbonite Migrate processing, not the
entire server.

Chapter 6 Full server migration 113

 While the target is paused, the Carbonite Migrate target cannot queue data
indefinitely. If the target queue is filled, data will start to queue on the source. If the
source queue is filled, Carbonite Migrate will automatically disconnect the
connections and attempt to reconnect them.
If you have multiple jobs to the same target, all jobs from the same source will be
paused and resumed.
l Refresh Status—Refreshes the job status immediately.
Filter
Select a filter option from the drop-down list to only display certain jobs. You can display
Healthy jobs, Jobs with warnings, or Jobs with errors. To clear the filter, select
All jobs. If you have created and populated server groups, then the filter will only apply
to the jobs associated with the server or target servers in that server group. See
Managing servers on page 15.
Search
Allows you to search the source or target server name for items in the list that match the
criteria you have entered.

Overflow Chevron
Displays any toolbar buttons that are hidden from view when the window size is
reduced.

Chapter 6 Full server migration 114

Viewing full server migration job details
From the Jobs page, highlight the job and click View Job Details in the toolbar.
Review the following table to understand the detailed information about your job displayed on the View
Job Details page.

Job name
The name of the job
Job type
Each job type has a unique job type name. This job is a Full Server Migration job. For a
complete list of all job type names, press F1 to view the Carbonite Replication Console
online help.
Health

The job is in a healthy state.

The job is in a warning state.

The job is in an error state.

The job is in an unknown state.

Activity
There are many different Activity messages that keep you informed of the job activity.
Most of the activity messages are informational and do not require any administrator
interaction. If you see error messages, check the rest of the job details.
Connection ID
The incremental counter used to number connections. The number is incremented
when a connection is created. The counter is reset if there are no existing jobs and the
Double-Take service is restarted.
Transmit mode
l Active—Data is being transmitted to the target.
l Paused—Data transmission has been paused.
l Scheduled—Data transmission is waiting on schedule criteria.
l Stopped—Data is not being transmitted to the target.
l Error—There is a transmission error.
l Unknown—The console cannot determine the status.

Chapter 6 Full server migration 115

Target data state
l OK—The data on the target is in a good state.
l Mirroring—The target is in the middle of a mirror process. The data will not be in a
good state until the mirror is complete.
l Mirror Required—The data on the target is not in a good state because a remirror
is required. This may be caused by an incomplete or stopped mirror or an operation
may have been dropped on the target.
l Busy—The source is low on memory causing a delay in getting the state of the data
on the target.
l Not Loaded—Carbonite Migrate target functionality is not loaded on the target
server. This may be caused by a license key error.
l Not Ready—The Linux drivers have not yet completed loading on the target.
l Unknown—The console cannot determine the status.
Target route
The IP address on the target used for Carbonite Migrate transmissions.
Compression
l On / Level—Data is compressed at the level specified.
l Off—Data is not compressed.
Encryption
l On—Data is being encrypted before it is sent from the source to the target.
l Off—Data is not being encrypted before it is sent from the source to the target.
Bandwidth limit
If bandwidth limiting has been set, this statistic identifies the limit. The keyword
Unlimited means there is no bandwidth limit set for the job.
Connected since
The source server date and time indicating when the current job was started. This field
is blank, indicating that a TCP/IP socket is not present, when the job is waiting on
transmit options or if the transmission has been stopped. This field will maintain the
date and time, indicating that a TCP/IP socket is present, when transmission has been
paused.
Additional information
Depending on the current state of your job, you may see additional information
displayed to keep you informed about the progress and status of your job. If there is no
additional information, you will see (None) displayed. Click the Why are file write
operations retrying link to open a web browser and view solutions to common
causes of retrying file write operations.

Chapter 6 Full server migration 116

Mirror status
l Calculating—The amount of data to be mirrored is being calculated.
l In Progress—Data is currently being mirrored.
l Waiting—Mirroring is complete, but data is still being written to the target.
l Idle—Data is not being mirrored.
l Paused—Mirroring has been paused.
l Stopped—Mirroring has been stopped.
l Removing Orphans—Orphan files on the target are being removed or deleted
depending on the configuration.
l Verifying—Data is being verified between the source and target.
l Unknown—The console cannot determine the status.
Mirror percent complete
The percentage of the mirror that has been completed
Mirror remaining
The total number of mirror bytes that are remaining to be sent from the source to the
target.
Mirror skipped
The total number of bytes that have been skipped when performing a difference mirror.
These bytes are skipped because the data is not different on the source and target.
Replication status
l Replicating—Data is being replicated to the target.
l Ready—There is no data to replicate.
l Pending—Replication is pending.
l Stopped—Replication has been stopped.
l Out of Memory—Replication memory has been exhausted.
l Failed—The Double-Take service is not receiving replication operations from the
Carbonite Migrate driver. Check the Event Viewer for driver related issues.
l Unknown—The console cannot determine the status.
Replication queue
The total number of replication bytes in the source queue
Disk queue
The amount of disk space being used to queue data on the source
Bytes sent
The total number of mirror and replication bytes that have been transmitted to the
target

Chapter 6 Full server migration 117

Bytes sent compressed
The total number of compressed mirror and replication bytes that have been
transmitted to the target. If compression is disabled, this statistic will be the same as
Bytes sent.
Recovery point latency
The length of time replication is behind on the target compared to the source. This is the
time period of replication data that would be lost if a failure were to occur at the current
time. This value represents replication data only and does not include mirroring data. If
you are mirroring and failover, the data on the target will be at least as far behind as the
recovery point latency. It could potentially be further behind depending on the
circumstances of the mirror. If mirroring is idle and you failover, the data will only be as
far behind as the recovery point latency time.
Mirror start time
The UTC time when mirroring started
Mirror end time
The UTC time when mirroring ended
Total time for last mirror
The length of time it took to complete the last mirror process

Chapter 6 Full server migration 118

Validating a full server migration job
Over time, you may want to confirm that any changes in your network or environment have not impacted
your Carbonite Migrate job. Use these instructions to validate an existing job.
1. From the Jobs page, highlight the job and click View Job Details in the toolbar.
2. In the Tasks area on the right on the View Job Details page, click Validate job properties.
3. Carbonite Migrate validates that your source and target are compatible. The Summary page
displays your options and validation items.
Errors are designated by a white X inside a red circle. Warnings are designated by a black
exclamation point (!) inside a yellow triangle. A successful validation is designated by a white
checkmark inside a green circle. Errors are sorted at the top of the list, then warnings, then
success messages. Click on any of the validation items to see details. You must correct any errors
before you can continue. Depending on the error, you may be able to click Fix or Fix All and let
Carbonite Migrate correct the problem for you. For those errors that Carbonite Migrate cannot
correct automatically, you will need to modify the source or target to correct the error, or you can
select a different target. You must revalidate the selected servers, by clicking Recheck, until the
validation check passes without errors. Click the Common Job Validation Warnings and
Errors link to open a web browser and view solutions to common validation warnings and errors.
Validation checks for an existing job are logged to the job log on the target server.
4. Once your servers have passed validation, click Close.

Chapter 6 Full server migration 119

Editing a full server migration job
Use these instructions to edit a full server migration job.
1. From the Jobs page, highlight the job and click Edit Job Properties in the toolbar. (You will not
be able to edit a job if you have removed the source of that job from your Carbonite Replication
Console session or if you only have Carbonite Migrate monitor security access.)
2. You will see the same options for your full server job as when you created the job, but you will not
be able to edit all of them. If desired, edit those options that are configurable for an existing job.
See Creating a full server migration job on page 94 for details on each job option.

Changing some options may require Carbonite Migrate to automatically disconnect,

reconnect, and remirror the job.

If you have specified replication rules that exclude a volume at the root, that volume will be
incorrectly added as an inclusion if you edit the job after it has been established. If you
need to edit your job, modify the replication rules to make sure they include the proper
inclusion and exclusion rules that you want.

3. If you want to modify the workload items or replication rules for the job, click Edit workload or
replication rules. Modify the Workload item you are protecting, if desired. Additionally, you can
modify the specific Replication Rules for your job.
Click OK to return to the Edit Job Properties page.

If you remove data from your workload and that data has already been sent to the target,
you will need to manually remove that data from the target. Because the data you
removed is no longer included in the replication rules, Carbonite Migrate orphan file
detection cannot remove the data for you. Therefore, you have to remove it manually.

4. Click Next to continue.

5. Carbonite Migrate validates that your source and target are compatible. The Summary page
displays your options and validation items.
Errors are designated by a white X inside a red circle. Warnings are designated by a black
exclamation point (!) inside a yellow triangle. A successful validation is designated by a white
checkmark inside a green circle. Errors are sorted at the top of the list, then warnings, then
success messages. Click on any of the validation items to see details. You must correct any errors
before you can continue. Depending on the error, you may be able to click Fix or Fix All and let
Carbonite Migrate correct the problem for you. For those errors that Carbonite Migrate cannot
correct automatically, you will need to modify the source or target to correct the error, or you can
select a different target. You must revalidate the selected servers, by clicking Recheck, until the
validation check passes without errors. Click the Common Job Validation Warnings and
Errors link to open a web browser and view solutions to common validation warnings and errors.
If you receive a path transformation error during job validation indicating a volume does not exist
on the target server, even though there is no corresponding data being protected on the source,
you will need to manually modify your replication rules. Go back to the Choose Data page and

Chapter 6 Full server migration 120

 under the Replication Rules, locate the volume from the error message. Remove any rules
associated with that volume. Complete the rest of the workflow and the validation should pass.
After a job is created, the results of the validation checks are logged to the job log. See the
Carbonite Availability and Carbonite Migrate Reference Guide for details on the various
Carbonite Migrate log files.
6. Once your servers have passed validation and you are ready to update your job, click Finish.

Chapter 6 Full server migration 121

Viewing a full server migration job log
You can view a job log file through the Carbonite Replication Console by selecting View Job Log from
the toolbar on the Jobs page. Separate logging windows allow you to continue working in the Carbonite
Replication Console while monitoring log messages. You can open multiple logging windows for
multiple jobs. When the Carbonite Replication Console is closed, all logging windows will automatically
close.

Because the job log window communicates with the target server, if the console loses
communication with the target server after the job log window has already been opened, the job
log window will display an error.

The following table identifies the controls and the table columns in the Job logs window.

Start
This button starts the addition and scrolling of new messages in the window.

Pause
This button pauses the addition and scrolling of new messages in the window. This is
only for the Job logs window. The messages are still logged to their respective files on
the server.

Chapter 6 Full server migration 122

Copy
This button copies the messages selected in the Job logs window to the Windows
clipboard.

Clear
This button clears the Job logs window. The messages are not cleared from the
respective files on the server. If you want to view all of the messages again, close and
reopen the Job logs window.
Time
This column in the table indicates the date and time when the message was logged.
Description
This column in the table displays the actual message that was logged.

Chapter 6 Full server migration 123

Cutting over full server migration jobs
When the migration mirror has completed, the target may or may not reboot automatically depending on
your selection for user intervention. If you disabled user intervention, the target will reboot automatically
to complete the migration process. If you enabled user intervention, when the migration mirror is
complete, the status will change to Protecting. Use this time to complete any necessary tasks. When
you are ready to complete the migration, use the following instructions to cutover.
1. On the Jobs page, highlight the job that you want to cutover and click Failover or Cutover in the
toolbar.
2. Select the type of cutover to perform.
l Cutover to live data—Select this option to initiate a full, live cutover using the current data

on the target. The source may be automatically shut down if it is still running, depending on
your job configuration. The target will stand in for the source by rebooting and applying the
source identity, including its system state, on the target. After the reboot, the target
becomes the source, and the target no longer exists.
l Perform test cutover—This option is not applicable to full server migration jobs.

l Cutover to a snapshot—This option is not available for migration jobs.

3. Select how you want to handle the data in the target queue.
l Apply data in target queues before failover or cutover—All of the data in the target

queue will be applied before cutover begins. The advantage to this option is that all of the
data that the target has received will be applied before cutover begins. The disadvantage to
this option is depending on the amount of data in queue, the amount of time to apply all of
the data could be lengthy.
l Discard data in the target queues and failover or cutover immediately—All of the

data in the target queue will be discarded and cutover will begin immediately. The
advantage to this option is that cutover will occur immediately. The disadvantage is that any
data in the target queue will be lost.
4. When you are ready to begin cutover, click Cutover.

Google Cloud requires specific installation packages from the Google Cloud Repository in
order to successfully migrate. There is not a concise list of packages required because the
list is dependent on multiple factors including the source operating system and
configuration and your Google Cloud project. Rather than try to pre-install every possible
package, it is generally easier to complete the migration and if there are package issues,
address them post-migration. If the migration fails to cutover, review the job log and then
modify the /opt/dbtk/etc/management-service.properties files to include any missing
packages. See the knowledge base article Full Server to Google Cloud Platform (GCP)
Fails Updating Packages at https://support.carbonite.com/doubletake/articles/Full-
Server-to-Google-Cloud-Platform-GCP-Fails-Updating-Packages for details on how to
update the properties file.

Chapter 6 Full server migration 124

Chapter 7 Full server to ESX migration
Create a full server to ESX migration job when you want to migrate an entire physical server or virtual
machine to an ESX target.
l Full server to ESX migration requirements on page 126—Full server to ESX migration includes
specific requirements for this type of migration.
l Creating a full server to ESX migration job on page 133—This section includes step-by-step
instructions for creating a full server to ESX migration job.
l Managing and controlling full server to ESX migration jobs on page 152—You can view status
information about your full server to ESX migration job.
l Cutting over full server to ESX migration jobs on page 171—Use this section when you are ready
to cutover from your source to your target, which will become your new source.

Chapter 7 Full server to ESX migration 125

Full server to ESX migration requirements
Use these requirements for full server to ESX migration.
l Source server—The source server can be a 64-bit physical or virtual server running any of the
following operating systems.
l Operating system—Red Hat Enterprise Linux, Oracle Enterprise Linux, and CentOS
l Version—6.8 through 6.10

l Kernel type—Default, Unbreakable Enterprise Kernel (UEK)

l File system—Ext3, Ext4, XFS

l Operating system—Red Hat Enterprise Linux, Oracle Enterprise Linux, and CentOS
l Version—7.7 through 7.9

l Kernel type—Default, Unbreakable Enterprise Kernel (UEK)

l File system—Ext3, Ext4, XFS

l Operating system—Red Hat Enterprise Linux, Oracle Enterprise Linux, and CentOS
l Version—8.2 through 8.4

l Kernel type—Default, Unbreakable Enterprise Kernel (UEK)

l File system—Ext3, Ext4, XFS

l Operating system—CloudLinux
l Version—7.9

l Kernel type—Default

l File system—Ext3, Ext4, XFS

l Operating system—SUSE Linux Enterprise

l Version—11.2 through 11.4

l Kernel type—Default, Xen

l File system—Ext3, XFS

l Operating system—SUSE Linux Enterprise

l Version—12.3 through 12.5

l Kernel type—Default

l File system—Ext3, Ext4, XFS, Btrfs

l Notes—If you are planning to convert an existing file system to Btrfs, you must

delete any existing Carbonite Migrate jobs and re-create them after converting to
Btrfs.
l Operating system—SUSE Linux Enterprise
l Version—15.0 through 15.2

l Kernel type—Default

l File system—Ext3, Ext4, XFS, Btrfs

l Notes—If you are planning to convert an existing file system to Btrfs, you must

delete any existing Carbonite Migrate jobs and re-create them after converting to
Btrfs.

Chapter 7 Full server to ESX migration 126

 l Operating system—Ubuntu
l Version—16.04.5 through 16.04.7

l Kernel type—Generic

l File system—Ext2, Ext3, Ext4, XFS

l Operating system—Ubuntu
l Version—18.04.1 through 18.04.3

l Kernel type—Generic

l File system—Ext2, Ext3, Ext4, XFS

l Operating system—Ubuntu
l Version—20.04.0

l Kernel type—Generic

l File system—Ext2, Ext3, Ext4, XFS

For all operating systems except Ubuntu, the kernel version must match the expected
kernel for the specified release version. For example, if /etc/redhat-release declares the
system to be a Redhat 7.5 system, the kernel that is installed must match that.

Carbonite Migrate does not support stacking filesystems, like eCryptFS.

If Carbonite Migrate does not have the driver binary files for the kernel you are using, they
can be compiled automatically, but you need the build-essential package for them to be
installed. Run apt-get install build-essential to install the build tools and then restart the DT
service. This will build the driver from the source and load it.

l Packages and services—Each Linux server must have the following packages and services
installed before you can install and use Carbonite Migrate. See your operating system
documentation for details on these packages and utilities.
l sshd (or the package that installs sshd)
l lsb

l parted

l dmidecode

l scp

l which

l libnsl (only required for Red Hat Enterprise Linux, Oracle Enterprise Linux, and CentOS

version 8.0 and later)

l vCenter—vCenter is not required, but if you are using it, then you must use version 5.5 or later. If
you upgrade your version of vCenter after it has been entered into the Carbonite Replication
Console, you must remove and re-add the vCenter in order for the console to recognize the
upgraded version.
l vMotion—Host vMotion is only supported if you are using vCenter. Storage vMotion is not
supported.
l Target host server—The target host server must be an ESX server. It can be any of the
following ESX operating systems.

Chapter 7 Full server to ESX migration 127

 l ESXi 6.5
l ESXi 6.7
l ESXi 7.0

The free versions of ESX restrict functionality that Carbonite Migrate requires. Therefore,
you must use one of the paid editions of ESX.

l Virtual recovery appliance—The target ESX host must have an existing virtual machine,
known as a virtual recovery appliance. You must have this appliance before you can begin
migration. When you begin migration, the virtual recovery appliance will mount disks, format disks,
and so on. When cutover occurs, a new virtual machine is powered on using the replicated disks
from the appliance. Once the new virtual machine is online, it will have the identity, data, and
system state of the source. Since the appliance maintains its own identity, it can be reused for
additional cutovers.
You have the choice of using an OVF (Open Virtualization Format) virtual machine included with
Carbonite Migrate for your appliance, or creating your own appliance that meets the requirements
below. In either case, keep in mind the following caveats for the appliance.
l The virtual recovery appliance must be a standalone virtual machine.
l It should not reside in any multiple virtual machine vApp.
l The OVF appliance is pre-configured for optimal performance. You do not need to modify
the memory, CPU, or other configurations.
l You should not install or run anything else on the appliance.
l A single virtual recovery appliance can migrate a maximum of 10 sources or jobs with a
maximum of a combined total of 59 volume groups and raw block devices.
If you are creating your own appliance, it must meet the following requirements.
l Operating system—The virtual machine must be running a 64-bit version of one of the
following operating systems.
l Ubuntu version 18.04.1 through 18.04.3

l Red Hat Enterprise Linux or CentOS version 7.7 through 7.9

l Red Hat Enterprise Linux or CentOS version 8.2 through 8.4

l SUSE Linux Enterprise version 12.3 through 12.5

A SLES appliance can only protect source servers running a Carbonite Migrate
supported SLES version. You cannot protect other Linux operating systems to a
SLES appliance.

You cannot protect Btrfs to a Red Hat or CentOS appliance.

l Memory—The virtual machine must have at least 4 GB of virtualized physical RAM.

l CPUs—The virtual machine must have at least two CPUs (two virtual sockets, not two
virtual cores).
l Disk space—The virtual machine must have at least 16 GB of disk space available.

Chapter 7 Full server to ESX migration 128

 l SCSI controller—The virtual machine must be configured to use LSI Logic Parallel
controllers. For every 10 source disks you are protecting, you should add another
controller.
l Networking—The virtual machine must have a valid, working network configuration,
including DNS.
l Function—The virtual machine must be dedicated to Carbonite Migrate processing only.
Do not use the virtual machine for any other activity (web server, database server, and so
on).
l Volume group name—If your virtual machine is running Red Hat or CentOS and is using
an LVM setup, you must make sure the volume group on the virtual machine is using a
unique name. If the same volume group name is used as any volume group name from a
protected source, failover will fail because of a name conflict. Refer to your Red Hat
documentation for details on renaming a volume group.
l SELinux policy—SELinux is supported on the source and appliance, except for SLES
11.x sources. If you are using a SLES 11.x source, then SELinux must be disabled on the
target appliance.
l Packages—You will need specific packages installed on your appliance depending on the
operating system of your source servers.
l Ext—If the source server you will be protecting has the ext file system, you must

have the e2fsprogs package on your appliance.

l Xfs—If the source server you will be protecting has the xfs file system, you must

have the xfsprogs package on your appliance.

l LVM—If the source server you will be protecting has an LVM setup, you must have

the lvm2 package on your appliance.

l Btrfs—If the source server you will be protecting has the Btrfs file system and you

are using an Ubuntu appliance, the appliance must have the btrfs-tools package. If
the source server you are protecting is SLES 12.x with Btrfs and you are using a
SLES appliance, the btrfsprogs package should already be on the SLES appliance
by default. You cannot protect Btrfs to a Red Hat or CentOS appliance.
l Permissions—If you want to limit the permissions required for the account that you will be using
for your full server to ESX migration job, your account must have at a minimum the permissions
listed below. These permissions can be set at the vCenter, Datacenter, or host level.
l Datastore—Allocate Space, Browse Datastore, Low level file operations, and Remove

File
l Host, Local Operations—Create Virtual Machine, Delete Virtual Machine, and

Reconfigure virtual machine

l Network—Assign Network

l Resource—Assign virtual machine to resource pool

l Scheduled Task—Create Tasks, Modify Task, Remove Task, and Run Task

l Tasks—Create task and Update task

l Virtual Machine, Configuration—Add existing disk, Add new disk, Add or remove

device, Change resource, Modify device settings, and Remove disk

l Virtual Machine, Interaction—Device connection, Power off, and Power on

l Virtual Machine, Inventory—Create new, Register, Remove, and Unregister

Chapter 7 Full server to ESX migration 129

 Make sure if you also define permissions at the VMs and Templates level in vCenter that you have
not denied any of the required permissions listed above.
l System memory—The minimum system memory on each server is 1 GB.
l Disk space for program files—This is the amount of disk space needed for the Carbonite
Migrate program files. This is approximately 400 MB on a Linux source server. The appliance
needs approximately 620 MB.

Make sure you have additional disk space for Carbonite Migrate queuing, logging, and so
on.

l Server name—Carbonite Migrate includes Unicode file system support, but your server name
must still be in ASCII format. Additionally, all Carbonite Migrate servers and appliances must have
a unique server name.
l Target drivers—Install on the source any drivers that are required on the target after failover.
For example, you need to install on the source any NIC drivers that will be required on the target
after failover.
l Protocols and networking—Your servers must meet the following protocol and networking
requirements.
lYour servers must have TCP/IP with static IP addressing.
l IPv4 only configurations are supported, IPv4 and IPv6 are supported in combination,

however IPv6 only configurations are not supported.

l WAN failover is not supported with IPv6 addresses.

l If you are using IPv6 on your servers, your console must be run from an IPv6 capable

machine.
l In order to properly resolve IPv6 addresses to a hostname, a reverse lookup entry should

be made in DNS.
l If you are using Carbonite Migrate over a WAN and do not have DNS name resolution, you

will need to add the host names to the local hosts file on each server running Carbonite
Migrate.
l Ubuntu Netplan is supported, however the network configuration on the source and target

should match. If you have a mix of network types (traditional, NetworkManager, or Netplan)
on the source and target, you may have to configure the networking on the target after
cutover.
l NAT support—Carbonite Migrate supports NAT environments with the following caveats.
l Only IPv4 is supported.
l Only standalone servers are supported.
l Make sure you have added your server to the Carbonite Replication Console using the
correct public or private IP address. The name or IP address you use to add a server to the
console is dependent on where you are running the console. Specify the private IP address
of any servers on the same side of the router as the console. Specify the public IP address
of any servers on the other side of the router as the console.
l DNS failover and updates will depend on your configuration
l Only the source or target can be behind a router, not both.

l The DNS server must be routable from the target

Chapter 7 Full server to ESX migration 130

 l Name resolution—Your servers must have name resolution or DNS. The Carbonite Replication
Console must be able to resolve the virtual recovery appliance, and the virtual recovery appliance
must be able to resolve all source servers. For details on name resolution options, see your Linux
documentation or online Linux resources.
l Ports—Port 1501 is used for localhost communication between the engine and management
service and should be opened inbound and outbound for both TCP and UDP in iptables. Ports
1500, 1505, 1506, 6325, and 6326 are used for component communication and must be opened
inbound and outbound for both TCP and UDP on any firewall that might be in use.
l Security—Carbonite Migrate security is granted through membership in user groups. The
groups can be local or LDAP (Lightweight Directory Access Protocol). You must provide a valid
local account or LDAP account that is a member of the Carbonite Migrate security groups.
l SELinux policy—SELinux is supported on the source and appliance, except for SLES 11.x
sources. If you are using a SLES 11.x source, then SELinux must be disabled on the target
appliance.
l UEFI, trusted boot, secure boot—UEFI (Unified Extensible Firmware Interface) is supported
on the source, however, trusted boot (tboot), secure boot, or other volume blocking mechanisms
are not supported on the source.
l Docker—Your source cannot be a Docker host.
l Mount option—The mount option noexec is not supported on the /tmp filesystem.
l Trusted Boot (tboot)—Trusted Boot is not supported and should be disabled on the source.
l Snapshots—Carbonite Migrate snapshots are not supported with migration jobs.
l Supported configurations—The following table identifies the supported configurations for a full
server to ESX migration job.

Server to Host Not

Description Supported
Configuration Supported

One to one You can migrate a single source to a

X
active/standby single target host.
You cannot migrate a single source to a
One to one single target host where each server acts
X
active/active as both a source and target actively
replicating data to each other.
You can migrate many source servers to
one target host. Replication occurs from
Many to one each source to the one target host. This X
will consolidate your source servers to a
single host server.
You cannot migrate a single source to
One to many X
multiple target hosts.

Chapter 7 Full server to ESX migration 131

 Server to Host Not
Description Supported
Configuration Supported

You cannot migrate a single source to a

single target host, where the target host
Chained X
then acts a source in order to send the
original source to another target.
You cannot migrate a single source to
Single server X
itself.
Standalone to Your source and target host can be in a
X
standalone standalone to standalone configuration.
Standalone to Your source and target host cannot be in
X
cluster a standalone to cluster configuration.
Cluster to Your source and target host cannot be in
X
standalone a cluster to standalone configuration.
Your source and target host cannot be in
Cluster to cluster X
a cluster to cluster configuration.

Chapter 7 Full server to ESX migration 132

Creating a full server to ESX migration job
Use the following instructions to migrate an entire server to a new virtual machine on an ESX server.
1. From the Servers page, right-click the server you want to migrate and select Migrate. You can
also highlight a server, click Create a New Job in the toolbar, then select Migrate.
2. Choose the type of workload that you want to migrate. Under Server Workloads, in the
Workload types pane, select Full Server to ESX Migration. In the Workload items pane,
select the volumes on the source that you want to migrate.

Unsupported file systems will be displayed but will not be accessible.

3. By default, Carbonite Migrate selects the system and boot volumes for migration. You will be
unable to deselect these volumes. Select any other volumes on the source that you want to
migrate.

The swap partition is excluded by default and you cannot select it, however, a swap
partition will be created on the replica.

If desired, click the Replication Rules heading and expand the volumes under Folders. You will
see that Carbonite Migrate automatically excludes particular files that cannot be used during the
migration. If desired, you can exclude other files that you do not want to migrate, but be careful
when excluding data. Excluded volumes, folders, and/or files may compromise the integrity of
your installed applications.
Volumes and folders with a green highlight are included completely. Volumes and folders
highlighted in light yellow are included partially, with individual files or folders included. If there is

Chapter 7 Full server to ESX migration 133

 no highlight, no part of the volume or folder is included. To modify the items selected, highlight a
volume, folder, or file and click Add Rule. Specify if you want to Include or Exclude the item.
Also, specify if you want the rule to be recursive, which indicates the rule should automatically be
applied to the subdirectories of the specified path. If you do not select Recursive, the rule will not
be applied to subdirectories.
You can also enter wildcard rules, however you should do so carefully. Rules are applied to files
that are closest in the directory tree to them. If you have rules that include multiple folders, an
exclusion rule with a wild card will need to be added for each folder that it needs applied to. For
example, if you want to exclude all .log files from /home and your rules include /home,
/home/folder1, and /home/folder2, you would need to add the exclusion rule for the root and each
subfolder rule. So you will need to add exclude rules for /home/*.log , /home/folder1/*.log, and
/home/folder2/*.log.
If you need to remove a rule, highlight it in the list at the bottom and click Remove Rule. Be
careful when removing rules. Carbonite Migrate may create multiple rules when you are adding
directories. For example, if you add /home/admin to be included in protection, then /home will be
excluded. If you remove the /home exclusion rule, then the /home/admin rule will be removed
also.

If you return to this page using the Back button in the job creation workflow, your
Workload Types selection will be rebuilt, potentially overwriting any manual replication
rules that you specified. If you do return to this page, confirm your Workload Types and
Replication Rules are set to your desired settings before proceeding forward again.

4. Click Next to continue.

5. Choose your target server. This is the virtual recovery appliance on your ESX server.

l Current Servers—This list contains the servers currently available in your console
session. Servers that are not licensed for the workflow you have selected and those not

Chapter 7 Full server to ESX migration 134

 applicable to the workload type you have selected will be filtered out of the list. Select your
target server from the list. If the server you are looking for is not displayed, enable Show all
servers. The servers in red are not available for the source server or workload type you
have selected. Hover your mouse over an unavailable server to see a reason why this
server is unavailable.
l Find a New Server—If the server you need is not in the Current Servers list, click the
Find a New Server heading. From here, you can specify a server along with credentials
for logging in to the server. If necessary, you can click Browse to select a server from a
network drill-down list.

If you enter the target server's fully-qualified domain name, the Carbonite Replication
Console will resolve the entry to the server short name. If that short name resides in two
different domains, this could result in name resolution issues. In this case, enter the IP
address of the server.

When specifying credentials for a new server, specify a user that is a member of the local
dtadmin security group.

6. Click Next to continue.

7. Choose the server where your target virtual recovery appliance is located. This is also the server
where your replica virtual machine will be located.

l Current VMware Servers—This list contains the vCenter and ESX servers currently
available in your console session. Select your server from the list.
l Find a New VMware Server—If the server you need is not in the Current VMware
Servers list, click the Find a New VMware Server heading.
l vCenter/ESXi Server—Select your server from the list. If your server is not in the

list, manually type it in.

Chapter 7 Full server to ESX migration 135

 l User name—Specify the root user or another user that has the administrator role on
the specified server.
l Password—Specify the password associated with the User name you entered.

l Domain—If you are working in a domain environment, specify the Domain.

If your server name does not match the security certificate or the security certificate has
expired, you will be prompted if you want to install the untrusted security certificate.
8. Click Next to continue.

You may be prompted for a route from the target to the source. This route is used so the
target can communicate with the source to build job options. This dialog box will be
displayed only if needed.

9. You have many options available for your server migration job. Configure those options that are
applicable to your environment.
Go to each page identified below to see the options available for that section of the Set Options
page. After you have configured your options, continue with the next step on page 150.
l General on page 136
l Replica Virtual Machine Location on page 136
l Replica Virtual Machine Configuration on page 137
l Replica Virtual Machine Volumes on page 138
l Replica Virtual Machine Network Settings on page 144
l Failover Options on page 145
l Mirror, Verify & Orphaned Files on page 145
l Network Route on page 146
l Compression on page 148
l Bandwidth on page 149

General

For the Job name, specify a unique name for your job.

Replica Virtual Machine Location

Chapter 7 Full server to ESX migration 136

 Select one of the volumes from the list to indicate the volume on the target where you want to
store the configuration files for the new virtual server when it is created. The target volume must
have enough Free Space. You can select the location of the .vmdk files under Replica Virtual
Machine Volumes.

Replica Virtual Machine Configuration

l Display name—Specify the name of the replica virtual machine. This will be the display
name of the virtual machine on the host system.
l Hardware configuration—Specify how you want the replica virtual machine to be
created.
l Sockets—Specify how many sockets to create on the new virtual machine. The

number of sockets on the source is displayed to guide you in making an appropriate

selection. If you select fewer sockets than the source, your clients may be impacted
by slower responses.
l Cores per socket—Specify how many cores to create per socket. The number of

cores per socket on the source is displayed to guide you in making an appropriate
selection.
l Memory—Specify the amount of memory, in MB, to create on the new virtual

machine. The memory on the source is displayed to guide you in making an

appropriate selection. If you select less memory than the source, your clients may be
impacted by slower responses.
l Network adapter type—Depending on the operating system of your source, you may be
able to select the type of adapter to use on the replica virtual machine. This selection will
apply to all adapters on the replica.

If the operating system on the source is not compatible with the VmxNet3 driver on
the target appliance, and the source does not have VMware Tools already, you
need to install VMware Tools on the replica after failover in order for the VmxNet3
adapter to work correctly. Alternatively, you could select a different network
adapter type, if another type is available.

Chapter 7 Full server to ESX migration 137

 l Virtual switches—Identify how you want to handle the network mapping after cutover.
The Source Network Adpater column lists the NICs from the source. Map each one to a
Replica Virtual Switch, which is a virtual network on the target. You can also choose to
discard the source's NIC and IP addresses. To make a selection, click the browse button
and select a virtual switch from the list. You can enter text in the Filter to limit the list of
switches displayed.

Replica Virtual Machine Volumes

If your source is UEFI, you will only have the option to create disks that match your
source. You will not be able to create disks per volume on your replica virtual machine.

l Create disks matching source—Select this option if you want the disk configuration on
the target replica to match the disk configuration on the source.

l Virtual Disk—Specify if you want Carbonite Migrate to create a new disk for your
replica virtual machine or if you want to use an existing disk. If you have more than
one disk, you cannot mix and match new and existing. They must all be new disks or
all existing disks.
Reusing a virtual disk can be useful for pre-staging data on a LAN and then
relocating the virtual disk to a remote site after the initial mirror is complete. You save
time by skipping the virtual disk creation steps and performing a difference mirror
instead of a full mirror. With pre-staging, less data will need to be sent across the wire
initially. In order to use an existing virtual disk, it must be a valid virtual disk, it cannot
be attached to any other virtual machine, and it cannot have any associated
snapshots.
Each pre-existing disk must be located on the target datastore specified. If you have
copied the .vmdk file to this location manually, be sure you have also copied the
associated -flat.vmdk file too. If you have used vCenter to copy the virtual machine,
the associated file will automatically be copied. There are no restrictions on the file

Chapter 7 Full server to ESX migration 138

 name of the .vmdk, but the associated -flat.vmdk file must have the same base name
and the reference to that flat file in the .vmdk must be correct. Carbonite Migrate will
move, not copy, the virtual disk files to the appropriate folders created by the replica,
so make sure the selected target datastore is where you want the replica virtual disk
to be located.
In a WAN environment, you may want to take advantage of using an existing disk by
using a process similar to the following.
a. Create a job in a LAN environment, letting Carbonite Migrate create the virtual
disk for you.
b. Complete the mirror process locally.
c. Delete the job and when prompted, do not delete the replica.
d. Move the virtual disk files to the desired target datastore. Do not forget to move
the associated -flat.vmdk file if you move the files manually.
e. Create a new protection job for the same source and reuse your existing disk.

If you have reused some existing disks and created some new disks, the
numbering of the hard disks will not be identical on the source and the replica
virtual machine. New disks will be created first and then existing disks will be
attached. VMware assigns the hard disk numbers in order of creation and
then those that are attached. The Virtual Device Node SCSI IDs will still be
correct and there will be no impact within the guest of the replica virtual
machine.

If your source has multiple partitions inside a single .vmdk, you can only use
an existing virtual disk that Carbonite Migrate created. You can only use an
existing virtual disk created outside of Carbonite Migrate if there is one
partition in each pre-existing disk.
If you are using Logical Volume Manager, then you can only use existing
disks when creating a new full server to ESX appliance job if the existing
disks were created using Carbonite Migrate version 7.1 or later. Versions
prior to 7.1 have important LVM information deleted when the job is deleted,
thus you cannot reuse the disk for a future job. If you are not using LVM, this
is not an issue.

l Datastore—Specify the datastore where you want to store the .vmdk files for the
disk. You can specify the location of the virtual machine configuration files in the
Replica Virtual Machine Location section.
l Replica disk format—If you are creating a new disk, specify the format of the disk
that will be created.
l Thick Lazy Zeroed—This disk format allocates the full amount of the disk

space immediately, but does not initialize the disk space to zero until it is
needed. It may also be known as a flat disk.
l Thick Eager Zeroed—This disk format allocates the full amount of the disk

space immediately, initializing all of the allocated disk space to zero.

l Thin—This disk format does not allocate the disk space until it is needed.

Chapter 7 Full server to ESX migration 139

 l Desired disk size—If you are creating a new disk, specify the maximum size, in
MB or GB, of the disks.
l Pre-existing disk path—If you are using an existing virtual disk, specify the location

of the existing virtual disk that you want to reuse.

l Create disks per volume—Select this option if you want the disk configuration on the
target replica to be per source volume.
l Volume Group Properties—If your source has volume groups, you will see them

listed in the Volume list. Highlight a volume group and set the available Volume
Group Properties that are displayed to the right of the Volume list. The fields
displayed in the Volume Group Properties will depend on your selection for
Virtual disk.

l Virtual Disk—Specify if you want Carbonite Migrate to create a new disk for
your replica virtual machine or if you want to use an existing disk.
Reusing a virtual disk can be useful for pre-staging data on a LAN and then
relocating the virtual disk to a remote site after the initial mirror is complete.
You save time by skipping the virtual disk creation steps and performing a
difference mirror instead of a full mirror. With pre-staging, less data will need to
be sent across the wire initially. In order to use an existing virtual disk, it must
be a valid virtual disk, it cannot be attached to any other virtual machine, and it
cannot have any associated snapshots.
Each pre-existing disk must be located on the target datastore specified. If you
have copied the .vmdk file to this location manually, be sure you have also
copied the associated -flat.vmdk file too. If you have used vCenter to copy the
virtual machine, the associated file will automatically be copied. There are no
restrictions on the file name of the .vmdk, but the associated -flat.vmdk file
must have the same base name and the reference to that flat file in the .vmdk
must be correct. Carbonite Migrate will move, not copy, the virtual disk files to
the appropriate folders created by the replica, so make sure the selected
target datastore is where you want the replica virtual disk to be located.
In a WAN environment, you may want to take advantage of using an existing
disk by using a process similar to the following.

Chapter 7 Full server to ESX migration 140

 a. Create a job in a LAN environment, letting Carbonite Migrate create the
virtual disk for you.
b. Complete the mirror process locally.
c. Delete the job and when prompted, do not delete the replica.
d. Move the virtual disk files to the desired target datastore. Do not forget
to move the associated -flat.vmdk file if you move the files manually.
e. Create a new protection job for the same source and reuse your existing
disk.

If you have reused some existing disks and created some new disks,
the numbering of the hard disks will not be identical on the source and
the replica virtual machine. New disks will be created first and then
existing disks will be attached. VMware assigns the hard disk numbers
in order of creation and then those that are attached. The Virtual
Device Node SCSI IDs will still be correct and there will be no impact
within the guest of the replica virtual machine.

If your source has multiple partitions inside a single .vmdk, you can
only use an existing virtual disk that Carbonite Migrate created. You
can only use an existing virtual disk created outside of Carbonite
Migrate if there is one partition in each pre-existing disk.
If you are using Logical Volume Manager, then you can only use
existing disks when creating a new full server to ESX appliance job if
the existing disks were created using Carbonite Migrate version 7.1 or
later. Versions prior to 7.1 have important LVM information deleted
when the job is deleted, thus you cannot reuse the disk for a future job.
If you are not using LVM, this is not an issue.

l Datastore—Specify the datastore where you want to store the .vmdk files for
the volume group. You can specify the location of the virtual machine
configuration files in the Replica Virtual Machine Location section.
l Replica disk format—If you are creating a new disk, specify the format of the
disk that will be created.
l Thick Lazy Zeroed—This disk format allocates the full amount of the

disk space immediately, but does not initialize the disk space to zero
until it is needed. It may also be known as a flat disk.
l Thick Eager Zeroed—This disk format allocates the full amount of the

disk space immediately, initializing all of the allocated disk space to zero.
l Thin—This disk format does not allocate the disk space until it is

needed.
l Physical volume maximum size—If you are creating a new disk, specify the
maximum size, in MB or GB, of the virtual disks used to create the volume
group. The default value is equal to the maximum size that can be attached to
the datastore you selected. That will depend on your ESX version, your file
system version, and the block size of your datastore.

Chapter 7 Full server to ESX migration 141

 l Volume Group size—If you are creating a new disk, specify the maximum
size, in MB or GB, of the volume group. The default value will match the
source. This value cannot be less than the logical volumes total size that you
are trying to create on the volume group.
l Pre-existing virtual disks path—If you are using an existing virtual disk,

specify the location of the existing virtual disks that you want to reuse.
l Logical Volume Properties—If your source has logical volumes, you will see them
listed in the Volume list. Highlight a logical volume and set the available Logical
Volume Properties that are displayed to the right of the Volume list.

If you are using an existing virtual disk, you will not be able to modify the
logical volume properties.

The size and space displayed may not match the output of the Linux df
command. This is because df shows the size of the mounted file system not
the underlying partition which may be larger. Additionally, Carbonite Migrate
uses powers of 1024 when computing GB, MB, and so on. The df command
typically uses powers of 1000 and rounds up to the nearest whole value.

l Name—This field displays the logical volume name.

l Disk size—This field displays the size of the logical volume on the source.
l Used space—This field displays the amount of disk space in use on the
source logical volume.
l Replica volume size—Specify the size, in MB or GB, of the replica logical
volume on the target. The value must be at least the size of the specified Used
space on that volume.

In some cases, the replica virtual machine may use more virtual disk
space than the size of the source volume due to differences in how the
virtual disk's block size is formatted and how hard links are handled.

Chapter 7 Full server to ESX migration 142

 To avoid this issue, specify the size of your replica to be at least 5 GB
larger.

l Partition Properties—If your source has partitions, you will see them listed in the
Volume list. Highlight a partition and set the available Partition Properties that are
displayed to the right of the Volume list. The fields displayed in the Partition
Properties will depend on your selection for Virtual disk.

The size and space displayed may not match the output of the Linux df
command. This is because df shows the size of the mounted file system not
the underlying partition which may be larger. Additionally, Carbonite Migrate
uses powers of 1024 when computing GB, MB, and so on. The df command
typically uses powers of 1000 and rounds up to the nearest whole value.

l Virtual Disk—Specify if you want Carbonite Migrate to create a new disk for
your replica virtual machine or if you want to use an existing disk. Review the
details above under Volume Group Properties Virtual Disk for information
on using an existing disk.
l Disk size—This field displays the size of the partition on the source.
l Used space—This field displays the amount of disk space in use on the
source partition.
l Datastore—Specify the datastore where you want to store the .vmdk files for
the partition. You can specify the location of the virtual machine configuration
files in the Replica Virtual Machine Location section.
l Replica disk format—Specify the format of the disk that will be created.
l Thick Lazy Zeroed—This disk format allocates the full amount of the

disk space immediately, but does not initialize the disk space to zero
until it is needed. It may also be known as a flat disk.

Chapter 7 Full server to ESX migration 143

 l Thick Eager Zeroed—This disk format allocates the full amount of the
disk space immediately, initializing all of the allocated disk space to zero.
l Thin—This disk format does not allocate the disk space until it is

needed.
l Replica volume size—Specify the size, in MB or GB, of the replica partition
on the target. The value must be at least the size of the specified Used space
on that partition.
l Pre-existing disks path—If you are using an existing virtual disk, specify the
location of the existing virtual disks that you want to reuse.

Replica Virtual Machine Network Settings

l Use advanced settings for replica virtual machine network configuration—Select

this option to enable the replica virtual machine network setting configuration. This setting is
primarily used for WAN support.

IPv6 is not supported for WAN failover.

l Network adapters—Select a network adapter from the source and specify the Replica
IP addresses, Replica Default Gateways, and Replica DNS Server addresses to be
used after cutover. If you add multiple gateways or DNS servers, you can sort them by
using the arrow up and arrow down buttons. Repeat this step for each network adapter on
the source.

Updates made during cutover will be based on the network adapter name when
protection is established. If you change that name, you will need to delete the job
and re-create it so the new name will be used during cutover.

If you update one of the advanced settings (IP address, gateway, or DNS server),
then you must update all of them. Otherwise, the remaining items will be left blank.

Chapter 7 Full server to ESX migration 144

 If you do not specify any of the advanced settings, the replica virtual machine will be
assigned the same network configuration as the source.
By default, the source IP address will be included in the target IP address list as the
default address. If you do not want the source IP address to be the default address
on the target after failover, remove that address from the Replica IP addresses
list.
Linux operating systems only support one gateway, so the first gateway listed will
be used.

Failover Options

l Wait for user to initiate failover—The cutover process can wait for you to initiate it,
allowing you to control when cutover occurs. When a cutover occurs, the job will wait in the
Protecting state for you to manually initiate the cutover process. Disable this option if you
want cutover to occur immediately after the mirror is complete.
l Shutdown source server—Specify if you want to shut down the source server, if it is still
running, before the source is cutover to the target, This option prevents identity conflicts on
the network in those cases where the source and target are still both running and
communicating.
l Target Scripts—You can customize cutover by running scripts on the target appliance
and replica. Scripts may contain any valid Linux command, executable, or shell script file.
The scripts are processed using the same account running the Double-Take Management
service. Examples of functions specified in scripts include stopping and starting services,
stopping and starting applications or processes, notifying the administrator before and after
cutover occurs, and so on. There are two types of cutover scripts.
l Pre-failover script—This script runs on the target appliance at the beginning of the
cutover process. Specify the full path and name of the script file.
l Delay until script completes—Enable this option if you want to delay the cutover
process until the associated script has completed. If you select this option, make sure
your script handles errors, otherwise the cutover process may never complete if the
process is waiting on a script that cannot complete.
l Post-failover script—This script runs on the replica at the end of the cutover
process. Specify the full path and name of the script file.
l Arguments—Specify a comma-separated list of valid arguments required to
execute the script.

Mirror, Verify & Orphaned Files

Chapter 7 Full server to ESX migration 145

 l Mirror Options—Choose a comparison method and whether to mirror the entire file or
only the bytes that differ in each file.
l Do not compare files. Send the entire file.—Carbonite Migrate will not perform
any comparisons between the files on the source and target. All files will be mirrored
to the target, sending the entire file. This option requires no time for comparison, but
the mirror time can be slower because it sends the entire file. However, it is useful for
configurations that have large data sets with millions of small files that are frequently
changing and it is more efficient to send the entire file. You may also need to use this
option if configuration management policies require sending the entire file.
l Compare file attributes. Send the attributes and bytes that differ.—Carbonite
Migrate will compare file attributes and will mirror only the attributes and bytes that
are different. This option is the fastest comparison method and fastest mirror speed.
Files that have not changed can be easily skipped. Also files that are open and
require a checksum mirror can be compared.
l Compare file attributes and data. Send the attributes and bytes that differ.—
Carbonite Migrate will compare file attributes and the file data and will mirror only the
attributes and bytes that are different. This comparison method is not as fast because
every file is compared, regardless of whether the file has changed or is open.
However, sending only the attributes and bytes that differ is the fastest mirror speed.

If a file is small enough that mirroring the entire file is faster than comparing it and
then mirroring it, Carbonite Availability will automatically mirror the entire file.

l General Options—Choose your general mirroring options.

l Delete orphaned files—An orphaned file is a file that exists in the replica data on
the target, but does not exist in the protected data on the source. This option
specifies if orphaned files should be deleted on the target.

Orphaned file configuration is a per target configuration. All jobs to the same
target will have the same orphaned file configuration.

If delete orphaned files is enabled, carefully review any replication rules that
use wildcard definitions. If you have specified wildcards to be excluded from
protection, files matching those wildcards will also be excluded from
orphaned file processing and will not be deleted from the target. However, if
you have specified wildcards to be included in your protection, those files that
fall outside the wildcard inclusion rule will be considered orphaned files and
will be deleted from the target.

Network Route

Chapter 7 Full server to ESX migration 146

 By default, Carbonite Migrate will select an IP address on the target for transmissions. If desired,
specify an alternate route on the target that the data will be transmitted through. This allows you to
select a different route for Carbonite Migrate traffic. For example, you can separate regular
network traffic and Carbonite Migrate traffic on a machine with multiple IP addresses. You can
also select or manually enter a public IP address (which is the public IP address of the server's
router) if you are using a NAT environment.

If you change the IP address on the target which is used for the target route, you will be
unable to edit the job. If you need to make any modifications to the job, it will have to be
deleted and re-created.

Chapter 7 Full server to ESX migration 147

 Compression

To help reduce the amount of bandwidth needed to transmit Carbonite Migrate data, compression
allows you to compress data prior to transmitting it across the network. In a WAN environment this
provides optimal use of your network resources. If compression is enabled, the data is
compressed before it is transmitted from the source. When the target receives the compressed
data, it decompresses it and then writes it to disk. You can set the level from Minimum to
Maximum to suit your needs.
Keep in mind that the process of compressing data impacts processor usage on the source. If you
notice an impact on performance while compression is enabled in your environment, either adjust
to a lower level of compression, or leave compression disabled. Use the following guidelines to
determine whether you should enable compression.
l If data is being queued on the source at any time, consider enabling compression.
l If the server CPU utilization is averaging over 85%, be cautious about enabling
compression.
l The higher the level of compression, the higher the CPU utilization will be.
l Do not enable compression if most of the data is inherently compressed. Many image (.jpg,
.gif) and media (.wmv, .mp3, .mpg) files, for example, are already compressed. Some
images files, such as .bmp and .tif, are decompressed, so enabling compression would be
beneficial for those types.
l Compression may improve performance even in high-bandwidth environments.
l Do not enable compression in conjunction with a WAN Accelerator. Use one or the other to
compress Carbonite Migrate data.

All jobs from a single source connected to the same IP address on a target will share the
same compression configuration.

Chapter 7 Full server to ESX migration 148

 Bandwidth

Bandwidth limitations are available to restrict the amount of network bandwidth used for
Carbonite Migrate data transmissions. When a bandwidth limit is specified, Carbonite Migrate
never exceeds that allotted amount. The bandwidth not in use by Carbonite Migrate is available
for all other network traffic.

All jobs from a single source connected to the same IP address on a target will share the
same bandwidth configuration.

l Do not limit bandwidth—Carbonite Migrate will transmit data using 100% bandwidth
availability.
l Use a fixed limit—Carbonite Migrate will transmit data using a limited, fixed bandwidth.
Select a Preset bandwidth limit rate from the common bandwidth limit values. The
Bandwidth field will automatically update to the bytes per second value for your selected
bandwidth. This is the maximum amount of data that will be transmitted per second. If
desired, modify the bandwidth using a bytes per second value. The minimum limit should be
3500 bytes per second.
l Use scheduled limits—Carbonite Migrate will transmit data using a dynamic bandwidth
based on the schedule you configure. Bandwidth will not be limited during unscheduled
times.
l New—Click New to create a new scheduled bandwidth limit. Specify the following

information.
l Daytime entry—Select this option if the start and end times of the bandwidth

window occur in the same day (between 12:01 AM and midnight). The start
time must occur before the end time.
l Overnight entry—Select this option if the bandwidth window begins on one

day and continues past midnight into the next day. The start time must be later
than the end time, for example 6 PM to 6 AM.
l Day—Enter the day on which the bandwidth limiting should occur. You can

pick a specific day of the week, Weekdays to have the limiting occur Monday
through Friday, Weekends to have the limiting occur Saturday and Sunday, or
Every day to have the limiting repeat on all days of the week.
l Start time—Enter the time to begin bandwidth limiting.

l End time—Enter the time to end bandwidth limiting.

l Preset bandwidth—Select a bandwidth limit rate from the common

bandwidth limit values. The Bandwidth field will automatically update to the
bytes per second value for your select bandwidth.
l Bandwidth—If desired, modify the bandwidth using a bytes per second value.

The minimum limit should be 3500 bytes per second.

Chapter 7 Full server to ESX migration 149

 l Edit—Click Edit to modify an existing scheduled bandwidth limit.
l Delete—Click Delete to remove a scheduled bandwidth limit.

If you change your job option from Use scheduled limits to Do not limit
bandwidth or Use a fixed limit, any schedule that you created will be preserved.
That schedule will be reused if you change your job option back to Use scheduled
limits.

You can manually override a schedule after a job is established by selecting Other
Job Options, Set Bandwidth. If you select No bandwidth limit or Fixed
bandwidth limit, that manual override will be used until you go back to your
schedule by selecting Other Job Options, Set Bandwidth, Scheduled
bandwidth limit. For example, if your job is configured to use a daytime limit, you
would be limited during the day, but not at night. But if you override that, your
override setting will continue both day and night, until you go back to your schedule.
See the Managing and controlling jobs section for your job type for more
information on the Other Job Options.

10. Click Next to continue.

11. Carbonite Migrate validates that your source and target are compatible. The Summary page
displays your options and validation items.
Errors are designated by a white X inside a red circle. Warnings are designated by a black
exclamation point (!) inside a yellow triangle. A successful validation is designated by a white
checkmark inside a green circle. Errors are sorted at the top of the list, then warnings, then
success messages. Click on any of the validation items to see details. You must correct any errors
before you can continue. Depending on the error, you may be able to click Fix or Fix All and let
Carbonite Migrate correct the problem for you. For those errors that Carbonite Migrate cannot
correct automatically, you will need to modify the source or target to correct the error, or you can
select a different target. You must revalidate the selected servers, by clicking Recheck, until the
validation check passes without errors. Click the Common Job Validation Warnings and
Errors link to open a web browser and view solutions to common validation warnings and errors.
If you receive a path transformation error during job validation indicating a volume does not exist
on the target server, even though there is no corresponding data being protected on the source,
you will need to manually modify your replication rules. Go back to the Choose Data page and
under the Replication Rules, locate the volume from the error message. Remove any rules
associated with that volume. Complete the rest of the workflow and the validation should pass.
After a job is created, the results of the validation checks are logged to the job log. See the
Carbonite Availability and Carbonite Migrate Reference Guide for details on the various
Carbonite Migrate log files.
12. Once your servers have passed validation and you are ready to begin migration, click Finish, and
you will automatically be taken to the Jobs page.

Jobs in a NAT environment may take longer to start.

Once a job is created, do not change the name of underlying hardware components used in the
job. For example, volume names, network adapter names, or virtual switch names. Any
component used by name in your job must continue to use that name throughout the lifetime of

Chapter 7 Full server to ESX migration 150

 job. If you must change a name, you will need to delete the job and re-create it using the new
component name.

Chapter 7 Full server to ESX migration 151

Managing and controlling full server to ESX migration
jobs
Click Jobs from the main Carbonite Replication Console toolbar. The Jobs page allows you to view
status information about your jobs. You can also control your jobs from this page.
The jobs displayed in the right pane depend on the server group folder selected in the left pane. Every
job for each server in your console session is displayed when the Jobs on All Servers group is
selected. If you have created and populated server groups (see Managing servers on page 15), then
only the jobs associated with the server or target servers in that server group will be displayed in the right
pane.
l Overview job information displayed in the top right pane on page 152
l Detailed job information displayed in the bottom right pane on page 155
l Job controls on page 157

Overview job information displayed in the top right pane

The top pane displays high-level overview information about your jobs. You can sort the data within a
column in ascending and descending order. You can also move the columns to the left or right of each
other to create your desired column order. The list below shows the columns in their default left to right
order.
If you are using server groups, you can filter the jobs displayed in the top right pane by expanding the
Server Groups heading and selecting a server group.

Column 1 (Blank)
The first blank column indicates the state of the job.

A green circle with a white checkmark indicates the job is in a healthy state. No
action is required.

A yellow triangle with a black exclamation point indicates the job is in a pending or
warning state. This icon is also displayed on any server groups that you have created
that contain a job in a pending or warning state. Carbonite Migrate is working or waiting
on a pending process or attempting to resolve the warning state.

A red circle with a white X indicates the job is in an error state. This icon is also
displayed on any server groups that you have created that contain a job in an error
state. You will need to investigate and resolve the error.

The job is in an unknown state.

Job
The name of the job

Chapter 7 Full server to ESX migration 152

Source Server
The name of the source. This could be the name or IP address of your source.
Target Server
The name of the target. This could be the name or IP address of your target.
Job Type
Each job type has a unique job type name. This job is a Full Server to ESX Migration
job. For a complete list of all job type names, press F1 to view the Carbonite Replication
Console online help.
Activity
There are many different Activity messages that keep you informed of the job activity.
Most of the activity messages are informational and do not require any administrator
interaction. If you see error messages, check the job details. Keep in mind that Idle
indicates console to server activity is idle, not that your servers are idle.
Mirror Status
l Calculating—The amount of data to be mirrored is being calculated.
l In Progress—Data is currently being mirrored.
l Waiting—Mirroring is complete, but data is still being written to the target.
l Idle—Data is not being mirrored.
l Paused—Mirroring has been paused.
l Stopped—Mirroring has been stopped.
l Removing Orphans—Orphan files on the target are being removed or deleted
depending on the configuration.
l Verifying—Data is being verified between the source and target.
l Unknown—The console cannot determine the status.
Replication Status
l Replicating—Data is being replicated to the target.
l Ready—There is no data to replicate.
l Pending—Replication is pending.
l Stopped—Replication has been stopped.
l Out of Memory—Replication memory has been exhausted.
l Failed—The Double-Take service is not receiving replication operations from the
Carbonite Migrate driver. Check the Event Viewer for driver related issues.
l Unknown—The console cannot determine the status.
Transmit Mode
l Active—Data is being transmitted to the target.
l Paused—Data transmission has been paused.
l Scheduled—Data transmission is waiting on schedule criteria.
l Stopped—Data is not being transmitted to the target.

Chapter 7 Full server to ESX migration 153

 l Error—There is a transmission error.
l Unknown—The console cannot determine the status.
Operating System
The job type operating system

Chapter 7 Full server to ESX migration 154

Detailed job information displayed in the bottom right pane
The details displayed in the bottom pane provide additional information for the job highlighted in the top
pane. You can expand or collapse the bottom pane by clicking on the Job Highlights heading.

Name
The name of the job
Target data state
l OK—The data on the target is in a good state.
l Mirroring—The target is in the middle of a mirror process. The data will not be in a
good state until the mirror is complete.
l Mirror Required—The data on the target is not in a good state because a remirror
is required. This may be caused by an incomplete or stopped mirror or an operation
may have been dropped on the target.
l Busy—The source is low on memory causing a delay in getting the state of the data
on the target.
l Not Loaded—Carbonite Migrate target functionality is not loaded on the target
server. This may be caused by a license key error.
l Not Ready—The Linux drivers have not yet completed loading on the target.
l Unknown—The console cannot determine the status.
Mirror remaining
The total number of mirror bytes that are remaining to be sent from the source to the
target.
Mirror skipped
The total number of bytes that have been skipped when performing a difference mirror.
These bytes are skipped because the data is not different on the source and target.
Replication queue
The total number of replication bytes in the source queue
Disk queue
The amount of disk space being used to queue data on the source
Recovery point latency
The length of time replication is behind on the target compared to the source. This is the
time period of replication data that would be lost if a failure were to occur at the current
time. This value represents replication data only and does not include mirroring data. If
you are mirroring and failover, the data on the target will be at least as far behind as the
recovery point latency. It could potentially be further behind depending on the
circumstances of the mirror. If mirroring is idle and you failover, the data will only be as
far behind as the recovery point latency time.

Chapter 7 Full server to ESX migration 155

Bytes sent
The total number of mirror and replication bytes that have been transmitted to the
target
Bytes sent (compressed)
The total number of compressed mirror and replication bytes that have been
transmitted to the target. If compression is disabled, this statistic will be the same as
Bytes sent.
Connected since
The date and time indicating when the current job was started. This is the current time
where the console is running.
Recent activity
Displays the most recent activity for the selected job, along with an icon indicating the
success or failure of the last initiated activity. Click the link to see a list of recent activities
for the selected job. You can highlight an activity in the list to display additional details
about the activity.
Additional information
Depending on the current state of your job, you may see additional information
displayed to keep you informed about the progress and status of your job. If there is no
additional information, you will see (None) displayed. Click the Why are file write
operations retrying link to open a web browser and view solutions to common
causes of retrying file write operations.

Chapter 7 Full server to ESX migration 156

Job controls
You can control your job through the toolbar buttons available on the Jobs page. If you select multiple
jobs, some of the controls will apply only to the first selected job, while others will apply to all of the
selected jobs. For example, View Job Details will only show details for the first selected job, while Stop
will stop protection for all of the selected jobs.
If you want to control just one job, you can also right click on that job and access the controls from the
pop-up menu.

View Job Details

This button leaves the Jobs page and opens the View Job Details page.

Edit Job Properties

This button leaves the Jobs page and opens the Edit Job Properties page.

Delete
Stops (if running) and deletes the selected jobs.

Provide Credentials
Changes the login credentials that the job (which is on the target machine) uses to
authenticate to the servers in the job. This button opens the Provide Credentials dialog
box where you can specify the new account information and which servers you want to
update.

View Recent Activity

Displays the recent activity list for the selected job. Highlight an activity in the list to
display additional details about the activity.

Start
Starts or resumes the selected jobs.
If you have previously stopped protection, the job will restart mirroring and replication.
If you have previously paused protection, the job will continue mirroring and replication
from where it left off, as long as the Carbonite Migrate queue was not exhausted during
the time the job was paused. If the Carbonite Migrate queue was exhausted during the
time the job was paused, the job will restart mirroring and replication.
Also if you have previously paused protection, all jobs from the same source to the
same IP address on the target will be resumed.

Chapter 7 Full server to ESX migration 157

Pause
Pauses the selected jobs. Data will be queued on the source while the job is paused.
All jobs from the same source to the same IP address on the target will be paused.

Stop
Stops the selected jobs. The jobs remain available in the console, but there will be no
mirroring or replication data transmitted from the source to the target. Mirroring and
replication data will not be queued on the source while the job is stopped, requiring a
remirror when the job is restarted. The type of remirror will depend on your job settings.

Take Snapshot
Snapshots are not applicable to migration jobs.

Manage Snapshots
Snapshots are not applicable to migration jobs.

Failover or Cutover
Starts the cutover process. See Cutting over full server to ESX migration jobs on page
171 for the process and details of cutting over a full server to ESX migration job.

Failback
Starts the failback process. Failback does not apply to migration jobs.

Restore
Starts the restoration process. Restore does not apply to migration jobs.

Reverse
Reverses protection. Reverse protection does not apply to migration jobs.

Undo Failover or Cutover

Cancels a test failover by undoing it. Undo failover does not apply to full server to
ESX migration jobs.

View Job Log

Opens the job log. On the right-click menu, this option is called View Logs, and you
have the option of opening the job log, source server log, or target server log.

Chapter 7 Full server to ESX migration 158

Other Job Actions
Opens a small menu of other job actions. These job actions will be started immediately,
but keep in mind that if you stop and restart your job, the job's configured settings will
override any other job actions you may have initiated.
l Mirroring—You can start, stop, pause and resume mirroring for any job that is
running.
When pausing a mirror, Carbonite Migrate stops queuing mirror data on the source
but maintains a pointer to determine what information still needs to be mirrored to
the target. Therefore, when resuming a paused mirror, the process continues where
it left off.
When stopping a mirror, Carbonite Migrate stops queuing mirror data on the source
and does not maintain a pointer to determine what information still needs to be
mirrored to the target. Therefore, when starting a mirror that has been stopped, you
will need to decide what type of mirror to perform.
l Mirror Options—Choose a comparison method and whether to mirror the
entire file or only the bytes that differ in each file.
l Do not compare files. Send the entire file.—Carbonite Migrate will
not perform any comparisons between the files on the source and
target. All files will be mirrored to the target, sending the entire file. This
option requires no time for comparison, but the mirror time can be
slower because it sends the entire file. However, it is useful for
configurations that have large data sets with millions of small files that
are frequently changing and it is more efficient to send the entire file.
You may also need to use this option if configuration management
policies require sending the entire file.
l Compare file attributes. Send the attributes and bytes that
differ.—Carbonite Migrate will compare file attributes and will mirror
only the attributes and bytes that are different. This option is the fastest
comparison method and fastest mirror speed. Files that have not
changed can be easily skipped. Also files that are open and require a
checksum mirror can be compared.
l Compare file attributes and data. Send the attributes and bytes
that differ.—Carbonite Migrate will compare file attributes and the file
data and will mirror only the attributes and bytes that are different. This
comparison method is not as fast because every file is compared,
regardless of whether the file has changed or is open. However,
sending only the attributes and bytes that differ is the fastest mirror
speed.

If a file is small enough that mirroring the entire file is faster than
comparing it and then mirroring it, Carbonite Availability will
automatically mirror the entire file.

Chapter 7 Full server to ESX migration 159

 l Calculate size of protected data before mirroring—Specify if you want
Carbonite Migrate to determine the mirroring percentage calculation based
on the amount of data being protected. If you enable this option, the
calculation will begin when mirroring begins. For the initial mirror, the
percentage will display after the calculation is complete, adjusting to the
amount of the mirror that has completed during the time it took to complete the
calculation. Subsequent mirrors will initially use the last calculated size and
display an approximate percentage. Once the calculation is complete, the
percentage will automatically adjust down or up to indicate the amount that
has been completed. Disabling calculation will result in the mirror status not
showing the percentage complete or the number of bytes remaining to be
mirrored.

The calculated amount of protected data may be slightly off if your

data set contains compressed or sparse files.

l Verify—Even if you have scheduled the verification process, you can run it manually
any time a mirror is not in progress.
l Report only—Select this option if you only want to generate a verification

report. With this option, no data that is found to be different will be mirrored to
the target. Choose how you want the verification to compare the files.
l Report and mirror files—Select this option if you want to generate a
verification report and mirror data that is different to the target. Select the
comparison method and type of mirroring you want to use. See the previous
mirroring methods described under Mirror Options.
l Set Bandwidth—You can manually override bandwidth limiting settings configured
for your job at any time.
l No bandwidth limit—Carbonite Migrate will transmit data using 100%

bandwidth availability.
l Fixed bandwidth limit—Carbonite Migrate will transmit data using a limited,

fixed bandwidth. Select a Preset bandwidth limit rate from the common
bandwidth limit values. The Bandwidth field will automatically update to the
bytes per second value for your selected bandwidth. This is the maximum
amount of data that will be transmitted per second. If desired, modify the
bandwidth using a bytes per second value. The minimum limit should be 3500
bytes per second.
l Scheduled bandwidth limit—If your job has a configured scheduled

bandwidth limit, you can enable that schedule with this option.
l Delete Orphans—Even if you have enabled orphan file removal during your mirror
and verification processes, you can manually remove them at any time.
l Target—You can pause the target, which queues any incoming Carbonite Migrate
data from the source on the target. All active jobs to that target will complete the
operations already in progress. Any new operations will be queued on the target
until the target is resumed. The data will not be committed until the target is
resumed. Pausing the target only pauses Carbonite Migrate processing, not the
entire server.

Chapter 7 Full server to ESX migration 160

 While the target is paused, the Carbonite Migrate target cannot queue data
indefinitely. If the target queue is filled, data will start to queue on the source. If the
source queue is filled, Carbonite Migrate will automatically disconnect the
connections and attempt to reconnect them.
If you have multiple jobs to the same target, all jobs from the same source will be
paused and resumed.
l Refresh Status—Refreshes the job status immediately.
Filter
Select a filter option from the drop-down list to only display certain jobs. You can display
Healthy jobs, Jobs with warnings, or Jobs with errors. To clear the filter, select
All jobs. If you have created and populated server groups, then the filter will only apply
to the jobs associated with the server or target servers in that server group. See
Managing servers on page 15.
Search
Allows you to search the source or target server name for items in the list that match the
criteria you have entered.

Overflow Chevron
Displays any toolbar buttons that are hidden from view when the window size is
reduced.

Chapter 7 Full server to ESX migration 161

Viewing full server to ESX migration job details
From the Jobs page, highlight the job and click View Job Details in the toolbar.
Review the following table to understand the detailed information about your job displayed on the View
Job Details page.

Job name
The name of the job
Job type
Each job type has a unique job type name. This job is a Full Server to ESX Migration
job. For a complete list of all job type names, press F1 to view the Carbonite Replication
Console online help.
Health

The job is in a healthy state.

The job is in a warning state.

The job is in an error state.

The job is in an unknown state.

Activity
There are many different Activity messages that keep you informed of the job activity.
Most of the activity messages are informational and do not require any administrator
interaction. If you see error messages, check the rest of the job details.
Connection ID
The incremental counter used to number connections. The number is incremented
when a connection is created. The counter is reset if there are no existing jobs and the
Double-Take service is restarted.
Transmit mode
l Active—Data is being transmitted to the target.
l Paused—Data transmission has been paused.
l Scheduled—Data transmission is waiting on schedule criteria.
l Stopped—Data is not being transmitted to the target.
l Error—There is a transmission error.
l Unknown—The console cannot determine the status.

Chapter 7 Full server to ESX migration 162

Target data state
l OK—The data on the target is in a good state.
l Mirroring—The target is in the middle of a mirror process. The data will not be in a
good state until the mirror is complete.
l Mirror Required—The data on the target is not in a good state because a remirror
is required. This may be caused by an incomplete or stopped mirror or an operation
may have been dropped on the target.
l Busy—The source is low on memory causing a delay in getting the state of the data
on the target.
l Not Loaded—Carbonite Migrate target functionality is not loaded on the target
server. This may be caused by a license key error.
l Not Ready—The Linux drivers have not yet completed loading on the target.
l Unknown—The console cannot determine the status.
Target route
The IP address on the target used for Carbonite Migrate transmissions.
Compression
l On / Level—Data is compressed at the level specified.
l Off—Data is not compressed.
Encryption
l On—Data is being encrypted before it is sent from the source to the target.
l Off—Data is not being encrypted before it is sent from the source to the target.
Bandwidth limit
If bandwidth limiting has been set, this statistic identifies the limit. The keyword
Unlimited means there is no bandwidth limit set for the job.
Connected since
The source server date and time indicating when the current job was started. This field
is blank, indicating that a TCP/IP socket is not present, when the job is waiting on
transmit options or if the transmission has been stopped. This field will maintain the
date and time, indicating that a TCP/IP socket is present, when transmission has been
paused.
Additional information
Depending on the current state of your job, you may see additional information
displayed to keep you informed about the progress and status of your job. If there is no
additional information, you will see (None) displayed. Click the Why are file write
operations retrying link to open a web browser and view solutions to common
causes of retrying file write operations.

Chapter 7 Full server to ESX migration 163

Mirror status
l Calculating—The amount of data to be mirrored is being calculated.
l In Progress—Data is currently being mirrored.
l Waiting—Mirroring is complete, but data is still being written to the target.
l Idle—Data is not being mirrored.
l Paused—Mirroring has been paused.
l Stopped—Mirroring has been stopped.
l Removing Orphans—Orphan files on the target are being removed or deleted
depending on the configuration.
l Verifying—Data is being verified between the source and target.
l Unknown—The console cannot determine the status.
Mirror percent complete
The percentage of the mirror that has been completed
Mirror remaining
The total number of mirror bytes that are remaining to be sent from the source to the
target.
Mirror skipped
The total number of bytes that have been skipped when performing a difference mirror.
These bytes are skipped because the data is not different on the source and target.
Replication status
l Replicating—Data is being replicated to the target.
l Ready—There is no data to replicate.
l Pending—Replication is pending.
l Stopped—Replication has been stopped.
l Out of Memory—Replication memory has been exhausted.
l Failed—The Double-Take service is not receiving replication operations from the
Carbonite Migrate driver. Check the Event Viewer for driver related issues.
l Unknown—The console cannot determine the status.
Replication queue
The total number of replication bytes in the source queue
Disk queue
The amount of disk space being used to queue data on the source
Bytes sent
The total number of mirror and replication bytes that have been transmitted to the
target

Chapter 7 Full server to ESX migration 164

Bytes sent compressed
The total number of compressed mirror and replication bytes that have been
transmitted to the target. If compression is disabled, this statistic will be the same as
Bytes sent.
Recovery point latency
The length of time replication is behind on the target compared to the source. This is the
time period of replication data that would be lost if a failure were to occur at the current
time. This value represents replication data only and does not include mirroring data. If
you are mirroring and failover, the data on the target will be at least as far behind as the
recovery point latency. It could potentially be further behind depending on the
circumstances of the mirror. If mirroring is idle and you failover, the data will only be as
far behind as the recovery point latency time.
Mirror start time
The UTC time when mirroring started
Mirror end time
The UTC time when mirroring ended
Total time for last mirror
The length of time it took to complete the last mirror process

Chapter 7 Full server to ESX migration 165

Validating a full server to ESX migration job
Over time, you may want to confirm that any changes in your network or environment have not impacted
your Carbonite Migrate job. Use these instructions to validate an existing job.
1. From the Jobs page, highlight the job and click View Job Details in the toolbar.
2. In the Tasks area on the right on the View Job Details page, click Validate job properties.
3. Carbonite Migrate validates that your source and target are compatible. The Summary page
displays your options and validation items.
Errors are designated by a white X inside a red circle. Warnings are designated by a black
exclamation point (!) inside a yellow triangle. A successful validation is designated by a white
checkmark inside a green circle. Errors are sorted at the top of the list, then warnings, then
success messages. Click on any of the validation items to see details. You must correct any errors
before you can continue. Depending on the error, you may be able to click Fix or Fix All and let
Carbonite Migrate correct the problem for you. For those errors that Carbonite Migrate cannot
correct automatically, you will need to modify the source or target to correct the error, or you can
select a different target. You must revalidate the selected servers, by clicking Recheck, until the
validation check passes without errors. Click the Common Job Validation Warnings and
Errors link to open a web browser and view solutions to common validation warnings and errors.
Validation checks for an existing job are logged to the job log on the target server.
4. Once your servers have passed validation, click Close.

Chapter 7 Full server to ESX migration 166

Editing a full server to ESX migration job
Use these instructions to edit a full server to ESX migration job.
1. From the Jobs page, highlight the job and click Edit Job Properties in the toolbar. (You will not
be able to edit a job if you have removed the source of that job from your Carbonite Replication
Console session or if you only have Carbonite Migrate monitor security access.)
2. You will see the same options available for your full server to ESX migration job as when you
created the job, but you will not be able to edit all of them. If desired, edit those options that are
configurable for an existing job. See Creating a full server to ESX migration job on page 133 for
details on each job option.

Changing some options may require Carbonite Migrate to automatically disconnect,

reconnect, and remirror the job.

If you have specified replication rules that exclude a volume at the root, that volume will be
incorrectly added as an inclusion if you edit the job after it has been established. If you
need to edit your job, modify the replication rules to make sure they include the proper
inclusion and exclusion rules that you want.

3. If you want to modify the workload items or replication rules for the job, click Edit workload or
replication rules. Modify the Workload item you are protecting, if desired. Additionally, you can
modify the specific Replication Rules for your job.
Volumes and folders with a green highlight are included completely. Volumes and folders
highlighted in light yellow are included partially, with individual files or folders included. If there is
no highlight, no part of the volume or folder is included. To modify the items selected, highlight a
volume, folder, or file and click Add Rule. Specify if you want to Include or Exclude the item.
Also, specify if you want the rule to be recursive, which indicates the rule should automatically be
applied to the subdirectories of the specified path. If you do not select Recursive, the rule will not
be applied to subdirectories.
You can also enter wildcard rules, however you should do so carefully. Rules are applied to files
that are closest in the directory tree to them. If you have rules that include multiple folders, an
exclusion rule with a wild card will need to be added for each folder that it needs applied to. For
example, if you want to exclude all .log files from /home and your rules include /home,
/home/folder1, and /home/folder2, you would need to add the exclusion rule for the root and each
subfolder rule. So you will need to add exclude rules for /home/*.log , /home/folder1/*.log, and
/home/folder2/*.log.
If you need to remove a rule, highlight it in the list at the bottom and click Remove Rule. Be
careful when removing rules. Carbonite Migrate may create multiple rules when you are adding
directories. For example, if you add /home/admin to be included in protection, then /home will be
excluded. If you remove the /home exclusion rule, then the /home/admin rule will be removed
also.
Click OK to return to the Edit Job Properties page.

Chapter 7 Full server to ESX migration 167

 If you remove data from your workload and that data has already been sent to the target,
you will need to manually remove that data from the target. Because the data you
removed is no longer included in the replication rules, Carbonite Migrate orphan file
detection cannot remove the data for you. Therefore, you have to remove it manually.

4. Click Next to continue.

5. Carbonite Migrate validates that your source and target are compatible. The Summary page
displays your options and validation items.
Errors are designated by a white X inside a red circle. Warnings are designated by a black
exclamation point (!) inside a yellow triangle. A successful validation is designated by a white
checkmark inside a green circle. Errors are sorted at the top of the list, then warnings, then
success messages. Click on any of the validation items to see details. You must correct any errors
before you can continue. Depending on the error, you may be able to click Fix or Fix All and let
Carbonite Migrate correct the problem for you. For those errors that Carbonite Migrate cannot
correct automatically, you will need to modify the source or target to correct the error, or you can
select a different target. You must revalidate the selected servers, by clicking Recheck, until the
validation check passes without errors. Click the Common Job Validation Warnings and
Errors link to open a web browser and view solutions to common validation warnings and errors.
If you receive a path transformation error during job validation indicating a volume does not exist
on the target server, even though there is no corresponding data being protected on the source,
you will need to manually modify your replication rules. Go back to the Choose Data page and
under the Replication Rules, locate the volume from the error message. Remove any rules
associated with that volume. Complete the rest of the workflow and the validation should pass.
After a job is created, the results of the validation checks are logged to the job log. See the
Carbonite Availability and Carbonite Migrate Reference Guide for details on the various
Carbonite Migrate log files.
6. Once your servers have passed validation and you are ready to update your job, click Finish.

Chapter 7 Full server to ESX migration 168

Viewing a full server to ESX migration job log
You can view a job log file through the Carbonite Replication Console by selecting View Job Log from
the toolbar on the Jobs page. Separate logging windows allow you to continue working in the Carbonite
Replication Console while monitoring log messages. You can open multiple logging windows for
multiple jobs. When the Carbonite Replication Console is closed, all logging windows will automatically
close.

Because the job log window communicates with the target server, if the console loses
communication with the target server after the job log window has already been opened, the job
log window will display an error.

The following table identifies the controls and the table columns in the Job logs window.

Start
This button starts the addition and scrolling of new messages in the window.

Pause
This button pauses the addition and scrolling of new messages in the window. This is
only for the Job logs window. The messages are still logged to their respective files on
the server.

Chapter 7 Full server to ESX migration 169

Copy
This button copies the messages selected in the Job logs window to the Windows
clipboard.

Clear
This button clears the Job logs window. The messages are not cleared from the
respective files on the server. If you want to view all of the messages again, close and
reopen the Job logs window.
Time
This column in the table indicates the date and time when the message was logged.
Description
This column in the table displays the actual message that was logged.

Chapter 7 Full server to ESX migration 170

Cutting over full server to ESX migration jobs
When the migration mirror has completed, the target may or may not reboot automatically depending on
your selection for user intervention. If you disabled user intervention, the target will reboot automatically
to complete the migration process. If you enabled user intervention, when the migration mirror is
complete, the status will change to Protecting. Use this time to complete any necessary tasks. When
you are ready to complete the migration, use the following instructions to cutover.
1. On the Jobs page, highlight the job that you want to cutover and click Failover or Cutover in the
toolbar.
2. Select the type of cutover to perform.
l Cutover to live data—Select this option to initiate a full, live cutover using the current data

on the target. The source may be automatically shut down if it is still running, depending on
your job configuration. The protection job is stopped and the replica virtual machine is
started on the target with full network connectivity.
l Perform test failover—This option is not applicable to full server to ESX migration jobs.

l Cutover to a snapshot—This option is not available for migration jobs.

3. Select how you want to handle the data in the target queue.
l Apply data in target queues before failover or cutover—All of the data in the target

queue will be applied before cutover begins. The advantage to this option is that all of the
data that the target has received will be applied before cutover begins. The disadvantage to
this option is depending on the amount of data in queue, the amount of time to apply all of
the data could be lengthy.
l Discard data in the target queues and failover or cutover immediately—All of the

data in the target queue will be discarded and cutover will begin immediately. The
advantage to this option is that cutover will occur immediately. The disadvantage is that any
data in the target queue will be lost.
4. When you are ready to begin cutover, click Cutover.

Once cutover has started, do not reboot the target appliance. If the cutover process is
interrupted, it may fail.

Chapter 7 Full server to ESX migration 171

Chapter 8 DTSetup
DTSetup is a menu-driven application that provides easy access to Carbonite Migrate server
configuration. Select a link for more information on DTSetup configuration tasks.
l Running DTSetup on page 173—This topic includes instructions for launching DTSetup.
l Setup tasks on page 174—The setup tasks allow you to configure license keys, security groups,
block device replication configuration, server configuration, and driver performance settings.
l Starting and stopping the service on page 179—Built-in scripts allow you to quickly and easily
start and stop the Carbonite Migrate service.
l Starting DTCL on page 180—You can launch the Carbonite Migrate interactive command prompt
which allows you to enter DTCL commands one at a time.
l Viewing documentation and troubleshooting tools on page 181—DTSetup provides easy access
to Carbonite Migrate log files, a diagnostic collection tool, and several legal documents.
l DTSetup menus on page 182—This topic includes a list overview of the DTSetup menu system.
Reference the links in the list for complete details on completing tasks in DTSetup.

Chapter 8 DTSetup 172

Running DTSetup
1. Run the DTSetup command from the shell prompt to start DTSetup. The command is case-
sensitive.
2. The first time you run DTSetup after an installation, you will be prompted to review the Carbonite
license agreement. Review the agreement and accept the terms of agreement by typing yes. You
cannot use Carbonite Migrate without agreeing to the licensing terms.
3. When the DTSetup menu appears, enter the number of the menu option you want to access.

Chapter 8 DTSetup 173

Setup tasks
The setup tasks are generally configured once. Select a link below to learn more about that setup task.
l Activating your server on page 175—License keys and activation keys license and activate your
Carbonite Migrate servers.
l Modifying security groups on page 176—Security groups provide access to Carbonite Migrate.
l Configuring server settings on page 177—If desired, you can modify server settings through the
Carbonite Migrate configuration file.
l Configuring driver performance settings on page 178—If desired, you can specify Carbonite
Migrate driver performance settings.

Chapter 8 DTSetup 174

Activating your server
Before you can use Carbonite Migrate, each source and target server must have a valid license key,
which is an alpha-numeric codes that applies the appropriate Carbonite Migrate license to your
installation.
1. Start DTSetup. See Running DTSetup on page 173.
2. Select Setup tasks.
3. Select Set License Key Menu.
4. Select Set License Key in /etc/DT/DT.conf.
5. Enter your license key and press Enter. The license key will automatically be inserted into the
configuration file. You are prompted to start the Carbonite Migrate service after the first
installation, and you must restart the service each time the license key is modified, such as after an
upgrade.
6. Press Enter to return to the menu.
7. Press Q as many times as needed to return back to the main menu or to exit DTSetup.

Chapter 8 DTSetup 175

Modifying security groups
During the installation, the user root is automatically added to the Carbonite Migrate administrators
security group. If you want to add other users or remove root, you will need to modify the security group
configuration for each source and target server. See Security on page 183 for more details on the
security groups and the privileges granted to each group.
1. Start DTSetup. See Running DTSetup on page 173.
2. Select Setup tasks.
3. Select Add/Remove users to Double-Take groups.
4. Select the necessary menu options to add or remove groups to the administrator or monitors
group as needed, and specify the user name when prompted.
5. When you have completed your security group modifications, press Q as many times as needed
to return back to the main menu or to exit DTSetup.

Chapter 8 DTSetup 176

Configuring server settings
Server settings are available in various places. You can access them via the Replication Console for
Linux, through DTCL, or through DTSetup. Initially, the server settings file, /etc/DT/DT.conf, on the
source and target is blank. To populate it with default values, start and stop the Double-Take service
once.
1. Start DTSetup. See Running DTSetup on page 173.
2. Select Setup tasks.
3. Select Edit Double-Take config file.
4. The server settings are listed in alphabetical order. Make modifications as necessary, using the
control keys specified at the bottom of the page. For a complete list of each server setting, valid
values, default values, and optional notes, see Server Settings in the Scripting Guide.
5. Press control-X to exit the configuration file.
6. Enter Yes or No to save any changes.
7. Press Q as many times as needed to return back to the main menu or to exit DTSetup.

Chapter 8 DTSetup 177

Configuring driver performance settings
Driver settings provide configuration flexibility so you can adjust Carbonite Migrate based on your
servers, network, and replication requirements. You may want to modify driver settings on both the
source and target.

Changing the driver performance settings can have a positive or negative impact on server
performance. These settings are for advanced users. If you are uncertain how to best modify the
driver performance settings, contact technical support.

1. Start DTSetup. See Running DTSetup on page 173.

2. Select Setup tasks.
3. Select Configure Double-Take driver performance.
4. The current driver settings are displayed.
5. Select a driver setting to modify the option.
l Toggle Adaptive Throttling—You can toggle between enabling (true) and disabling

(false) Adaptive Throttling. This occurs when kernel memory usage exceeds the
Throttling Start Level percentage. When throttling is enabled, operations are delayed by,
at most, the amount of time set in Maximum Throttling Delay, thus reducing kernel
memory usage. Throttling stops when the kernel memory usage drops below the
Throttling Stop Level percentage.
l Toggle Forced Adaptive Throttling—You can toggle between enabling (true) and

disabling (false) Forced Adaptive Throttling. This causes all operations to be delayed by,
at most, the amount of time in set in Maximum Throttling Delay, regardless of the kernel
memory being used. Adaptive Throttling must be enabled (true) in order for Forced
Adaptive Throttling to work.
l Set Maximum Throttling Delay—This option is the maximum time delay, in milliseconds,

used by the driver during a system delay.

l Set Throttling Delay Interval—This option is the interval, in milliseconds, to check

memory usage during a throttling delay. If a delay is no longer needed, the remainder of the
delay is skipped.
l Set Throttling Start Level—Throttling starts when disk writes reach the specified

percentage. This prevents the driver from stopping replication because memory has been
exhausted.
l Set Throttling Stop Level—Throttling stops when disk writes reach the specified

percentage.
l Set Memory Usage Limit—This option is the amount of kernel memory, in bytes, used for

queuing replication operations. When this limit is exceeded, the driver will send an error to
the service forcing a remirror of all active connections.
l Set Maximum Write Buffer Size—This option is the maximum amount of system

memory, in bytes, allowed for a single write operation. Operations exceeding this amount
are split into separate operations in the queue.
6. After you have completed your driver performance modifications, press Q as many times as
needed to return back to the main menu or to exit DTSetup.

Chapter 8 DTSetup 178

Starting and stopping the service
The Double-Take service will start automatically after Carbonite Migrate is installed and the server is
rebooted. You can start and stop the Double-Take service using this built-in DTSetup script.
1. Start DTSetup. See Running DTSetup on page 173.
2. Select Start/Stop Double-Take service.
3. Select the necessary menu option to start or stop the service and handle the driver configuration.
l Start Double-Take and process driver config—This option starts the Double-Take

service and loads the Carbonite Migrate drivers.

l Stop Double-Take but preserve driver config—This option stops the Double-Take

service but does not unload the Carbonite Migrate drivers.

l Restart service but preserve driver config—This option does a full stop and start of the

Double-Take service but does not unload the Carbonite Migrate drivers.
l Restart service and reset driver config—This option does a full stop and start,

completely unloading the Double-Take service and Carbonite Migrate drivers and then
reloading them.
l Stop the running service and teardown driver config—This option stops the Double-

Take service and the Carbonite Migrate drivers are unloaded.

l Go to Replication Configuration menu—This option takes you to Setup Tasks,

Configure Block Device Replication. When you press Q to exit from that menu, you will
return this menu.
4. When you have completed your starting and stopping tasks, press Q as many times as needed to
return back to the main menu or to exit DTSetup.

Chapter 8 DTSetup 179

Starting DTCL
You can launch the Carbonite Migrate interactive command prompt which allows you to enter DTCL
commands one at a time.
1. Start DTSetup. See Running DTSetup on page 173.
2. Select Start User Interface (DTCL -i).
3. Enter your DTCL commands one at a time at the Command prompt. For a complete list of DTCL
commands, their syntax, and instructions for completing tasks using DTCL, see the Scripting
Guide.
4. To exit the DTCL Command prompt, type exit.
5. When you have completed your DTCL tasks, press Q as many times as needed to return back to
the main menu or to exit DTSetup.

Chapter 8 DTSetup 180

Viewing documentation and troubleshooting tools
1. Start DTSetup. See Running DTSetup on page 173.
2. Select Documentation/Troubleshooting tasks.
3. Select View log files to view the following log files. Carbonite Migrate logs alerts, which are
processing notifications, warnings, and error messages. The logs are written to disk.
l View /*.dtl in less—This option uses the less file viewer program to view all of the

Carbonite Migrate logs, starting from the most recent.

l Follow the output of latest—This option uses tail -f to watch the output of the Carbonite

Migrate logs in real-time.

l View /var/log/messages in less—This option uses the less file viewer program to view

the system log messages.

l Follow the output of /var/log/messages—This option uses tail -f to watch the output of

the system log messages in real-time.

4. Select one of the Collect and package diagnostic info selections to run the DTInfo script
which collects configuration data. This can be useful when reporting problems to technical
support. Depending on the diagnostic option you select, the amount of data to be collected varies
between basic, detailed and full diagnostic information. You must have root (or uid 0 equivalent) to
execute the diagnostics or to copy or read the resulting file.
5. Select View user documentation to view several legal documents. DTSetup attempts to
determine your viewers, although you can specify your viewer.
l View End User License Agreement TXT—This option views the End User License

Agreement legal document.

l View driver module license TXT—This option views the open source legal document.

l Change a document viewer—This option allows you to specify a document viewer.

6. When you have completed your documentation and troubleshooting tasks, press Q as many times
as needed to return back to the main menu or to exit DTSetup.

Chapter 8 DTSetup 181

DTSetup menus
The following lists is an overview of the DTSetup menu system. Reference the links for complete details
on completing tasks in DTSetup.
1. Setup tasks—License keys, security groups, replication configuration, server configuration, and
driver performance settings. See Setup tasks on page 174.
1. Set License Key Menu—See Activating your server on page 175.
2. Add/Remove users to Double-Take groups—See Modifying security groups on page
176.
3. Edit Double-Take config file—See Configuring server settings on page 177.
4. Configure Double-Take driver performance—See Configuring driver performance
settings on page 178.
2. Start/Stop Double-Take service—See Starting and stopping the service on page 179.
3. Start User Interface (DTCL -i)—See Starting DTCL on page 180.
4. Documentation/Troubleshooting tasks—See Viewing documentation and troubleshooting
tools on page 181.

Chapter 8 DTSetup 182

Chapter 9 Security
To ensure protection of your data, Carbonite Migrate offers multi-level security using native operating
system security features. Privileges are granted through membership in user groups defined on each
machine. To gain access to a source or target, the user must provide a valid local user account that is a
member of one of the Carbonite Migrate security groups. Once a valid user name and password have
been provided and the source or target has verified membership in one of the security groups, the user is
granted appropriate access to the source or target and the corresponding features are enabled in the
client. Access is granted on one of the following three levels.
l Administrator Access—All features are available for that machine.
l Monitor Access—Servers and statistics can be viewed, but functionality is not available.
l No Access—Servers appear in the clients, but no access to view the server details is available.
Although passwords are encrypted when they are stored, Carbonite security design does assume that
any machine running the client application is protected from unauthorized access. If you are running the
client and step away from your machine, you must protect your machine from unauthorized access.

Chapter 9 Security 183

Adding users to the security groups
The security groups are automatically created during the installation process.
Users that need administrator access to Carbonite Migrate must be added to the dtadmin group. Users
that need monitor only access must be added to the dtmon group. In both cases, you must provide a
valid local or LDAP user account.
1. Run the DTSetup command from the shell prompt. The command is case-sensitive.
2. Select Setup tasks.
3. Select Add/Remove users to Double-Take groups.
4. Select the necessary menu options to add or remove groups to the administrator or monitors
group as needed, and specify the user name when prompted.
5. When you have completed your security group modifications, press Q as many times as needed
to return back to the main menu or to exit DTSetup.

Chapter 9 Security 184

Chapter 10 Special network configurations
Carbonite Migrate can be implemented with very little configuration necessary in small or simple
networks, but additional configuration may be required in large or complex environments. Because an
infinite number of network configurations and environments exist, it is difficult to identify all of the
possible configurations. Review the following sections for configuration information for that particular
type of network environment.
l Firewalls on page 186
l NAT on page 187

Chapter 10 Special network configurations 185

Firewalls
If your source and target are on opposite sides of a firewall, you will need to configure your hardware to
accommodate communications. You must have the hardware already in place and know how to
configure the hardware ports. If you do not, see the reference manual for your hardware.
l Carbonite Migrate ports—Ports 1500, 1505, 1506, 6325, and 6326 are used for Carbonite
Migrate communications and must be open on your firewall. Open UDP and TCP for both
inbound and outbound traffic.
l ESX ports—If you are using VirtualCenter or an ESX host, port 443 is also required and must be
opened.
You need to configure your hardware so that the Carbonite Migrate ports and ESX ports applicable to
your environment are open. Since communication occurs bidirectionally, make sure you configure both
incoming and outgoing traffic.
There are many types of hardware on the market, and each can be configured differently. See your
hardware reference manual for instructions on setting up your particular router.

Chapter 10 Special network configurations 186

NAT
As outlined in the requirements, Carbonite Migrate supports NAT environments with the following
caveats.
l Only IPv4 is supported.
l Only standalone servers are supported.
l DNS failover and updates will depend on your configuration
l Only the source or target can be behind a router, not both.

l The DNS server must be routable from the target

When setting up a job in an environment with IP or port forwarding, make sure you specify the following
configurations.
l Make sure you have added your server to the Carbonite Replication Console using the correct
public or private IP address. The name or IP address you use to add a server to the console is
dependent on where you are running the console. Specify the private IP address of any servers
on the same side of the router as the console. Specify the public IP address of any servers on the
other side of the router as the console. This option is on the Add Servers page in the Manual
Entry tab.

Chapter 10 Special network configurations 187

 l When choosing the target server for your job, you may be prompted for a route from the target to
the source. This route, and a port if you are using a non-default port, is used so the target can
communicate with the source to build job options. This dialog box will be displayed, only if needed,
after you click Next on the Choose Target page in the job creation wizard.

Chapter 10 Special network configurations 188