VPS on 或る阿呆の記

【GMO】お名前.comデスクトップクラウドで理不尽な資金蒸発がFX戦士を襲う

Sun, 25 Oct 2026 00:00:00 +0900

GMOにやらかされたFX民が同じFX民としてあまりにも可哀想。

2秒で失った400万円 GMO系サービスで「意図しないFX取引」（朝日新聞） - Yahoo!ニュース

わずか2秒ほどの間に400万円超の損失を出していた。その後も2分近く身に覚えのない取引が続き、損害は600万円を超えた。

同じサービスを使っていた愛知県内の女性会社員（29）は22日朝、いつものようにFX取引の状況を確認して「頭が真っ白になった」。

その日の午前5時前から短時間で意図していない大量の取引が繰り返されていた。口座残高は6768円しかなく、430万円余りの資金はほぼ底をついていた。

情報漏洩ってレベルじゃねぇぞ！ さすがにドン引きというか本当に可哀想過ぎる。しかもこの後の展開がゲームみたいになってる。

ただこの事件、金融系のFXとIT系のクラウド・VPSの事情両方をある程度知らないと、詳細がよくわからないニュースでもあります。このサイトに足を運ばれる方はIT民が多いのかと思いますが、私はIT民と同時にFX民でもあるので、軽くFX周りの解説も交えつつ所感を書いていきます。

何が起きた？ってかFXって何？なんでお名前.comが出てくるの？

事件の概要

何が起きたかというと、お名前.comデスクトップクラウドなるサービスが侵入を受けたようです。このサービスは、ITmediaの記事を引用しますと

お名前.com デスクトップクラウドは、FXの自動売買ソフト（「MetaTrader 4」「MetaTrader 5」など）を、自宅のPCを使わずにクラウド上のサーバで24時間動かし続けるためのサービス

— 「お名前.com デスクトップクラウド」不正プログラム設置で全プラン停止 FX用VPS、2万6739サーバに影響か - ITmedia NEWS

というものです。で、このFXの自動売買ソフトをクラウド上のサーバで動かすGMOのサービスがあって、今回それが侵入を受けて、盛大にやらかして冒頭の悲劇が起きた、という感じです。

そもそもFXとは？

うちのサイトの場合VPS云々は何かわかるがFX正味知らんという人が多そうなので、こちらのを少し詳しめに説明します。

ネットでは昔から失敗した人間の断末魔などが面白おかしく取り上げられ、また昨今FX戦士くるみちゃんのアニメ化という狂気もあって、FXはやべーやつの印象かもしれませんが、なんのことはなくて一言で言えば為替取引です。が、レバレッジかけてやるのが特徴ですね。1万ドル単位で売買するのが普通です。

1万ドルって1ドル150円だと150万円ですので、それが1単位って貴族の遊びか？って感じですが、ここに25倍のレバレッジをかけると、6万円で1万ドル売買できたりします。ここでドル円が151円になると、150万円が151万円になるので1万円の儲けになります。6万円が7万円になります。夢がある。そしてもちろん1円下がれば、1万円の損になります。6万円が5万円になります。しにます。さらに5円下がったら？0円です。飛びます。10円下がったら？-4万円ですこんにちは借金。

まぁそれはFX戦士の世界観で、実際はセーフティネットはあるし、そもそもそんな丁半どっちみたいなことをすることはなく、1倍や2倍くらいのゆるーい倍率で長くまったりやっている人もけっこういます。僕もだいたい3-5倍くらいかなぁ。目論見外すと8倍くらいになって焦ることもあるって感じ。まぁコロナショックの時などの急激な変動ではロスカが見えてきて泡吹いていたこともありましたが…知人はあんとき300万くらいロスカされたって言ってたな(；´Д｀)

なんでお名前.comが出てくるのか

さてここまでいくと、完全に金融投資のコンテクストで、なんでVPSだのデスクトップクラウドなんだのが出てくるのかですが、ソフトウェアを使って自動トレードするユーザとそのサービスがターゲットになっているから、ですね。

基本的に取引所経由でやることになるんですけれど、仮想通貨の取引所と違ってAPI環境があることは稀で、自動トレードやろうと思ったら記事に出たMT4/MT5みたいな専用ソフトウェアかつそれに対応した取引所を使う必要があります。

一応専用の環境を用意せずとも、ループイフダンとかトライオートとか、システムトレードができることをウリにした取引所はあるんですが、手数料やスプレッド（実質手数料と思え）が高いし融通のきかないシンプルなロジックしか組めないので、本格的に自動トレードやりたいぞってなるとどうしてもそうなってしまうんですね。

といっても私はMT4/MT5は使っていないので詳細な操作や手数料の体系なんかは知りませんけれど、常駐させて対応取引所と自動トレードし続けるソフトウェア、ということは言えるでしょう。で、そのためのインフラ基盤としてGMOの出しているお名前.comデスクトップクラウドが一つ定番だったのかな。ちょっと業界の定番までは知りませんが、記事にはみんな使っていたから安心だと思った的な感じで書かれてましたね。

まぁ確かに市井のFX民にとって自動トレードは長らくハードル高めだったと思いますので、GMOがそのニーズを拾い上げた感じでしょうか、色々な意味でGMO感あります。

核心：なぜ被害が広がったのか？

で、最初に返りまして、今回やらかしたのはこのGMOの基盤部分、ということになります。ここまでの説明のとおりソフトウェアを置いているだけなので、直接のやりとりはここから複数の取引所それぞれ、となります。もちろん連携が取れているわけではありません。

ここがポイントの一つです。GMOは取引所そのものではなく、取引所に注文をするソフトウェアを置いているサーバをユーザに提供している、というポジションです。

つまり、GMOがやらかしたことなど取引所は知ったことでないので、取引は続行されます。

これを絵にするとこうなります。この絵がこの記事のすべてです。

flowchart TB
U["FX利用者資金・取引口座を保有"]
A["攻撃者"]
subgraph VPS["GMOのサービス領域"]
direction TB
G["GMOVPS・実行環境の提供"]
M["自動売買ソフトMT4 / MT5"]
G -->|"実行環境を提供"| M
end
B["FX業者注文の受付・執行"]
U -.->|"取引設定・認証情報"| M
M -->|"売買注文"| B
B -->|"約定・損益"| U
A -.->|"不正侵入"| VPS
style VPS fill:#E8F1FF,stroke:#477BC0,stroke-width:2px,color:#222
style B fill:#E5F5E8,stroke:#39804A,stroke-width:2px,color:#222
style U fill:#FFF0E6,stroke:#C66B32,color:#222
style A fill:#FFE8E8,stroke:#C44,color:#222
style G fill:#FFFFFF,stroke:#477BC0,color:#222
style M fill:#FFFFFF,stroke:#477BC0,color:#222

ユーザ、GMO、各事業者がそれぞれ疎結合になっているのがシステムとして見た時のポイントになります。

なので、犯人にGMO部分を乗っ取られた場合、取れる手段はユーザ-FX事業者部分の対応になります。GMO自身は直接は何もできないんです。それでGMOはFX事業者に注文通すラインそのものを切断してくれという連絡をしているわけです。

……応急措置ですが。乗っられた時点で厳しい。犯人が既にセッション確立している場合、ユーザアクションのログオフで全セッション切断できるのかも事業者次第だろうし。まぁ実際、その後も破壊活動が止まってないようですし。

とはいえやるべきことであるのは確かです。GMOのやるべきことは全顧客にあらゆる手段でユーザに直接連絡して対応をお願いすることだと思いますけどね。実際はその真逆ですが。実は21日水曜日の第一報の時点ではGMOの報告内容は比較的穏やかで、「不正侵入受けた！ユーザは情報閲覧とかあるかも！」くらいの感じだったんですわ。で、このニュースを見たのも21日なんですが、僕はちょっと違和感あったんですね。そんときのツイートがこれ。

https://x.com/tamasan774/status/2112848040856072501?s=20

GMOのクラウド基盤がやられたの…？どこまでやられたんだろう。本当に情報閲覧程度なんか。プログラム設置されたなら少なくともそこはWriteと実行権限とられてるよな。。いろんな意味でやられたらダメだろのサービス内容と事業者ではある

これは元記事見ると不正にプログラムを設置されたとあったので、そこまでされているのに本当に情報閲覧されたかもなんて程度なんだろうか？と違和感があったんです。結果的にフラグだったわけですが……しかしまさか本当にここまで盛大にやらかしているとはこの時は思いませんでした。

だってそうなら言うべきでしょう。確かにすべてを言えない事情はあるかもしれないけれど、事態の深刻さは伝えられたはずで、そうしていえれば、この時点で直ちに取引所に連絡してすべての注文を止めるとか、そういうことは出来た可能性もあるとのではないでしょうか。なにしろ大金がかかっている。みんな必死だよ。

まぁもちろんそのときにはそこまでのことがわからなったといえるかもしれないんですが、現場のエンジニアがそんな悠長なこと考えていたとも思えないんですよねぇ…。最悪のケースは現場レベルでは共有されてたんじゃないのかなぁ。第三者の僕が、このニュース一つで「ほんとにその程度？」って引っかかってるくらいですし。謎のプログラム見つけた時点で、青ざめたんじゃねぇのかな…それともこの会社で働くヒトはそんなタマじゃないかしら。

それで実は激ヤバでしたってゲロった第2報が既に色々あったあとの木曜日16時59分（【重要】「お名前.com デスクトップクラウド」への不正アクセスに関するお詫びとお知らせ（第2報） | GMOインターネットグループ株式会社）、ここで各事業者単位でのログオフ（セッション切断）が対応としてあるんですけど、まぁそれはそうなんですが、どこまで伝わったのか。記事の人なんかはそもそもこの時点で時既に遅しですし。第3報「【重要】「お名前.com デスクトップクラウド」への不正アクセスに関するお詫びとお知らせ（第3報） | GMOインターネットグループ株式会社」はその対応をより強く書いたのがほとんどですね。この時金曜日16時10分。FXって平日しかやってないんだよ(^_^;)

FX訴訟戦士爆誕待ったなし？

まぁ真相はこれから訴訟沙汰になった時にわかることかもしれません。いや、本当になりそうな気配が。被害金額がもう泣き寝入りできる金額じゃない。

かなり醜悪なんですが、攻撃者はわざとユーザの口座を破壊しているっぽいんですね。具体的にはフルレバでガンガン注文入れて資産を蒸発させていたようです。ひでぇ…相対取引のFXの仕組み上、そんなことしてもブローカーが儲かるだけで攻撃者の得にはならないはず。

じゃあなんでそんなことを？というと、どうも脅迫が目的っぽい。

https://x.com/yutoriineet/status/2113264833307267254?s=20

今出回ってる脅迫文マジです私の破綻させられた口座の番号、被害額一致しました

本当？となるわけですが、第三報には攻撃者から連絡があっても返事するなという旨が書かれていることなどみると、どうもマジっぽい。しかもこの文章えげつないですよ。まぁちょっと意訳しますけど、

犯罪者「あなた達は悪くありません。しかしGMOが交渉に応じないので口座破壊しました。GMOを訴訟すればきっと全額戻ってきます。私たちが支援します！」

サイコパスか？

つまり口座を破壊されて泣き寝入りできなくなったユーザを、GMOを攻撃するためのファンネルに仕立て上げようとしているんでしょう。人の心とかないんか？

しかしもしGMOが今回のユーザの被害についてなんら補償を示さなかった場合、ユーザは自分の金を取り戻すには、自分の財布を燃やした犯人の支援を受けて、利用されているとわかりながらGMOを訴えるしかない。地獄か？

なかなか絶望的です。IT系じゃないとGMOのイメージはなさそうですが、決して評判の良い会社とは言えません。一般ユーザにとってもお名前.comのダークパターンは有名ですし、色々あったのか、ツイートを見ていると「このまま倒産してしまえ」という類のものが散見されました。第三報を見ても、具体的なことは何もわからないが、とりあえず法務を通しているということだけビンビンに伝わってくる、自己保身しか感じないものでした。GMOェ…

顧客の口座を燃やし尽くし、裁判では我々はサイトで連絡した、何もしなかった顧客が悪いで通す気なんだろうか…いやまさかさすがに通らんだろう…。

どうにかならないんですか

とにかく現状ユーザがあまりにも可哀想過ぎるのですが、本当にどうにかならんのですか。

悪いのは犯罪者だ理論はそれはそうなんですが、それでユーザのお金は戻ってきません。テロリストに屈するな！というのも正論ですが、テロリストが人質にしてるのはGMOの金じゃなくてユーザの金です。攻撃者vs企業において企業は被害者ですが、企業vsユーザにおいては守るべきものを守れなかったものと被害者です。

また企業の対応を見ると、本当にそこに過失がなかったのか…なんならいわゆる重過失がなかったのかも、けっこう疑問があります。

SNSでは「GMOは規約でガチガチに固めてる。さすが」みたいなのもありましたが、AIに法的な有効性を考えさせてみると「BtoCで全部免責は消費者契約法第8条第1項第1号により無効やから、訴訟になったら使えんと思うわ。諦めさせるためのポーズちゃう？」とのこと。また「一部免責でも重過失が認められた無効やな。法人の場合もそれはそう。重過失が認められるかが焦点になると思うわ」とのことなので、まぁ係争の余地はありそうです。

まぁGMOがしっかりしていればいいんですが…このままだと合理的には自分の金を取り戻すには自分の口座を破壊した犯人の支援を受けるハメに…。支援は恐らく証拠ログみたいなもんと思われ、犯人の証拠が使えるのか？という疑問がありますがが、これまたAIに聞いてみたところそこは使える可能性が高いで、とのこと。AI便利。さっきの図もAIに書かせた。AIは使い方次第……。

VPSはもはや危険？

思い出したのは同じくGMO系列であるConoHa VPSで半年前にあった大規模障害です。あれもユーザ間では荒れました。あれば別にサイバー攻撃ではなく、単に設計・運用のまずさだったんじゃないかと思いますが…。

しかしこういうことが立て続けに起きていると、既にVPSレベルだとセキュリティの観点でオンプレと逆転現象が起きているのかもしれないと思います。さすがにメガクラウドにまでなれば話もまた変わりますが…いずれにせよ記事の主旨とだいぶ変わってくるので別の記事でまた取り上げるかもですけどね。

ただまぁ、結果論ですが、ユーザは取る必要のないリスクを取っていた、とは言えてしまう。でもVPS・クラウドを使いましょう、はこれまでむしろスマートとされたやり方でした。ユーザは勉強熱心な層だったんじゃないでしょうか…それに自動トレードユーザは基本的に資金管理をしっかりしながら地道に稼くことを目指す堅実な人が多いんじゃないでしょうか。多分。自動トレードって基本的には中長期目線になるので。それだけにやるせないんですが…。

やっぱり、この10-15年くらいの常識が通用しなくなり始めている、大きな転換点にいるのかもしれません。

<関連記事>

あわせて読みたい

AIによるサイバー攻撃時代の個人サイト・個人ブログのセキュリティ

セルフホストしたアプリをマシン移行する汎用的な仕組みについて考える

Mon, 31 Aug 2026 00:00:00 +0900

現在VPS上で、仮想通貨の自作トレードアプリを稼働しています。これは元々自宅サーバでやっていたのですけれど、引越しのときに数日から下手すると10日以上のダウンが見込まれたので、その間に相場の急変があったらたまらないということで、VPSに移行しました。

アプリケーションを動作させるマシンを移行したい

で、ようやく環境も落ち着いてきたので、いつまでもグローバル空間に置く必要はないし、自宅サーバに戻そうと考えています。もちろん手順を踏めばすぐできるんですけれど、ここで、少し汎用的に考えられないか、と思いました。セルフホスト勢にとってマシン移行は常に生じる汎用的な悩みです。

実際、このサイトはWordPressをセルフホストしているのですが、VPS,ConoHaの大規模障害（永遠にこする）や引越し前後において頻繁に引越しをしています。それはやはり面倒くささがあったわけです。

個人的には、マシンの移行はもっと気軽にやりたい、という思いがあります。それはもしもの役にも立つでしょう。何をやるべきで、何をやらないのか、自動化できる部分はなにか、自動しない部分はなにか、そういうことを汎用的に考えたい、と思いました。

中継地点を介した移行

考えたところ、基本的には以下のような中継地点を挟むものになると思います。

graph LR
mA(移行元)
mB(移行先)
st(中継地点)
repo(リポジトリ)
mA -->|push| st
st -.->|pull| mB
repo -.->|pull| mB

この絵がすべてです。

なんでダイレクトに送らないのかと言うと、移行元から移行先にダイレクトにpushできる権限があるとは限らない、からです。これは完全に自宅サーバしか使わない！というならダイレクトでいいかもしれませんが、実際には自宅が使えなくなることはあります（今回の場合）し、アプリケーションによっては自宅サーバはやめたほうがよいものもあります。

なので、移行元からpushできて、移行先がpullできる、そういう中継地点を用意するのが汎用的です。この中継地点の役割は、アクセス制御と一時的なストレージ、ただそれだけです。グローバルなアクセスが必要ならS3のようなクラウドサービスでもいいですし、VPSでもいいでしょう。移行元も移行先も同一ネットワークなら、わざわざ外に出す必要はなく、両者がSSHで通信できるサーバならなんでもいい。

具体的な作業自体は、アプリケーションごとに個別で判断します。この切り分けによって、搬出と搬入のタイミングをずらせるとか、データの整理が明確になるといった副次的な効能もあります。

ここで重要なことは、何を引越して何を引っ越さないのかを明確に切り分けることです。具体的には、以下の3つに分かれると思います。

リポジトリから引き継ぐ
- ソースコードや設定ファイルのテンプレートなど
ファイルの移行で引き継ぐ
- エクスポートしたファイルやデータストアやアプリケーションログなど
引き継がない
- OS/インフラの差分に基づく設定ファイルなど

それぞれ何が対象となるかはアプリケーションごとに変わるでしょう。すべてのパターンを考えて統一的にやろうとしないことです。また、引き継げない部分がある以上全自動の夢も捨てるのが筋です。変に自動的に翻訳するみたいなことするのはトラブルの元です。セルフホストでそこまでする必要があることは皆無ですし、もしやる場合は差分が出なくなるように環境から選定すべきでしょうね。

そのうえで手順は以下のように言えるでしょう。

移行元と移行先で、リポジトリから引き継ぐものをアップデート
移行元をstopして、中継地点に搬出
移行先に、中継地点から搬入
データのインポート、差分の編集
移行先で動作開始

自前で開発したものか、あるいは他人が開発したものを使わせてもらっているか、色々あると思いますが、この手順に集約できるかと思われます。

この方法は基本的にダウンタイムが生じます。工夫次第で発生させないのも可能かと思いますが、セルフホストでそこまで頑張る意味は薄いんじゃないでしょうか。

とはいえダウンタイムは短いほうがよいので、短くするなら差分の編集は搬出前にやると良いのですけれど、個人的には搬入後に揃ってからのほうがいいかと思います。搬入のどさくさで差分が上書きされるリスクや、また何かしら動かさないと編集できないとかもありえるので…。

データのインポートはファイルシステムレベルなのか、アプリケーションレベルで実行したほうがいいのか、これもアプリケーションによるでしょうねぇ…。まぁ、都度判断ですね。

まとめ

ここまでの流れをやや詳細に図示すると以下になります。

flowchart TB
subgraph Repo["コード管理"]
Code["ソースコード / 設定テンプレート"]
end
subgraph Relay["中継地点"]
ExportData["エクスポートデータ / DBダンプ / アプリログ"]
end
subgraph Source["移行元"]
SrcApp["アプリ停止"]
SrcData["データ抽出・ダンプ"]
SrcEnv["【破棄】OS・インフラ固有設定"]
end
subgraph Target["移行先（自宅サーバなど）"]
TgtEnv["【新規作成】OS・インフラ固有設定の編集"]
TgtApp["アプリ起動・動作検証"]
TgtData["データインポート"]
end
%% コードの流れ
Code -->|Pull| Source
Code -->|Pull| Target
%% データと状態の流れ
SrcApp --> SrcData
SrcData -->|Push / アップロード| Relay
Relay -->|Pull / ダウンロード| TgtData
TgtData --> TgtEnv
TgtEnv --> TgtApp
%% スタイル
classDef storage fill:#e1f5fe,stroke:#0288d1,stroke-width:2px;
classDef nodeBox fill:#f5f5f5,stroke:#616161,stroke-width:1px;
class Repo,Relay storage;
class Source,Target nodeBox;

やることは、事前準備として「リポジトリからpullするもの、中継地点で飛ばすもの、直接編集するもの」の切り分け。そのうえで5つの手順の具体的な操作の当てはめ。

整理してみると、当たり前といえば当たり前なんですが。あらかじめ分類したものを適合させるだけだと思ったほうが、脳の負荷が多少下がるので…。

とりあえず、トレードアプリから移行するかー。手順を抽象化したところで具体化するのは結局めんどくさいのであった。というより、そういう面倒くささを残したところが肝なのですが…。

<関連記事>

あわせて読みたい

セルフホストしたWebアプリになぜかうまくアクセスできない時のチェック

/selfhost-webapps-down/

あわせて読みたい

セルフホストのすゝめ

/selfhosted-susume/

ConoHaのVPSまた落ちたか

Tue, 30 Jun 2026 01:20:58 +0900

つい先日の6/26にConoHaから障害メールがきていた。僕は障害を確認していないのだが、どうやら3月の大規模障害でさんざっぱら叩かれたのを反省したらしい。

6/25 23:16に発生とあるにも関わらず、最初の障害報が6/26 3:00であるし、復旧報も自分のサーバが対象かどうかを自分で調べさせるというストロングスタイルではあるものの、メールを送るようになっただけマシになった。

しかしそうはいっても、障害起きすぎじゃないの、とはやはり思う。今現在、家にネット回線がきていないネット難民化しているため、このブログを含めた常時稼働のアプリケーションをConoHa VPSにうつしているため、不安になる。頼む、僕が使っている間だけは落ちてくれるな…。

落ちた☺️

朝アクセスしようとしたその瞬間にまさに落ちたと思うわ。マジかよと思ったけど、だいたい15分くらいで復旧したかな。復旧したと信じたい。

朝でかつ比較的短い時間ではあったものの、X見ると僕以外にも何人かまた落ちてる？とツイしていたので、多分障害だったのだろう。というか僕のXアカウント、ConoHa VPSの死活監視botになってるわ。落ちるたびにSNSで騒いでるうえ、スクショあげたり記事にしたりまでしているので、ConoHaの中の人にマークされている気もする。とりあえずその後メールはきてないので、ConoHa的にはこれは障害ではなさそう。

まぁこういう感じなので、ConoHaはもう全然おすすめできるVPSではなくなってしまったね。昔はこんなに不安定じゃなかったんだけどね。。。

あわせて読みたい

ConoHa VPS落ちすぎ問題

/conoha-vps-down/

WordPress(Docker)をコンテナとボリュームごと別マシンに移行するスクリプト

Sun, 14 Jun 2026 15:37:33 +0900

以下の記事の自動化スクリプト。

あわせて読みたい

コンテナ構築のWordPressサイトを別マシンに移行する

/container-wp/

やることとやらないこと

やること
- 移行元からボリュームをバックアップして、移行先で復元する
やらないこと
- 移行後のルーティング

スクリプトでやっていることについて図示する。バックアップ中はダウンタイムとなるので注意。

flowchart TD
subgraph Local["ローカルマシン (移行元)"]
direction TB
A[YAMLからボリューム一覧を取得] --> B[移行対象のボリュームを選択]
B --> C[元マシンのコンテナ停止]
C --> D[選択ボリュームのバックアップvackup export]
D --> E[元マシンのコンテナ再開ダウンタイム短縮]
E --> F[設定ファイル一式とバックアップを転送rsync]
end
subgraph Remote["リモートマシン (移行先) SSH経由で自動実行"]
direction TB
G[作業ディレクトリに移動]
H[ボリュームのリストアvackup import]
I[ネスト構造の解消vackup-volumeを直下へ移動]
J[移行先コンテナ起動docker compose up -d]
K[リモートの一時バックアップ削除]
end
F -->|ネットワーク転送| G
G --> H
H -.各ボリュームごとにループ.-> I
I --> J
J --> K
subgraph Local_Cleanup["ローカルマシン (完了後)"]
L[ローカルの一時バックアップ削除]
end
K -->|処理完了| L

準備

移行元から移行先に、sshで転送できるようにしておく。
- 移行元はLAN内のマシンで、移行先はVPSとする。
移行元と移行先にdockerとdocker composeとvackupを入れる。

vackupについては以下。

あわせて読みたい

DockerのボリュームをCLIでバックアップ・復元する

/docker-volume-cli-backup/

また、移行元のディレクトリ構成を以下のようにする。

.
├── site1
│   ├── custom-php.ini
│   └── docker-compose.yml
├── site2
│   ├── ads.txt
│   ├── custom-php.ini
│   └── docker-compose.yml
└── migrate-wp.sh

上記のディレクトリ構成で、migrate-wp.shを実行すると、転送先のマシンにコンテナの設定とボリュームごともってく。ディレクトリごともっていくので、見えていないが.envも含む。

スクリプトと実行

スクリプトは以下。AIが書いた。

#!/bin/bash

# エラー発生時にスクリプトを終了
set -e

# 引数のチェック
if [ "$#" -ne 3 ]; then
 echo "Usage: $0 <dir_name> <user@ip> <remote_base_path>"
 echo "Example: $0 site1 user@192.168.1.50 /home/user/wordpress"
 exit 1
fi

DIR_NAME=$1
REMOTE_TARGET=$2
REMOTE_BASE_PATH=$3

LOCAL_DIR="./$DIR_NAME"
REMOTE_DIR="$REMOTE_BASE_PATH/$DIR_NAME"

# ローカルディレクトリの存在確認
if [ ! -d "$LOCAL_DIR" ]; then
 echo "Error: Local directory '$LOCAL_DIR' does not exist."
 exit 1
fi

echo "=== 1. ボリューム名の取得 ==="
cd "$LOCAL_DIR"

# docker compose config を使ってボリューム名一覧を取得
VOLUMES=$(docker compose config --volumes)

if [ -z "$VOLUMES" ]; then
 echo "Error: No volumes found in docker compose config for $DIR_NAME."
 exit 1
fi

echo "対象ボリューム:"
echo "$VOLUMES"

echo "=== 2. 元マシンのコンテナ停止 ==="
docker compose stop

echo "=== 3. ボリュームのバックアップ (vackup) ==="
mkdir -p volume-backups
for vol in $VOLUMES; do
 echo "Exporting volume: $vol"
 vackup export "$vol" "volume-backups/$vol.tar.gz"
done

echo "=== 4. 元マシンのコンテナ再開 (ダウンタイム短縮) ==="
docker compose up -d

echo "=== 5. 移行先へのファイル転送 (設定ファイル一式 + バックアップ) ==="
cd ..

# 移行先にターゲットディレクトリを作成
ssh -o ServerAliveInterval=60 "${REMOTE_TARGET}" "mkdir -p ${REMOTE_DIR}"

# フォルダごとリモートへ同期
rsync -avz --progress -e "ssh -o ServerAliveInterval=60 -o ServerAliveCountMax=10" \
 "$DIR_NAME/" "${REMOTE_TARGET}:${REMOTE_DIR}/"

echo "=== 6. 移行先でのボリュームリストアと起動 ==="

# 変数内の改行をスペースに変換する
VOLUMES_ONELINE=$(echo "${VOLUMES}" | tr '\n' ' ')

REMOTE_SCRIPT=$(cat << EOF
cd "${REMOTE_DIR}"

for vol in ${VOLUMES_ONELINE}; do
 echo "----------------------------------------"
 echo "Processing volume on remote: \$vol"
 
 # リストアを実行
 vackup import "volume-backups/\$vol.tar.gz" "\$vol"
 
 # vackup-volume のネスト構造を修正
 echo "Fixing nested directory structure for \$vol..."
 docker run --rm -v "\$vol":/volume alpine sh -c "
 if [ -d /volume/vackup-volume ]; then
 mv /volume/vackup-volume/* /volume/ 2>/dev/null || true
 mv /volume/vackup-volume/.[!.]* /volume/ 2>/dev/null || true
 rmdir /volume/vackup-volume 2>/dev/null || true
 fi
 "
done

echo "----------------------------------------"
echo "Starting containers on remote host..."
docker compose up -d
EOF
)

# 移行先マシンでリストア処理を実行
ssh -o ServerAliveInterval=60 "${REMOTE_TARGET}" "${REMOTE_SCRIPT}"

echo "=== 7. ローカルの一時バックアップを削除 ==="
rm -rf "$DIR_NAME/volume-backups"

echo "=== 移行プロセスが完了しました ==="

使い方は以下。

./migrate-wp.sh site1 VPSのユーザ@VPSのIPアドレス /home/VPSのユーザ/wordpress

これを実行すると、移行先に~/wordpress/site1ができる。すでにコンテナの実行までされている。

なので、あとはDNSなどを操作して移行元から移行先に向けるとか、ルーティングで必要なことをやれば移行完了。

以上。