WordPressサイトのバックアップ方法

Q: `mysqldump`は引き続き安全に使用できますか？`mysqlpump`に切り替えるべきですか？

`mysqlpump`ではなく`mysqldump`を使用してください。`mysqlpump`ユーティリティはMySQL 8.0.34で非推奨となり、MySQL 8.4で完全に削除されたため、これを呼び出すスクリプトは現在のサーバーでは失敗します。`mysqldump`は引き続きサポートされており、MySQLはその代替として`mysqldump`またはMySQL Shellのダンプユーティリティを推奨しています。稼働中のInnoDBサイトの整合性のあるスナップショットを取得するには、`--single-transaction`フラグを付けて`mysqldump`を実行してください。このフラグにより、ダンプ中にテーブルをロックせずに済みます。

mysqldump、tar、cron、rcloneでWordPressサイトをバックアップ。ファイル、MySQLデータベース、オフサイト保存、復元テストまで解説。

OpenReplay Team

Aug 6, 2026 · 5 min read

完全なWordPressバックアップとは、ファイルとMySQLデータベースの2つを同時に取得したコピーです。どちらか一方でも欠けると、リストアは失敗します。本ガイドでは、コマンドラインから確実にバックアップを行う方法として、mysqldump、tar、そしてアーカイブをオフサイトに転送するcronジョブを取り上げます。これにより、プラグインに依存することなく、バックアップを自分自身で管理できます。また、ホスティング会社のバックアップやプラグインによるバックアップについても公平に評価し、バックアップが実際に機能することを確認するためのリストアコマンドも紹介します。

重要なポイント

完全なWordPressバックアップには、必ず同時に取得しなければならない2つの要素があります。ファイル（コア、wp-content、wp-config.php、およびApacheの場合は.htaccess）と、すべての投稿・ページ・コメント・ユーザー・設定が実際に保存されているMySQLデータベースです。どちらか一方だけをリストアしても、サイトは正常に復元されません。
初心者が最もよく犯すミスは、FTP経由でファイルをバックアップしてデータベースを忘れることです。すべての投稿・ページ・コメント・ユーザー・設定は、実際にはデータベースに保存されています。
基本コマンドは1行です：mysqldump --single-transaction -u USER -p DBNAME > db.sql。--single-transactionオプションにより、稼働中のInnoDBデータベースの整合性のあるスナップショットを取得できます。
データベースのダンプ、wp-contentのtar圧縮、そしてrcloneを使ったオフサーバーへのアーカイブ転送を行うシェルスクリプトをcronで自動化しましょう。手動で実行することを覚えているバックアップと、自動的に実行されるバックアップの差は大きいです。
3-2-1ルールに従い、バックアップの唯一のコピーをサイトと同じサーバーに保存しないでください。

完全なWordPressバックアップには何が含まれるか？

WordPressサイトは2つの独立したシステムで構成されており、バックアップは両方を取得する必要があります。ファイルとは、WordPressコア、wp-content以下のすべてのコンテンツ（テーマ、プラグイン、および通常最も容量が大きいuploadsフォルダ）、そしてルートのwp-config.phpです。Apacheを使用している場合は.htaccessも対象となりますが、nginxやCaddyでは.htaccessは存在しません。リライトルールはWebルート外のサーバー設定に記述されるためです。データベースとは、投稿・ページ・コメント・ユーザー・タクソノミー、そすべてのプラグインとテーマの設定を保持するMySQLデータベースです。

初心者が最もよく犯すミスは、FTP経由でファイルをバックアップしてデータベースを忘れることです。テーマやコアは再ダウンロードできますが、コンテンツは再取得できません。「バックアップ」がファイルのみの場合、リストアしたサイトは投稿も設定も存在しない状態で起動します。

WordPressをバックアップする3つの方法

実用的なアプローチは3つあり、それぞれ利便性とコントロールのトレードオフがあります。

アプローチ	コントロール	スクリプト化	デフォルトでオフサイト	備考
ホスト自動バックアップ	低	不可	場合による	保存期間が短い。ホストがダウンすると利用不可。多くの場合、責任はユーザーにあると免責される
バックアッププラグイン	中	限定的	可（設定次第）	ダッシュボードからスケジュールとクラウドアップロードが可能。非常に大規模なサイトや高度にカスタマイズされたサイトでは動作が重くなることがある
手動 / CLI	完全	可	選択可能	`mysqldump` + `tar` + オフサイト転送。本ガイドの主題

ホストのバックアップは便利ですが、唯一のコピーとして頼るべきではありません。保存期間が短く、サーバーが侵害されたり障害が発生した場合、そこに保存されているバックアップも失われる可能性があります。UpdraftPlusなどのプラグインは、ダッシュボードからスケジュール設定とクラウドアップロードを管理でき、コマンドラインに不慣れなユーザーには合理的な選択肢です。CLIによる方法は、開発者がバージョン管理・スケジュール設定・監査を行えるアプローチです。

コマンドラインからWordPressをバックアップする

コマンドラインによるバックアップは、SSH経由で3つのステップで行います。データベースのダンプ、ファイルのアーカイブ、そして両方をサーバーから取り出すことです。まず接続します：

ssh user@example.com -p 2222

次に、ファイルをアーカイブしてデータベースをダンプします：

# Webルートの上位ディレクトリからサイトファイルをアーカイブ
tar -zcf files.tar.gz public_html

# 整合性のあるスナップショットでデータベースをダンプ
mysqldump --single-transaction -u DB_USER -p DB_NAME > db.sql

--single-transactionフラグは、稼働中のサイトでのダンプを信頼性の高いものにするために不可欠です。整合性のある状態でダンプされるのはInnoDBテーブルのみであり、MyISAMやMEMORYテーブルはダンプ中に変更される可能性があります。WordPressはデフォルトでInnoDBで動作するため、--single-transactionは--lock-tablesよりもはるかに優れた選択肢です。テーブルをロックする必要がなく、ダンプ中もサイトは稼働し続けます。mysqlpumpではなくmysqldumpを使用してください。前者はMySQL 8.4で削除されており、これを呼び出すスクリプトは現在のサーバーでは単純に失敗します。

scpを使って両方のファイルをローカルに取得します：

scp -P 2222 user@example.com:~/files.tar.gz .
scp -P 2222 user@example.com:~/db.sql .

チュートリアルでよく見落とされる注意点があります：scpではポート指定に大文字の-Pを使いますが、sshとmysqldumpでは小文字の-pを使います（それぞれポートとパスワードを意味します）。これを混同するのは典型的なコマンド失敗の原因です。

WP-CLIを使用している場合、wp db exportの方がよりシンプルです。このコマンドはwp-config.phpに記載されたDB_HOST、DB_NAME、DB_USER、DB_PASSWORDの認証情報を使ってmysqldumpユーティリティを実行し、有効なmysqldumpフラグをすべて受け付けます。

wp db export --single-transaction db.sql

マネージドホストやcPanelホストでは、テーブルスペースのダンプ時にPROCESS権限エラーが発生し、通常のmysqldumpが失敗することがあります。WP-CLIはこの問題をすでに対処しており、wp db exportはデフォルトで--no-tablespacesをmysqldumpに追加します。マネージドホストで生のmysqldumpを使用する場合は、--no-tablespacesを自分で追加してください。

cronとrcloneでWordPressバックアップを自動化する

データベースのダンプ、wp-contentのtar圧縮、そしてアーカイブのオフサーバー転送を行う短いシェルスクリプトをcronスケジュールで自動化しましょう。rcloneは「クラウドストレージのためのrsync」とも呼ばれ、S3、Backblaze B2、Google Driveなどを転送先として指定できます。

#!/usr/bin/env bash
set -euo pipefail

SITE_DIR="/var/www/example.com"
DEST="b2remote:example-backups"     # 設定済みのrcloneリモート
STAMP="$(date +%F)"
WORK="$(mktemp -d)"

cd "$SITE_DIR"

# データベース — WP-CLIはwp-config.phpから認証情報を読み取る
wp db export --single-transaction "$WORK/db-$STAMP.sql"

# ファイル — テーマ、プラグイン、アップロード、および設定ファイル
tar -zcf "$WORK/wp-content-$STAMP.tar.gz" wp-content wp-config.php

# オフサイトに転送
rclone copy "$WORK" "$DEST/$STAMP"

rm -rf "$WORK"

毎日03:15に実行してログを記録するcrontabの行でスケジュールを設定します：

15 3 * * * /usr/local/bin/wp-backup.sh >> /var/log/wp-backup.log 2>&1

これが「バックアップを自分で管理する」ことの真価です。ダッシュボードも、プラグインも、手動の操作も不要です。WP-CLIがインストールされていない場合は、エクスポートの行をmysqldump --single-transaction --no-tablespaces -u DB_USER -pPASS DB_NAME > "$WORK/db-$STAMP.sql"に置き換えてください。

3-2-1ルールに従ってバックアップを保存する

3-2-1ルールに従いましょう：サイトのコピーを少なくとも3つ保持し、2種類の異なるメディアに保存し、1つはオフサイトに置くことです。バックアップの唯一のコピーをサイトと同じサーバーに保存しないでください。不正アクセスやディスク障害が発生した場合、サイトとバックアップが同時に失われます。これが、上記の自動化スクリプトがアーカイブをWebルートに残さず、オブジェクトストレージに転送する理由です。アーカイブにはwp-config.php内のシークレット情報を含むサイトの完全なコピーが含まれているため、転送先を強力な認証情報と、ストレージアカウントの二要素認証で保護してください。

リストアのテストと避けるべきミス

テストされていないバックアップはバックアップではありません。.sqlファイルとファイルアーカイブをステージング環境またはローカル環境に定期的にリストアし、コピーが実際にサイトを再構築できることを確認してください：

tar -xzf wp-content-2026-07-06.tar.gz
wp db import db-2026-07-06.sql          # WP-CLIを使わない場合：
mysql -u DB_USER -p DB_NAME < db-2026-07-06.sql

サイトが失われる原因の大部分を占める3つの失敗パターンがあります：データベースなしでファイルをバックアップすること、バックアップをサイトと同じサーバーに保存すること、そしてホストの自動バックアップだけを信頼することです。いずれも、上記のワークフローで回避できます。

信頼性の高いパターンはシンプルで地味なものです。データベースを整合性のある形でダンプし、ファイルをアーカイブし、両方をオフサイトに転送するcronジョブ、そして実際にテストするリストアです。スクリプトを一度書いてオブジェクトストレージに向け、crontabの行を追加し、今週中にテストリストアを実行してください。それが、うまくいっていることを願うバックアップではなく、自分でコントロールするバックアップです。

よくある質問

`wp db export`と`mysqldump`を直接実行することの違いは何ですか？

`wp db export`は`mysqldump`の薄いラッパーです。`wp-config.php`にすでに保存されている`DB_HOST`、`DB_NAME`、`DB_USER`、`DB_PASSWORD`の認証情報を使って`mysqldump`ユーティリティを実行するため、接続情報を調べたり渡したりする必要がなく、有効な`mysqldump`フラグをすべて受け付けます。また、デフォルトで`--no-tablespaces`を追加するため、マネージドホストでよく発生するPROCESS権限エラーを回避できます。生の`mysqldump`も同じダンプを生成しますが、認証情報とフラグを自分で指定する必要があります。

マネージドホストで`mysqldump`がPROCESS権限エラーをスローするのはなぜですか？修正方法は？

マネージドホストやcPanelホストでは、`mysqldump`がテーブルスペース情報のダンプを試みます。これにはPROCESS権限が必要ですが、共有データベースユーザーには通常この権限がないため、「Access denied; you need the PROCESS privilege」というエラーが発生します。`--no-tablespaces`フラグを追加してそのステップをスキップすると、ダンプは正常に完了します。WP-CLIの`wp db export`は自動的に`--no-tablespaces`を追加します。多くの場合、エラーが発生してもエクスポート自体は成功するため、テーブルが存在することを確認してダンプを検証してください。

WordPressコアやプラグインは再ダウンロードできるので、ファイルのバックアップはスキップできますか？

アーカイブする内容を減らすことはできますが、ファイルを完全にスキップしてはいけません。WordPressコア、テーマ、プラグインはそれぞれのソースから再ダウンロードできるため、一部のバックアップツールはデータベースと`uploads`フォルダのみを保存します。ただし、`uploads`フォルダには再ダウンロードできないすべてのメディアが含まれており、`wp-config.php`にはデータベース認証情報とキーが保存されており、カスタムファイルや変更されたファイルは代替が効きません。`wp-content`と`wp-config.php`をバックアップすることで、サイト固有の本当に重要な部分を取得できます。

`mysqldump`とtarバックアップからWordPressサイトをリストアするにはどうすればよいですか？

`tar -xzf archive.tar.gz`でファイルアーカイブをサイトディレクトリに展開し、次にデータベースをインポートします。WP-CLIを使用する場合は`wp db import db.sql`を実行します。このコマンドは`wp-config.php`から認証情報を読み取ります。WP-CLIを使用しない場合は、既存のデータベースに対して`mysql -u DB_USER -p DB_NAME < db.sql`を実行します。両方の要素を同時にリストアし、ドメインが変更された場合はデータベースに対して検索・置換を実行して保存されているURLを更新してください。本番環境で信頼する前に、必ずステージング環境またはローカル環境でリストアをテストしてください。

`mysqldump`は引き続き安全に使用できますか？`mysqlpump`に切り替えるべきですか？

`mysqlpump`ではなく`mysqldump`を使用してください。`mysqlpump`ユーティリティはMySQL 8.0.34で非推奨となり、MySQL 8.4で完全に削除されたため、これを呼び出すスクリプトは現在のサーバーでは失敗します。`mysqldump`は引き続きサポートされており、MySQLはその代替として`mysqldump`またはMySQL Shellのダンプユーティリティを推奨しています。稼働中のInnoDBサイトの整合性のあるスナップショットを取得するには、`--single-transaction`フラグを付けて`mysqldump`を実行してください。このフラグにより、ダンプ中にテーブルをロックせずに済みます。