请原谅这个相当简单的问题。
首先，我不是系统管理员，而且我在 Linux 方面的经验有些有限。
大约 3-4 个月前，出于各种原因，我在工作中设置了一个 CentOS 服务器。我们将它用作网站（我们的客户可以访问）的开发服务器、颠覆服务器，并且我们也在其中托管一个 wiki 用于内部通信，因此它已成为我们非常重要的工具。（可能比我设置它时我们想象的更重要！）
我注意到 Yum 想要将大约 250 个软件包更新到 repo 中的最新版本。
既然服务器对我们来说工作正常，我应该冒险更新这些包吗？当我更新所有内容时，安全风险是否超过服务器崩溃的风险？
我应该指出，虽然我对所有内容都有备份，但将所有内容设置为刚才的方式需要时间，而且我目前没有太多空闲时间工作！
如果建议是更新，是否有任何最佳实践可以传递以使该过程尽可能安全？
提前感谢您的任何建议。
更新 - 感谢大家的回复。如果我有足够的代表来投票给每个人，我会的。;) 我决定对硬盘进行镜像并更新。不幸的是，目前无法选择全职或兼职系统管理员，所以我只需要尽可能地处理这个问题！
快速而肮脏（即战场管理员）的解决方案：
使您的系统脱机（我希望您可以）并执行 NortonGhost 备份（或类似的东西）到第二个硬盘驱动器。
启动第二个硬盘驱动器（以确保您的备份确实有效）并在该驱动器上执行 yum 更新。
如果一切正常...恭喜！
如果它搞砸了...继续并放入您的原始驱动器并提出“B计划”。
更新：
只是想我会提到这里真正的问题是“我是否更新了我的 waaaay 过时的系统并冒着把它搞砸的风险？” 或“我是否让我完美的工作系统未打补丁并冒着被黑客入侵/受损的风险？”
答案是……一旦您通过上述步骤对系统进行了修补……尝试通过经常备份和经常修补来掌握它。
然后，您将拥有两全其美。;-)
是的，更新。
RHEL（以及因此的 CentOS）小心不要将版本更新到任何不兼容的东西，而是向后移植错误修复和安全修复，因此对包的实际更改是最小的，并且不太可能导致兼容性问题。
如果任何配置文件已更改，软件包将告诉您有关已创建的 .rpmorig 或 .rpmnew 文件。这取决于 RPM 本身的配置。您可以查找有关正在创建的任何警告的警告，然后将旧配置放回 ("
cp foo foo.bak; cp foo.rpmorig foo") 或查看 .rpmnew 文件并将任何更改合并到您的配置中。如果您定期更新，问题就不那么明显了。
我们有很多系统每季度（每 3 个月）更新一次；并且很少看到包更新的任何问题。（除了系统做奇怪的内核事情来从 SAN 访问 LUN）
虽然是的，但升级需要时间，并且在同一个庄园中，如果出现问题，需要时间来恢复，如果该系统上的数据通过漏洞利用/黑客攻击被删除，会有多大的痛苦/痛苦？
在大多数情况下，从 CentOS 基础存储库升级是可以安全安装的，我唯一遇到 CentOS 更新问题的时候是我启动/或需要使用外部存储库（DAG、RPMForge 等）时
此类事情的最佳设置是准备好可热插拔的服务器，因此您可以在将更新部署到实时服务器之前对其进行测试。
如果这个系统如此重要，那么安全更新就变得更加重要。如果（何时？）一个过时的软件包允许系统妥协，请考虑如果必须关闭该系统以进行重建的影响。理想情况下，您应该以类似的方式配置一个测试服务器，您可以先更新它，然后检查是否有任何问题。
当您应用更新时，您需要确保以下几点：
一个好的系统管理员应该有这种工作的经验，并且无论如何都应该做所有这些事情。如果您的组织有，那么这可能是时候将系统管理转储给他们了。或者，如果您对自己做这件事感到紧张，那么请考虑聘请有合同的人来进行这种日常维护。无论哪种方式，都需要进行更新，因为您将面临更糟糕的情况。
听起来您需要一个真正的系统管理员花几个小时来检查您的系统，更新它并确保一切再次运行。理想情况下，你会让这个人每个月来为你做几次。服务器不是安装一次就忘记的东西。它需要定期服务。
这就是为什么今天我几乎从不在真实硬件上运行任何生产系统的原因。我在虚拟机中运行它们。然后在短暂的停机时间（5 分钟）内，我从 ESX 本身运行快照，或者如果我使用自定义 Xen/Solaris/OpenVZ 设置，我对服务器映像进行 LVM 快照。然后我启动原始备份，现在我有一个我可以随意使用的副本。
也就是说，从更新内核和 apache 开始，然后从那里向后工作。您不必获取 yum 报告的完整软件包列表，但最重要的攻击向量应该是您最快修补的攻击向量。
每次我有一个 Linux 系统被黑，都是因为我没有给 apache、openssh 或内核本身打补丁。
我只会更新与安全相关的软件包。
大约一年前我就提出了那个确切的问题……我在 CentOS 机器上进行了 yum 更新，在戴尔硬件上运行，它安装了一个无法启动的内核。盒子上还没有装任何东西（否则我会更加谨慎）。花了很多时间弄乱它，似乎 CentOS/Linux 较新的内核和戴尔盒子之间存在一些不兼容。对您的更新非常谨慎。我仍然建议更新，因为这是正确的做法，但要准备好从损坏的系统中恢复！