さくらVPSでKernel Panicからの諦めと、別システムからAWSで再構築するまでの格闘劇

先日起こしたトラブルがとても勉強になったので、実際の行動を時系列に並べて、ログとして残そうと思います。

1. 事件は、さくらVPSで運用しているWordPressサイト（マルチサイト対応）のステージング環境で画像がアップロードできなくなったというクライアントからの連絡から始まります。
   調べてみるとすべてのメディアアップロードができない状態だったので、これはHDD容量オーバーかな？と思い、SSHで入ってコマンドを叩いて確認します。

   df

   案の定、ディスクが used 100% になっており、サーバーのスケールアップを決断します。
   　

2. スケールアップ自体はGUIからワンクリックですが、そのあとディスクを拡張しないと使えませんので、以下のURLをもとに拡張手順を進めます。
   https://manual.sakura.ad.jp/vps/server/disk-expansion/centos7.html
   これの「パーティションをソートする」のコマンドを打ったところでトラブルスタートです。
   コマンド実行後、dfコマンドで容量を確認すると、容量のところに異常に高い数値が表示され、使用率も同じくらいの高い数値。。なんだこれ？使用率100%！？
   　
3. 嫌な予感はしつつも再起動 → OSが立ち上がらない → トラブル確定
   ・・・。
   再度再起動してVNCコンソールを立ち上げるとなんと、Kernel Panic発生中。
   またまた再起動かけてすぐにVNCコンソールを立ち上げ、すぐにescapeボタンでカーネル選択画面を開き、一つ下のカーネルを選択して起動をかけるも、状況変わらず・・。
   何度かこの手の手順でできないものかと格闘するも、結局状況は一向に改善せず、渋面でさくらVPSでの再稼働を諦めます。
   　
4. 幸いステージング環境でのトラブルなので（無論、本番環境でこんなことを簡単にはしません）、本番環境をごっそりコピーしてステージング環境を一から作り直す決断をします。
   本番環境はAWS。コピー生成はお手の物ですからね。
   EC2のAMIとRDSのスナップショットを取って、それぞれのインスタンスを複製するだけだから簡単っしょ。

   －－と思っていたんですが、実際はそうでもありませんでした。
   複製したEC2インスタンスにSSH接続ができない！（そこからー！？）
   VPCもセキュリティーグループも元のインスタンスと同じにしてあるのになぜだ！？
   　

5. －－よくよく考えれば、この本番環境ネットワークはロードバランサの配下にEC2インスタンスを置くという構成にしていたんでした－－ステージング環境は別のネットワークにしないといけないので、専用のVPC作りからリスタートです。

   （10分経過）

   さあ今度こそと、そのVPC内に本番環境複製のEC2インスタンスを置いて再度SSH接続を試みるも、またしてもつながらない！！
   　

6. ロードバランサ配下前提のECインスタンスのAMIからの複製だから、直接そのインスタンスにアクセスするには少し設定変更が必要そうだったので、専門外のことをするよりは、と思い、複製で作るのは諦め、本番環境のファイル群を全部手動でダウンロードし、ゼロから立ち上げたEC2インスタンスにて、アップロードの権限関係を調整して、クライアントソフトから粛々と全ファイルをアップロードして、本番環境のRDSのスナップショットから立ち上げた複製RDSとつなげます。

   手順は以前自分がやったこの履歴がありますから難しくありません。
   https://100webdesign.jp/services/web_knowhow/aws-site/

   （ファイル数が膨大につき、転送だけで60分経過）

   そうこうしてようやく環境を作り上げ、HOSTS設定して本番ドメインでアクセスできるところまでは到達。
   ここまでくればゴールは見えた！
   　

7. 最後はデータベース内の本番のURLになっているところを全部ステージングのURLに直せれば完了です。
   ところが、40GBもあるデータベースだったため、
   https://100webdesign.jp/services/wordpress/wp_result/wp_result-279/
   この手順でやっても途中でエラーが出てしまう始末。
   しかたなく、テーブルを少しずつ選択して数十回に分けて置換作業をおこないました。

   （60分経過）

   さあ、ステージングドメインでアクセスしてみましょう。
   ・・・
   開きません。。なぜ？
   原因は簡単で、マルチサイトWordPressなので、ドメインの指定がされており、そこがちゃんと置換されてなかったということで、置換対象のURLを「https://（http://）」を除いた純粋なドメイン部分だけにして、追加の置換作業をおこないます。
   ようやく無事ステージング環境にアクセス成功！
   　

8. 最後にSSLを設定して完了。
   https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/SSL-on-amazon-linux-2.html

　
　
ということでトラブル発生から再構築稼働まで正味丸一日の作業となりましたが、久々の悪戦苦闘で自分自身勉強にもなったので、ここに残しておきます。
同じようなトラブルに見舞われた方の一助にでもなれば幸いです。