技術ブログのバックアップと移行｜復元できるかを先に試す

更新日：2026年10月6日 ／ 公式情報確認日：2026年10月5日

WordPressのバックアップは、保存数だけでなく「何を、どの時点へ戻せるか」で選びます。記事本文を保存しても、画像やテーマ設定が戻らなければサイトの見た目は再現できません。

まずファイルとデータベースを同じ作業時点で保存し、公開サイトとは別の環境で復元を確認します。 本稿は、小規模な技術ブログの運営者向けです。手元で実行した公開記事1本のHTML・画像の復元例と、公式資料に基づくWordPress全体の復旧手順を分けて示します。広告リンクはありません。

保存するものを4つに分ける

WordPress公式もファイルとデータベースの両方を保存するよう説明しています。公式バックアップ資料

保存日時、WordPress・PHP・テーマ・プラグインのバージョン、バックアップ取得中に更新した投稿の有無を一緒に記録します。設定ファイルやDBには認証情報が含まれるため、公開フォルダーに置かず、復旧担当者が読める保存先にします。

実際に試したこと：公開記事と画像をZIPから戻す

2026年10月5日に、このサイトのAI開発学習ロードマップの公開本文とアイキャッチを取得し、ZIPに保存しました。別フォルダーに展開し、2ファイルのSHA-256が一致することを確認しました。

これは1記事の閲覧用HTMLと画像の保全確認です。WordPressのDB、コメント、管理画面、フォームの復元は検証していません。 内部リンクは元の公開URLを向いたままで、オフラインサイト全体のコピーにもなりません。

自分のファイルで再現する

Python 3と標準ライブラリだけで動きます。original フォルダーに article.html と thumbnail.png を入れます。HTML内の画像指定は <img src="thumbnail.png" alt="記事画像"> とし、文字コードはUTF-8にします。任意の公開可能なHTMLとPNGで試せます。

次を restore_check.py として保存してください。

"""Rehearse restoration of two public files into a new directory."""
import hashlib
import json
import sys
import zipfile
from pathlib import Path

source, archive, restored = map(Path, sys.argv[1:])
names = ("article.html", "thumbnail.png")
if archive.exists() or restored.exists():
    raise SystemExit("Use a new archive and restore directory")
expected = {name: hashlib.sha256((source / name).read_bytes()).hexdigest()
            for name in names}
with zipfile.ZipFile(archive, "w", zipfile.ZIP_DEFLATED) as z:
    for name in names:
        z.write(source / name, name)
    z.writestr("manifest.json", json.dumps(expected))
restored.mkdir(parents=True)
with zipfile.ZipFile(archive) as z:
    for name in names:
        (restored / name).write_bytes(z.read(name))
    manifest = json.loads(z.read("manifest.json"))
for name in names:
    actual = hashlib.sha256((restored / name).read_bytes()).hexdigest()
    if actual != manifest[name]:
        raise SystemExit("MISMATCH: " + name)
    print("MATCH: " + name)
print("Restored 2 files; WordPress database and settings are outside this check")

ターミナルで、original とコードを置いたフォルダーへ移動して実行します。

python3 restore_check.py original article-backup.zip restored

検証環境はmacOS・Python 3.14.2です。実行結果は次のとおりでした。

MATCH: article.html
MATCH: thumbnail.png
Restored 2 files; WordPress database and settings are outside this check

restored/article.html をブラウザーで開き、コード・表・画像を確認します。ZIPには許可した2ファイルとハッシュ一覧だけを入れ、展開時も決めたファイル名だけを読み出しています。2回目は同じ出力先を上書きしないため停止します。再試行には別のZIP名と復元先を指定します。

ハッシュ一致は「保存したデータと同じ」であることを示すだけです。保存前の内容が正しいか、リンク先が動くかは別に確認します。

WordPress全体を復元する具体的な順番

以下は公式仕様をもとに整理した復旧計画です。本稿のローカル実験でWordPress全体を復元した結果ではありません。

1. 戻したい日時を決める。 不具合が発生する前のファイルとDBを選びます。その日時以降の投稿・コメントが失われる範囲を記録します。
2. 復元用の別サイトを用意する。 公開アクセスを制限し、メール送信や外部サービスへの書き込みを止めます。現行サイトは残します。
3. ファイルとDBをそろえる。 サーバーのバックアップ機能、SFTP、DB管理画面など、利用できる手段で取得します。SQLだけ、uploadsだけでは不十分です。
4. 復元先のDBへ取り込む。 復元先の接続情報を確認してから、保存SQLを取り込みます。WP-CLIが導入済みなら、復元先WordPressディレクトリで wp db import backup.sql が利用できます。本番DBで実行しません。公式importコマンド
5. ファイルと設定を戻す。 保存したテーマ・プラグイン・画像を配置し、wp-config.php のDB接続先を復元先に合わせます。ファイルのアクセス権も確認します。
6. URLが変わる場合だけ置換する。 DBの文字列を一括編集せず、WordPressのシリアライズを扱える手段で変更します。WP-CLIならまず下の --dry-run で対象を確認します。
7. 表示・機能を確認してから切り替える。 DNS変更の前に代表記事、ログイン、画像、フォーム、コード表示を確認します。

wp search-replace 'https://old.example.com' 'https://new.example.com' --skip-columns=guid --dry-run

復元先のDB接続と対象テーブルを確認し、置換内容が適切な場合だけ --dry-run を外します。独自のプラグインテーブルがあれば、その対象も個別に確認します。公式search-replace仕様

ConoHa WINGを使っている場合

公式ではWeb・Mail・DBを1日1回、過去14日分保持します。管理画面の WING → サーバー管理 → 自動バックアップ で対象サーバー・日付・Web/DBを選び、復元用データを準備します。

「復元」を押すだけで稼働中サイトが元通りになるとは限りません。 公式案内ではサーバー上にデータを設置し、必要なデータを使って復旧作業を行う流れです。Webの復元ファイルは24時間で削除され、再リストアで以前のファイルも削除されるため、取得先と時刻を控えます。公式リストア手順・バックアップ仕様

移行の合否を記録する

記録例は「復元日／保存日時／対象ファイル・DB／確認URL／結果／未解決／切り戻し先」です。復元に要した時間には、データ取得、取込、表示確認を分けて残すと、次回の停止時間を見積もれます。

旧環境を止める前に決めること

切替後の確認担当、旧環境の保持期間、元へ戻す条件を決めます。DNSの反映中に新旧サイトへ書き込みが分散する場合は、投稿・コメントの差分をどう回収するかも必要です。

費用は新サーバーだけでなく、移行中の重複契約、ドメイン更新、バックアップ保管、復旧担当者の時間を含めます。技術ブログの公開・制作費用の費用表に追記してください。

最初の作業は、保存済みデータを別の場所へ戻し、本文と画像が一致することを確かめることです。その後、DBと設定まで含む復元試験を行って、サイト全体の移行可否を判断します。

出典と検証範囲

公式情報の確認日・ローカル検証日：2026年10月5日。ローカル検証はHTML・PNGのZIP保存と復元、ハッシュ一致まで。ConoHa管理画面での復元、WP-CLIのDB取込・URL置換、本番DNS切替は未実施です。

• WordPress Backups
• WP-CLI db import
• WP-CLI search-replace
• ConoHa WING自動バックアップ
• ConoHa WINGリストア手順