25 Oct The benefits of using iSCSI for BackupAssist image backups

I often get asked about the best way to create off-site image backups.

One logical approach is to use a windows network share for the destination, however because the destination is not accessible at the disk sector level, the incremental imaging feature can’t be used. A full image backup must be taken each time the job runs which can take significantly more time as well as requiring a larger amount of storage if you wish to keep multiple images.

For this reason, we often recommend that customers stick to local destinations for image backups with history, and plug in either a local dedicated USB hard drive or a pool of USB drives. This approach works very well and allows for multiple images a day, typically taking less than an hour to run on an average SBS server.

However the disadvantages of relying on local backups are clear in that they’re still susceptible to loss, theft and damage. An often overlooked solution for image backups that combines the best features from both of these methods is iSCSI.

So what is iSCSI?

iSCSI is a network protocol that provides a virtual SCSI interface over IP. Simply put, this allows you to create and share a virtual SCSI device over an IP network to be seen on a remote server, as if it was a local attached drive. In our example we will share a virtual hard drive from an iSCSI server ‘target’.

Why is iSCSI different to a Windows share?

With a windows share you create a standard windows folder on a server and specify share permissions in order for other devices to gain access over the network. This folder can have multiple connections to it and works at the file access level. It is seen by the remote device as a network device not a local one, and within BackupAssist is referred to as its unique UNC Path. There is however, no access to the destination at a disk level (blocks/ sectors) and it’s this access that the Windows Image engine requires to be able to compare existing images and perform incremental backups.

iSCSI on the other hand is a block level device share. A standard virtual hard drive container file ‘VHD’ is created on the iSCSI server (target) and is shared to the iSCSI client (initiator) over the network. This client can then mount the virtual hard drive locally (using Computer Management in Windows) and given a drive letter. To the operating system this iSCSI device appears in exactly the same way as a local attached drive and full drive block level access is supported. The read/ write access is also quicker than a windows share and most importantly for backups, incremental imaging is fully supported.

One thing to note, is that generally an iSCSI device is only mounted by one Client at a time. There are advanced clustering capabilities in some iSCSI services to allow multiple servers to connect but in general, an iSCSI share is assigned to only one client at a time (think of them as remote dedicated hard drives).

How do I get an iSCSI server?

There are a few options for building an iSCSI server, you can purchase quite expensive SAN devices that can be configured as iSCSI shares and there are also cheaper NAS devices that are better suited to the SMB environment that also support iSCSI. Alternatively you can install the free iSCSI target initiator provided by Microsoft for Windows 2008 server here. 

For step by step instructions on how to configure this I would suggest you have a look at this excellent Technet blog post by Jose Barreto here.

(source: blogs.technet.com – follow the setup instructions from the section labelled ‘Loading the iSCSI initiator’.)