WordPressバックアップからの復元方法：ConoHa Wing

WordPressのデータが飛んだ！
バックアップから復元したい
プラグイン入れてなかった。。。

ConoHa WINGには自動バックアップがあります。ただし、戻せる日付や対象を確認し、今の状態も保存してから作業することが大切です。

この記事ではその方法を画像付きで初心者にも分かり易く解説します。

ConoHa Wing：バックアップからの復元方法

プラグインを用いてバックアップを取っている方も多いと思いますが、ConoHa Wingでは14日間分は自動でバックアップを作成してくれています。

バックアップの復元手順概要

バックアップデータは『レストア』することで使用出来るようになります。

『レストア』という作業自体は復元行為ではありません。

確かに復元はしますが、その復元したデータを使うという設定を手動で行わない限りは、実質的に復元されません。

始める前にイメージを持っておくと操作に迷わなくなると思います。

こんなイメージです。

それでは早速方法を見ていきましょう。

2021年11月時点で実際にバックアップからの復元操作を行ってみましたのでその際のスクリーンショットで説明します。

ConoHa Wingのアップデートなどで操作が変わる可能性もあります。

また操作は自己責任でお願いします。

バックアップ復元手順

まず、ConoHa Wingにログインしたら、WINGタブにある『サーバー管理』から『自動バックアップ』を確認します。

ここに14日分のバックアップが保存されています。

記事本文は主にデータベースに、アップロード画像やテーマ等はファイルに保存されます。何が失われたかで、必要な復元対象は変わります。

一つの記事の編集ミスなら、先にWordPressのリビジョンで戻せるかを確認します。サイト全体のDBを戻すと、その後に追加された他の記事や設定まで戻るためです。

『リストア可』の部分をクリックして、続けて『リストア』をクリックします。

ConoHaのバックアップでは、まず復旧用データを用意する工程と、実際の公開サイトへ反映する工程を分けて考えます。画面の操作が何を置き換えるかを確認してから進めてください。

続いて、リストアしたDBを見てみましょう。

『サイト管理』から『データベース』に進むと、同じ名前のDBが二つになっていると思います。

DBをクリックすると『ネームタグ』、『データベース名』などを閲覧出来ます。

復元したデータベースは、復元日時と実際のデータベース名で識別します。ネームタグは見分けやすくする表示名であり、接続名とは区別してください。

以下の画像の通り鉛筆マークをクリックすると編集出来ます。ここでは『_211120』を追記してみました。

ネームタグを変えるだけでは、WordPressの接続先は変わりません。接続設定の変更は、復元先の内容を確認してから行います。

進めていきましょう。

この先はもし操作を誤るとパニクって自分で元に戻せなくなる可能性がゼロでは無いので、心配な場合はスクリーンショットや画面の写真を撮っておくと問い合わせ時に助かります。

上の画像と同じく『サイト管理』から『ファイルマネージャー』をクリックします。

自動的に新しいタブで開きます。

下の画像のように復元したいドメイン名の中にある『wp-config.php』を右クリックして『ファイル編集』から『ACE Editor』を選択しましょう。

『ファイル編集』ではなく『ダウンロード』を選択することで編集前のファイルを保存しておくこともできますし、そうして外部で編集したものと差し替える（上書き保存する）ことでも対処出来ますので、操作ミスの可能性が怖い場合はダウンロードしておきましょう。

ここではACE Editorで編集する様子を紹介します。

編集箇所と内容はダウンロードした場合も一緒です。

下の画像の通り、『DB_NAME』の部分を編集します。

DB_NAMEへ指定するのは、管理画面に表示された正確なデータベース名です。ネームタグから「_1」などを付けて推測する方法は誤りでした。DB_HOST、DB_USER、DB_PASSWORDとユーザーの接続権限も一致する必要があります。

復元したいデータベース名をここに入力することで、このデータベースを実際に読み込む（使う）ことを指定する作業になります。

落ち着いて、確実に作業しましょう。

設定を誤るとデータベース接続エラーになります。元のwp-config.phpを安全な場所へ保存し、変更箇所を記録しておけば、接続設定を元へ戻す判断がしやすくなります。認証情報を公開記事や画像へ載せないでください。

そして最後のステップです。

狙った通りの変更が出来ているかどうかを確認します。

下の画像の通り、『サイト管理』から『データベース』、『ユーザー』と進み、『接続先データベース』を開きます。

WordPressが使うDBユーザーに、対象データベースへの必要な接続権限があるかを確認します。接続できることと、復元した内容が正しいことは別なので、ログイン後の記事も確認してください。

修正前のデータベース名になっている場合には右側にある『設定』を開いてタブから選択しましょう。

操作は以上になります。

バックアップからの復元方法：まとめ

WINGの自動バックアップは過去14日分が案内されています。必要な日付が残っているか、管理画面で実際の状態を確認します。

元記事では2021年の復元時に、その日の夜に保存した下書きが残っていました。これは一回の経験で、毎日の取得時刻や当日分の保存を保証するものではありません。

バックアップの日付だけで判断せず、復元したデータの中に必要な記事と更新内容があるかを確認します。事故の直前まで必ず保存されている、とは限りません。

この復元作業は滅多に行うことはないと思いますが、万一のことは起こるものです。

練習する場合は、本番へ上書きせず検証環境で試します。復元後の確認項目と、元に戻す手順を先に用意しておくと、いざというときに役立ちます。

折角書いた記事が消えてしまわないように。

公開へ戻す前に確認すること

復元前の状態、事故が起きる前のバックアップ、復元を試す環境を区別します。日付の古いDBへ戻すと、その後に公開した記事、コメント、設定変更などが失われます。必要な記事だけを取り出せるか、サイト全体を戻す必要があるかを考えてください。

DBとファイルは同じ役割ではありません。DBだけが古く、画像ファイルが新しい状態なら、記事の参照が一致しないことがあります。反対に古いファイルを戻すと、追加した画像やコードがなくなる場合があります。どの時点の組合せを復旧したいのかを決めます。

検証では、管理画面へログインできることに加え、最近の記事、本文中の画像、メニュー、日英の切替、広告設定、canonicalを確認します。トップだけが表示されても、すべて正常とは言えません。元のURLを保ち、検証用のURLが本番の記事へ混ざっていないかも点検します。

復旧用ファイルには記事や接続情報が含まれるため、公開フォルダーへ無期限に置かないよう管理します。復元作業を終えたら不要な公開状態を残さず、バックアップ自体は安全な保存先で保管します。

公式資料：WINGの自動バックアップ、Webデータのリストア。掲載画像は2021年の操作例です。2026年10月16日見直し。関連するテーマ移行時の確認、保存時の403エラーも参照してください。