我们有一个内部 Web 服务器(虚拟化,托管 ReviewBoard,但不是特别相关),并且我们有一个相对一致的故障模式,NFS 安装失败导致 / 填满。发行版是 Ubuntu(不要问),如果解决方案依赖于不同的发行版,则实施起来会更慢。
备份正在执行到 /mnt/backup/,它应该是另一个系统的 NFS 挂载。不幸的是,当挂载失败或掉线时,备份将在根文件系统上执行,您可以想象,这很快就会在 / 填满之前完成,然后服务开始失败。
我们讨论了许多可能的解决方案。
监控 /mnt/backups 并确保它不是 root。也许是一个 cron 作业。
使用 /mnt/protected/backups,并首先将 /protected 挂载到一个小的文件系统,也许循环挂载到本地文件,这样失败的可能性就小得多。
Chmod a-rwx /mnt/backups(根文件系统挂载点)。我不确定通过受保护的目录进行挂载是否可行,但我认为可以。
在已安装的树上创建一个名为“Backups”的目录,然后软链接“ln - s /mnt/backup/Backups /Backups”。除非已安装 /mnt/backup,否则使用 /Backups 进行备份将失败,因为本地树不包含子目录。
检查目录是否在备份脚本中正确挂载。
我对这些方法的任何反馈、优缺点或人们用来作为保护根文件系统免受此类恶意攻击的标准方法的任何其他技术都很感兴趣。
答案1
最防错的解决方案是使挂载点不可写。这将是您的解决方案 #3。但是您还应该执行一个额外的步骤。chattr +i /mnt/backups
这是因为即使没有权限,root 仍然可以写入目录。使用chattr +i
(设置不可变标志),即使是 root 也无法写入它。一旦挂载被挂载,权限就无关紧要了,因为权限是远程目录的权限,而不是本地目录的权限。
答案2
第 5 条 - 在备份脚本中进行测试,确保目录已挂载,然后再继续。如果挂载不可用或不存在,脚本应该会失败。或者,您可以确保在运行备份之前已挂载内容。
尝试该mountpoint
命令,检查指定目录是否是挂载点:
mountpoint -q /mnt/backups || mount /mnt/backups
答案3
答案4
您可以chmod a-rwx
在根文件系统上找到挂载目标的子目录:
mkdir /mnt/backup/Backups
chmod a-rwx /mnt/backup/Backups
远程共享挂载后,创建子目录再次供脚本实际使用:
mount REMOTE_FS /mnt/backup
mkdir /mnt/backup/Backups
现在/mnt/backup/Backups
仅在挂载远程文件系统时才可用。