我们目前已经开始使用以下策略进行Windows备份，我希望通过puppet进行部署：

• iSCSI启动器在客户端服务器上启用。
• iSCSI虚拟磁盘+ VHDconfiguration在备份服务器上，VHD文件分布在众多RAID容器中。
• 同样在备份服务器上，configuration了一个新的iSCSI目标，指向该虚拟磁盘，仅限于客户服务器的DNS名称或IP。 随机的用户名/密码被configuration。
• 客户端服务器上的iSCSI启动器configuration为连接到新目标，并通过磁盘pipe理添加虚拟磁盘。
• 最后，windows备份被configuration为在本地指向VHD，以执行备份。

我刚刚开始使用puppet，到目前为止，我的主要挑战是必须按照特定顺序configuration两个单独的节点（例如，iSCSI启动器在存在之前无法连接到目标）。

可能的解决scheme

导出的资源集合

我一直在寻找一种方法来做到这一点，到目前为止，我能find的最适合的configuration模式是Exported Resource Collection 。 我已经看了一些使用Nagios的例子，似乎需要我定义一个新的types，这本质上是Ruby代码，以便对导出的资源执行操作。

• 什么原因导致SqlServerWriter在Sql Express服务器上运行Windows Server备份失败？
• DiskStation备份任务被删除？
• 服务器映像的现场/异地备份是一个好主意吗？
• 在原始服务器的不同快照上恢复“未来”备份的最简单方法是什么？
• 如何使用AMANDA捕获服务器的一次性完整备份？

尽pipe我有编程经验，但是我的同事却不这样做，而且我尽量保持尽可能简单。

单独的节点条目

我正在尝试的一个想法是，而不是尝试从客户端节点定义整个备份（目标服务器和启动器）所涉及的复杂性，只需在每个节点中定义两个独立的angular色即可。

然后为了简化事情，虽然configuration应该按照特定的顺序来完成，但我只是依靠puppet来继续尝试运行configuration，最终所有的预先要求都会被满足。 （例如，第一次，木偶可能会尝试连接到iSCSI目标，但在第二次尝试时，另一个节点应该已经完成​​创build目标，所以如果puppet第二次尝试，它应该suceed。）

就像是：

node 'backup-server' { windows_backup::server::target { 'client01': dns_name => 'client01.example.com', username => '', password => '', drive_letter => '', drive_size => '', }, windows_backup::server::target { 'client02': dns_name => 'client02.example2.com', username => '', password => '', drive_letter => '', drive_size => '', } } 

然后…

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

但是，正如您所看到的那样，您开始进入硬编码太多值的领域（例如，确定VHD的大小将需要我们login到服务器并手动确定大小 – 而这可以是可能自动完成）。 然后，这又回到理想状态，自动共享所涉及的两个节点之间的数据/资源。

在某些时候，所有的手工硬编码都没有提供足够的优势（比如花时间进行configuration）来certificate使用puppet来部署这个复杂性所带来的额外复杂性。

过去有没有人部署类似的工作stream程，并且有更简单的方法吗？