--- title: "WordPressのバックアップ設計：WP-CLIでの取得・世代管理・復元テストの手順【7.1系対応】" url: "https://www.issoh.co.jp/tech/details/18612/" published: 2026-10-20 updated: 2026-10-20 categories: ["開発"] publisher: "株式会社一創" --- # WordPressのバックアップ設計：WP-CLIでの取得・世代管理・復元テストの手順【7.1系対応】 WordPressのバックアップは、プラグインを入れて「毎日」を選べば終わる作業に見えます。ところが障害の場面で困るのは、取得したはずのファイルが同じサーバーの中にしか無い、データベースとファイルの時点がずれていて画像が欠ける、そもそも一度も戻したことがない、という3つです。どれも取得の設定ではなく、設計の抜けから起きます。 この記事では、WordPressのバックアップを「確実に戻せる状態」を作る実装として整理します。データベースとファイルの取得順序、WP-CLIとmysqldumpで一貫したダンプを取るオプション、crontabでの日次実行と世代管理、外部ストレージへの転送、バックアッププラグインの無料版で足りる範囲、検証環境への復元テストまでを、コマンド付きで確認できる構成です。サーバー引っ越しの手順そのものは[WordPress移行（サーバー引っ越し）の手順と注意点](https://www.issoh.co.jp/column/details/15310/)に譲ります。版の前提は2026年10月時点のWordPress 7.1.3です。 ## まとめ：WordPressのバックアップは取得方法より先に保存先と復元手順を決める 結論を先に置きます。対象はデータベースとファイルの両方で、同じ時点のものを1組として保管するのが基本です。WordPressの公式文書は、データベースはWordPressのディレクトリの外にあるため、ディレクトリをダウンロードしても取れないと明記しています。片方だけのバックアップは、戻した瞬間に記事と画像の対応が崩れます。 頻度と世代数は公式の目安が出発点になります。投稿の少ないサイトは週1回、更新の多いサイトは毎日、世代は直近3〜5個以上を残す、という基準です。保存先はサーバーの外に最低1か所を確保してください。サーバー内だけの保管は、サーバー障害と不正侵入の両方に無力だからです。 取得の自動化は、WordPress内部の予約実行ではなくサーバーのcrontabから起動します。そして年に数回、検証環境へ実際に戻して表示まで確かめる。この復元テストまで組み込んで、初めてバックアップ運用が完成します。 ## WordPressのバックアップ対象：データベースとファイルを同じ時点でそろえる理由 何を取ればよいかは、WordPressのデータがどこに置かれているかで決まります。置き場所は2系統しかありません。 ### データベースに入るものとwp-content配下のファイルに入るものの線引き 投稿・固定ページ・コメント・ユーザー・サイト設定、そしてプラグインの設定値はデータベースに入ります。一方、テーマ・プラグイン本体・アップロードした画像やPDFはファイルとしてサーバーに置かれ、その大半は`wp-content`の中です。[公式のバックアップ解説](https://developer.wordpress.org/advanced-administration/security/backup/)は、これに加えて`wp-config.php`と`.htaccess`もファイル側の対象に挙げています。 | 置き場所 | 主な中身 | 失うと起きること | | ------------- | -------------------- | ------------ | | データベース | 投稿・設定・ユーザー | 記事と設定がすべて消える | | wp-content | テーマ・プラグイン・画像 | 表示崩れと画像の欠落 | | wp-config.php | 接続情報・認証キー | 接続できず起動しない | | コアファイル | wp-admin・wp-includes | 公式配布物で再取得できる | 表の最下段だけは、バックアップから戻す必要がありません。同じ版のコアは公式から何度でも取り直せるため、保管容量を食う割に価値が低い部分です。逆に`wp-config.php`には認証キーと接続情報が平文で入っているので、保管先の権限管理を他より厳しくしてください。 ### 取得はDBが先・復元はファイルが先という公式の順序と整合性の考え方 公式文書は、取得時はデータベースを先、続けてファイル、復元時はファイルを先に戻してからデータベースを読み込む順序を示しています。両者を同じタイミングで作り、1つのセットとして管理することも併せて求めています。 順序が問題になるのは、取得の途中に投稿や画像の追加が入ったときです。データベースが先なら、後から取ったファイル側に「データベースが知らない画像」が余分に入るだけで済みます。逆順だと、データベースは新しい画像を参照しているのにファイルが無い状態になり、復元後に画像が欠けます。余るのは害がなく、欠けるのは害がある。順序の理由はこれだけです。 ## WP-CLIとmysqldumpでWordPressのバックアップを取得するコマンド手順 管理画面のプラグインを使わずに取る方法を先に示します。プラグインを使う場合も、裏で何をしているかを知っておくと設定の判断が速くなります。 ### wp db exportに一貫性オプションを付けてDBを書き出す基本の形 [wp db export](https://developer.wordpress.org/cli/commands/db/export/)は、`wp-config.php`の接続情報を読んで内部でmysqldumpを実行するコマンドです。mysqldumpのフラグをそのまま追加でき、権限不足で失敗しやすい表領域の出力を止める指定も既定で付きます。ファイル名に`-`を渡すと標準出力へ書き出すため、そのまま圧縮へ流せます。 ``` #!/bin/bash # WordPressのDBとファイルを同じ時刻の1組として取得する set -euo pipefail SITE=/var/www/example DEST=/backup/wp STAMP=$(date +%Y%m%d_%H%M) cd "$SITE" # 1. DBを先に取る（InnoDBを止めずに一貫した断面で書き出す） wp db export - --single-transaction --quick | gzip > "$DEST/db_$STAMP.sql.gz" # 2. 続けてファイルを取る（キャッシュと一時領域は除外） tar -czf "$DEST/files_$STAMP.tar.gz" \ --exclude='wp-content/cache' \ --exclude='wp-content/upgrade' \ wp-content wp-config.php .htaccess ``` `--single-transaction`はダンプ開始時にトランザクションを開き、その時点の状態をアプリケーションを止めずに書き出すmysqldumpの指定です。ただしMySQLの文書によると一貫性が保たれるのはInnoDBのテーブルだけで、MyISAMのテーブルはダンプ中にも変化します。古いプラグインがMyISAMでテーブルを作っていないか、`wp db query "SHOW TABLE STATUS"`のEngine列で一度確かめておきましょう。大きなテーブルを含む場合は`--quick`を併用すると、行をメモリに溜めずに書き出せます。 ### tarでwp-contentを固めるときに外すディレクトリと容量の見積もり方 ファイル側で容量を占めるのは、ほぼ`wp-content/uploads`です。画像の多いサイトでは数十GBに届くことも珍しくありません。一方でキャッシュ系プラグインが作る`wp-content/cache`や、更新時の作業領域である`wp-content/upgrade`は、戻す価値がないうえに容量を膨らませます。 除外対象はサイトごとに違うため、最初に`du -sh wp-content/*`で内訳を見てから決めてください。バックアッププラグインが自分の保存先を`wp-content`配下に作っている場合、それを丸ごと固めるとバックアップの中にバックアップが入り、世代を重ねるごとに倍々で太ります。この入れ子は、容量の急増で最初に気づく典型的な失敗です。 ### バックアップ取得の前後にメンテナンスモードを挟むべきサイトの条件 会員登録やECの注文のように、取得中にもデータベースへ書き込みが続くサイトでは、DBとファイルの数秒から数分のずれが問題になります。[wp maintenance-mode](https://developer.wordpress.org/cli/commands/maintenance-mode/)には有効化・無効化・状態確認のサブコマンドがあり、取得スクリプトの前後に挟めます。 ``` wp maintenance-mode activate # ここで上の取得処理を実行 wp maintenance-mode deactivate wp maintenance-mode status ``` ただし、更新が1日数件のコーポレートサイトでは不要です。メンテナンス画面を毎晩出すほうが、検索エンジンのクロールと夜間の閲覧者に不利になります。判断の線は「取得中に外部の利用者がデータベースへ書き込むかどうか」で、書き込まないなら挟まない、と決めてしまって構いません。 ## crontabで日次実行しWordPressのバックアップを世代管理する自動化の組み立て 手で取るバックアップは、忙しい月に必ず抜けます。取得スクリプトができたら、次は起動の仕組みと残し方を決めます。 ### WP-Cron任せにせずサーバーのcrontabから起動する理由と設定例 バックアッププラグインの予約実行は、多くがWordPress内部のWP-Cronに乗っています。[公式の解説](https://developer.wordpress.org/plugins/cron/)によると、WP-Cronは常時動いているわけではなく、ページが読み込まれたときにだけ予定を確認して実行する仕組みです。文書自身が、14時の予定がページの読み込みが無いまま17時まで実行されない例を挙げています。アクセスの少ない深夜に予約したバックアップほど、実行が遅れるか、日中の閲覧時に重い処理が割り込む形になります。 ``` // wp-config.php：ページ読み込み時のWP-Cron起動を止める define( 'DISABLE_WP_CRON', true ); # crontab -e：WP-Cronは15分ごと、バックアップは毎日3時30分に起動 */15 * * * * wget -q --delete-after https://www.example.com/wp-cron.php 30 3 * * * /usr/local/bin/wp-backup.sh >> /var/log/wp-backup.log 2>&1 ``` WP-Cronを止める定数とcrontabからの起動は、[システムのタスクスケジューラへ載せ替える公式手順](https://developer.wordpress.org/plugins/cron/hooking-wp-cron-into-the-system-task-scheduler/)に沿った形です。WP-Cronを止めると、予約投稿などほかの予約処理もcrontab側の起動に依存します。15分間隔の行は消さないでください。 ### 世代数は公式の3〜5世代を下限に日次7・週次4を残す保持ルール 公式の目安は直近3〜5世代以上です。実務では、これを日次の世代だけで満たすのは危うい設計になります。改ざんやデータ破損は、気づくまでに1〜2週間かかることがあるからです。日次5世代しか無いと、気づいた時点で健全な世代がすべて上書きされています。 ``` # 日次は7日分、週次（日曜に別ディレクトリへ複製）は28日分を残す find /backup/wp/daily -name '*_*.gz' -mtime +7 -delete find /backup/wp/weekly -name '*_*.gz' -mtime +28 -delete ``` 日次7世代と週次4世代を組み合わせると、約1か月前までさかのぼれます。保管量の目安は、日次だけで28世代持つ場合の4割程度です。不正侵入の後始末では、侵入より前の世代を選んで戻す必要が出ます。[wp2shellのようなWordPressの未認証RCE](https://www.issoh.co.jp/tech/details/15412/)が公表されたときに、公表日より前の世代が残っているかどうかで復旧の難度が大きく変わります。 ### 同じサーバー内の保存では守れない障害と外部ストレージへの転送 公式文書は保存先を分散させるよう勧め、ホスティングサーバー・クラウドストレージ・手元のPCを例に挙げています。サーバー内のバックアップが役に立つのは、プラグイン更新の失敗のような「サーバーは無事でWordPressだけが壊れた」場面だけです。ディスク故障、契約の失効、管理者権限を奪われた侵入では、本体と一緒に失われます。 ``` # 取得後にS3互換ストレージへ転送する（バケット側でバージョニングを有効化） aws s3 cp "/backup/wp/daily/db_$STAMP.sql.gz" s3://example-wp-backup/daily/ aws s3 cp "/backup/wp/daily/files_$STAMP.tar.gz" s3://example-wp-backup/daily/ ``` 転送用の認証情報には、書き込みだけを許し削除を許さない権限を割り当ててください。サーバーを乗っ取った攻撃者が、同じ認証情報で外部のバックアップまで消す手口を防ぐためです。サーバーがAWS上にあるなら、[AWS Backupのバックアッププランと復元手順](https://www.issoh.co.jp/tech/details/3380/)でボリューム単位の保護を重ねる構成も選べます。 ## WordPressのバックアッププラグインの選び方と無料版で足りる範囲の境界 コマンドを書かずに済ませたい場合はプラグインを使います。選ぶ基準は機能の多さではありません。無料版で外部保存と復元まで回るかどうかです。 ### UpdraftPlus無料版で使える外部保存先と増分・暗号化が有料になる点 [UpdraftPlus](https://wordpress.org/plugins/updraftplus/)は2026年10月時点で1.26.13系、WordPress 7.1.3まで動作確認済みです。無料版でもDropbox・Google Drive・Amazon S3（互換ストレージを含む）・Rackspace Cloud・FTP・DreamObjects・OpenStack Swift・メールへ送れるため、外部保存の要件は無料の範囲で満たせます。 有料版に回るのは、増分バックアップ・マルチサイト対応・移行機能・データベースの暗号化、そしてOneDriveやSFTPなどの追加の保存先です。注意したいのはデータベースの暗号化で、無料版では外部ストレージに平文のダンプが置かれます。保存先のアクセス権を絞るか、有料版で暗号化するかを先に決めてください。 ### BackWPup無料版は手動アップロードでの復元に限られる制約と向く現場 [BackWPup](https://ja.wordpress.org/plugins/backwpup/)は5.7.8系（2026年10月14日更新）で、PHP 7.4以上が必要です。無料版の保存先はサーバー内・Dropbox・FTP・Microsoft Azure・Amazon S3互換・SugarSync・Rackspace Cloud Filesで、1つのジョブに複数を組み合わせられます。 復元には制約があります。無料版で戻せるのは手動でアップロードしたバックアップだけで、クラウド上の保存先から直接戻す機能と、WordPressが起動しない状態で使える復元アプリはPro版の機能です。管理画面に入れない障害で戻すには、自分でファイルを取り寄せてデータベースを読み込む手順が別に要ります。取得はプラグイン、復元はコマンドという分担を割り切れる現場向けです。 ### プラグインを使わずサーバー機能とWP-CLIで組むべきサイトの条件 次のどれかに当てはまるなら、プラグインは採用しません。画像を含むファイル総量が10GBを超える、共用サーバーのPHP実行時間の上限で取得が途中で止まる、会員情報など個人情報をデータベースに持つ、のいずれかです。PHPの中で巨大なアーカイブを作る方式は時間制限とメモリに縛られ、途中で失敗しても管理画面では気づきにくいからです。 逆に、記事数百本規模のコーポレートサイトで、SSHが使えない共用サーバーならUpdraftPlus無料版に外部保存を設定するだけで足ります。[Jetpackの機能と料金](https://www.issoh.co.jp/tech/details/7494/)に含まれる有償のバックアップを選ぶ手もありますが、その場合も保存先と復元方法は上の2製品と同じ観点で確かめてください。 ## WordPressのバックアップを復元テストで確かめる手順と外部委託の判断基準 戻したことのないバックアップは、戻せるかどうかが分かりません。障害の当日に初めて手順を組むと、数時間で済む復旧が丸一日になります。 ### wp db importとsearch-replaceでの検証環境への復元と表示確認手順 復元テストは本番とは別のドメインの検証環境で行います。公式の順序どおりファイルを先に展開し、[wp db import](https://developer.wordpress.org/cli/commands/db/import/)でデータベースを読み込むのが復元の手順です。そのままでは本番のURLがデータベース内に残るため、[wp search-replace](https://developer.wordpress.org/cli/commands/search-replace/)で検証環境のURLへ置き換えます。このコマンドはPHPのシリアライズ済みデータも壊さずに書き換えるので、SQLファイルを文字列置換するより安全です。 ``` tar -xzf files_20261020_0330.tar.gz -C /var/www/staging gunzip -c db_20261020_0330.sql.gz > restore.sql wp db import restore.sql wp search-replace 'https://www.example.com' 'https://staging.example.com' --skip-columns=guid --dry-run wp search-replace 'https://www.example.com' 'https://staging.example.com' --skip-columns=guid ``` 置換は必ず`--dry-run`で件数を見てから本実行します。表示確認では、トップページだけでなく画像の多い記事・お問い合わせフォーム・管理画面へのログインの4か所を見てください。画像の欠けは取得順序の誤り、フォームの不達はメール設定の環境依存、ログイン不可は`wp-config.php`の差し替え漏れ、とそれぞれ原因の当たりが付きます。 ### 復元後にverify-checksumsでコア改ざんの有無を確かめて記録を残す 侵入被害からの復旧では、戻した世代そのものが汚染されていないかも確かめます。[wp core verify-checksums](https://developer.wordpress.org/cli/commands/core/verify-checksums/)は、現在の版のチェックサムをWordPress.orgから取得してインストール済みのコアファイルと突き合わせるコマンドです。`--include-root`を付けると、ルート直下にある配布物以外のファイルも警告します。 ``` wp core verify-checksums --include-root wp core version ``` テストの記録には、実施日・戻した世代・展開から表示確認までの所要時間・見つかった不具合の4点を残せば足ります。記録した所要時間は、障害時に関係者へ伝える復旧見込みの根拠です。許容できる停止時間とデータ損失の決め方は[リカバリーとは？リストアとバックアップの違いと企業の実務判断](https://www.issoh.co.jp/column/details/13354/)で扱っています。改ざんの検出や更新運用まで含めた対策は[WordPressセキュリティ対策とWP-CLIでの確認手順](https://www.issoh.co.jp/tech/details/18610/)を参照してください。 ### バックアップ運用を自社で回せる条件と保守委託へ切り替える場面 取得スクリプトの設置と外部保存の設定までは、SSHを触れる担当者が1人いれば内製で持てます。問題は継続です。復元テストは年に数回しか実施しないため手順が身に付かず、担当者が異動すると、動いているかどうか誰も確かめないcrontabだけが残ります。 復元テストを半年以上実施していない、バックアップの失敗を通知する仕組みが無い、更新の前に取得する手順が担当者の記憶頼み。このうち2つ以上に当てはまるなら、保守を外部に任せたほうが安く付きます。一創の[WordPress保守・メンテナンス](https://www.issoh.co.jp/service/web/wordpress-support/)では、バックアップの設計と復元確認を、コアやプラグインの更新作業と一体で請けています。委託範囲と費用の考え方は[WordPress保守運用とは：作業範囲・費用相場と内製か外注かの判断基準](https://www.issoh.co.jp/column/details/15799/)にまとめました。 ## よくある質問 WordPressのバックアップについて、設計と運用の場面でよく出る質問に答えます。 ### WordPressのバックアップはどのくらいの頻度で取ればよいですか？ 公式文書の目安は、投稿の少ないサイトで週1回、更新の多いサイトで毎日です。加えて、コア・テーマ・プラグインを更新する直前には必ず取ります。判断に迷ったら、失ってもよい作業量で決めてください。1日分の投稿や問い合わせを失うと困るなら日次、1週間分でも作り直せるなら週次で足ります。会員登録や注文を受けるサイトは日次でも粗いため、データベースだけを数時間おきに取る構成を検討しましょう。 ### レンタルサーバーの自動バックアップがあればプラグインは不要ですか？ 不要とは言い切れません。サーバー会社の自動バックアップは、多くが同じ事業者の設備内に保管され、保持期間も事業者が決めます。契約の失効やアカウントの乗っ取りが起きると、本体と一緒に使えなくなる点も同じです。サーバーの機能は1つ目の保存先として使い、プラグインかスクリプトで別事業者のストレージへ2つ目を送る構成にすると、保存先の分散という公式の勧めを満たせます。 ### データベースだけバックアップすれば記事は復元できますか？ 本文と設定は戻りますが、画像やPDFは戻りません。データベースが持っているのはアップロードしたファイルの場所と情報だけで、ファイルそのものは`wp-content/uploads`に置かれているからです。テーマを独自に改修している場合は、その変更もファイル側にしかありません。容量を抑えたいなら、データベースは日次、ファイルは週次と頻度を分ける設計にして、どちらも省かないでください。 ### バックアップファイルはどこに保存すべきですか？ WordPressが動いているサーバーの外に、最低1か所を確保します。候補はS3互換のクラウドストレージ、Google DriveやDropbox、社内のファイルサーバーなどです。外部の保存先には、書き込みはできても削除はできない権限で送ると、侵入者に消される事態を防げます。`wp-config.php`やダンプには接続情報と個人情報が入るため、共有リンクで誰でも開ける場所には置かないでください。 ### WordPressを更新する前に何をバックアップすればよいですか？ 日次のバックアップとは別に、更新の直前にデータベースとファイルの両方を手動で1組取ります。日次の取得から更新までの間に入った投稿を失わないためです。メジャー版の更新は、データベースの構造が変わることがあり、旧版のファイルだけを戻しても動かない場合があります。更新前の確認手順は[WordPress 7.0の変更点と安全なアップデート手順](https://www.issoh.co.jp/tech/details/11971/)で扱っています。 ## 関連記事 - [WordPress保守運用とは：作業範囲・費用相場と内製か外注かの判断基準を解説](https://www.issoh.co.jp/column/details/15799/)：バックアップを含む保守の委託範囲と費用 - [WordPress移行（サーバー引っ越し）の手順と注意点｜自力と代行の判断基準も解説](https://www.issoh.co.jp/column/details/15310/)：バックアップを使ったサーバー移行の流れ - [WordPressセキュリティ対策：攻撃面ごとの設定とWP-CLIでの確認手順【2026年10月・7.1.3対応】](https://www.issoh.co.jp/tech/details/18610/)：侵入を防ぐ側の設定 - [システムバックアップとは？フル・差分・増分の違いと取得手順・方式の選び方を解説](https://www.issoh.co.jp/column/details/13448/)：方式そのものの一般的な整理 - [WordPress 7.0「Armstrong」の新機能・変更点と安全なアップデート手順](https://www.issoh.co.jp/tech/details/11971/)：更新前のバックアップと確認手順 --- 出典: [WordPressのバックアップ設計：WP-CLIでの取得・世代管理・復元テストの手順【7.1系対応】]()（株式会社一創）