I came across an issue on a support call the other day I thought worth sharing as it's bound to be something a few of you will see too.
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.

iscsi-icon.jpgHopefully you're already aware that one of the great new features coming in BackupAssist version 6.4 is the native support for iSCSI targets. This feature allows you to run Windows image jobs that fully support incremental updating and history. This is a great feature for disaster recovery backups as it negates the need to have local media (typically USB hard drives) attached to every server or workstation you want protected. I have covered the idea of iSCSI backups in this previous post, but as part of my help with the beta testing of BackupAssist I'm running some real world speed testing on my own Windows 7 box. The aim being to see how long backups will actually take in order to to get an idea of how often they can be run within the day to provide as up to date a backup as possible of the full system drive.

You may have picked up on the grapevine (or the phone when talking to us!), that there's an exciting new version of BackupAssist in the offing. Well, I can confirm the rumours, version 6.4 is due to include both advanced iSCSI support and RecoverAssist, which will make life considerably easier for those of you performing image backups and bare metal restores on 2008/R2/SBS/Hyper-V/Win7/Vista.