什么是完整的根分区的副作用?

我有一个关键的服务器运行,我不能打倒(或者至less,我告诉我现在不能)。

不幸的是它填满了根分区。

它正在运行一个自定义的进程,写一些日志文件,因为我主要是一个开发人员,我想修复程序logging的方式,使其与Logrotate兼容,因为它不是现在。

所以我需要说服主要的开发者,解决这个问题是值得的,应该是一个高度优先的事情。 目前,我可以压缩日志并将它们分离出来,因为它们想要保存很长时间才能分析。 但是有一天,服务器stream量很大,并且在我有机会做任何事情之前logging下很多数据。 一旦磁盘已满,无法备份压缩大文件是不可能的。 而且由于它们很大,复制到另一台服务器可能需要相当长的一段时间。

所以我需要一些杠杆来帮助推高这个优先级。 什么是完整的根分区的副作用?

如果文件系统的其他部分位于其自己的分区上,则可以减轻完整根分区的严重程度。 但是,只是想象一下,如果任何进程无法写入文件系统,而是得到一个错误,则可能会发生什么。

作为一个例子,/var/run/*.pid文件不能由使用这种机制的任何进程创build(并且很多),它们应该无法启动或只是崩溃,或者可能会反复尝试并启动,而不会检测到它们已经开始了,因为没有pid文件存在,并开始一个新的实例,直到内存不足的杀手进程启动,并开始大部分随机杀死的东西。

副作用可以包括但不限于

  • 服务器意外地在午夜崩溃,而pipe理员正在假期,严重睡着,等等…
  • 取决于您的自定义应用程序的写入方式,它可能无法以任何合理的方式处理该崩溃,并将自身损坏到需要从备份还原的地步。 大多数开发人员首先想到的是testing不是,“如果我把电源线拔出来,会发生什么…..现在,哇,没有杀死它,如果我这样做,怎么样…….现在”

你有备份权利…

需要多长时间?

  • 意识到你无法在任何合理的时间内恢复现有的系统
  • 可能会build立一个新的机器(所以你拿出旧的分析一些有希望的信息恢复)
  • 实际上从备份恢复

像这样的停机时间和数据丢失pipe理多less…?