この記事が解決する状況
| あなたの状況 | 読むべきセクション |
|---|
| バックアップを取ったことがない | 何をバックアップするか |
| プラグインで自動バックアップしているが不安 | 復元テスト必須チェックリスト |
| 復元に失敗した経験がある | 復元失敗の地獄 |
| バックアップの頻度がわからない | バックアップ頻度の設計 |
バックアップは「取ること」より「戻せること」が重要。 復元できないバックアップは存在しないのと同じ。
復元失敗の地獄
実際にあった事故パターン。
事故1: DBはあるがファイルがない
状況: データベースは毎日バックアップ。いざ復元しようとしたら画像がない
原因: wp-content/uploads をバックアップ対象から外していた
結果: 3年分の画像が消失。再取得不可能なものも多数
事故2: バックアップはあるが復元できない
状況: UpdraftPlusで毎週バックアップ。サーバー障害で復元しようとしたら動かない
原因: 本番PHP8.0、復元先PHP7.4。互換性のないコードがあった
結果: PHPバージョンを合わせるまで2日ダウン
事故3: 「最新」のつもりが3ヶ月前
状況: 自動バックアップが動いているはず。復元したら古いデータ
原因: ディスク容量不足でバックアップが3ヶ月前から失敗していた
結果: 3ヶ月分の投稿と注文データが消失
事故4: バックアップごとサーバーと心中
状況: バックアップをサーバー内に保存。サーバーがクラッシュ
原因: 本体とバックアップが同じ場所
結果: 全データ消失。完全にゼロからやり直し
共通点：「取っているつもり」で、実際には復元できなかった。
何をバックアップするか
最低限必要なもの
| 対象 | 内容 | 場所 |
|---|
| wp-content | テーマ、プラグイン、アップロード画像 | /wp-content/ |
| データベース | 投稿、固定ページ、設定、ユーザー | MySQL |
| wp-config.php | DB接続情報、各種設定 | ルート直下 |
この3つがあれば復元できる。1つでも欠けると復元できない。
よくある見落とし
| 見落とし | 結果 |
|---|
| データベース未取得 | 投稿・設定がすべて消失 |
| wp-config.php未取得 | DB接続情報がわからず復元不可 |
| uploads以外のメディア | CDN上の画像が復元されない |
| プラグインの外部データ | S3に保存した画像が対象外 |
どこに保存するか
単一障害点を避ける
| 保存先 | リスク |
|---|
| サーバー内のみ | サーバー障害で本体もバックアップも消失 |
| ローカルPCのみ | PC故障で消失 |
| クラウドのみ | アカウント停止で消失 |
推奨: サーバー内 + クラウド（または物理的に別の場所）の二重保存。
保存先の組み合わせ例
| パターン | 構成 | コスト |
|---|
| 最小構成 | サーバー内 + Google Drive | 無料 |
| 推奨構成 | サーバー内 + Google Drive + ローカル | 無料 |
| 業務用 | サーバー内 + S3 + 別サーバー | 月500円〜 |
手動バックアップ
ファイル（SSH）
cd /path/to/wordpress
tar -czvf backup-files-$(date +%Y%m%d).tar.gz wp-content wp-config.php
データベース（mysqldump）
mysqldump -u ユーザー名 -p データベース名 > backup-db-$(date +%Y%m%d).sql
圧縮する場合:
mysqldump -u ユーザー名 -p データベース名 | gzip > backup-db-$(date +%Y%m%d).sql.gz
phpMyAdmin
- 対象データベースを選択
- 「エクスポート」タブ
- 形式: SQL、「実行」
プラグインでバックアップ
選定基準
| 要件 | 確認ポイント |
|---|
| ファイル + DB両方 | 片方だけでは不完全 |
| クラウド保存対応 | Google Drive、Dropbox、S3 |
| スケジュール設定 | 手動だと忘れる |
| 復元機能 | バックアップだけでなく復元も簡単か |
プラグイン比較
| プラグイン | 特徴 | 判断 |
|---|
| UpdraftPlus | 無料でクラウド保存・復元可能 | ✓ 推奨 |
| BackWPup | 高機能、ジョブ管理 | 設定が複雑でも良ければ |
| All-in-One WP Migration | サイト移行向け | 移行目的なら |
UpdraftPlusの落とし穴
| 落とし穴 | 対策 |
|---|
| 無料版は増分バックアップ不可 | 大規模サイトは有料版検討 |
| クラウド認証が切れる | 3ヶ月に1回は認証確認 |
| 復元時にタイムアウト | サーバーのPHP実行時間を延長 |
バックアップ頻度の設計
| サイト種別 | ファイル | データベース |
|---|
| 更新少ない企業サイト | 週1回 | 週1回 |
| ブログ（週数回更新） | 週1回 | 毎日 |
| ECサイト・会員サイト | 毎日 | 毎日または毎時 |
判断基準: 「何日分のデータを失っても許容できるか」
保持世代の設計
| 世代 | 保持期間 | 理由 |
|---|
| 日次 | 7日分 | 直近の問題に対応 |
| 週次 | 4週分 | 1週間以上前に発生した問題に対応 |
| 月次 | 3ヶ月分 | 長期的な問題に対応 |
「3世代だけ」は危険。 問題発覚が遅れた場合、全世代が汚染されている可能性がある。
復元テスト必須チェックリスト
年に1回は必ず復元テストを実施する。
テスト環境の準備
| 項目 | 確認 |
|---|
| PHPバージョン | 本番と同じか |
| MySQLバージョン | 本番と同じか |
| ディスク容量 | バックアップを展開できる空きがあるか |
復元テスト手順
- テスト用サーバー（またはローカル）を準備
- バックアップファイルをダウンロード
- ファイルを展開
- データベースをインポート
- wp-config.phpのDB情報を修正
- 動作確認
動作確認チェックリスト
| 確認項目 | 方法 |
|---|
| トップページ表示 | ブラウザでアクセス |
| 管理画面ログイン | /wp-admin/ |
| 投稿・固定ページ | 最新記事が存在するか |
| メディアライブラリ | 画像が表示されるか |
| プラグイン動作 | 主要機能が動くか |
| お問い合わせフォーム | テスト送信 |
テスト結果の記録
復元テスト実施日: 2025-10-29
テスト者: 田中
結果: OK / NG
所要時間: 45分
問題点: なし / （問題があれば記載）
次回テスト予定: 2026-01-29
自動化（cron）
#!/bin/bash
BACKUP_DIR="/path/to/backups"
DB_NAME="wordpress_db"
DB_USER="db_user"
DB_PASS="db_password"
DATE=$(date +%Y%m%d)
# バックアップ実行
mysqldump -u$DB_USER -p$DB_PASS $DB_NAME | gzip > $BACKUP_DIR/db-$DATE.sql.gz
# 7日以上前のファイルを削除
find $BACKUP_DIR -name "db-*.sql.gz" -mtime +7 -delete
cron登録:
0 3 * * * /path/to/backup-script.sh
毎日3時に実行、7日分保持。
やってはいけないこと
| NG | 理由 |
|---|
| サーバー内だけに保存 | サーバー障害で全滅 |
| 「自動でやってるから大丈夫」と放置 | 失敗に気づかない |
| 復元テストをしない | いざという時に動かない |
| パスワードをバックアップに含めない | wp-config.phpは必須 |
| 「昨日のバックアップ」だけ保持 | 問題発覚が遅れると全滅 |
トラブル対応
| 問題 | 原因 | 対処 |
|---|
| phpMyAdminでインポートできない | ファイルサイズ上限 | コマンドラインでインポート |
| 復元後に真っ白 | wp-config.phpのDB情報が違う | DB名・ユーザー・パスワードを確認 |
| 画像が表示されない | uploads未復元 | /wp-content/uploads/ を確認 |
| プラグインエラー | PHPバージョン違い | 復元先のPHPバージョンを確認 |
まとめ
- バックアップ対象: wp-content + データベース + wp-config.php
- 保存先: サーバー内 + クラウドの二重保存
- 頻度: 「何日分失っても許容できるか」で決める
- プラグインならUpdraftPlus
- 年に1回は必ず復元テストを実施
- 「取っているつもり」が一番危険
関連記事
