私のクラウドホスティングファイルを盗んだのは誰ですか? ！落とし穴を避けるための5つのシナリオ

[[326625]]

クラウドサーバーの日常的な運用と保守において、当社のエンジニアはさまざまな理由でユーザーから報告されるファイル損失の問題に頻繁に遭遇し、ユーザーに多かれ少なかれ迷惑をかけています。私たちは、より一般的なシナリオを整理し、誰もがこれらのリスクを回避し、同じ間違いを繰り返さないようにしたいと考えています。

シナリオ 1: クラウドホストの再起動後にファイルが失われる

現象：

ユーザーレポート: クラウドホストを再起動すると、そこに保存されていたデータが消えてしまいました。クラウドホストに何か問題がありますか? ！

分析:

ユーザーとやり取りした結果、ユーザーが /dev ディレクトリに保存したファイルが欠落していることが確認されました。当然のことながら、ユーザーデータは、ファイルシステムタイプが tmpfs の /dev ディレクトリに保存されます。 tmpfs ファイルシステムは、永続ディスクではなく、デフォルトでメモリに保存されるため、ホストを再起動するとデータが失われます。

分析：

1. tmpfs とは何ですか?

tmpfs はメモリベースの一時ファイルシステムです。データは RAM に保存され、パフォーマンスが非常に優れています。

2. Linux システムにはどのような tmpfs がありますか?

/dev、/dev/shm、/sys/fs/cgroup、/run/user/0 など。tmpfs ファイルシステムのデフォルトは、合計メモリサイズの半分です。 df コマンドを使用すると、どのボリュームが tmpfs ファイルシステムであるかを確認できます (Filesystem 列に tmpfs が表示されます)。

提案：

1. tmpfs はプログラム/アプリケーションキャッシュにのみ使用されます。

2. tmpfs にデータを保存することは推奨されません (データ損失のリスクを負うことができる場合を除く)。

シナリオ2: 誤ってrmコマンドを実行する

現象：

ユーザーレポート: 再起動後にクラウドホストに ping できない、一部のシステムサービスを開始できない、重要なシステムファイルが失われるなど。

分析:

1. 仮想化コンソールを通じて、OS がブートインターフェイスで停止し、多数のコマンドが存在しないことが報告されます。

2. イメージをマウントしてシステムに入ったら、less /root/.bash_history を通じてユーザーの操作記録を確認します。 rm -rf /、rm -rf、rm -rf などのコマンドが表示されることがあります。 /* (ドットとスラッシュの間にはスペースがあります)、および rm -rf ./ により、多数のシステムディレクトリとファイルが削除されます。

3. rpm -Va |grep miss コマンドを実行して、不足しているシステムファイルを確認します (rpm パッケージを通じてインストールされていないファイルは確認できません)。

提案：

1. rm コマンドは、特に -r および -f パラメータを使用する場合は注意して使用してください。削除を確認するには -i パラメータを追加できます。

2. エラーが発生した場合は、まずディスクへの書き込みを停止し、削除されたファイルのディスク領域が上書きされないように回復する方法を見つけます。

3. 削除されたシステムファイルについては、他の通常のシステムからコピーすることで復元できます。

4. 一部のシステムファイルまたは構成ファイルについては、yum reinstall package name/yum update package name コマンドを使用して再インストール/アップグレードすることで復元することもできます。

シナリオ 3: ファイルシステムの破損 (FIO)

現象：

ユーザーレポート: クラウドホスト上で実行されている MySQL データベースが異常です。

分析:

1. 監視により、クラウドホストの IOWAIT が比較的高いことがわかり、これは IO 制限に関連していると思われます。

2. クラウドホストのディスク制限を解除した後も例外が発生します。 MySQL サービスがクラッシュし続け、スタンバイマシンでもホストマシンと同じ現象が発生し、次のログが出力されます。

3. DBA は、MySQL データファイルに問題があることを発見し、報告します。

4. スタンバイマシンでは、MySQL データファイルが配置されているボリュームのファイルシステムに重大な異常があり、そのボリューム上にファイルを作成することも失敗することが判明しました。

5. history コマンドを使用して root ユーザーの操作記録を分析すると、ユーザーが fio コマンドを使用して /dev/vdb ディスク (/data ボリュームが配置されているディスク) に対して直接ストレステストを実行していることがわかります。ストレステストにはランダム書き込みとシーケンシャル書き込みが含まれますが、/data ディレクトリへの書き込みは含まれません。

6. MySQL マスターノードも同じ fio 操作を実行します。 fio はファイルシステム層をバイパスしてブロックデバイス上で直接操作するため、ディスク上の実際のデータが上書きされ、ファイルが深刻な損傷を受けることになります。 MySQL データベースはエラーのあるデータファイルを解析できず、クラッシュします。

7. 2 つの MySQL ホストの /data ボリュームデータは信頼できなくなりました。 /data ボリュームを再フォーマットし、バックアップノードを通じてデータを復元する必要があります。

提案：

1. fio ツールは実稼働環境では注意して使用する必要があり、オンラインにする前にストレステストを実行する必要があります。

2. fio コマンドを使用する場合、--filename パラメータでブロックデバイス (/dev/sda、/dev/vdb など) を直接指定するのではなく、通常のファイルを指定する必要があります。最初に空のファイルをタッチし、次にファイル名を指定できます。

テストが完了したら、ファイルを削除します。そうしないと、-size パラメータで指定されたスペースが占有されます。

シナリオ 4: ファイルシステムの破損 (DD)

現象：

ユーザーレポート: クラウドホストファイルへの異常なアクセス。

分析:

1. クラウドホストデータボリューム上のファイルにアクセスできず、ls も異常で、[構造をクリーニングする必要があります] というエラーが報告されています。

2. dmesg および /var/log/messages ログファイルから、多数の xfs ファイルシステムエラーを確認できます。

3. history コマンドを使用して root ユーザーの操作記録を分析し、root ユーザーが dd コマンドを使用して /dev/vdb ディスク (/data ボリュームが配置されているディスク) で直接ストレステストを実行し、/dev/vdb ディスクにゼロを書き込んだことを確認します。

提案：

1. dd ツールは実稼働環境では注意して使用し、オンラインにする前にストレステストを実行する必要があります。

2. dd コマンドを使用する場合、of パラメータはブロックデバイス (/dev/sda、/dev/vdb など) を直接指定するのではなく、通常のファイルを指定する必要があります。

次のように：