包含大量硬链接的硬盘几乎一夜之间就“填满”

包含大量硬链接的硬盘几乎一夜之间就“填满”

我最近在服务器上安装了一个便宜的 2TB 硬盘,用于备份也在其他地方备份的文件。它基本上是一个溢出驱动器。服务器上的其他驱动器配置为 Raid 6 阵列中的 1TB。为了方便起见,我将这个单个驱动器配置为 Raid 0。

本质上,我将大约 700GB 的数据从 Raid 6 驱动器移至 Raid 0 驱动器,因为 Raid 6 驱动器几乎已满。所以... 2 TB 应该绰绰有余,对吧?

数据是从远程服务器 rsync 的数据形式,以标准“硬链接”方式处理 6 天的增量备份,以确保我只存储/传输更改,而不是每天备份整个数据。

然而,我看到的行为是,存储在 Raid 6 驱动器上约 700GB 的数据迅速膨胀到几乎填满 2TB 驱动器,就好像我没有使用硬链接一样。

昨天我删除了大约 300GB 不再需要的数据,一夜之间存储空间又恢复到了 97%。

有人知道发生了什么吗?驱动器真的“已满”吗,还是只是硬链接计算错误?

所有驱动器均格式化为 Ext4。

**编辑 **

备份过程的详细信息:

每天,cronjob 都会使用 将备份 0 复制到备份 1。在 rsync 发生之前,cp -al backup0 backup1以前的备份会通过 等移动。mv backup1 backup2

backup5每天都会删除。删除后,远程服务器会 rsync 到 backup0(因此只更新已更改的文件)。因此,5 天的增量备份。这基本上也是“backintime”等软件的工作原理。

**第二次编辑 **

我刚刚删除了备份 3 到备份 5,它释放了大约三分之二的驱动器空间。所以,问题似乎在于如何计算存储空间。(我用它df -h来监控存储空间)。

问题仍然存在......当驱动器达到“100%”时,即使有足够的空间,它是否会被视为“已满”?

答案1

cp -al无需使用,只需使用mvrsync

请参阅 Admin Magazine 的文章:“Linux 上的增量备份“:

“大多数现代 Linux 发行版都有一个相当新的 rsync,其中包含非常有用的选项 --link-dest= 。此选项允许 rsync 将文件副本与现有目录结构进行比较,并允许您告诉 rsync 仅复制相对于指定目录的已更改文件(增量备份)并对其他文件使用硬链接。”。

该文章完整展示了以下脚本的工作原理和作用,特别是每个备份中的 inode 编号都是相同的(从而节省了空间):

“...请注意,第一个文件的 inode 编号在两个备份中是相同的,这意味着该文件实际上只存储一次,并带有硬链接,从而节省了时间、空间和金钱。由于硬链接的存在,不需要额外的数据。为了更好地理解这一点,您可以对两个备份目录中的文件运行 stat 命令。”。

GNU 的 cp命令:

-a,--存档

尽可能多地保留副本中原始文件的结构和属性(但不要尝试保留内部目录结构;即,“ls -U”可能会以不同的顺序列出复制目录中的条目)。尝试保留 SELinux 安全上下文和扩展属性 (xattr),但忽略任何失败,并且不打印相应的诊断。相当于 -dR --preserve=all,但诊断减少

-l,--link

创建硬链接而不是非目录的副本。

Samba.org 的 rsync命令:

-a,--存档

存档模式;等于 -rlptgoD(无 -H、-A、-X)

-H, --hard-links

保留硬链接

-v,--详细

增加详细程度

另请参阅GNU 的 du命令:

-h, --人类可读

在每个大小后面附加一个大小字母,例如“M”表示兆字节。使用的是 1024 的幂,而不是 1000;“M”代表 1,048,576 字节。此选项相当于 --block-size=human-readable。如果您喜欢 1000 的幂,请使用 --si 选项。

-s,--总结

仅显示每个参数的总数。

你会想要这样的东西:

rm -rf backup.3 
mv backup.2 backup.3 
mv backup.1 backup.2 
mv backup.0 backup.1 
rsync -avh --delete --link-dest= backup.1/ source_directory/ backup.0/

第一次运行脚本时,由于所有备份文件都不存在,你会看到一些错误,但一旦脚本运行人口稠密一切都将没有错误。使用du -sh并将其与ls的输出,如ls -s

问题仍然存在......当驱动器达到“100%”时,即使有足够的空间,它是否会被视为“已满”?

假设您正在运行的应用程序用于确认剩余驱动器空间的实用程序两个都然后使用正确的系统调用检查剩余空间两者都将报告正确的值,任何接近于零的值都是“满的”,因为临时文件的大小各不相同,并且在活动操作系统上不断创建和删除。绝不接近于零,您可能会在重新启动时崩溃并出现启动错误。

相关内容