Xserver
通常レンタルサーバーの公式資料を参照。Webは「自動バックアップデータ取得・復元」、DBは新パネルの「MySQLバックアップ取得・復元」で対象を照合します。旧パネルでは名称が異なります。
Web側の対象ドメイン/領域と、DB側の対象DB/日付を別に確認。確認画面の注意事項を読み、対象外データ・保持世代・上書きされる範囲を照合してから実行します。
公式：Web等の復元WORDPRESS / BACKUP & RECOVERY
保存しただけで、
戻せるとは限らない。
画像はファイル、本文はDB。戻す範囲と時点を間違えると、表示が直っても新しい投稿を失います。実際の復元結果から、保存と復旧の判断を整理します。
上書き前に戻す範囲を確認する ↓公式確認2026-10-15 ｜ 独立WordPressで復元を実操作 ｜ 本番の完全復旧・成功率は未検証
WordPressの保守・障害対応へ →01 / 不具合があるなら先に止める
新着と復旧先が決まるまで、古いDBを上書きしない。
復元を実行するツールではなく、入力条件に基づく準備案内です。入力・ファイル・パスワードを送信しません。
侵害・改ざんが疑われる場合：正常な保存点も感染している可能性があります。状況・ログ・新着を保全し、提供者や専門担当へ。復元だけで侵入原因が消えたとは判断しません。
02 / 本文・画像・設定は同じ場所ではない
何が戻るかは、保存した中身で決まる。
| 対象 | 主な中身 | これだけでは戻らないもの |
|---|---|---|
| DB | 記事・固定ページ・コメント・ユーザー・添付ファイルの参照情報・有効テーマ/プラグインの設定等。独自表も確認 | 削除した画像ファイル、テーマ本体、プラグイン本体 |
| Webファイル | uploadsの原画像と生成画像、テーマ/子テーマ・プラグイン本体、必要なWordPress本体と独自コード | 保存していないDBの本文や新しい注文 |
| 構成・設定 | wp-config.php、独自rewrite、接続先、版や依存設定の控え | 外部のDNS・メール・証明書等の全設定 |
| 外部サービス | メール、外部ストレージ、決済等、サイト外の設定と保管範囲 | WordPressを戻しただけでは外部の取引/配送は巻き戻らない |
画像は、DBの添付情報とuploads内の実ファイルの両方が必要です。DBの添付情報だけでは削除した原画像を生成できません。テーマ/プラグインも、ファイル本体とDB内の有効化・個別設定を分けて保存します。外部ストレージ利用時はその保存範囲も別途確認します。
保存物にはユーザー情報・問い合わせ・認証値が含まれる場合があります。公開ディレクトリや共有URLへ置かず、所有者だけが扱える保管先を選びます。バックアップ自体や設定ファイルをこの記事へアップロードする必要はありません。
公式資料 WordPress：ファイルとDBの保存 · 確認2026-10-15。下記の提供者パネル操作を当サイトで実施した証拠ではありません。
03 / 取得と整合性検査
ダウンロードした日時と、データの保存時点を分ける。
- 対象サイトとDBの対応、取得するWeb領域、保存点、保存先を確認。WordPressのエクスポートだけを、全ファイル・設定を含む完全なバックアップとは扱わない。
- 契約先の自動バックアップ取得、手元への保存、既存の管理手順など、自分の復旧先で扱える形式を選ぶ。選んだ方法がファイル/DB/メールのどれを含むか照合する。
- 取得中に書込みが続くサイトは、WebとDBの時点差を確認。停止や差分調整の担当・範囲を決める。個別DBの整合性と、サイト全体の同一時点保証は別です。
- 取得後は圧縮ファイルを最後まで読めるか、対象のファイル/表が揃うか、控えたハッシュと一致するかを確認。破損・欠落なら復元せず取得元に確認。
- 本番とは別の場所へもう1組保管し、取出せることを確認。秘密情報を含む生データや詳細ファイル一覧は公開しない。
当サイトの実取得物：承認済みSSH配備時に取得したWeb＋DBアーカイブを、今回もMac内だけでSHA・gzip終端・Web構造・SQL表定義・非公開権限で検査しました。この実アーカイブそのものの復元は未実施です。実証の範囲を「本番の復元成功」に広げません。
以下の復元画面は合成データ専用の別環境です。実バックアップのユーザー/認証情報を取り込んだ画面ではありません。
公式資料 WordPress：DBのバックアップ · 確認2026-10-15。下記の提供者パネル操作を当サイトで実施した証拠ではありません。
04 / 当サイトの独立実験
DBだけ戻すと、本文は戻っても画像は404だった。
2026-10-15、WordPress7.1.2・PHP8.5.11・SQLite統合・合成投稿と画像1点で試験。保存時点の後に本文を変更し、画像を削除、新しい投稿を追加。その後、DBと画像を別々に戻して比較しました。バックアップ/復元中の同時リクエストはありません。
| 戻した対象 | 本文 | 画像 | 保存後の追加投稿 |
|---|---|---|---|
| 変更後・復元前 | 変更後 | 404 | 200 |
| DBのみ | 保存時点 | 404 | 404 |
| 画像のみ | 変更後 | 200 | 200 |
| DB＋対象画像 | 保存時点 | 200 | 404 |
元記事は全ケースで200。HTTP200だけでは、画像や新しい投稿まで戻ったとは言えません。「両方を戻した」は保存点へ戻ったことであり、保存後の新着まで戻ったという意味ではありません。
画像だけ戻した結果と、変更前の画面も見る
壊した試験用gzipと不正SQLiteも整合性検査で拒否し、復元に使用しませんでした。DBのコピー操作自体は成功しましたが、DBのみでは画像復旧、画像のみでは本文復旧という目的を達成できませんでした。破損ファイルは検査で止めたため、破損DBの復元実行が失敗した試験ではありません。復元方法はSQLiteの整合バックアップと対象画像のコピーです。実ホスティングのMySQL、全Web領域、メール、注文の差分統合、作業時間・成功率の試験ではありません。
05 / 上書き前に順序を決める
正常な保存点を、隔離先で先に確かめる。
- 現状を別保存：壊れた側にも新着がある可能性があります。変更時刻と症状、追加投稿・注文・問い合わせ・画像・メールを保全する。保全のために秘密情報を一般公開しない。
- 戻す範囲を選ぶ：対象サイト、正常だった保存日時、ファイルとDBの組合せ、接続先、版を照合。不具合発生後の保存点を「最新だから」と選ばない。
- 隔離先を作る：本番の公開先/DNSを変えず、外部メール・解析・広告計測・決済・ジョブを止めて復元。検索除外だけをアクセス保護としない。取扱担当だけが使える場所にする。
- ファイルとDBを復元：対象と接続先の対応、表接頭辞、必要な画像・テーマ/プラグイン・設定を照合。実サイトの秘密を例示SQLや公開画像へ出さない。SQLiteの手順をMySQLへそのまま流用しない。
- 隔離先の合否判定：代表記事だけでなく画像の実URL、新着の有無、管理画面、URL/HTTPS、必要なフォーム等を検査。送信停止のままの試験と、実メール配送を分けて記録。
- 本番反映の判断：新着の差分を統合でき、外部機能と戻す手順を担当者が確認した場合だけ。データが増え続けるEC/会員サイトは専門担当と作業窓を設計。合成実験を根拠に本番へ一括上書きしない。
ここでは実行しない操作：対象DBが不明なままのインポート、正常DBの削除、DROP TABLE等での本番上書き、保存後の画像を古いuploadsで削除同期、版の異なるテーマ/プラグインの一括上書き。現在のWeb・DB・新着を別保存できない、正常な保存点が不明、破損がある、切戻し先がない場合は中止します。初心者は本番では試さず、提供者・管理担当へ対象と範囲を確認してください。
失敗したら：復元を繰り返す前に、不具合の証拠・試した保存点・結果を残す。隔離先で修正しても本番の正常部分はそのまま保つ。実本番を戻す場合は、書込み/差分を止める範囲と復帰先を先に合意します。
06 / 同じ「復元」でも工程は違う
XserverとConoHa WINGの画面名を混同しない。
ConoHa WING
「WING → サーバー管理 → 自動バックアップ」で対象サーバーとWeb/Mail/DBを確認。リストア後に実際の利用先へ戻す工程が別にあるため、履歴の完了表示だけをサイト復旧完了としません。
Webは生成された復旧用データから必要な実Web領域へ、DBは公式の接続先切替例と構成を照合。認証値を転記・公開せず、担当者と確認します。
公式：リストアの開始公式確認2026-10-15。今回両社のパネルで復元を実行した事実はありません。実パネルの操作画像は未撮影です。ConoHa VPSやXServerビジネスなど別製品の手順を混ぜません。
取得・復元の画面で、何を順に照合する？
- 契約先の管理パネルを開き、サイトのドメインと利用DBを控える。wp-config.php等を参照できる担当者と照合し、秘密値は共有しない。
- XserverではWebの取得画面とMySQLの取得画面を別々に開き、同じサイトに対応する保存日を選ぶ。生成・取得が完了したか、手元へ保存したファイルを最後まで読めるか確認する。
- 復元前に、現在のWeb・DBと保存後の新着を別保存する。最初は隔離先で試す。実パネルの復元対象が本番なら、練習のために実行しない。
- XserverではWebとDBそれぞれの対象・日付・上書き範囲を復元確認画面で再照合。ConoHa WINGはリストアで生成したデータから実Web領域/DB接続へ戻す追加工程まで公式手順を追う。
- 処理履歴だけで終えず、元記事・画像・新着・管理画面を確認。配送停止の隔離試験で実メールまで成功したとは扱わない。未確認なら本番への反映を止める。
両社の契約パネルは今回未操作です。ここは公式手順をたどるための照合順であり、すべての契約画面が同じことや、一律の復元成功を保証する説明ではありません。
保持期間と、生成した取得/復旧用ファイルの保存期限は別です。Xserverの一部旧環境の例外、ConoHaのWebリストアファイルの期限/操作制限も最新公式と契約画面で照合。古い保存点や生成ファイルがいつまでも残る前提で計画しないでください。
公式資料 Xserver：Web等の取得と生成データの注意 · 確認2026-10-15。下記の提供者パネル操作を当サイトで実施した証拠ではありません。
公式資料 Xserver：DBの取得 · 確認2026-10-15。下記の提供者パネル操作を当サイトで実施した証拠ではありません。
公式資料 ConoHa：リストア後の復元工程と期限 · 確認2026-10-15。下記の提供者パネル操作を当サイトで実施した証拠ではありません。
07 / 失敗する場所を分ける
取得できない、読めない、表示できないを切り分ける。
| 症状 | 先に確認 | 止める行動 |
|---|---|---|
| ダウンロード/取得失敗 | 対象・空き容量・取得履歴・保存期限 | 不完全なファイルで復元しない |
| 圧縮/DBの検査エラー | 取得元の正常性、転送、元のSHA/サイズ | 破損を無視してインポートしない |
| DB接続エラー | 復旧先のDB/ユーザー対応、設定と表 | 認証値を公開しない。正常DBを削除しない |
| 本文は戻るが画像404 | 画像の保存範囲、URL、実ファイル、権限 | DBだけを繰り返し上書きしない |
| 記事/設定が古い | 選んだ保存点と保存後の新着 | 新着が不要だったと決めつけない |
| フォーム送信が届かない | 隔離時の送信停止、配送設定と実受信 | 「画面に完了表示」で配送成功にしない |
異なる保存点を無計画に混ぜるほど、どの版を戻したか分からなくなります。1回ごとの対象・日時・結果を記録し、分からない場合は追加上書きを止めて担当者へ相談してください。
08 / 最後は自分のサイトの成功条件で
表示された、その先まで確認する。
自己確認の補助であり、復元を実行/保証するものではありません。
これから記事を公開する
開設から最初の記事公開と匿名確認へURLや公開設定を確認する
URL・公開設定の変更前チェックと復旧手順へ公開済みサイトでは、URLやパーマリンクを初期設定のつもりで変更しないでください。
他社へ移すための保存なら、Xserverへの移行前確認・DNS/メール・切戻し手順へ。復元練習と実際の移行成功は別です。
バックアップのためだけに乗り換える前に、現在の契約にある取得/復元機能と保存責任を確認。契約判断が必要なら Xserverの運用条件・ConoHaの制約と条件 へ進めます。
根拠・実証範囲・未実施
公式資料は提供者/WordPressの説明、実取得アーカイブは整合性検査、復元画面は独立した合成WordPress/SQLite実験です。10/11の既存実験も対照し、今回10/15の別コピーで再現。過去の隔離復元台帳があることを、今回の実本番アーカイブの復旧成功に読み替えません。実MySQL全体復旧、Xserver/ConoHaパネル復元、メール/SSL/DNS、第三者初心者テスト、復旧時間・成功率・収益効果は未検証です。