Bare Metal Recovery Experiences with Veeam Endpoint BETA

Note! This article describes a product that wasn’t released yet, so things might have changed from this to the release version! Some of the screenshots are from the release version of the Recovery Media

Note! Some of the images are from a different run than described, so ignore possible inconsistencies.

A prospective customer was having some issues when they were trying out Veeam Endpoint Free (while it was in beta), specifically bare metal recoveries. Not having tried it, I decided to give it a go to see where they might have gone astray. Here are some notes from the road.

Let’s start out with my environment:

  • Lenovo Thinkpad T440s running Windows 8.1, 256GB SSD drive
  • Veeam Endpoint Backup version 1.0.0.1921 (not the release version)
  • Backups are running to a server running Veeam 8 with the pre-release Patch 2 which allows Endpoint backups to a Veeam Backup Repository
  • Laptop and server are not on the same subnet/VLAN but traffic is allowed between the two
  • Target laptop is a Thinkpad R61 (just the empty first machine I saw without an owner in sight :)). Machine has an empty 320 GB spinny disk
  • Backup job is set to “Entire Computer”

Nothing exotic regarding the job, it takes everything on the machine except for deleted, temporary and page files, allowing for a complete restore of the computer to a given state.

To enable the bare metal recovery, create the Recovery media when prompted during install. Note that you can also skip this step and create it later, but I suggest doing it now. I chose to make it an ISO file, and then burned that onto a CD. I suppose you could use a USB drive as well, but I didn’t test it. The image in my case was about 480 megabytes in size, and was named VeeamRecoveryMedia_HOSTNAME.iso. When creating the recovery media, I left the default checkbox for hardware drivers checked, and did not add any additional drivers for this exercise.

After the backup was done, booted up the Thinkpad R51 from the recovery cd. The process was fairly straightforward from then on. Also noteworthy is that I didn’t even expect this to work, since I’m restoring to a completely different generation and model series of Thinkpad with completely different hardware. Windows usually throws a hissy fit if you change the direction of the wind, or the moon is at an odd phase, but to my utter amazement, this actually worked. Not sure whether I should thank Veeam or Microsoft Windows 8.1 for this one 🙂

Starting off, this is the first thing you see when you boot from the recovery media:

First screen in the recovery media
First screen in the recovery media

We can start using different tools (familiar to those that have used Windows PE type disks before), or to start the Bare Metal Recovery Process. Screenshots taken from a restore I did in Virtualbox to avoid potato-quality pictures.

In the second screen, we have to choose where our backup files reside: Either a local storage medium (USB disk, other hard drive etc.) or a network storage location:

Chose where your backups are located
Chose where your backups are located

I chose network storage, since my backups are located on a Veeam BRS server. After this, we may have to tell it some network settings in order to access the network. You can use either wired or Wireless connection. You can also specify drivers in case you have more exotic hardware that isn’t detected by the boot disk.

Network settings dialog
Network settings dialog

After this, we select whether we want to use a network share, or a BRS server:

 

Give the name or ip of the BRS server, and credentials. On the server side, you can set which credentials have access to which repositories, so make sure these are in order. On the next pages , you can choose the machine and restore point:

Veeam Server Credentials
Veeam Server Credentials
Select the computer from the job
Select the computer from the job
Select restore point
Select restore point

So at this point we have chosen what, and when we are going to restore. Now we continue by telling it how we want our disk layout in the backup to look on our target machine (which may have a different sized disk, for instance). Maybe we don’t want or need to restore every partition? I went with Manual restore (advanced) for more fine grained control.

What to restore?
What to restore?
Chose the disks that we want to restore from our backup
Chose the disks that we want to restore from our backup

In my example, I want a full working replica of my original machine:  hence I will select all OS drives. In my case this means the System Reserved partition that later Windows’ boxes create to store certain boot files, and the C drive. Note the partition sizes. Also note the ‘Customize disk mapping’ link in the lower right hand corner. There, we could configure a different layout than our original. The default is noted in the ‘Restore layout’ column, ‘Automatic’. This will keep the original layout if possible.

We can now see a summary of what we are about to do. We then start the process:

..the process has started
..the process has started

Despite the scary warning (which may or may not be related to this being a beta at the time of my test), the restore process was completed. Note how it updates the BCD (bootcode) so we can boot our newly restored system. It also does some magic with drivers, which might be why it booted on a completely different laptop (T440s vs. R61).

...and completed
…and completed

We can now hit finish, remove the boot media when instructed and boot to our restored system. As I mentioned, everything worked, and was exactly as I could have hoped! I will do an update on this article when I’ve had a chance to try the release version (build 1.0.0.1954 available since April 14, 2015, see http://www.veeam.com/blog/veeam-endpoint-backup-free-is-here.html)

The finished product!
The finished product!

Veeam 8 backup copies over WAN to a Cloud Connect repository

Veeam 8 has been out now for a while, and has received it’s first patch, too. I’ve been running some tests using the new/improved Cloud Connect functionality, which allows you to send backups or backup copies to a repository located at a service provider. To reduce network traffic between sites, I’m using WAN Accelerators at both sides. The basic setup is, that I’m running backups to a VBR server at the remote site, and then a backup copy of that to the Cloud Connect repository over a WAN. You can run straight backups to the Cloud Connect repository (it acts as any other repository), but then you can’t leverage WAN Accelerator (only available for Backup Copies and Replication (and only with an Enterprise Plus license).

Having run the first full backups to the remote VBR server’s local repository, I set up the Backup Copy job. The way it works is, it looks for the latest restore points in the defined repository / job, and when it finds them, it starts moving them over to your specified destination (while adhering to the schedule you set). After that, if you’ve set it to ‘Continuous’ mode, it’ll go idle, and wait for new restore points to appear, and then move those, and so on.

What I had not taken into account, is that I had defined multiple backup jobs, which I thought were identical, and then added those to the backup copy job. After a while, I noticed that some of the jobs were not being processed by the copy job. The VM’s in those jobs were listed as “Pending” in the backup copy job. After a short investigation, the reason was that one of the jobs had a storage optimization setting of “Local”, while the rest had “LAN”. This setting affects the block size of the backups (ranging from Local (8192 KB) to WAN (256KB).

I wasn’t cognizant of this limitation in Backup Copy jobs. All VM’s being processed have to have identical storage optimization settings. You can’t mix Local and LAN, or LAN and WAN.

The easiest fix for me (though maybe not the most optimal) was to create another backup copy job, add the jobs with “LAN” optimization to that job, leaving the one Local job to the original backup copy job. Or, as suggested in one of the posts in the Sources section, you could delete appropriate backups, change the settings in the backup jobs, and then allow the backup copy job to work its magic.

After the second job was enabled, it immediately started copying over the latest restore points to the Cloud Connect repository.

TL;DR: When creating Backup Copy jobs, make sure all the jobs included are using the same storage optimization settings (while creating the job, on the storage page -> advanced -> storage tab).


Sources:

http://helpcenter.veeam.com/backup/80/vsphere/backup_copy_job_task.html

http://forums.veeam.com/veeam-backup-replication-f2/backup-copy-never-starts-t17874.html

http://forums.veeam.com/veeam-backup-replication-f2/source-backup-file-has-different-block-size-t24272.html