今日は新しいバックアップドライブを受け取ったので、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）を実行しているように聞こえません。ドライブを使用することは、通常、ハードウェア障害から回復しようとするよりもはるかに重要です。