今日、新しいバックアップ ドライブを入手したので、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 が原因であることは確認できます。再度 rsync を実行してシステムを再起動すると、再びオフラインになったからです。
答え1
rsync の後に実行時ログを調べてみてください。カーネル ログにはおそらく と出力されますRemounting filesystem read-only。読み取り専用であっても、エラーが発生すると自動的に発生します。メモリ内のカーネル ログは で取得されますdmesg。systemd を使用している場合は、journalctl -btmpfs を使用して動作を継続することもできます。
他の人もログについてコメントしているようです。明確に言うと、エラーによってファイルシステムが読み取り専用で再マウントされた場合、エラーメッセージをログファイルに書き込む機会はなくなると考えられます。ファイルシステム上:)。
私がこれに自信を持てる理由は、その後に続く「ドライブで問題が検出されたため、変更を自動的に修正する」という部分です。
また、rsync は少なくともいくつかのエラーが発生しても続行できることがわかっているので、目立つエラー メッセージで必ずしも早期に中止されるわけではありません。代わりに、いくつかのファイルの転送中にエラーが発生したという一般的な警告で終了する可能性があります。私は過去にこれを見落としていました。(または、rsync がエラーの影響をまったく受けなかった可能性もありますが、これを引き起こす状況は思いつきません)。
システムを再び壊すことなく
ハードディスクに障害がある可能性があります
SMART を使用してドライブの状態を確認してください。 smartctl -Hまたsmartctl -a、セクターを示すカウンターを特に確認してください。「保留中」または「修正不可」のセクターがある場合は、ドライブに障害があると見なすことを強くお勧めします。
(大規模なストレージ システムを構築する企業は、ドライブの冗長性を使用し、不良セクターを書き換え、障害が一時的か永続的かを推測するアルゴリズムを作成します。冗長システム (RAID) を実行しているようには思えません。この場合、ドライブを使用するリスクは、ハードウェア障害の回復を試みることによるメリットよりも一般的にはるかに大きくなります)。