今朝、Google Cloud Platform（GCP）の仮想マシン（VM）にSSH接続しようとしましたが、接続できませんでした。コンソールを確認すると、シリアルコンソールは無効になっており、スタートアップスクリプトも動いていません。少し調べてみた結果、原因はディスクが完全にいっぱいになっていたことでした。
すべてのリモートアクセスがブロックされていましたので、唯一の解決策はディスクを「外科手術」のように取り外し、別のVMに接続して不要ファイルを削除し、再び元のVMに戻すこと。
作業メモを共有します。
1. ヘルパーVMを作成する
GCPコンソールで、新しいVMを問題のあるVMと同じゾーンに作成します。
安価で軽量な e2-micro タイプで十分です（クリーンアップ作業にはこれでOK）。
これで、問題のディスクを調査・修復するための別の稼働中のVMが用意できました。
2. 問題のあるVMからディスクを切り離す
- 問題のあるVMを停止します。
-
編集 → ストレージ → ブートディスク欄で 「切り離し」 をクリックします。
（この操作ではディスクは削除されず、VMから取り外すだけです）
元のVMから安全にディスクを取り外し、他のVMでマウントできる状態になりました。
3. ディスクをヘルパーVMに接続する
- ヘルパーVMの編集ページを開きます。
- 追加ディスク → 既存のディスクを接続 をクリック。
- 先ほど切り離したディスクを選択します。
- 変更を保存し、ヘルパーVMを起動します。
ヘルパーVMが問題のあるディスクをセカンダリドライブとして利用できるようになりました！
4. ヘルパーVMで問題のディスクをマウントする
ヘルパーVMにSSH接続します。
接続されたディスクのパーティションを確認（恐らく/dev/sdb1になりますが要確認）：
lsblk
マウント用ディレクトリを作成し、ディスクをマウント：
sudo mkdir /mnt/rescue
sudo mount /dev/sdb1 /mnt/rescue # 名前が異なる場合は適宜修正
これで、元のVMの全ファイルシステムが /mnt/rescue にマウントされました。
5. ディスクをクリーンアップする
ディスク容量を多く使っているディレクトリ・ファイルを調べるには：
sudo du -ak /mnt/rescue/ | sort -nr > /tmp/bad_vm_usage.txt
/tmp/bad_vm_usage.txt を開くと、使用量が多い順に確認できます。
私の場合、キャッシュファイルや古いログを削除しました：
sudo rm -rf /mnt/rescue/var/lib/docker/buildkit/*
sudo rm -rf /mnt/rescue/var/cache/apt/archives/*
sudo rm -f /mnt/rescue/var/log/*.gz
sudo rm -rf /mnt/rescue/var/lib/snapd/cache/*
sudo rm -rf /mnt/rescue/var/log/journal/*
削除後、以下で空き容量を確認します：
df -h
元のVMは起動してSSH接続が可能になるだけの空き容量が確保されます。
6. アンマウントしてディスクを元に戻す
- ディスクをアンマウント：
sudo umount /mnt/rescue - ヘルパーVMを停止します
- ヘルパーVMから救出ディスクを切り離します
- 元のVMにブートディスクとして再接続します
- 元のVMを起動します
これで再びSSH接続できるようになっているはずです！
結論
クリーンアップ後のディスクを元のVMに再接続して「起動」ボタンを押すと、問題なくSSH接続できました。
データは失われず、サーバーをゼロから再構築する必要もありませんでしたので、ホッとしました！