我的问题很简单，我想我知道我的答案——我真的在得到别人的确认。
显然，如果我的 WSUS 服务器死了，我将在它备份后进行大量下载，这不是问题。我在想更多的 WSUS 背后的数据库 - 应该备份吗？
我认为会发生的是，这就像第一次重新设置 WSUS - 更改组策略，然后 WSUS 服务器将从头开始构建其计算机数据库及其安装的更新。
我的假设是正确的，还是会做一些意想不到的事情？
从长远来看，备份数据库是否更好，比如每月一次并完成它？
AskOverflow.Dev
我的问题很简单，我想我知道我的答案——我真的在得到别人的确认。
显然，如果我的 WSUS 服务器死了，我将在它备份后进行大量下载，这不是问题。我在想更多的 WSUS 背后的数据库 - 应该备份吗？
我认为会发生的是，这就像第一次重新设置 WSUS - 更改组策略，然后 WSUS 服务器将从头开始构建其计算机数据库及其安装的更新。
我的假设是正确的，还是会做一些意想不到的事情？
从长远来看，备份数据库是否更好，比如每月一次并完成它？
这在某种程度上取决于您的组布局有多复杂，以及您是否对某些组进行了很多自定义批准/拒绝。这还取决于您是否关心数据库中计算机的历史记录和当前状态。
如果您有一个非常简单的设置，您只是批准所有更新并且您并不真正关心任何计算机的历史记录，则无需备份数据库或更新。与从备份恢复相比，从头开始重新构建服务（取决于您的网络连接到 Microsoft 的速度）可能需要更少的时间。一旦新服务器启动，您所有现有的机器都将在新服务器上签入。
对于任何服务来说，这都是一个非常基本的风险分析。如果您有成本高昂（时间或金钱）或无法从头开始重新创建的数据，您应该备份它。否则，不要打扰。
备份数据库是一项小任务，备份更新确实没有意义，因为如果您必须重建 WSUS 服务器，您只需重新下载它们即可。无论如何，大多数更新都已应用。
我备份了我的 WSUS 数据库，这样我就不必写下（或记住）要拒绝的更新（例如，我们有一个自定义单词插件，它会因某个 KB 崩溃）。
当备份接近磁带容量时，我在之前的工作中对此进行了研究。我没有继续备份 WSUS，而是将其设置在另一台服务器上并将其配置为下游服务器，即使它实际上并未为任何客户端提供服务。我想如果有必要，我可以编辑指向服务器的 GPO 设置，然后继续处理更紧急的事情，比如恢复故障系统的其余部分。使用的磁盘空间无关紧要，但它确实释放了磁带上的宝贵空间。
无论如何我都会支持它，只是为了额外的舒适因素。令我震惊的是，WSUS 并不是绝对需要包含在您的常规夜间备份作业中的东西，而是可以在白天运行，如果您的时间窗口和/或存储空间紧张，这可能会使事情变得更容易。是否要备份更新以及数据库和其他配置完全取决于您；如果再次下载它们很简单，那么您可能不需要。
如果您决定不备份它，请确保您彻底记录配置。重建操作系统以及应用程序和数据库软件可能是微不足道的，但除非你已经恢复了配置，否则你还没有真正恢复。
你在说什么 re：重建 WSUS 服务器是正确的（尽管如果替换 WSUS 服务器的更新 URL 与失败的 WSUS 服务器相同，则不会更改客户端配置 re：组策略、注册表设置等必要的）。
是否备份 WSUS 数据库实际上只是下载时间与备份资源（备份窗口中的空间、时间）使用之间的权衡。它通常很小，所以我会经常去抓它。
重新设置它需要多少工作？
支持它需要多少努力/成本？
如果设置它的工作成本低于备份它的成本，那么您有一个答案。
我每季度只拍一次我们的鬼影。几个月的补丁在计划中是小菜一碟。但无论如何我也强迫它使用代理，所以如果它真的死了，我仍然可以通过它在本地加载大部分..（我们的代理有一个大缓存，100GB）
欢呼提醒我，我正在添加计划任务，所以我不会忘记下个季度并且现在正在备份它！
备份任何服务器总是一个好主意。
不得不再次设置 wsus 然后将所有机器混入其中的痛苦远远大于在机器上设置某种备份所需的 30 秒。
每天将数据库/系统转储到一个简单的外部卷，或者如果您有内部备份基础架构将其转储到那里。
IMO 不，重建 WSUS 服务器的时间/麻烦可以忽略不计，而且它不是一个时间紧迫的项目，当它关闭时会杀死你。
如果您想尽可能地减轻麻烦，请通过您的工作站/服务器的组策略设置客户端定位。这将减少您的整体 WSUS 管理开销，并使重建无痛。
当您考虑 SQL 备份 CAL 的成本，或通过手动方法设置/维护它时，我真的找不到强有力的论据来支持它。