序文#
先週金曜日、私が Vultr プラットフォームで購入した 2C2G サーバーが突然カーネルエラーを起こし、SSH 接続も再起動もできなくなりました。さまざまな救出策を試した後、1000 枚以上の画像を救出することができましたが、非常に心配でした。救出プロセスを記録し、新しい画像ホスティングソリューションを試してみました。
サーバーの救出#
このサーバーは約 1 年半安定して稼働しており、多くの重要なサービスと、Docker ボリュームを介してホスト上に永続化されたバックアップのない 1000 枚以上のブログ画像があります。
サーバーダウン#
実際には、何が問題だったのかまだわかりません。朝、実行している RSSHub インスタンスのイメージバージョンを更新する必要があったため、すべてのサービスを最新のものに更新しようと考えました。docker pullとdocker-composeの操作を行いましたが、最初の方は問題ありませんでした。しかし、最後のサービスを起動しようとしたときに突然コンテナの起動に失敗し、「not enough space」というエラーが発生しました。ダウンロードしたイメージが多すぎてディスクがいっぱいになった可能性があると思い、docker image prune --all、docker volume prune、docker system pruneなどの操作を行い、約 10G のスペースを解放しましたが、問題は解決しませんでした。
開発者として、わずかなサーバー管理経験しかない私は最初に再起動することを考えましたが、それが一日の悪夢の始まりであるとは思いもしませんでした。
再起動後、Uptime Kuma がすべてのサービスがオフラインになったことを通知し、SSH でマシンに接続できなくなりました。
急いで Vultr のオンラインコンソールにログインしましたが、カーネルエラーが発生しており、起動できませんでした。強制的に再起動しても効果がありませんでした。そのため、チケットを提出し、DevOps の友人たちに助けを求めました。
データの救出#
STRRL によると、おそらくrootfsに問題が発生しているとのことですが、このような小さなクラウドプロバイダーには高度な起動などの追加機能が提供されていないため、公式の技術サポートの対応を待つしかありません。しかし、私は 1 年半もの間、バックアップのない画像ホスティングデータがあることを心配していました。そのため、データを救出する方法を考え始めました。
Vultr のコントロールパネルを調べてみると、約 1 週間ごとにバックアップが作成され、バックアップをスナップショットに変換することができることがわかりました。最新のバックアップは 6 月 22 日に作成されました。最初に思いついたのは、スナップショットを直接復元することです。もし今日の操作が何らかの設定の問題を引き起こした場合、1 週間前のスナップショットは正常に起動できるはずです。そのため、スナップショットの復元を待つことにしましたが、結果は同じエラーが発生しました。諦めずに、6 月 15 日のバックアップも復元してみましたが、やはりダメでした。
これで事態の深刻さに気づき、データがすべて失われる可能性も考え始めましたが、チケットの回答を待ちながら同様の状況を調査し始めました。最終的に、Vultr のマシンのスナップショットイメージをダウンロードできることに気づき、「搬瓦工备份快照镜像文件 .tar.gz 下载解压后打开 .disk 文件查看数据教程」という記事を見つけました。
まず、スナップショットイメージをダウンロードし、.diskファイルを取得しました。このファイルは専用の形式であり、教程によれば、Virtual Box のコマンドラインツールvboxmanage convertfromrawを使用して形式を変換できますが、公式ウェブサイトでダウンロードしたところ、Mac の M チップはサポートされていないことがわかりました。そのため、以前の古い 19 インチの Intel Mac にインストールして変換を実行し、.vmdkファイルを取得しました。
変換が完了したら、この.vmdkファイルを Virtual Box の CentOS 仮想マシンにディスクとしてマウントしましたが、同じエラーが発生しました。
そこで、一味違う方法を試しました。7-Zipソフトウェアは、一般的な仮想マシンの形式を解凍することができますが、クライアントは Windows 版しかありません。
理論的には、macOS でコマンドラインバージョンのp7zipを使用して実行することもできますが、私は解凍中にエラーが発生するため、この方法は使えませんでした。そこで、Windows 11 を仮想マシンでダウンロードし、7-Zip ソフトウェアをダウンロードして解凍に成功しました。
問題が発生しました。取得したのは1.img、2.imgという形式の Linux ディスクイメージファイルであり、macOS ではロードできませんでした。会社の運用チームの友人に尋ねたところ、fuse を試してみましたが、ロードできませんでした。
その間、良いニュースもありました。ウェブ全体を検索していると、データ復旧ソフトウェアの UFS Explorer を見つけました。試してみると正常にロードできましたが、768k を超えるファイルには有料のライセンスが必要でした。もちろん、ライセンスを購入するつもりはありませんでしたが、ファイルが読み取れることを確認できたので、少なくともデータは残っているという安心感がありました。あとは技術的な問題だけです。
その間、Vultr のチケットも回答され、再起動または再インストールを試してみるようにとのことでした...🤣
チケットのやり取りを諦め、引き続きimgのデータを救出しました。頼りになる STRRL は、OrbStack を使用して Linux マシンを起動し、このimgを Linux ディスクとしてマウントできると教えてくれました。
sudo losetup -fP 1.img
mkdir /mnt/bwg
sudo mount /dev/loop0 /mnt/bwg
上記のコマンドを使用して、imgディスクイメージを OrbStack の Ubuntu マシンにマウントしました。
コマンドラインの出力結果に画像が表示されたとき、感動して涙が出そうになりました 😭。
tar -czvf cheverto_chevereto_images.tar.gz cheverto_chevereto_images/
rsync -acvP ./cheverto_chevereto_images.tar.gz pseudoyu@[yu-mac-studio]:~/Downloads/
すぐにtarアーカイブを作成し、rsyncを使用してローカルの Mac に転送しました。ローカルで解凍すると、すべての画像が表示されました。
画像ホスティングシステムを r2 に移行#
しかし、今回の経験から、サーバー単体での画像ホスティングの信頼性に疑問を抱くようになりました。半日かけて新しい無料の画像ホスティングシステムを構築しました。「从零开始搭建你的免费图床系统 （Cloudflare R2 + WebP Cloud + PicGo）」。
既存のデータをr2に移行するために、rcloneを使用しました。移行作業は完了し、大成功です！
まとめ#
サービスのデプロイやデータのセキュリティなど、再考する必要がありました。重要なデータをクラウドにアップロードし、単一のマシンに依存しないようにする準備をし、fly.ioやZeaburなどのサーバーレスプラットフォームにいくつかのサービスを移行し続ける予定です。