予期しない停電 (または VM ホスト障害) が発生した場合に、Linux OS の潜在的な破損をチェックし、回復するためのベスト プラクティスの手順は何ですか?
もちろん、それはインストールとセットアップに「依存」しますが、私は Linux OS (Debian、Ubuntu、Mint、その他) とファイル システム (XFS、ZFS、EXT4、vfat) の大部分に対して実行する共通のアクション/チェックを探しています。
これは、予期しないシャットダウンを防ぐことではなく、シャットダウンが発生したときに対処し、最善の回復を確実に行うことです。
OS は、ファイルシステムがアンマウントされていないことを検出し (正常なシャットダウン時のように)、起動時に自動的にチェックを実行する傾向があることは承知していますが、それらのチェックとは何ですか。また、手動で実行するにはどうすればよいですか。
たとえば、e2fsck -fそのようなツールの 1 つですが、初心者にとっては、いつ使用できるか、いつ使用すべきか、いつ使用できないか (または機能しないか) がわかりません。
たとえば、Windows では次のように実行します。
- PowerShellの古いバージョン
chkdskまたは最新のバージョンを使用して、NTFS ファイルシステムの破損をチェックします。repair-volume - OSコアシステムファイルの整合性を検証する
sfc.exe /scannow
MySQL databaseまたはなどのアプリケーション固有の検証/回復手順は、一部の OS データベース (またはデータベースLDAP directoriesなど) のように非常に一般的なものでない限り、この質問の範囲外です。aptsnap
職業はなんですか？
答え1
最新のファイルシステムはメタデータ ジャーナルを実行するため、単純な停電ではファイルシステムの整合性自体に問題は発生しません。完了したがコミットされていないトランザクションは再生され、部分的なトランザクションはロールバックされます。
ただし、転送中またはキャッシュされたデータは、できる結局、アプリケーションがOSに非同期書き込み（通常の書き込み）のためにデータを処理したが、OSがそれを永続的なストレージに書き戻す前にマシンの電源が落ちた場合、データは失われるか、部分的に書き込まれる可能性があります。意思失われます。
まさにこの理由から、データベースなどの重要なアプリケーション ( を除くMyISAM) は独自のジャーナリングを実装し、fsync()などを使用して同期セマンティクスでデータを書き込みます。
簡単に言うと、計画外のシャットダウンでは、通常はファイルシステムの修復は必要ありません（自動ジャーナル再生以外）。アプリケーションのチェックはアプリケーション自体に依存しており、ほとんどのデータベースは突然の電源喪失の影響を受けません（ただしMyISAM、必要ランニングmysqlcheck