WordPressのバックアップと復元手順|保存するデータと戻せるかの確認方法

WordPressのバックアップと復元手順|保存するデータと戻せるかの確認方法 テクノロジー

バックアップは取ってあるから大丈夫。そう思っていても、サイトが動かなくなったときに、どのファイルを使って何を戻せばよいかまで分かっているでしょうか。保存が終わることと、元のサイトを取り戻せることは同じではありません。

当サイトでは再構築に先立ち、元のサイトを残したままバックアップを別の検証環境へ戻しました。公開記事118件を復元できましたが、途中でファイルの権限や保存先の設定を調整する必要がありました。

その確認とWordPress公式の説明をもとに、何を保存するか、どこへ置くか、どう復元を確かめるかを順番に紹介します。サーバーの画面操作は異なっても、準備するデータと確認する順番は整理できます。

WordPressのデータは二つに分かれている

記事の本文や設定は主にデータベース、画像・テーマ・プラグインはファイル側にあります。記事だけ保存しても画像がなければ写真は出ず、画像やテーマだけ残しても本文がなければ元のサイトには戻せません。全体を戻すには、二つをセットで保存します。

WordPressの復元に必要な組み合わせ
データベース
記事本文・設定・ユーザー
ファイル
画像・テーマ・プラグイン

二つを同じ時点のセットで戻す → サイトを確認

管理画面のエクスポートは記事を別のWordPressへ取り込む際には役立ちますが、サイト全体のバックアップの代わりになるとは限りません。ツールを使う場合も、含まれるデータを確認しましょう。

保存するものを決め、日付が分かる形で残す

方法にはサーバーの自動保存、プラグイン、ファイルとDBを個別に取り出す方法があります。どれを使っても、復元に必要な組み合わせが揃うことが大切です。

保存するもの 確認したいこと
データベース 記事や設定を取得したか。空のファイルではないか
画像・テーマ・プラグイン uploads、themes、pluginsなど必要なファイルを含むか
構成に応じた設定 独自の転送やサーバー設定を再現できるか
作業メモ 日時、バージョン、復元方法が分かるか

DBとファイルを別々に保存する場合は、取得の間に更新が増えないようにします。毎日記事や注文が増えるサイトでは、どの時点の状態を戻せるのかが重要です。日時を名前に入れ、復元する組み合わせをメモしておくと迷いません。

設定やDBには認証情報やユーザー情報が含まれる場合があります。公開ページや誰でも取れる場所に置かず、必要な人だけが扱える保存先を使います。復元を相談するときも、保存物をそのまま公開する必要はありません。

サイトが壊れても取り出せる場所へ保存する

同じディスクに置くだけでは、故障や誤削除で一緒に失うことがあります。自宅サーバーなら別の機器や手元にも保存し、レンタルサーバーでも必要な時点のコピーを取り出しておくと、復元の選択肢が増えます。

複数の保存先があっても、失敗したままでは役に立ちません。最後に成功した日時、サイズ、開けるかを定期的に見ます。新しいファイルで上書きする方法なら、更新後の不具合が起きる前のコピーが残るかも確認しましょう。

頻度は、どれくらいのデータを失うと困るかで決めます。週1回のブログと毎日注文が入るサイトでは間隔が違います。大きなテーマ変更や更新の前は、定期保存と別に直前のバックアップを取ります。

復元は公開サイトとは別の環境で確かめる

練習のために本番へ上書きする必要はありません。別の検証環境へ戻し、コピーで確認します。公開サイトを残せば、途中で止まっても読者への影響を避けられます。

検証環境は外部の読者が見られないようにします。「検索エンジンに表示しない」のチェックだけはアクセス制限ではありません。コピーしたフォームや定期処理からメール・外部通知が送られないよう、送信も制限します。

図:安全に復元を確認する順番
① 公開サイトを残す
現在のサイトには上書きしない

↓

② 別の検証環境を用意
閲覧とメール・外部通知を制限

↓

③ ファイルとDBを戻す
同じ時点の保存物を組み合わせる

↓

④ コピーで点検
記事・画像・管理画面・機能を確認して記録

復元ではファイルを配置し、DBを読み込み、接続設定やURLを環境に合わせます。URLの置換はWordPressの保存形式に対応した方法を使います。DB全体を単純な文字列置換で書き換える操作は避け、使うツールやサーバーの手順に従ってください。

当サイトで118記事を復元したとき、設定の調整も必要だった

今回は元のファイルとDBを保存し、隔離環境へ戻しました。公開記事118件があることを確認し、元の公開サイトは保全しています。

途中で調整したのはファイルの権限や保存先の設定です。データが残っていても、復元先で読み書きできなければ処理が進みません。取得したサーバーと復元先が異なる場合、こうした設定も確認します。

この経験から、完了の表示を見るだけでなく、別環境で戻してみることが大切だと分かりました。ただし、件数の一致だけで全ページや全機能の正常動作を証明できるわけではありません。表示と機能の点検も分けて行います。

復元後は、普段使う画面と機能を確認する

新旧の記事、画像の多いページ、管理画面を開きます。画像が出なければ保存対象、ログインできなければ接続設定やURLなど、症状に応じて調べる場所を絞ります。

場所 確かめる内容
記事 新旧の記事が開き、本文が揃うか
画像 表示され、元サーバーに頼っていないか
管理画面 ログインでき、テーマ・プラグインが揃うか
保存操作 検証環境で下書きを保存できるか
必要な機能 フォームなどを安全な宛先・方法で確認できるか

保存日時、戻すまでの作業、つまずいた箇所を簡単に記録します。障害が起きてから思い出すより、前回のメモを見て進められる方が落ち着いて対応できます。

自動バックアップも復元手順まで見て選ぶ

保存期間が同じでも復元操作はサービスで異なります。画面から復元する部分と、取り出したファイルを自分で配置する部分をマニュアルで確認します。

ConoHa WINGのWeb復元は、取り出したデータをFTPなどで配置する手順です。取り出したデータは24時間後に削除されるため、保存と作業を先に用意します。エックスサーバーにはサーバーパネルからDBを復元する手順がありますが、DBだけではWebファイルが揃うとは限りません。

移行先を検討している方は、エックスサーバーとConoHa WINGの比較で復元方法を見比べてください。引っ越しでは、WordPress移行のチェックリストに沿って準備を進められます。

次の更新前に、三つだけ確認しておこう

ファイルとDBの両方を保存したか。壊れても取り出せる別の保存先があるか。戻す手順が分かるか。この三つが揃うと、更新や移行へ進む不安を減らせます。

バックアップは、必要なときに記事と画像を取り戻せる状態を作るためのものです。時間のあるうちに一度復元を確かめ、次回に使えるメモを残しておきましょう。

参照した公式資料

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