結論
WordPress のバックアップは、データベースとファイルの2つを、更新の前と定期的に取るのが基本です。公式の解説は、データベースを定期的に、そして更新の前には必ずバックアップするよう書いています。
取ったバックアップは、本当に戻せるかを一度試すところまでが1セットです。ただし、復元はサイトの内容を上書きする作業なので、本番ではなくローカル環境やテスト用のサイトで試します。
原因・仕組み(何を取るか)
WordPress のデータは、2か所に分かれて保存されています。公式の解説は、データベースは別のデータベースシステム(通常は MySQL/MariaDB)に保存されるため、WordPress のフォルダをダウンロードするだけでは足りないと注意しています。
| 対象 | 中身 | 取り方の例 |
|---|---|---|
| データベース | 投稿・固定ページ・コメント・設定など | サーバーの管理画面や phpMyAdmin で .sql に書き出す、WP-CLI の wp db export |
wp-content フォルダ |
テーマ・プラグイン・アップロード画像 | SFTP でダウンロード、サーバーのバックアップ機能 |
wp-config.php |
データベースの接続情報などの設定 | SFTP でダウンロード(中身は他人に見せない) |
.htaccess |
パーマリンクや転送の設定(Apache の場合) | SFTP でダウンロード(隠しファイルの表示を有効にする) |
WordPress 本体のファイルは公式からいつでも入手できますが、同じバージョンを用意する手間を省くため、まとめて取っておくと復元が速くなります。
具体例(頻度と保管の目安)
公式の解説は、更新の少ない小さなサイトは週1回、更新の多いサイトは毎日を目安としています。サーバーに自動バックアップがあるなら、普段はそれに任せ、手作業のバックアップは更新の前と月1回の点検のときに取る、という分担が続けやすいと考えます(無いときは手作業を週1回)。また、直近のバックアップを3〜5個は残し、サーバー上、クラウドストレージ、手元のパソコンのように、別々の場所に置くよう勧めています。
たとえば週1回のバックアップを5世代残す場合、最も古いもので約1か月前(7日 × 4回 = 28日前)まで戻れます。気づくのが遅れやすい改ざんやデータの消失に備えるには、この「どこまで戻れるか」で世代数を決めます。
手順(バックアップと復元の順番)
公式の解説は、取るときと戻すときの順番を次のように示しています。
- 取るとき: データベース → ファイルの順に取る。
- 戻すとき: ファイル → データベースの順に戻す。
- 接続情報が変わったら: 移転などでデータベースの名前やユーザーが変わった場合は、
wp-config.phpを書き換える。
プラグインを使わずに取る方法の例です。
- データベース: 先に
wp-config.phpのDB_NAMEの行で WordPress のデータベース名を確かめ、サーバーの管理画面から phpMyAdmin などのデータベース管理ツールを開き、その名前のデータベースを選んで「エクスポート」→「簡易」→「実行」。公式の解説にある手順で、.sqlファイルがダウンロードされます。 - ファイル: SFTP で接続し、
wp-content、wp-config.php、.htaccessをダウンロードします(点で始まるファイルは、転送ソフトで隠しファイルの表示を有効にする)。
復元テストのやり方の例です。
- ローカル環境を用意する(WordPressのローカル環境の作り方|4つの方式の違いと選び方)。Local を使う場合は、
wp-contentフォルダと.sqlファイルを1つの ZIP にまとめ、Local の画面にドラッグ&ドロップすると取り込めます(Local の公式ドキュメント)。 - ほかのツールでは、空の WordPress の
wp-contentを置き換え、データベースを取り込む。
ローカル環境を使わない人は、少なくとも .sql ファイルをエディタで開いて CREATE TABLE や自分の記事のタイトルが入っているか、wp-content/uploads に画像があるかを確かめ、サーバーの復元機能の申し込み方と何日前に戻せるかをメモしておきます。
3. URL が本番と違う場合は、専用の置換手段で URL を書き換える。データベース全体の単純な文字列置換は、シリアライズされたデータを壊すおそれがあると公式の移転ガイドが警告しています。
4. 記事・画像・設定が戻っているか確認する。
WordPressのバックアップと復元の基本の注意点
- バックアップの置き場所: サーバーの中だけに置くと、サーバーの障害や乗っ取りで一緒に失います。少なくとも1つは別の場所に置きます。
- 中身の扱い:
wp-config.phpやデータベースには、接続情報や利用者のメールアドレスなどが入っています。公開フォルダに置きっぱなしにしない、共有しない、を守ります。 - 完全性の確認: 公式の Hardening ガイドは、バックアップの完全性を確認する手段(ハッシュ値の比較)にも触れています。少なくとも、ファイルが開けるか、容量が極端に小さくないかは確認します。
WordPressのバックアップと復元の基本でよくあるミス
- ファイルだけ取って、データベースを取っていない(記事が戻らない)。
- サーバーの自動バックアップに頼り切り、保存期間や復元の手順・費用を知らない。
.htaccessが隠しファイルで表示されず、取り忘れる。- 一度も復元を試しておらず、いざというときに戻し方が分からない。
WordPressのバックアップと復元の基本のチェックリスト
- [ ] データベースとファイル(
wp-content・wp-config.php・.htaccess)を取った - [ ] 頻度(週1回または毎日)を決めた
- [ ] 3〜5世代を、別々の場所に残している
- [ ] 更新の前に必ず取る習慣にした
- [ ] ローカル環境で一度、復元を試した
WordPressのバックアップと復元の基本のFAQ(よくある質問)
Q. バックアップ用のプラグインを使ってもよいですか?
A. 使えます。公式の解説にも、定期的に自動でバックアップを取るプラグインがあると書かれています。ただし、保存先がサーバー内だけにならないよう設定し、復元の手順も確認します。
Q. どのくらいの容量が必要ですか?
A. サイトの画像の量で大きく変わります。サイトヘルスの「情報」タブの「ディレクトリとサイズ」で、アップロードフォルダやデータベースの大きさを確認できます。
Q. 更新の前のバックアップは、毎回フルで取るべきですか?
A. 本体やプラグインの更新前は、少なくともデータベースと wp-content を取ります。公式の更新手順も、作業前にバックアップを取り、使えることを確かめるよう書いています。
筆者の見解(WordPressのバックアップと復元の基本)
バックアップは、取ることより「戻せること」に価値があると考えます。取ったつもりでも、データベースが空だったり、古い世代しか残っていなかったりする事故は、戻そうとして初めて気づくものです。サイトを作った直後の、まだ失うものが少ない時期に一度だけ復元を練習しておくと、その後の更新や改造に落ち着いて取り組めると私は思います。
WordPressのバックアップと復元の基本の関連項目
- WordPressの更新のしかた|本体・プラグイン・テーマと自動更新
- WordPressのセキュリティ対策の基本|公式Hardeningガイドの要点
- WordPressのローカル環境の作り方|4つの方式の違いと選び方
- WP-CLIでできること:検索置換・DB書き出し・キャッシュ削除をコマンド1行で(準備中)
- 「サイトに重大なエラーが発生しました」が出たときの切り分け手順
出典(一次情報)
- WordPress Backups(Advanced Administration Handbook)
- Hardening WordPress(Advanced Administration Handbook)
- Updating WordPress(Advanced Administration Handbook)
- Moving WordPress(Advanced Administration Handbook)
- Backing Up Your Database(Advanced Administration Handbook)
- How to import a WordPress site into Local(Local Help Docs)
