在我的小型商业 Linux 服务器上，我使用 dump 进行备份。我有 4 个文件系统（root、home、app1、app2），其中 root 是“真实”分区，而其他的是 LVM 分区。全部都是 ext4。
我以前能在 40-45 分钟内完成 0 级转储。突然有一天，它们开始需要 8 个小时，从那时起，速度越来越慢……现在需要超过 24 小时。1 级转储大多数日子里仍然能在 10-15 分钟内完成。
我首先想到的是，最大的文件系统 (/home) 中可能存在“污垢”，因此最先出现速度变慢。但是 fsck 并没有解决问题。
我受启发，检查了具有实时文件系统的驱动器上的 smartctl 设备状态，确实发现了几十万个瞬时读取错误。更换了驱动器，并从备份中恢复（备份完好无损）。问题仍然存在。替换驱动器上的 smartctl 显示数百万个瞬时读取错误。网上的一些文章表明，对于现代 TB 驱动器来说，这可能是正常的。尽管如此，我用 SSD 替换了驱动器，但没有任何变化。
实时文件系统位于 Seagate Barracuda 500 GB 硬盘上。我一直被告知 Seagate Barracuda 是硬盘的黄金标准。
备份暂存磁盘是 WD 1TB 驱动器。smartctl 显示 0 个错误。
知道为什么这个问题会突然出现以及可能是什么原因造成的吗？
有些人会说 dump/restore 太老派了，不适合今天使用，但我发现它比 rsync 更容易管理。我有每日增量，然后将每周级别 0 存档到 BD-R DL 光盘。
帮助