Review the installation notes below before beginning an installation or upgrade.
- Requirements—Although the installations are shared between Carbonite Availability and Carbonite Migrate products, the requirements for each Carbonite Availability and Carbonite Migrate product and each job type within each product are unique. Be sure and review the requirements for your product and job type in that product's User's Guide or in the Carbonite Replication Console help.
- Prerequisites—Installation prerequisites depend on your operating system.
- Windows—The Carbonite Availability and Carbonite Migrate Windows installation will automatically install the following software, if they are not installed already.
- Microsoft .NET 4.8 Full Setup—This package is installed on all supported Windows operating systems.
- Visual C++ Runtimes—One or more of these packages are installed on all supported Windows operating systems. The required packages depend on your Windows version and what is already installed.
Linux—Each Linux server must have the following packages and services installed before you can install and use Carbonite Availability and Carbonite Migrate. See your operating system documentation for details on these packages and utilities.
- sshd (or the package that installs sshd)
- lsb
- parted
- dmidecode
- scp
- which
- libnsl (only required for Red Hat Enterprise Linux, Oracle Enterprise Linux, and CentOS version 8.0 and later)
- Windows—The Carbonite Availability and Carbonite Migrate Windows installation will automatically install the following software, if they are not installed already.
- Operating system upgrade—Because Carbonite Availability and Carbonite Migrate have operating system dependent files, if you are upgrading your operating system (to a new major version, not a service pack) and have Carbonite Availability and Carbonite Migrate installed, you must remove Carbonite Availability and Carbonite Migrate prior to the operating system upgrade. Uninstall Carbonite Availability and Carbonite Migrate, perform the operating system upgrade, and then reinstall Carbonite Availability and Carbonite Migrate. Also, if you have upgraded the guest Windows operating system on a Hyper-V virtual machine that you intend to protect or migrate, you must also upgrade Integration Services on that virtual machine.
- Windows servers—The following notes are specific to Windows servers.
- Since Carbonite Availability and Carbonite Migrate install device drivers, it is recommended that you update your Windows Recovery Disk before installing or making changes to your servers. For detailed instructions on creating a recovery disk, see your Windows reference manuals. Make sure that you select the option to back up the registry when building the repair disks.
- If you are installing to a drive other than the drive which contains your system TEMP directory, the Microsoft Windows Installer will still load approximately 100 MB of data to the TEMP directory during the installation. If you do not have enough disk space on the drive that contains the TEMP directory, you may need to change its location.
- If during the installation you receive the message that the wizard was interrupted before the installation could be completed, you will need to delete the registry value DefaultAccessPermissions under the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole key in order to install Carbonite Availability and Carbonite Migrate. This registry setting denies permissions for retrieving and setting property values. Deleting this registry setting will not have a negative impact on your server.
- Version interoperability—Carbonite Availability and Carbonite Migrate have different interoperability requirements for different products.
- Carbonite Availability—Version 8.5 is interoperable back to version 8.3 but is restricted to the following limitations. The Carbonite Availability clients can only control the same or older releases. To accommodate rolling upgrades, older sources can connect to newer targets, but newer sources cannot connect to older targets.
- 8.3 console—Supports 8.3 source and target, but does not support 8.4 or 8.5 source or target
- 8.4 console—Supports 8.3 or 8.4 source and target as long as the target is the same or newer than the source, but does not support 8.5 source or target
- 8.5 console—Supports 8.3, 8.4, or 8.5 source and target as long as the target is the same or newer than the source
- Carbonite Migrate—Interoperability for this product is dependent on the type of job you will be creating.
- Files and folders and full server jobs—These job types are not interoperable between versions. Each source, target, and Carbonite Replication Console must be running the same version of Carbonite Migrate.
- Full server to ESX and full server to Hyper-V jobs—These jobs are interoperable between versions. Version 8.5 is interoperable back to version 8.3 but is restricted to the following limitations. The Carbonite Migrate clients can only control the same or older releases. To accommodate rolling upgrades, older sources can connect to newer targets, but newer sources cannot connect to older targets.
- 8.3 console—Supports 8.3 source and target, but does not support 8.4 or 8.5 source or target
- 8.4 console—Supports 8.3 or 8.4 source and target as long as the target is the same or newer than the source, but does not support 8.5 source or target.
- 8.5 console—Supports 8.3, 8.4, or 8.5 source and target as long as the target is the same or newer than the source
- Carbonite Replication Console—Options available in a newer console will not be functional when creating jobs for servers running older versions.
- Carbonite Availability—Version 8.5 is interoperable back to version 8.3 but is restricted to the following limitations. The Carbonite Availability clients can only control the same or older releases. To accommodate rolling upgrades, older sources can connect to newer targets, but newer sources cannot connect to older targets.
- Upgrades—Keep in mind the following caveats when upgrading.
- Rolling upgrade—When performing a rolling upgrade, update the target servers first. After the upgrade is complete, the sources will automatically reconnect to the targets. Upgrade the sources when convenient.
- Chained upgrades—If you are using a chained configuration, update the last target first, then update the middle server acting as both a source and target, and update the production source last.
- Restore and reverse—If you are using a configuration where the source is an older version than the target, you will not be able to restore or reverse from the newer version target back to the older version source. You must upgrade the source to the same version as the target before restoring or reversing.