私のクラウドホスティングファイルを盗んだのは誰ですか? ！落とし穴を避けるための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 など) を直接指定するのではなく、通常のファイルを指定する必要があります。

次のように：

シナリオ5: データディスクが誤って削除される

現象：

ユーザーレポート: クラウド ディスクが誤って削除されました。

分析:

1. クラウド ポータルにログインして、クラウド ディスクの削除時間を表示します。クラウド リソースは遅延後に削除されるため、削除されたリソースは短時間で取得できます。

2. 仮想化コンソールで、ディスクが削除されたかどうかを確認します (状態ステータスが「準備完了」になっている必要があります)。

3. 削除されていない場合は、クラウド ディスクをホストに再接続できます。

4. クラウド ポータルでクラウド ディスク情報を同期します。

提案：

1. クラウドディスクを削除するときは注意してください。誤って削除した場合、データを回復することはできません。

2. 削除する前に確認してください:

A. ホスト上で lsof -n、df -h、lvs/pvs/vgs、lsblk などのツールを使用して、ディスクが使用中かどうか、拡張するボリュームに使用されているかどうかを確認します。

B. 容量拡張に使用しないボリュームについては、確認後、まずボリュームをアンマウントし、/etc/fstab のマウントポイント情報をクリアします。

C. 容量拡張に使用したボリュームは、削除すると元のボリュームが異常になるため、直接削除することはできません。

3. 誤った操作が発生した場合は、すぐにリカバリに連絡してください。そうでない場合は、ディスクが物理的に消去されます。