![转储/恢复 4 个文件系统过去需要 40 分钟,现在需要 24 小时](https://linux22.com/image/1524246/%E8%BD%AC%E5%82%A8%2F%E6%81%A2%E5%A4%8D%204%20%E4%B8%AA%E6%96%87%E4%BB%B6%E7%B3%BB%E7%BB%9F%E8%BF%87%E5%8E%BB%E9%9C%80%E8%A6%81%2040%20%E5%88%86%E9%92%9F%EF%BC%8C%E7%8E%B0%E5%9C%A8%E9%9C%80%E8%A6%81%2024%20%E5%B0%8F%E6%97%B6.png)
在我的小型商业 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 光盘。
帮助