【諦めないで】WordPressのデータベースを吹っ飛ばしてしまったが、エックスサーバーの機能で一瞬で復旧した話

中の人
中の人

どうも、先日誤ってWordPressのデータをまるまる消してしまったのですが、エックスサーバーの機能により、事なきを得た事があったので記事にしました

記事作成日:2026年2月26日

 

先日ブログの記事を移行する中で操作を誤ってしまい、
6年続けてきたブログのデータを全削除してしまい、
バックアップも2週間前のものしか手元に無くて青い顔をしていたのですが、
無事復旧できたという記事にしました。

スポンサーリンク

ことの発端

ChatGPTとGeminiが同じ事を言ってて油断してしまった

数年間続けていたWordPressのブログ記事を、
別のサイトに一部移行して居た時の話です。
あまりにもその記事だけアクセス数が多いので、
URLをそのままに移行したいと思っていました。

そのURLというのが「.com/?p=1298」といったID付きのURLです。

つまり、移行先にも全く同じpost IDを保ったままその記事だけ移行できるかという話。
移行先には該当IDが存在しないために可能で、簡単な作業だと考えていました。
が、ChatGPTに聞いてもGeminiに聞いても、
これは思いのほか難しいという話で。

sshを使ってデータベースからダンプし、新WP側にimportする必要があるという話。

[移行元WPで]
mysqldump (無闇に実行しちゃダメな例なので伏せます)

[移行先WPで]
wp db import ~/dump_1298.sql
wp db import ~/dumpmeta_1298.sql
または
mysql -u [ユーザー名] -p [新DB名] < ~/dump_1298.sql
mysql -u [ユーザー名] -p [新DB名] < ~/dumpmeta_1298.sql

チャッピーとGeminiどちらもほぼほぼ同一の処理を示唆してくれたので、
何も疑わずに実行。

 

すると、データベース破壊

言われたとおりにやっただけなのですが、
WordPress上で見ると・・・・
その記事以外の投稿がすべて無くなっている!!!

急いでChatGPTに確認。

今回「全投稿が1件になった」のは、こちらが指示した import 手順が原因で起き得る事故です。申し訳ありません。

起きたことはほぼ確定で、
mysqldump の出力には通常 DROP TABLE / CREATE TABLE が含まれます

それを 新WP側で wp db import すると、posts テーブル等が作り直され(=中身が消え)、ダンプに入っていた行(今回なら 1298 など)だけが残る

という流れです。

申し訳ありませんで済まないですよこれは。
そして「データベースをバックアップする」という簡単で確実な作業を怠った自分に大後悔。
AI相手にも怒り。

チャッピーにボロクソ言いたくなりましたが、
怒ったら余計に阿呆になってしまうのを知っているので、
ここはグッとこらえて復旧作業をなんとか試みます。

 

復旧できるか?

チャッピーに聞いても

ここからは、被害をこれ以上広げず、復旧に全振りします。

とか言ってますが、
これ以上広がらないぐらい既に大被害。
チャッピーやGeminiと共に復旧作業に入ります。

幸か不幸かUpdraftsPlusのプラグインを導入したときの手動バックアップが手元に残っていました。
しかし設定をうまく出来ておらず、それより新しいものは残っていませんでいた。
直近2週間の、いくつかの記事が消え去りました。

次に、この記事をGoogleキャッシュかなにかから復元出来ないか考えたのです。

 

復旧!

Claudeが教えてくれた

そういえばClaude Codeを使うために、Claudeにも課金していたのです。
試しにClaudeにも投げかけてみることに。

私の中では、先述のような復旧を途中まで行っていたので、
要点だけの指示を投げかけました。

間違ってブログのデータをふっとばしてしまって2週間前からの新しい記事が消えてしまった
Googleキャッシュからコピペで復元できないか考えてくれませんか

Claudeから帰ってきた言葉はこちらです。

まず厳しい現実から:Googleキャッシュは2023年以降に廃止されており、現在はほぼ機能しません。代替手段を含めて優先順位順に整理します。

復元手段(優先順位順)
① サーバーのバックアップ(最優先・今すぐ確認)
# ホスティング会社のバックアップを確認
# さくら、Xserver、ConoHaなどは自動バックアップがある場合が多い

**Xserverなら「バックアップ」→「MySQLバックアップ」で14日分取得可能な場合あり。**
ホスティング会社のコントロールパネルを今すぐ確認してください。

幸いにも、私はエックスサーバーを使っていましたのですぐに確認。

 

エックスサーバーは標準で14日間自動保存している

なんとデフォルトですべてのMySQLのデータを14日間自動保存している!!

わずか数分で復旧、
6年分の記事が元通り・・・
当日はブログ更新していなかったため、これは全データと等価。

感動!
使っててよかったエックスサーバー。

 

AIのおせっかい機能が功を奏したのか?

ということで、
無事エックスサーバーには14日間の自動保存データがあり、
一瞬で前日の状態に戻すことができたという話です。
「Googleキャッシュから復元できないか?」と相談を持ちかけたにも関わらず、
代替手段としてこれを教えてくれたのはClaude。

実はChatGPTとGeminiには、ハルシネーションを防ぐためや、
逐一質問してくるのを抑えるために、「パーソナライズ設定」をしまくっていました。
それにより、もしかすると視野が狭くなっていたかも知れないです。

Claudeにはほとんどパーソナライズ設定をやっておらず、
今回は「おせっかい機能」が功を奏したのかも知れないです。

 

なにが間違っていたか

sqlファイルに破壊的コマンドが含まれていましたが、
–no-create-infoを付ければよかったという話。

mysqldump -u [ユーザー名] -p [DB名] wp_posts —where=“ID=1298” –no-create-info > post_1298.sql

こちらに変更して無事移行できました。
冷静に考えると、すごく基本的なミスですね。
とはいえmysqldumpの仕様を知らないとこんなん気づきようがありません。
AIですら見落としていました。
AI頼りで注意を怠ると、こういう罠とも戦っていかないといけないですね

 

さいごに

教訓:データベースをいじる時は、AIが言ってても必ずバックアップを取れ!!!

じゃないと今回みたいな時に青い顔になります。
スパイvsスパイで時限爆弾しかけられた時みたいな青い顔になります。

ちなみに、全削除して青い顔してから復旧まではわずか20分間ぐらいの話。
でも体感は数時間ぐらい青ざめてたんですよね。
まあ、よかったよかった かなあ。

今回はエックスサーバーがデフォルトで神機能を持っていた&Claudeが賢かったから本当に助かりましたが、AIを信用しすぎないように、
気を付けましょう!!

それではまたー

 

タイトルとURLをコピーしました