The customer I was talking to was using the Windows imaging engine in BackupAssist to back up both their system drive ‘C:’ and a large data drive ‘D:’ (used for every day document storage etc.).

This was working just as expected and backups were updating quickly to a local USB hard drive when the inevitable happened – they had a local hard drive failure and of course wanted to perform a bare metal recovery from the last good image backup.

After replacing the dead hard drive, they’d followed the correct procedure and booted using the RecoverAssist boot media. They selected the most recent backup and were just about to restore when they noticed their backup also included a full snapshot of their large data drive ‘D:’ which was actually perfectly ok, being that it was a separate physical disk.

The way the Windows imaging engine works means that it assumes you wish to restore all the data that was backed up, so there’s not actually any stage during the recovery process that they could deselect the drives they didn’t want restoring.

They would have had to overwrite their 20 hour old backup to a drive containing much newer data but fortunately this customer had also configured BackupAssist to run a secondary backup of that drive and so had a copy of the data that had changed since the last backup. This meant after the bare metal restore they simply updated the data files on D: and were back to the same point in time.

However this does highlight an important point in that it’s always worth keeping your disaster recovery and data backups separate. I understand the BackupAssist guys are looking at adding some functionality to help herein a future release but for now I I recommend that you stick to two jobs. The first should be an image job for bare metal recovery which includes the Windows system drives, and the second for data drives (create an additional job for each extra physical disk).