Recover Windows-based AWS EC2 Instance in vSphere Environment
Oleksii Osypov, posted on August 22, 2016
After we have migrated our production workloads to Amazon EC2 and configured offline backups to protect our data, we have started to look into more intricate cases of data recovery from backups. Today, I will show you how to instantly recover an EC2 instance from a backup in a VMware vSphere environment. Once again, this feature is not available directly in the NAKIVO Backup & Replication interface, but it’s feasible if you dare to try.
Windows 2012 Server EC2 Instance BackupWe’ll start with a Windows 2012 Server instance (hvm type) backup, so pre-requisites for this hands-on session are the following:
- Full installation of NAKIVO Backup & Replication
- Local Linux-based Transporter that hosts a backup repository with EC2 backups
- A backup of an EC2 instance running Windows 2012 Server
- VMware ESXi host (please, don’t use a production server!)
- An SSH client (like putty or ssh)
- And last, but not least, connectivity between the Transporter and the target VMware ESXi server
In simple terms, what we need to do is this:
- Expose the backup disk(s) for remote access
- Attach disk(s) exposed from backup to the target ESXi host
- Create a VM with attached disks (as Raw Device Mapping targets)
- Use the VM
- Clean up
Start a file recovery session for the EC2 instance (with Windows 2012 Server) in NAKIVO Backup & Replication and leave the file recovery session open:
Open an SSH session to the Transporter host and do the following (assuming you’re using the root login, otherwise you may need to use sudo):
- Identify iSCSI targets for our exposed backup, we’ll need them later: > iscsiadm -m session
- Identify volumes mounted for file recovery and unmount them. Don’t worry, iSCSI targets will stay exposed: > mount | grep bh-mount > umount /dev/sdb1 > umount /dev/sdb2 > …
- Now, the tricky one – expose the iSCSI targets hosted locally on the Transporter (usually 127.0.0.1:10000) for external access over the standard iSCSI port 3260. This can be done in a variety of ways, but for the sake of simplicity, we’ll use the ssh client port forwarding capability to do this: > ssh -L 〈TRANSPORTER-EXTERNAL-IP〉:3260:127.0.0.1:10000 root@ TRANSPORTER-EXTERNAL-IP
This would effectively re-login into the Transporter via SSH, and expose the port 3260 with the traffic redirect that we need. So, enter the password when prompted and leave the SSH session open for now. Note: the local address and port should match the ‘iscsiadm -m session’ command output.
Now go to your VMware vSphere client and let’s create a VM for instant recovery.
On the target ESXi, go to “Configuration” → “Storage Adapters” and add a new static iSCSI target (Transporter IP address and targets listed by ‘iscsiadm -m session’ command), allow to rescan the bus so you should see new entries:
Create a VM with ‘Custom’ settings, Windows 2012 guest OS and select the attached iSCSI targets as VM RDM disk(s) in Virtual Compatibility mode (any RAM/CPU settings should do, but start with simpler networking card like E1000).
So at the end you should have a config like this:
Take a snapshot of the created VM with the name “changes”, so less changes end up traveling to the Transporter host:
Power on the created VM! After some time, you should see Windows booting up and, eventually, the OS login screen:
Have fun with your VM.
Once you’ve played with the VM, do a proper cleanup:
- Power off the VM.
- Delete the VM with its disks.
- Remove the static iSCSI target(s) from the target ESXi: “Configuration” → “Storage Adapters” (allow bus rescan).
- Terminate the “nested” SSH session.
- Close the file recovery session in NAKIVO Backup & Replication interface.
- Optionally, delete the .conf file from the backup repository folder.
First of all, don’t worry – the backup being exposed is read-only and all changes will be discarded on cleanup. Second, make sure you do the proper cleanup of your ESX(i) server, otherwise, you may experience some unpleasant moments (yes, nothing is perfect in this world).
As a quick summary – there shouldn’t be much trouble with booting your Windows-based EC2 instance from a backup and probably with the VM obtaining an IP address over DHCP without much intervention on your side. In the next post, we’ll talk about booting up a Linux EC2 instance of hvm type that should be far more “fine-tuned” for the Amazon hypervisor.