我的问题很简单，我想我知道我的答案 – 我真的是经过别人的确认。
显然，如果我的WSUS服务器死了，我会有一些重大的下载来做，一旦它备份，这不是一个问题。 我在想更多WSUS背后的数据库 – 是否应该备份？
我想会发生的情况就是，就像第一次设置WSUS一样 – 更改组策略，然后WSUS服务器将从头构build其计算机数据库及其安装的更新。
我是否对我的假设是正确的，还是会做出意想不到的事情？
从长远来看，把数据库备份起来，每月说一次，并且做好了，是不是更好？
这取决于你的组织布局是多么复杂，以及你是否为某些组织做了很多自定义的批准/拒绝。 这也取决于你是否关心数据库中计算机的历史和现状。
如果你有一个非常简单的设置，你只需要批准所有的更新，而你并不关心任何计算机的历史，那么就不需要备份数据库或更新。 从头开始重新构build服务（取决于与Microsoft的networking连接有多快），从备份恢复可能需要的时间较less。 一旦启动，所有现有的机器都将在新的服务器上进行检查。
对于任何服务来说，这都是非常基本的风险分析。 如果你有数据，这将是昂贵的（时间或金钱）或不可能从头开始重新创build，你应该支持它。 否则，不要打扰。
备份数据库是一项小任务，备份更新实在没有意义，因为如果必须重新构buildWSUS服务器，只需重新下载它们即可。 无论如何，大部分更新已经被应用。
我备份我的WSUS数据库，以便我不必记下（或记住）拒绝的更新（例如，我们有一个自定义词插件，以某个KB为例）。
当备份接近磁带容量时，我在之前的工作中对此进行了研究。 我没有继续备份WSUS，而是将其设置在另一台服务器上，并将其configuration为下游服务器，即使这些服务器实际上并没有为任何客户端提供服务。 我想如果有必要的话，我可以编辑指向服务器的GPO设置，然后继续处理更紧急的事情，比如恢复失败系统的其余部分。 所用的磁盘空间没有问题，但它释放了磁带上的宝贵空间。
无论如何，我会支持它，只是为了额外的舒适因素。 这让我觉得WSUS并不是绝对需要包含在夜间备份工作中，而是可以在白天运行，如果时间窗口和/或存储空间紧张，这可能会使事情变得更容易。 是否要备份更新以及数据库和其他configuration取决于您; 如果只是再次下载它们，那么你可能不需要。
如果您决定不备份，请确保您完全loggingconfiguration 。 重build操作系统和应用程序以及数据库软件可能是微不足道的，但是除非你的configuration正确，否则你还没有真正恢复。
你在说什么重build：重buildWSUS服务器是正确的（但是如果replaceWSUS服务器的更新URL与失败的WSUS服务器相同，则不改变客户端configuration：组策略，registry设置等必要）。
是否备份WSUS数据库实际上只是下载时间与备份资源的使用（备份窗口中的空间，时间）的权衡。 它通常很小，所以我会定期去抓。
将它重新设置多less工作？
需要多less努力/成本来支持它？
如果设置它的工作成本低于支持成本，那么你就有了答案。
我只是把我们的一个鬼影像一个季度一次..几个月的补丁是在事情的计划小土豆..但我也强迫它使用代理无论如何，所以如果它死了，我仍然可以通过它在本地加载大部分..（我们的代理有一个大的caching，100GB）
欢呼声提醒我，我正在添加一个计划的任务，所以我不会忘记下一个季度，现在支持它！
备份任何服务器总是一个好主意。
不得不重新设置wsus，然后将所有机器捣碎的痛苦远远大于在机器上设置某种备份所需的30秒。
运行数据库/系统的日常转储或者只是一个简单的外部卷，或者如果您有一个内部备份基础设施转储在那里。
国际海事组织没有，重buildWSUS服务器的时间/麻烦是可以忽略的，它不是一个时间关键的项目，当它停止时，你会杀了你。
如果您希望尽可能减轻麻烦，请通过组策略为您的工作站/服务器设置客户端定位。 这将减less您的整体WSUSpipe理开销，以及无痛苦的重build。
当考虑SQL备份CAL的成本，或者通过手动方法设置/维护时，我实在找不到支持它的强有力的论据。