适用于 Linux 的大文件(备份)的稳定文件系统

适用于 Linux 的大文件(备份)的稳定文件系统

什么文件系统最适合备份?我主要对稳定性感兴趣(特别是硬重启期间文件的完整性等),但它处理大型(> 5GB)文件的效率也很重要。

另外,我应该使用哪些安装参数?

内核是 Linux >= 2.6.34。

编辑:我愿意不是想要备份方法。我需要文件系统来存储它们。

答案1

您可以使用外部4但我建议使用journal_data模式安装,该模式将关闭 dealloc(延迟分配),这会导致一些早期的问题。禁用dealloc将使新数据写入速度变慢,但使在断电时写入不太可能丢失。我还应该提到,您可以在不使用的情况下禁用 dealloc,journal_data它还有一些其他好处(或者至少在 ext3 中确实如此),例如稍微改进了读取,并且我相信更好的恢复。

范围仍然有助于解决碎片问题。范围使大文件的删除速度比 ext3 快得多,在 ext4 上删除任何大小的数据(单个文件)应该几乎是瞬时的,但在 ext3 上可能需要很长时间。 (任何基于范围的FS都有这个优势)

ext4 也fsck比 ext3 更快。

最后一点,ext4 到 2.6.31 都有错误修复吗?我基本上会确保您没有运行 2.6.32 之前的内核,这是一个 LTS 内核。

答案2

XFS 坚如磐石,并且已经存在于内核中很多年了。检查 xfs_freeze 等工具,看看它是否是您正在寻找的。我知道这是非常主观的,但我多年来一直使用 XFS 进行数据存储,没有发生任何事故。

答案3

只需使用支持校验和的备份工具即可。例如达尔确实如此,并且它支持增量备份。然后您可以备份到像 ext3 这样坚如磐石的文件系统。

对于备份,您需要坚如磐石/非常稳定的东西。而 btrfs 或 ZFS 目前还没有准备好。

答案4

恕我直言,我在其他答案中没有看到讨论的一个非常重要的方面是磁盘布局的稳定性特征文件系统的(例如,考虑查阅可能的候选者的文档外部4,BTFS

虽然代码库和代码库文件系统驱动程序的测试量确实很重要,正如其他答案已经表明的那样,因为它是在读取和写入期间保护数据, 这关于磁盘布局/格式是针对静态数据的风险的保护,这些风险是硬件缺陷的形式,例如不可读的扇区或静默位腐烂

关于ext4,据说具有良好的特性,因为经过长期测试的代码库(https://events.static.linuxfound.org/sites/events/files/slides/AFL%20filesystem%20fuzzing%2C%20Vault%202016_0.pdf显示在其中找到错误比在更现代和更复杂的情况下花费的时间更长btrfs),我有研究了 ext4 静止时的电阻并发现其他赞扬的文件系统的一些恕我直言的缺陷。

我认为这是谨慎的(如果选择ext4坚如磐石的备份文件系统”)通过使用e2image开发人员ext4提供的工具来提高可恢复性(尽管“强化它”)

e2image 程序会将设备上的关键 ext2、ext3 或 ext4 文件系统元数据保存到 image-file 指定的文件中。通过使用这些程序的 -i 选项,可以通过 dumpe2fs 和 debugfs 检查映像文件。这可以帮助专家恢复灾难性损坏的文件系统。将来,e2fsck 将得到增强,能够使用映像文件来帮助恢复严重损坏的文件系统。

推荐

为系统上的所有文件系统创建映像文件并定期保存分区布局(可以使用 fdisk -l 命令生成)是一个非常好的主意——在启动时和/或每周或所以。映像文件应存储在除其包含数据的文件系统之外的某个文件系统上,以确保在文件系统严重损坏的情况下可以访问该数据。

考虑到甚至不是所有的元数据ext4 在磁盘布局上提供冗余(即超级块通常作为副本存储多次,indoes仅存储在恰好1个位置),这ext4肯定btrfs不如至少为以下内容提供校验和的情况:全部元数据+文件内容数据

为了弥补这个“缺点” ext4,让它变得更加rock-solid重要在磁盘布局上par2通过/补充文件内容的冗余和恢复可能是合理的帕奇韦

尽管这个问题需要关注文件系统解决方案,但我想提醒大家注意,文件系统提供的大部分功能(缓存、日志、回收分配的空间、分配块等)并不一定能让备份数据受益。当仅批量且少量地写入和读取时,会发生很多情况。为此,我会考虑使用parchive补充tar备份作为更优化的备份解决方案,因为过程中使用的代码库减少了,因此如果“功能”较少,则错误也会减少。

相关内容