WordPressのバックアップと復元手順|UpdraftPlusで自動化する方法

公開

/ 最終更新

WordPressのバックアップと復元手順|UpdraftPlusで自動化する方法

WordPressサイトは、プラグインの更新ミス、テーマの編集ミス、不正アクセス、サーバー障害など、ある日突然壊れる可能性と常に隣り合わせです。そのすべてに対する唯一の保険がバックアップです。

この記事では、定番プラグインUpdraftPlusを使った自動バックアップの設定と、いざという時の復元手順を解説します。当サイトでも同じ構成を採用しています。

バックアップすべきは「ファイル+データベース」

WordPressサイトはテーマ・プラグイン・画像などのファイルと、記事・設定が入ったデータベースの2種類で構成される図解
記事はデータベース側に入っています。画像だけ守っても記事は戻りません

WordPressは、テーマ・プラグイン・画像などのファイルと、記事・設定が保存されたデータベースの2つで構成されています。復元には両方が必要です。この前提を知っておくと、バックアップツールの設定項目の意味がすっと理解できます。

3層で守るのが理想

  1. サーバーの自動バックアップ:多くのレンタルサーバーが標準提供(選び方は別記事参照)。ただし復元条件は各社異なる
  2. プラグインによる自動バックアップ:この記事の本題。自分で管理でき、外部クラウドに逃がせる
  3. 大きな変更前の手動バックアップ:テーマ変更・大型更新の直前に1クリック

サーバー側とプラグイン側の二重化により、「サーバー側の障害でバックアップごと失う」最悪のシナリオを避けられます。これはバックアップの3-2-1ルールの応用です。

UpdraftPlusで自動化する(所要15分)

UpdraftPlusの自動バックアップ設定手順。設定画面を開き、スケジュールを決め、クラウド保存先を連携し、初回実行する4ステップ
設定は4ステップ。無料版で十分実用になります

ステップ1:設定画面を開く

「プラグイン」からUpdraftPlusをインストール・有効化し(未導入の場合)、「設定」→「UpdraftPlus バックアップ」を開きます。

ステップ2:スケジュールを決める

「設定」タブで、ファイルは週1回・データベースは毎日、保存世代数は各4〜7が個人サイトの目安です。記事の更新頻度が高いほどデータベースの頻度を上げます。

ステップ3:保存先をクラウドにする

保存先でGoogle DriveやDropboxなどの外部クラウドを選び、認証します。サーバー内保存のままでは、サーバー障害時に共倒れになるため、ここが最重要ポイントです。

ステップ4:初回バックアップと動作確認

「今すぐバックアップ」を実行し、完了後にクラウド側へファイルが5点(plugins/themes/uploads/others/db)保存されていることを確認します。

復元手順

  1. 管理画面に入れる場合:UpdraftPlusの「バックアップ/復元」タブ→対象日時の「復元」→戻したい要素(全部でも一部でも可)を選択して実行
  2. 管理画面に入れない場合:サーバーの自動バックアップから復元するか、新しいWordPressにUpdraftPlusを入れてクラウドと再連携し、バックアップを読み込んで復元
  3. 復元後:サイトの表示・ログイン・最新記事の有無を確認

年に1〜2回は「復元テスト」を。戻せることを確認して初めて、バックアップは保険として機能します。

運用のコツと注意点

  • プラグイン・テーマの一括更新の前には手動バックアップを1回挟む
  • クラウドの容量を定期確認(古い世代の自動削除を有効に)
  • バックアップファイルには機密情報が含まれるため、保存先クラウドのアカウントは2段階認証で保護する

よくある質問

Q. 無料版のUpdraftPlusで十分ですか?

A. 個人サイトなら十分です。有料版は移行機能や暗号化、複数サイト管理などが追加されますが、バックアップと復元の基本機能は無料版に含まれています。

Q. バックアップのデータ量はどのくらいになりますか?

A. 画像の量に依存します。テキスト中心のサイトなら数百MB程度が一般的で、Google Driveの無料枠(15GB)で複数世代を保存できます。

Q. サーバーのバックアップがあればプラグインは不要では?

A. サーバー側は「復元が有料」「保持期間が短い」などの制約がある場合があります。条件を確認したうえで、無料でできる二重化はしておく価値があります。

サーバーの自動バックアップだけでは、足りない理由

多くのレンタルサーバーは自動バックアップを標準で持っています。それがあるならプラグインは不要では、と考えたくなりますが、実際に困るのは次の場面です。

サーバーの自動バックアッププラグインでのバックアップ
保存先同じサーバー会社の中外部クラウド(Google Drive、Dropbox等)を選べる
アカウント停止・支払い忘れバックアップごと使えなくなる手元に残る
保持期間7日〜14日程度が多い自分で決められる
復元の粒度まるごと。テーブル単位・ファイル単位が選べない場合があるファイルのみ/DBのみ、といった選択ができる
復元の手数料有料の会社がある無料
他社サーバーへの移行使えないことが多いそのまま移行に使える

とくに保持期間が落とし穴です。改ざんに気づくのが2週間後だった場合、サーバー側のバックアップはすでに「改ざん後の状態」で上書きされています。この事態を避けるために、月次の世代を1つ、外部に長く残しておく運用が効きます。

3層構成の考え方。①サーバーの自動バックアップ(直近数日、手軽に戻せる)②プラグインの外部クラウド保存(週次、会社に依存しない)③大きな変更の前に取る手動バックアップ(更新前・テーマ変更前)。この3つは目的が違うので、どれか1つで代替はできません。

復元テストを、本番を壊さずにやる

バックアップは「取れている」ではなく「戻せる」を確認して初めて完成します。ただし本番サイトで試すわけにはいきません。安全に試す方法が3つあります。

方法難易度やり方
サーバーのステージング機能多くのレンタルサーバーが提供。本番の複製を作り、そこで復元を試す
サブドメインに別インストールtest.example.com のような場所に空のWordPressを入れ、そこへ復元する
ローカル環境PC上にWordPress環境を作るツールを使い、手元で復元する

テストで見るのは3点だけです。①トップページが表示されるか ②管理画面にログインできるか ③画像が表示されるか。3番目は見落とされがちで、データベースだけ戻して画像ファイルを戻し忘れると、記事は残っているのに画像が全て消えた状態になります。

テスト用のサイトは、検索エンジンにインデックスされないよう「検索エンジンでの表示を許可しない」設定を必ず入れてください。本番と同じ内容のサイトが2つ公開されると、重複コンテンツとして扱われます。テストが終わったら削除します。

バックアップの容量が膨らんだときの整理

運用を続けると、バックアップの保存先が容量不足になります。闇雲に世代を減らすのではなく、中身を見て減らします。

対象判断理由
uploads(画像)毎回含めなくてよい過去の画像は変化しない。月1回だけ含め、週次はDBとテーマだけにする
キャッシュフォルダ除外する再生成されるため、バックアップする意味がない。容量だけ食う
プラグイン本体除外してもよい公式ディレクトリから再取得できる。ただし有料・カスタム品は必ず含める
WordPress本体除外してもよい公式サイトから同じバージョンを入手できる
データベース絶対に含める記事、設定、コメント。ここだけは復元できない
wp-content/themes(自作・子テーマ)絶対に含めるカスタマイズしたコードは他から入手できない

優先度をひとことで言えば、「他から手に入らないもの」だけを確実に守るということです。データベースと自作テーマ、そして画像。この3つが揃っていれば、他は再構築できます。

復元がうまくいかない、典型パターン

いざ復元しようとして詰まるのは、だいたい次の5つです。原因を知っていれば、慌てずに済みます。

症状原因対処
復元の途中でタイムアウトするサーバーの実行時間制限ファイルとデータベースを分けて復元する。サーバー側で実行時間の上限を上げる
「メモリが足りません」と出るPHPのメモリ上限wp-config.php でメモリ上限を引き上げる。またはサーバー管理画面から変更
復元後、画像のリンクが全て切れるURLが変わっている(http→https、ドメイン変更など)データベース内のURLを一括置換するツールを使う。手作業では直しきれない
白い画面になる(真っ白)PHPバージョンの違い、プラグインの非互換PHPバージョンを元の環境に合わせる。全プラグインを一旦無効化してから1つずつ有効化
管理画面にログインできないセッションやcookieの不整合ブラウザのcookieを削除。それでも駄目ならデータベース上でパスワードを再設定

これらはすべて、事前のテストで一度経験しておけば怖くありません。逆に、本番が壊れた状態で初めて遭遇すると、判断を誤りやすくなります。年に1回のテストをおすすめするのは、この理由からです。

バックアップは、そのまま「引っ越し」に使える

サーバーを移転するとき、バックアップの仕組みがあればそれが移行手段になります。手順の要点だけ挙げます。

順番やること注意点
1移転の2〜3日前に、DNSのTTLを300秒に下げるこれをしないと、切り替え後に最大24時間、旧サーバーを見る人が残る
2新サーバーに同じPHPバージョンの環境を用意するバージョン差はトラブルの元
3バックアップを新サーバーへ復元し、hostsファイルで表示確認DNSを切り替える前に、新サーバー側の表示を確認できる
4問題なければDNSを切り替えるこの時点で初めて訪問者が新サーバーへ向かう
5旧サーバーを1週間は残す古いDNS情報を持つ人が残っているため
6TTLを元に戻す短いままだと問い合わせが増え続ける

3番の「hostsファイルで先に確認する」が、失敗しない移転の鍵です。自分のPCだけを新サーバーに向けて表示を確認できるため、訪問者に不完全なサイトを見せずに済みます。DNSの仕組みはDNSとはで詳しく解説しています。

まとめ

WordPressのバックアップは「サーバー標準+UpdraftPlus(外部クラウド保存)」の二重体制が鉄板です。設定は15分、費用はゼロ。次の記事更新の前に、まず自動バックアップを仕込んでおきましょう。セキュリティ対策全般はWordPressセキュリティの記事で解説しています。

この記事に関連する無料ツール

圧縮の匠(姉妹サイト)
画像・PDF・動画を、サーバーに送信せずブラウザ内だけで圧縮できます。登録不要・無料です。

この記事に出てくる用語

レンタルサーバー/バックアップ/プラグイン/クラウド/テーマ/ほか計117語をIT用語辞典で解説しています