我的问题很简单，我想我知道我的答案——我确实想得到别人的确认。
显然，如果我的 WSUS 服务器死机了，一旦服务器恢复，我将需要进行大量下载，这不是问题。我更多地考虑的是 WSUS 背后的数据库 - 应该备份吗？
我认为会发生的情况是，这就像第一次再次设置 WSUS 一样 - 更改组策略，然后 WSUS 服务器将从头开始构建其计算机数据库及其已安装的更新。
我的假设正确吗？还是它会做出意想不到的事情？
从长远来看，最好只备份数据库，比如说每月备份一次，然后就完事了？
答案1
这在某种程度上取决于您的组布局有多复杂，以及您是否对某些组进行了大量自定义批准/拒绝。这还取决于您是否关心数据库中计算机的历史记录和当前状态。
如果您的设置非常简单，只需批准所有更新，而您并不真正关心任何计算机的历史记录，则无需备份数据库或更新。从头开始重建服务（取决于您与 Microsoft 的网络连接速度）可能比从备份中恢复花费的时间更少。新服务器启动后，您现有的所有机器都会与新服务器进行签入。
对于任何服务来说，这都是非常基本的风险分析。如果您拥有的数据需要花费大量金钱（时间或金钱）或无法从头开始重建，则应该备份。否则，就别费心了。
答案2
备份数据库是一项小任务，备份更新实际上毫无意义，因为如果您必须重建 WSUS 服务器，您只需重新下载它们即可。无论如何，大多数更新都已应用。
我备份了我的 WSUS 数据库，这样我就不必写下（或记住）要拒绝哪些更新（例如，我们有一个自定义的 Word 插件，它会因某个 KB 而崩溃）。
答案3
在之前的一份工作中，当备份接近磁带容量时，我研究了这个问题。我没有继续备份 WSUS，而是将其安装在另一台服务器上，并将其配置为下游服务器，即使它实际上没有为任何客户端提供服务。我认为，如果有必要，我可以编辑指向该服务器的 GPO 设置，然后继续处理更紧急的事情，例如恢复故障系统的其余部分。使用的磁盘空间无关紧要，但它确实释放了磁带上的宝贵空间。
答案4
您所说的重建 WSUS 服务器是正确的（但是，如果替换 WSUS 服务器的更新 URL 与出现故障的 WSUS 服务器相同，则无需对组策略、注册表设置等客户端配置进行任何更改）。
是否备份 WSUS 数据库实际上只是下载时间与备份资源（空间、备份窗口时间）使用情况之间的权衡。它通常很小，所以我会定期去获取它。