我今天剛得到一個新的備份驅動器，所以我將它與 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）；在這種情況下使用驅動器的風險通常遠大於嘗試恢復硬體故障的任何好處）。