我今天刚得到一个新的备份驱动器,所以我将它与 rsync 一起使用,一切都很好,备份出现并且我的系统看起来很好,但后来我使用 apt-get 并收到了此错误:
root@cloud7-media:~# apt-get install sl
W: Not using locking for read only lock file /var/lib/dpkg/lock
E: Unable to write to /var/cache/apt/
E: The package lists or status file could not be parsed or opened.
所以我心想这没问题,可能只是一个错误,所以我重新启动。然后我的系统不在线。我进入网络面板检查我的系统是否已启动并正在运行,但事实并非如此。我插入显示器并接受自动修复更改,因为在驱动器上检测到问题,并且它再次启动。
这是我使用的 rsync 代码:
rsync -aAXv --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found","/BTSync","/home/cloud7/torrent"} / /mnt/backup/cloud7
顺便说一句,我可以确认 rsync 导致了它,因为我再次运行它并重新启动系统,并且它再次离线。
答案1
您可以尝试检查 rsync 之后的运行时日志。内核日志可能说Remounting filesystem read-only
。当遇到错误时,即使仅读取,也会自动发生这种情况。内存中的内核日志通过 检索dmesg
。如果使用 systemd,journalctl -b
也可以通过使用 tmpfs 继续工作。
我看到其他人也在评论日志。需要明确的是,当错误导致文件系统以只读方式重新挂载时,您可能没有机会将错误消息写入存储的日志文件中在文件系统上:)。
我对此如此有信心的原因是随后的“自动修复更改,因为在驱动器上检测到问题”。
我还知道 rsync 至少在遇到一些错误时可以继续,因此它不一定会因明显的错误消息而提前中止。相反,它可能会以一般警告结束,表明传输某些文件时出错 - 我过去忽略了这一点。 (或者 rsync 可能根本没有受到错误的影响,但我想不出会导致这种情况的情况)。
无需再次破坏您的系统
你的硬盘可能有问题
请使用 SMART 检查其运行状况。 smartctl -H
。另外smartctl -a
,还要特别注意提到行业的柜台。如果存在“待处理”或“无法纠正”的扇区,强烈建议考虑驱动器有故障。
(构建大型存储系统的公司在驱动器上使用冗余,重写坏扇区,并编写算法来猜测故障是暂时的还是持久的。听起来不像您正在运行冗余系统(RAID);在这种情况下使用驱动器的风险通常远大于尝试恢复硬件故障的任何好处)。