Wednesday, May 5, 2010

Using IET (ISCSI Enterprise Target) for Windows Server Backup

Windows Server Backup in win2k8 server is fantastic - it's a consistent, snapshot-based automatic backup system capable of full disaster recovery / bare metal restore. I'm not a huge fan of much of the way the Windows servers work, but the backup setup is fantastic. With one wee flaw...

Manual backups may be made to a network share, or to a local volume then copied to a network share. Fuss free, but only with operator intervention.

Unfortunately, automatic scheduled backups require direct access to a drive, they won't work on a mounted NTFS volume or on a network share. This doesn't do me much good for disaster recovery, as even a USB2 or FireWire drive nearby has a good chance of being destroyed by anything that takes out my server. It rained (and hailed) in my server room last month, so I'm taking disaster recovery even more seriously, and a nearby HDD just isn't good enough.

I could run a FireWire 800 drive over cat5e to the near-site backup location, but that's surprisingly expensive to do, especially as I want redundant storage to protect against pesky HDD failures. I have a perfectly good Ethernet-connected Linux server with a 10TB RAID array running Bacula to back up everything else on thge network, and I'd prefer to just use it for Windows Server Backup too.

The solution: Win2k8 has a built-in iSCSI initiator. Simply turn the backup server into an iSCSI target, then use Windows 2008's built-in iSCSI initiator to connect to it so Windows Server Backup sees it as a local disk and can write backups to it. This turns out to be astonishingly easy, at least on an Ubuntu system.

Security notice

The following configuration does NOT authenticate the windows server to the iSCSI target via iSCSI mutual authentication, so it may be possible to trick the server into backing up onto a different server and "steal" the backup. It also passes the actual backup over the network in the clear, as it doesn't use IPSec. You may wish to address those limitations in your implementation.

It would be a very good idea to enable mutual authentication, but by time of writing I was unable to get it working. The win2k8 iSCSI initiator complained about secret length, even though the provided secret appeared to match its criteria and had been entered in the main part of the control panel where the mutual authentication secret is expected. Similarly, IPSec wouldn't be a bad idea to prevent your backups passing over the network in the clear.

Configuring the iSCSI target

First, install the ISCSI Enterprise Target software (IET):

apt-get install iscsitarget

Now provision a volume to export as a target. This may be a local raw disk or partition, a logical volume provided by LVM, or even a great honking file on one of your mounted file systems. I'm using LVM, so I'll just allocate a logical volume:

lvm lvcreate -n winimagebackup -L 300G backupvg 

There is no need to format the volume; Windows does that. Just export it via iSCSI by adding a suitable target entry to /etc/ietd.conf (it might be /etc/iet/ietd.conf on your system):

 Target iqn.2010-01.localnet.backup:winimagebackup
        Lun 0 Path=/dev/backup/winimagebackup_iscsi,Type=blockio
        Alias winimagebackup
        IncomingUser xxxx

See the comments in the default ietd.conf and the ietd.conf man page for details on this. In brief:
  • Change "localnet.backup" to the reversed host and domain name of your target server's name (mine is called "backup.localnet"). 
  • Change "IncomingUser" to the user name you want the Win2k8 server to have to give to be permitted to connect, and "xxxx" to the password you wish to require. By default a 2k8 box will give the above user name, with "winhostname" replaced with the win2k8 box's hostname.
  • Set the path after "Path" to the location of your storage.
  • If you're using a file, you may need to specify "fileio" instead of "blockio" as the Type.
Restart ietd, and you're ready to connect the 2k8 box.

Connecting 2k8 to the iSCSI Target

Connecting to the target from win2k8 is similarly trivial. In the iSCSI Target control panel, in the "discovery" tab enter the dns name or ip of the target. Do not configure authentication (unless you've deviated from the ietd.confabove), just accept the dialog.

The server should appear in "target portals" and no error should be displayed. If successful, go to the "targets" tab, where you should see a target named "winimagebackup". Click "Log on..." to connect to it. Check the option to restore the connection at boot-time. Under Advanced, Configure CHAP authentication, using the password given in ietd.conf for IncomingUser under the target winimagebackup. Do not enable mutual authentication*. Accept the dialog, and the status of the volume should change to "connected".

Configuring Windows Server Backup

You're now ready to use Windows Server Backup with the volume. You do not need to format it under the disk mmc snapin before use. Just fire up Windows Server Backup and click "Backup Schedule", then follow the prompts, picking the iSCSI target as the backup storage when prompted.


  1. I have just successfully enabled Mutual CHAP Authentication. The problem isn't that your secret isn't good enough for Win2k8, it is that MS expects you to use *different* secrets for either auth. That is, the secret for IncomingUser must be different from that of OutgoingUser ... once you do that, it will work! :)

  2. I've got my server backing up this way, many thanks for the tutorial.

    The question is, how do you recover from the backup with this setup? As far as I know, Windows Server 2008 Setup doesn't have iSCSI support...

    1. During restore tests, I had no issues with either of these tested approaches:

      * Booting Linux off a CD/DVD on the restore host and `dd'ing over the network via a network block device (nbd); or
      * Take an LVM snapshot of an LVM PV with the iSCSI target on it, mount it locally with ntfs-3g on the backup server, export the mounted volume over Samba, and it as the backup volume to restore when booting a win2k8 recovery dvd.

      It should also be possible to export a RAID 1 of two physical drives as your iSCSI target, so you can just yank one of the drives out of the array and physically plug it in to the server you're restoring to. This will be fastest, of course. DO NOT do this with just a single disk, because you'd be putting your only backup in a situation where it could easily get reformatted/deleted. If you're using one drive from a RAID 1, you're not risking your only copy during the restore.

      It'd be great if Win2k8 setup had iSCSI support, but I haven't managed to find any. A physical iSCSI initiator host bus adapter card would work, but few people have one of those lying around.

      BTW, BEWARE and TEST YOUR BACKUPS: I discovered during testing that Acer have butchered their OEM versions of Windows 2008 so that when they're booted on non-Acer hardware they display a message saying that this version of the OS only runs on Acer hardware, then they power off. I'm now extremely angry with Acer, and I might have to re-install my PDC with clean, non-oem-contaminated win2k8 media to make sure I can restore safely. I won't be surprised if Acer aren't the only ones doing this, so test carefully. I reformatted and reinstalled the server when I received it, but I foolishly used the Acer win2k8 media that my vendor assured me was "just the Microsoft windows 2008 discs, not modified by Acer." Lesson: it's only clean if it's from MSDN.

  3. Hi Craig

    Am sorry if its too late to ask anything about this topic.
    For ages now I've been struggling to connect an iscsi target on CentOS with iscsi initiator on Win server 2008 R2.
    I don't know where I'm going wrong.

    I configured as below

    dd if=/dev/zero of=/iet/TGTimages/CentOSLUN bs=1M count=12288

    then, on ietd.conf

    Lun 0 Path=/iet/TGTimages/CentOSLUN,Type=fileio
    InitialR2T yes
    ImmediateData yes

    I get two types of error (in tandem) when I try connecting to the iscsi target from Windows server.
    1. Target error
    2. iscsi name specified contains invalid characters or too long.

    Just in case:
    lvdisplay shows as following

    --- Logical volume ---
    LV Name /dev/VolGroup00/LogVol00
    VG Name VolGroup00
    LV UUID 3xLWOC-m0ma-zs3U-1Mri-keqx-m1EF-zN8P94
    LV Write Access read/write
    LV Status available
    # open 1
    LV Size 73.59 GB
    Current LE 2355
    Segments 1
    Allocation inherit
    Read ahead sectors auto
    - currently set to 256
    Block device 253:0

    --- Logical volume ---
    LV Name /dev/VolGroup00/LogVol01
    VG Name VolGroup00
    LV UUID OjtRz7-vWtI-3mpq-9HQp-5x1E-EXbc-8B2Qam
    LV Write Access read/write
    LV Status available
    # open 1
    LV Size 2.97 GB
    Current LE 95
    Segments 1
    Allocation inherit
    Read ahead sectors auto
    - currently set to 256
    Block device 253:1

    Please help.
    Thanks in advance.

    1. Check to make sure that `initiators.deny` is empty and `initiators.allow` contains `ALL ALL` or a clause for your win2k server.

      I also had to configure an IncomingUser at the global level (before any Target declaration) - *as well as* an identical IncomingUser for each Target.

      All I can really advise is that you look at the iet logs, the win2k event logs, and iteratively debug by adding/removing directives, etc.

    2. Thanks for the reply,
      Now I'm able to identify the target on Win2k8 r2, but when I try connecting it
      error says,
      "The target name is not found or marked as hidden from login".

      What could be the reason now..???

    3. As I said, check the win2k8 event logs and iet logs, and iteratively debug by adding and removing directives. If necessary you may want to examine the network traffic with `wireshark`.

      It might be worth posting on Server Fault if you continue to have problems. I'd be interested in the outcome, so please link to the question here if you do. I can't really go through interactive troubleshooting with you, though, I'm juggling too much already.


Captchas suck. Bots suck more. Sorry.