When Double-Take Software released a series of products and strategies to perform migration from one hardware platform to another, many clients began to experiment with these new tools to help make their jobs faster and easier. Along with the ability to move between platforms (such as from physical to virtual), many clients wanted to know about options for moving between versions of Windows and between Windows and other OS’s. While Double-Take Availability, Double-Take Move and Livewire can assist with these procedures, there are some limitations to be aware of.
First and foremost, while Double-Take Software products support both Windows and Linux, you must stay within the same basic OS for any source/target connection. That means that you can go between any version of Red Hat Enterprise Linux (RHEL) and/or CentOS to any other; SUSE Enterprise to SUSE Enterprise only and Windows to Windows only. Going between types of operating systems is not currently supported by any of the Double-Take Software products, and as a matter of fact the consoles are designed to actively prohibit you from trying it. This is mainly because these different OS’s use wildly different formats for storing and processing data, and an I/O operation from Windows wouldn’t be committable on a Linux OS and vice versa.
Within the same base OS, there is a bit more flexibility. Generally, Double-Take Software products can move data between any two versions of the same basic OS. So, for example, you can replicate data from Windows 2003 to Windows 2008. Whenever possible, security and other attributes will be maintained, as long as the target OS can accept and process the security and attribute identifiers applied to the source. When moving from an earlier OS to a later one, this isn’t generally a problem. However, while moving data from later to earlier is allowed, not all attributes may be accepted by the Target and therefore may not replicate. This doesn’t break replication, but it does mean that the target data will get whatever inheritable permissions exist on the volume we’re replicating to. So when going between versions of an OS, it’s best to replicate from an older source OS to a new target OS whenever possible. Keep in mind that this only applies to the version of the OS, the version of the Double-Take Software product should be identical on both machines.
System State Protection (only available on Windows platforms) is another story. While data can safely move from Windows 2003 to 2008 – in example – the system state cannot. This is for one very obvious reason, they’re different versions of the Windows system, and therefore not compatible. So when using Double-Take Software tools to migrate between different versions of Windows, you will be able to move data only, not OS binaries, application binaries or registry settings. Usually, the installation and configuration of a Windows 2008 server and its applications is so different from that found on Server 2003 that you would rarely ever want to move system state, so this is not usually an issue.
Livewire is a different set of circumstances, however, as it is used to store system information and data for eventual restore to another server entirely. For this tool set, you may replicate everything including system state (the default for Livewire protection) to an image server that is running any valid version of Windows. Today, that includes both the Windows Server 2003 and Windows Server 2008 product lines, and will soon include Windows Server 2008 R2. The image server must be the same or newer than the source machines, but does not need to match the source machines or the recovery server that you will restore to.
This doesn’t mean that mixing and matching OS’s is without consideration, though. When you go to restore, if your recovery server is not the same OS as the image server, then you’ll need to install Livewire manually on that recovery server before you run the recovery wizard. The reason for this is that the image server can only push the version of Livewire it has installed, which wouldn’t match up with the OS on the recovery server. By manually installing Livewire on the recovery server, you ensure that the version is correct, and bypass any mismatch issues. Also, be aware that the recovery server will need the same version of Windows as the original source machine was running. This is because we will be restoring system state to that recovery server, and therefore will need the same OS installed.
Let’s use an example to illustrate this. If I have a Windows 2003 x86 server in production, I can replicate to a Windows 2008 Storage Server Edition x64 Image Server with no issues at all. When I go to restore, I can perform that restore to any Windows 2003 server, but I have to install Livewire on that recovery server before I begin the restore operation.
Finally, in the Windows world, there is the ability to have multiple levels of the same OS version. For example, you can install Windows Server 2003 in both Enterprise and Standard versions, as well as a Datacenter version for larger implementations. The same is true in Windows 2008. Double-Take Software products can safely move between product levels with no issues, however make sure that your target system can support the level of the OS installed on the source if you intend to protect the system state. The target will become the source in all respects after a failover, and this includes taking on the same level of Windows that the source had. Livewire will produce the same result after restoration to a recovery server, and therefore that hardware should be capable of running the same OS level that the source held before it failed.
OS mixing and matching is sometimes required due to limitations in server availability, licensing restrictions or a host of other factors. Double-Take Software products can allow you to move between different versions of the same OS, as long as you follow the basic rules outlined here. While we cannot make multi-version migrations as seamless as we’d like, we can definitely assist you and make them as easy as possible.
Filed under: Best Practices, Double-Take Availability, Double-Take Backup, Double-Take Move | Tagged: Availability, Double-Take Move, live hardware migration, LiveWire, OS migration, p2v
Why doesnt Double-Take for Virtual Infrastructure allow the scheduling of protection windows like most of your other products?
Hi Jamie:
DTVI does allow for limited scheduling, but becuase we operate with ESX Snapshots (and not the real-time I/O stream like you see with other DBTK products), we’re not able to offer the range of options that you would normally see with DBTK solutions. You can, however, set both the maximum time and maximum data that can accumulate between snap and send operations with DTVI.
If you need more granularity, then using a Guest-based product (say Double-Take Availability, for example), would be the better solution.
If you do need more assistnace, we’re here to help. Just stop by the Double-Take website and head over to the Support page, or reach out to your local Double-Take Software sales rep, who can get you linked in to a System Engineer.