我们使用 Symantec backup exec 12。我们认为没有必要每晚备份系统状态。我们选择每月备份一次，或者如果进行了系统更改。
我已阅读有关系统状态备份的确切内容的文章。根据我目前的理解，即使在系统状态下，仍然需要备份整个 C: 驱动器和系统上的任何其他驱动器才能执行系统还原。
我们正在将多台服务器备份到压缩的 800gb 磁带上。问题是，现在我们选择每月只备份系统状态，这样每次完整备份可以节省 80gb，您认为我们是否需要继续每晚备份完整的 C: 驱动器？
注意：我们每周进行一次主程序，每晚进行一次增量。出现这个问题的原因是我们坚持每周master，然后每月返回前一周进入轮换，每月持有直到年终执行，然后永久保存年终，每个月最终都会回到轮换。Blah Blah 我在胡说八道。目前，我们在每个完整备份中使用两个磁带。为了方便起见，我们试图减少到 1 个磁带，但想要正确地进行备份！
其他管理员认为最佳做法是什么？
从理论上讲，您可以严格备份系统状态，如果发生灾难，您可以将其恢复到新硬件上全新安装的操作系统。
在实践中，事情并不总是那么顺利。通常有 A) 日志或 B) 特定于硬件的实用程序/驱动程序位于 C 驱动器上，这在恢复时会很有帮助或很关键。
为了弄清楚您是否可以仅凭系统状态逃脱，您应该真正进行灾难恢复测试并进行实际恢复（实际上，您应该按照一般规则每年都进行此测试）。总是在备份太多方面犯错，直到你证明你可以用更少的东西做。
-j
我每周都会在选定的 Windows 服务器上对我们的 C: 驱动器进行完整的备份，并提供系统状态。我们只需要备份那些保存在 C: 驱动器上且不容易重新创建的机器的操作系统。无论如何，许多盒子重建比恢复更快。Weekly Fulls 背后的理论不应该在这些驱动器上经常改变。我们将这些备份保留两周，因此我们有两个备份副本。它使我们在能够取回我们需要的东西和不消耗太多磁盘方面取得了很好的平衡。这也意味着我们的操作系统/系统状态备份相对较新，如果我们必须回滚丢失的更改，它们只是从过去一周开始的，这意味着它们足够新，可以记住，而且不会太多麻烦。
我们不会在 C: 驱动器上存储任何类型的用户数据。它们只针对无法安装在另一个驱动器上的应用程序数据以及配置问题。
我们确实使用 SystemStates 对我们的 DC 进行了夜间备份，以便我们再次获得当前的 AD 信息，这些信息我们只保留两周，基本上只用于 DR。与我们保留更长时间的用户数据相比。
我不确定你的情况是什么，但根据我的经验，完全备份系统不是必需的，甚至不是一个好主意。（喘气！）
本质上，最好的办法是在开始时有故障安全冗余（例如 mysql 服务器上的 Master-Master 复制）或 Raid-1。（或 5 以获得最佳效果）。
基本上，在我看来和经验中，“状态备份”是一种完成工作的混乱方式。如果您需要绝对最短的停机时间（例如不到一分钟），请使用冗余。除此之外，请使用适合系统的备份解决方案（基于 rsync 的文件系统解决方案、代码存储库等）。
此外，请始终检查您的备份。在我之前作为 Jr. Linux 系统管理员的帖子中，我遇到了价值 8 年的每周备份……最终需要一个。发现刚刚因严重无能而被解雇的人，8年来一直在直接支持错误（一个空的）。
我们也不对 C: 进行完整备份，但我们每晚都会备份系统状态。如果您使用活动目录，从您的 DC 中保留常规系统状态备份非常重要——与整个驱动器的完整备份相比，它们本身不会占用太多空间，并且如果您的备份比 DNS 更旧墓碑年龄（默认为 60 天）不利于恢复 AD。
从直接经验来看，操作系统和系统驱动器的裸机备份通常并不顺利。我们选择使用诸如热插拔 RAID 之类的东西来实现冗余，然后备份数据和——只要有可能——配置，假设我们需要重新安装操作系统和应用程序，如果任何事情发生完全不正常的话。
在这里完成服务器上所有内容的备份；周末满员，每晚差价。考虑到执行系统状态在时间和存储方面对备份造成的相当小的开销，没有真正的理由不这样做。
请记住，系统状态包括注册表。注册表是否有任何更改将取决于您的服务器和安装的服务。如果这些服务定义中的任何一个驻留在注册表中并且设置发生更改，您将需要在任何这些服务定义更改后更新系统状态备份。