ねぇねぇ、佐藤さん！サーバーに「自動バックアップあり」と書いてあったので、もうCodexにテーマを直してもらって大丈夫ですか？もし画面が真っ白になった時、どこを押せば戻るのかは分かっていません。
保存されていることと、自分が必要な時点へ戻せることは別なんだ。まずデータベースとファイルが同じ時刻の一組になっているか、復元入口まで一緒に確かめよう。
画像とテーマをパソコンへコピーすれば、記事本文も一緒に入りますか？管理画面の設定までどこに入っているのか、まだごちゃごちゃです。
記事や設定の多くはデータベース、画像やテーマはサーバー上のファイルにあるよ。両方を同じバックアップセットとして揃えれば、何を守ったか見失いにくい。
WordPressをCodexで変更する前のバックアップは、「データベース」と「ファイル」を同じ時刻の一組として保存し、別の場所にもコピーし、復元方法まで確認できて初めて完成です。 サーバー画面に「自動バックアップ」と表示されているだけでは、対象・保存期間・復元単位・費用が分からないため、まだ作業開始の合図にはできません。
この記事を最後まで進めると、変更前バックアップの中身、名前、保管先、復元担当、成功確認を一枚の記録にできます。既存サイトの引き継ぎがまだなら、先に Codexへ既存WordPressを安全に引き継ぐ方法 も確認してください。
結論：六つ揃えば変更を始められる
- 対象サイトと本番・検証環境を特定した。
- データベースを書き出した。
-
wp-content、wp-config.php、サーバー固有設定を含む必要ファイルを保存した。 - DBとファイルを同じ時刻の一組として記録した。
- 本番サーバーとは別の場所へコピーした。
- 誰が、どの入口から、どの順で戻すか確認した。
一つでも「分からない」が残る場合は、Codexへ変更を依頼する前に保留します。特にEC、予約、会員、問い合わせを扱うサイトは、復元によって新しい注文や送信内容が巻き戻る可能性も記録します。
WordPressはDBとファイルの両方で動く
| 保存対象 | 代表的な内容 | 欠けた時に起きること |
|---|---|---|
| データベース | 投稿本文、固定ページ、ユーザー、コメント、各種設定、プラグインのデータ | 記事や設定を変更前へ戻せない |
| uploads | 画像、PDF、動画など | 本文があっても画像が表示されない |
| themes | テーマ、子テーマ、独自CSS・PHP | デザインや独自機能を再現できない |
| plugins | プラグイン本体 | 同じ機能構成を戻せない |
| wp-config.php | DB接続、環境固有の定数 | 復元後にWordPressへ接続できない |
| .htaccess等 | 転送、アクセス制御、URLルール | 404や転送漏れが起きる |
WordPress公式も、典型的なサイトを完全に戻すにはデータベースとファイルの両方が必要だと説明しています。管理画面の「ツール」→「エクスポート」で作るXMLは記事移行には便利ですが、テーマ、プラグイン、サーバー設定を含む完全バックアップではありません。
「すべてのコンテンツをエクスポート」を保存したので安心していました。画像やテーマまで丸ごと入った復元用ファイルではないんですね。
記事を別サイトへ移す補助にはなるけれど、サイト全体を同じ状態へ戻す材料とは分けよう。DBの書き出しと必要ファイルを揃えるのが先だよ。
pluginsフォルダをコピーすれば、プラグインの設定も全部戻ると思っていました。設定がDB側にあるものも多いんですね。
そう。だからDBだけ、ファイルだけと別々に考えず、「変更直前の一組」にするんだ。日時とサイト名を同じ記録へ残そう。
変更前バックアップの完全チェックリスト
| 確認 | 合格条件 | 記録例 |
|---|---|---|
| 対象 | ドメイン、設置先、DB名を取り違えない | example.com / public_html / DB末尾1234 |
| 時刻 | DBとファイルの取得差を記録 | 2026-08-30 14:05 JST |
| DB | SQL等の書き出しが完了し、容量が0ではない | db-before-theme.sql.gz |
| ファイル | uploads、themes、plugins、設定を含む | files-before-theme.zip |
| 外部保管 | 本番と同じサーバーだけに置かない | 作業PC＋アクセス制限した保管先 |
| 復元入口 | サーバーパネル、phpMyAdmin、担当窓口を特定 | サーバーパネル→バックアップ |
| 影響 | 復元後に失う更新を説明できる | 14:05以後の投稿・注文は要保全 |
| 検証 | 一覧・容量・解凍または検証環境で確認 | ZIP展開、SQL先頭末尾を確認 |
取得順とファイル名を一組にする
更新の少ない時間帯を選び、フォーム送信や注文が続くサイトでは作業時間を短くします。典型的にはDBを先に書き出し、続けてファイルを保存します。取得中に記事更新が入ると、DBと画像の時点がずれるためです。
- 対象サイトのURL、サーバー設置先、DBを照合する。
- 作業開始時刻を日本時間で記録する。
- データベースをエクスポートする。
- WordPressファイルを保存する。
- 二つを同じフォルダへ入れ、チェック記録を添える。
- 本番サーバー外へコピーし、ファイルが開けるか確認する。
jpansystem-example-before-theme-20260830-1405/
├─ database-20260830-1405.sql.gz
├─ wordpress-files-20260830-1407.zip
└─ RESTORE-NOTE.md
ファイル名へパスワード、DBパスワード、顧客名などを書かないでください。複数サイトならドメインの一部と変更目的を入れ、どのバックアップか人が判定できる名前にします。
サーバー自動バックアップで必ず見る七項目
- DBとファイルの両方が対象か。
- 何日前まで保持されるか。
- 取得時刻とタイムゾーンは何か。
- サイト単位、DB単位、アカウント全体のどれを戻すか。
- 復元操作またはデータ提供に料金がかかるか。
- 自分で実行できるか、サポート依頼が必要か。
- 障害・解約・アカウント停止時にも取得できるか。
自動バックアップは有力な復旧経路ですが、同じ契約内にしか存在しないコピーを唯一の保存先にはしません。利用中サービスの最新仕様を公式画面で確認し、必要なら手元にも保存します。費用面を詳しく比較したい場合は、 WordPressバックアップ復元の無料・有料範囲 へ進んでください。
復元テストは本番へ上書きせず確認する
バックアップの価値は、作れたことではなく戻せることです。ただし確認のために本番へ復元すると、正常な最新データまで失う危険があります。可能なら検証環境やローカル環境を使います。
- バックアップファイルの容量が0でないか確認する。
- 圧縮ファイルをコピー側で開き、必要なディレクトリを確認する。
- SQLが解凍でき、途中で切れていないか確認する。
- 検証環境へファイルを配置し、DBをインポートする。
-
wp-config.phpの接続先と検証URLを合わせる。 - トップ、管理画面、画像、主要ページ、ログインを確認する。
- 本番を変更していないことを再確認する。
検証環境を用意できない場合でも、復元画面の入口、対象選択、必要な権限、問い合わせ先までは確認できます。「復元ボタンを押して試す」のではなく、実行直前で止めて手順と影響を記録します。
復元画面に日付がいくつも並んでいて、今日の朝と昨日の夜のどちらを選ぶか迷います。確認のつもりで本番の復元ボタンを押すのは怖いです。
確認だけなら実行直前で止めていいよ。直前変更より前で、失いたくない注文や投稿より後という条件を先に書き、選べる日時と照らそう。
テーマファイルだけを直したなら、DBは戻さなくてもよいですか？全部戻した方が確実にも見えます。
DBを変更していないと確認できるなら、正常なDBまで巻き戻さない方が影響は小さい。変更差分と症状を見て、必要な範囲だけ戻すんだ。
変更内容ごとに守る範囲を変える
| 予定する変更 | 最低限確認する保存 | 復旧時の注意 |
|---|---|---|
| CSS・子テーマ | 対象テーマ＋現在の全体バックアップ | 対象ファイルだけ戻せるか確認 |
| プラグイン更新 | DB、plugins、uploads、設定 | 更新でDB構造が変わる場合がある |
| 記事・固定ページ | DB、関連uploads | 全DB復元は新しい投稿も巻き戻す |
| URL・パーマリンク | DB、.htaccess、サーバー設定 | 転送とcanonicalも再確認 |
| PHP・WordPress更新 | DBと全ファイル、現在バージョン | 互換性と管理画面ログインを確認 |
| 移転・ドメイン変更 | DB、全ファイル、DNS・SSL・メール設定記録 | 旧環境をすぐ削除しない |
Codexへ最初に頼むのは変更ではなく点検
点検後の修正依頼を作る時は、 CodexへWordPress作業を頼む基本プロンプト で、対象・守るもの・完成条件・確認方法を一つの依頼文にまとめられます。
バックアップの作成や復元は、サーバー画面と契約条件によって操作が変わります。Codexへは最初から削除・上書き・公開まで任せず、対象と不足の読み取り確認を頼みます。
対象は既存WordPressサイトです。
まだファイル変更・DB操作・公開・削除はしないでください。
変更予定は子テーマのCSS修正です。
バックアップ記録を読み、DB、uploads、themes、plugins、wp-config.php、.htaccessの保存有無を表にしてください。
本番外の保管先、取得日時、復元入口、未確認事項も分けてください。
パスワード、秘密鍵、APIキーは読んだり表示したりしないでください。
不足があれば変更を開始せず報告してください。
この依頼なら、Codexは変更前の材料を整理できます。バックアップサービスの実行、外部アップロード、本番復元などは、対象と影響を確認した後に一件ずつ判断します。
作業開始・停止の判定
- 対象サイト、バックアップ時刻、変更範囲が一致する
- DBと必要ファイルが一組である
- 本番外のコピーがある
- 復元担当と入口を説明できる
- 変更後の成功条件と戻す条件が決まっている
- 別サイトや別DBの可能性がある
- 自動バックアップの対象・保持期間が不明
- ファイル容量が0、解凍できない、取得エラーがある
- 復元すると失う注文・投稿・フォーム送信を確認できない
- 唯一のコピーが変更対象と同じサーバーにある
サーバーをこれから選ぶ人が見る復旧条件
すでに利用中のサーバーで必要なバックアップと復元ができるなら、この記事のために乗り換える必要はありません。これからWordPressを公開する人、または現在の環境では復旧入口を確認できない人だけ、保存対象・期間・復元単位・料金を公式ページで比較してください。
エックスサーバー
これからWordPressの設置先を選び、サーバー側の保存対象・保存期間・復元方法も契約前に確認したい人の候補です。
向いている人： 自分で取るバックアップと、サーバー側の復旧経路を分けて用意したい人。
利点： WordPressの設置環境とバックアップ関連の最新条件を公式情報で確認できます。
契約不要の条件： 現在のサーバーでDBとファイルを希望日時へ戻せ、復元手順まで確認できている人は乗り換え不要です。
注意点： 自動保存の対象・期間・復元単位・料金は変更されることがあります。契約前と復元前に公式画面で確認してください。
料金： プラン、契約期間、キャンペーンで変わるため、申込当日の税込総額を確認してください。
エックスサーバーの保存・復元条件を確認する
ConoHa WING
複数のWordPressを管理し、対象サイトと復元日時を管理画面で見分けたい人が比較できる候補です。
向いている人： 新しいサイトの契約時に、サイト別のバックアップと復旧入口も確認したい人。
利点： WordPress運用画面とバックアップ関連条件を同じ候補で確認できます。
契約不要の条件： 現在の環境で対象サイトを間違えずに復元でき、外部保管も用意できているなら変更は不要です。
注意点： サーバーの自動バックアップだけを唯一の保存先にしないでください。復元範囲と復元後に失われる更新を確認します。
料金： 料金タイプ、契約期間、キャンペーンで変わるため、申込画面の最新総額を確認してください。
ConoHa WINGの保存・復元条件を確認する広告・PRを含みます。バックアップ確認だけならサーバーの新規契約や乗り換えは不要です。
よくある質問
サーバーの自動バックアップだけで十分ですか？
対象、保持期間、復元単位、料金、障害時の取得可否が目的に合い、復元手順も確認できていることが条件です。重要サイトでは本番サーバー外のコピーも用意します。
データベースだけ保存すれば記事は戻せますか？
本文や設定の多くはDBにありますが、画像、テーマ、プラグイン、設定ファイルは別です。典型的なサイト全体復旧にはDBとファイルの両方が必要です。
WordPressのエクスポートは完全バックアップですか？
いいえ。コンテンツ移行の補助であり、テーマ、プラグイン、サーバー設定などを含む完全な復元セットとは分けて考えます。
バックアップは何世代残しますか？
更新頻度と失ってよい期間で決めます。WordPress公式は複数の最近のバックアップを異なる場所へ保管する考え方を案内しています。変更直前版に加え、問題発見が遅れた場合に備えて複数世代を残します。
バックアップZIPを公開フォルダへ置いてよいですか？
推奨しません。設定や個人情報を含む可能性があり、URLから取得される危険があります。公開領域外またはアクセス制限された保管先を使います。
Gitがあればバックアップは不要ですか？
Gitはコード差分の管理に役立ちますが、通常はDB、uploads、サーバー設定の完全な代わりにはなりません。何を管理対象にしているか確認します。
復元テストは必ず本番で行いますか？
本番での試験復元は避け、可能なら検証環境やローカル環境を使います。用意できない時は実行直前までの画面、権限、影響、問い合わせ先を確認します。
Codexへバックアップファイルを読ませてもよいですか？
秘密情報や個人情報を含む可能性があるため、内容を丸ごと表示させないでください。対象一覧、容量、日時など必要最小限を確認し、認証情報や顧客データは除外します。
DBとファイルを同じ時刻のフォルダにまとめて、別の場所にもコピーできました。復元はまだ少し緊張しますが、入口と失う更新まで記録できています。
「あるはず」から「何をどう戻すか」まで進められたのが大きいね。これなら変更範囲を小さく決めて、結果を見ながら進められるよ。
一度作ったら終わりではなく、次の更新前にも新しい一組が必要なんですね。古いバックアップを全部消すタイミングは迷いそうです。
そうだね。変更直前だけでなく、問題に気づく前へ戻れる世代も残そう。削除は保持方針と復元確認ができてからで大丈夫だよ。
まとめ：バックアップは戻せる状態まで作る
CodexでWordPressを変更する前は、データベースとファイルを同じ時刻の一組として保存し、本番サーバーとは別の場所へコピーします。対象、日時、復元入口、復元で失う更新、担当者まで記録してください。
自動バックアップの表示だけで開始せず、「六つの開始条件」をすべて説明できるかで判断します。 次は CodexでWordPressサイトを作る全体工程 へ戻るか、 必要なアカウント・権限の準備 と照合して、変更する一件だけを決めてください。