Open topic with navigation
Installation and upgrade notes
Review the following installation and upgrade notes before beginning your installation or upgrade.
- Because Double-Take Availability has operating system dependent files, if you are upgrading your operating system (to a new major version, not a service pack) and have Double-Take Availability installed, you must remove Double-Take Availability prior to the operating system upgrade. Uninstall Double-Take Availability, perform the operating system upgrade, and then reinstall Double-Take Availability.
- A script called DTInfo.sh is included in the installation. This script can be run via DTSetup to collect configuration data for use when reporting problems to technical support. Depending on the type of diagnostic information gathering you select, DTInfo can gather Double-Take Availability log files, Double-Take Availability and system settings, network configuration information, and other data which may be necessary for technical support to troubleshoot issues. After running the script, a .tar.gz is automatically created with the information gathered. You must have root (or uid 0 equivalent) to execute the diagnostics or to copy or read the resulting file.
- Double-Take Availability 7.0 is interoperable back to version 4.7 but is restricted to the following limitations. The Double-Take 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.
- 4.7 client—Supports 4.7 source and target, but does not support 6.0 or 7.0 source or target
- 6.0 client—Supports 4.7 or 6.0 source and target as long as the target is the same or newer than the source, but does not support 7.0 source or target
- 7.0 client—Supports 4.7, 6.0, or 7.0 source and target as long as the target is the same or newer than the source
- When performing a rolling upgrade, update the target servers first. After the upgrade is complete and the target daemon is restarted, the sources will automatically reconnect to the targets. Upgrade the sources when convenient.
- 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.
- If you are using a configuration where the source is an older version than the target, you will not be able to restore 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.
Related Topics