Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We currently have started using the following strategy for Windows backups, which I am looking to deploy via puppet:

  • iSCSI Initiator is enabled on the client server.
  • iSCSI Virtual Disk + VHD are configured on the backup server, with VHD files spread out over numerous RAID containers.
  • Also on the backup server, a new iSCSI target is configured pointing to this virtual disk, restricted to the DNS Name or IP of the client server. A random username/password are configured.
  • The iSCSI initiator on the client server is configured to connect to the new target and the virtual disk is added via disk management.
  • Finally, windows backup is configured to point to the VHD locally, to perform the backup.

I've only just begun using puppet, and my main challenge so far is that I must configure two separate nodes, in a particular order (eg. the iSCSI initiator cannot connect to the target before it exists).

Possible Solutions

Exported Resource Collection

I have been looking for a way to do this, and so far, the most suitable configuration pattern I can find is Exported Resource Collection. I have looked at a few examples using Nagios, and it seems that it would require me to define a new type, which is essentially Ruby code, in order to perform actions on the exported resources.

I would like to avoid doing something this advanced so soon as, although I have programming experience, my colleagues do not, and I'm trying to keep it as simple as I can.

Separate node entries

One idea I am toying with is, instead of the added complexity involved in trying to define the entire backup (target server and initiator) from the client node, simply define the two separate roles in each node.

And then to simplify things, although configuration should be done in a particular order for things to work, I would simply rely on puppet to keep trying to run the configuration and eventually, all pre-requesites would be met. (For example, the first time around, puppet would perhaps try and connect to the iSCSI target before it has been created, but upon trying the second time, the other node should have finished creating the target, so if puppet tried this a second time, it should suceed.)

Something like:

node 'backup-server' { 
    windows_backup::server::target { 'client01':
        dns_name => '',
        username => '',
        password => '',
        drive_letter => '',
        drive_size => '',
    windows_backup::server::target { 'client02':
        dns_name => '',
        username => '',
        password => '',
        drive_letter => '',
        drive_size => '',


node 'client01' { 
    windows_backup::client::backup { 'client01':
        username => '',
        password => '',
        drive_letter => '',

But then, as you can see, you start getting into the territory of hard-coding too many values (for example, determining the size of the VHD will require us to login to the server and determine the size manually -- whereas this can be done automatically potentially). And this then comes back to ideally automatically sharing data/resources between the two nodes involved.

At some point, all the manual hard-coding provides not enough of an advantage (eg. time spent doing configuration) to justify the extra layer of complexity involved in using puppet to deploy this.

Has anyone deployed similar workflows in the past, and are there simpler ways of doing this?

share|improve this question
TLDR; WTH? Surely there is an easier, less cumbersome and convoluted way to get backups of your Windows servers? – joeqwerty Sep 18 '13 at 4:43
@joeqwerty Not sure why you think the actual backup solution is cumbersome? I suppose only in that it requires configuration of the backup on each actual server - other than that, I fail to see what the issue is? We chose Windows backup because it is simple to use, it runs quickly to provide full image backups, and we don't really have any issues with it, unlike some third-party stuff like Backup Exec. It's also well supported in Windows disaster recovery scenarios. How would you rather see backups done? – Geekman Sep 18 '13 at 4:53
I'm not saying it's an issue, I'm just saying that to me it looks pretty cumbersome and convoluted. Others may (and probably will) disagree with me. I'm from the KIS school of system administration. I'm looking forward to seeing the answers that come in for this one. – joeqwerty Sep 18 '13 at 4:58
Also, my question is not with your use of Windows Backup. I think it's a great free alternative to commercial applications. It's the whole iSCSI, VHD, etc., etc part that strikes me as over engineered. Hopefully this goes without saying, but I mean no offense with my comments and questions. – joeqwerty Sep 18 '13 at 5:03
@joeqwerty Fair enough, I understand. Using iSCSI was not my first choice (not even on the radar, actually), but since we're in a datacentre environment providing backups for multiple separate customers, shared storage is a requirement (can you imagine 100x external USB drives?). And this was quite simply, the only supported mechanism I could find which also supported full bare-metal differential backups. Unfortunately using SMB file shares prevents differentials, apparently. Perhaps that should be a separate question. :) – Geekman Sep 18 '13 at 5:16

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Browse other questions tagged or ask your own question.