wordpressバックアップ完全攻略：手動や自動や復元まで失敗ゼロの実践手順と頻度設計

WordPressは便利ですが、更新やプラグイン変更のたびに「表示が真っ白」「画像が消えた」などのトラブルは珍しくありません。人的ミスや改ざん、サーバー障害も現実的なリスクです。JPCERT/CCの公開資料でも改ざん被害は継続的に報告されており、備えは必須です。

本記事では、wp-contentとデータベースを中心に「何を・いつ・どうやって」守るかを、手動（FTP・phpMyAdmin）と自動（BackWPup/UpdraftPlus/サーバー機能）で具体的に解説します。大容量uploads対策や差分、世代管理、ロールバックの考え方も整理します。

運用歴の長いサイトほど停止コストが高くなります。だからこそ、変更前スナップショットと定期バックアップを軸に、復旧までの手順を事前に整えることが重要です。「失敗しないバックアップ設計」と「確実に戻せる復元フロー」を、このページで一緒に固めましょう。

wordpressバックアップの基本：必要性と失敗しない考え方

データ消失の原因と影響を把握する（改ざん・障害・人的ミス）

WordPressのデータ消失は、人的ミス、クラッキング、サーバー障害、ソフト更新起因の不具合など複合要因で発生します。具体例として、不要ファイル削除でwp-contentごと消去、管理画面で固定ページ一括削除、脆弱なプラグイン経由の改ざん、DDoS後のストレージ破損、ホスティング側のディスク障害などが挙げられます。備える範囲は「ファイル一式」と「データベース」の二軸です。両方を同一世代で取得し、外部に複製を持つことが基本です。2025/09/04時点でも攻撃は継続的で、改ざん検知前に上書きされる事例が多く、世代管理とオフサイト保存が有効です。

• ファイル: wp-content(uploads,plugins,themes)とコア差分を取得

• DB: プレフィックスごとにフルエクスポート

• 保存先: ローカル+クラウド+サーバー外部の多重化

• 頻度: 更新頻度と重要度で日次/週次/直前実行を使い分け

バージョンアップ前後に多い不具合の実例

更新直後の不具合は、プラグイン衝突、テーマ更新不整合、PHPバージョン変更の互換性欠如に集中します。典型例は、jQuery依存の古いプラグインがJSエラーでフロントが真っ白、テーマの子テーマ未対応でテンプレート階層が崩れる、PHP8系移行で未定義関数やDeprecatedがFatal化する、といった症状です。編集画面が開かず管理操作ができないケースも多く、復元可能なバックアップが唯一の即時回避策になります。更新は必ずステージングやローカルで事前検証し、同一環境のバックアップを直前取得します。特にメジャーアップデートは、コア+プラグイン+テーマの整合性をセットで確認します。

• 衝突兆候: コンソールエラー、500/502、プラグイン読み込み順の競合

• テーマ起因: テンプレートタグ変更、フック名変更

• PHP起因: strict化でエラー顕在化、拡張モジュール非導入

影響範囲の見積りと許容停止時間の考え方

影響範囲は「コンテンツ更新の直近差分」「メディア点数」「フォーム/ECなどトランザクション有無」で見積もります。許容停止時間は、1時間以内、半日以内、1日以上のいずれかで運用要件を定義し、これに応じて世代数と頻度を決めます。例えば、ECや予約サイトはRPOを低く設定し、投稿や受注発生前後で差分を最小化する必要があります。復旧目標時間を短縮するため、バックアップは自動化し、保存先は復元経路が短いものを優先します。復元テストを定期的に実施し、手順の属人化を排し、暗号化・整合性検証を含めた運用ドキュメントを最新化します。2025/09/04現在の環境変化（PHP更新、プラグイン更新頻度増）を踏まえ、計画を年次見直しします。

• 目標: RPO(許容データ損失)とRTO(復旧時間)を具体化

• 周期: 変更頻度に応じた日次/時間単位のスケジュール

• 経路: ローカル+クラウドで冗長化、復元手順の通し稼働確認

何をバックアップすべきか：ファイルとデータベースの範囲

WordPress丸ごとバックアップの対象（wp-contentとデータベース）

WordPressのバックアップは、ファイル一式とデータベースの両方が対象です。特にwp-content配下のthemes、plugins、uploadsは変更頻度が高く、必須で取得します。設定を保持するwp-config.phpも重要です。データベースは投稿・固定ページ・設定を含む全テーブルが対象で、接頭辞が一致するテーブル群をまとめて取得します。2025/09/04時点でも、サイト移行や復元時はファイルとMySQL全テーブルの整合が必要です。片方のみでは完全復旧が困難になるため、同一タイミングでの取得を心掛けます。

• 取得対象を明確化し、対象外の一時ファイルを除外します。

• 同期ズレ防止のためメンテナンス時間帯に実施します。

• 保存先はローカルとクラウドの二重化が有効です。

wordpress データベース バックアップ（phpMyAdminエクスポートの要点）

phpMyAdminでのエクスポートは、対象データベース選択後に「エクスポート方式」と「出力形式」を適切に設定します。一般的にはクイック+SQLで十分ですが、大容量ではカスタムを選び、テーブル選択、DROP TABLE文追加、エンコーディング確認を行います。圧縮はgzipやzipを選ぶと転送が安定します。部分エクスポートを行う場合は、オプションテーブルの除外に留め、投稿やメタ、タクソノミー関連は一貫して含めて整合性を保ちます。2025/09/04現在、UTF-8と照合順序の不一致は復元エラーの原因になるため、サーバー側設定と一致させます。

• 大容量時はINSERT方式で「拡張INSERT」を有効化します。

• 旧環境へ復元時はSQLモードとタイムゾーンに注意します。

• 文字セットはutf8mb4を選択します。

メディア容量対策と差分の考え方

uploadsは画像や動画で肥大化しやすく、バックアップの所要時間と失敗率に影響します。初回はフルで取得し、以後は新規アップロード分のみを転送する差分や増分方針を検討します。年/月ディレクトリ構成を活用し、古い年月フォルダを定期アーカイブすることで日次のバックアップ対象を縮小できます。不要な自動生成サムネイルの削減、画像最適化、未使用メディアの整理は有効です。2025/09/04の時点でも、頻度の高いメディア更新サイトではクラウド保存やCDNを併用し、転送量と保存コストを抑える構成が推奨されます。

• 大容量ファイルは別ストレージにオフロードします。

• 例外ルールでcacheやtmp相当を除外します。

• 世代管理は短期と長期で保持期間を分けます。

バックアップのタイミングと頻度：更新前と定期実行

更新・カスタマイズ前に必ず取得（本体・プラグイン・テーマ）

WordPress本体やプラグイン、テーマの更新、コード編集、ウィジェット調整、デザイン変更などの前には、必ずフルバックアップを取得します。対象はデータベース、wp-content配下（themes/plugins/uploads）、wp-config.phpなどの設定ファイルです。取得直前のスナップショットを残し、問題発生時に即時ロールバックできる体制を前提に運用します。2025/09/04時点でも更新による不具合は一定数報告されており、事前バックアップは最小コストのリスク対策です。テスト環境での動作確認と組み合わせると安全性が高まります。

• 変更前スナップショットの徹底とロールバック前提の運用

• 対象

  • データベース全体（phpMyAdminやプラグインでエクスポート）
  • wp-content配下一式（テーマ・プラグイン・メディア）
  • 必要に応じてwp-config.phpや.htaccess

• 推奨手順

  • メンテナンス表示→バックアップ→更新→動作確認→問題時ロールバック

定期バックアップの設計（毎日・毎週・毎月）

定期バックアップは更新頻度とサイト規模を基準に設計します。記事投稿やフォーム受信が多いサイトはデータベースを毎日、ファイルを毎週が目安です。静的に近いサイトは週1回でも十分ですが、重要な変更は都度バックアップします。世代管理は少なくとも7日分、4週分、3カ月分を保持し、保存先は異なる場所へ分散します。障害、誤操作、マルウェアに備え、取得と復元テストをセットで運用することが信頼性を高めます。

• 変更頻度やサイト規模に応じたスケジュールと世代管理

• 推奨スケジュール例

  • 高頻度更新: DB毎日/ファイル毎週
  • 中頻度更新: DB週2/ファイル隔週
  • 低頻度更新: DB週1/ファイル月1

• 保存先分散

  • クラウド1系統＋外部FTP/NAS＋ローカル暗号化保管

• 復元演習

  • 月次でテスト復元を実施し、手順と所要時間を記録

バックアップ頻度別の保持推奨目安

手動でのWordPressバックアップ：FTPとphpMyAdmin

FTPでファイルを取得する手順と注意点

WordPressの手動バックアップでは、FTPでサイトのファイル一式を取得します。手順は、1.FTPでサーバーへ接続、2.ドキュメントルート直下のファイルとwp-content全体をダウンロード、3.転送モードをバイナリ/自動に設定、4.パーミッションとタイムスタンプの保持を有効化、が基本です。不要なキャッシュ系ディレクトリは除外し、必要ディレクトリを選別します。転送前にサーバー側でzip圧縮できる場合は圧縮し、通信途切れ対策として再開機能を有効化します。取得後はハッシュで整合性確認を行い、2025/09/04時点の環境名と取得日時をファイル名に付与して保存します。

• 必要ディレクトリの選別、権限・タイムスタンプ保持、圧縮の活用

• テーマ改変点の保存と大容量メディアの分割ダウンロード

wordpress テーマ バックアップとuploadsの扱い

テーマを子テーマ構成で運用している場合は、子テーマのfunctions.phpや独自テンプレート、カスタマイザー設定のエクスポートデータを優先して保存します。親テーマは配布元から再取得可能なことが多く、差分を明確に保管することが効率的です。uploadsは年/月単位で大容量になりがちです。FTPクライアントのキュー機能で年別に分割ダウンロードし、失敗時は該当フォルダのみ再取得します。重複を避けるため、ローカル側でフォルダごとにハッシュチェックを行い、破損ファイルの再転送を徹底します。ライセンスキー等を含む設定ファイルは暗号化保管します。

• テーマ改変点の保存と大容量メディアの分割ダウンロード

phpMyAdminでデータベースをエクスポートする

データベースはphpMyAdminでエクスポートします。手順は、1.対象DBを選択、2.テーブルの全選択または必要テーブルのみ選択、3.エクスポートで詳細設定を開き、4.SQL形式で「DROP TABLEを追加」「完全な挿入」「ロックしない」を選び、5.文字コードをutf8mb4に設定、6.gzip圧縮を有効化、です。巨大テーブルがある場合はテーブル単位で分割し、タイムアウトを回避します。取得後はSQLの先頭数行でDB名と照合順序を確認し、ローカルでインポートテストを行い復元可否を検証します。ファイル名に取得日時（例:2025-09-04）を含め、保存先を重複しないよう分散します。

• テーブル選択、エクスポート方式、文字コードと圧縮設定

プラグインで自動化：BackWPupの使い方と保存先

backwpup 使い方（ジョブ作成・スケジュール・圧縮）

BackWPupはWordPressのファイルとデータベースを自動で取得し、指定の保存先へ転送します。基本手順は、プラグインを有効化後、ジョブを新規作成し、バックアップ対象（DB、ファイル、プラグイン一覧）と圧縮形式を選択、保存先とスケジュールを設定します。圧縮は汎用性の高いZIPが無難です。スケジュールはWordPressのWP-Cronかサーバーのcronを選べます。2025/09/04時点で高頻度更新のサイトは差分ではなくフルの周期最適化が重要です。

• サイト規模別の設定例と検証手順を提示

小規模(〜1GB): 週2回フル、日次DB、ZIP、保存先はクラウド+ローカル。中規模(1〜10GB): 週1フル、日次DB、ファイルは除外ルール活用。大規模(10GB超): 月1フル、日次DB、アップロードは年別/月別で分割。検証はテスト環境で実復元を行い、DBインポートとwp-content差し替えで起動確認、ログの警告有無とアーカイブ整合性を確認します。

• サイト規模別の設定例と検証手順を提示

backwpup 保存 先の選び方（ローカル・クラウド・外部サーバー）

保存先は冗長化を前提に複数化します。ローカルは即時アクセス性に優れますがサーバー障害と同時消失の恐れがあるため、必ずクラウドや外部サーバーと併用します。クラウドは可用性が高く、ライフサイクルで世代管理を自動化できます。外部FTP/SFTPは転送制御が柔軟で地理的分散に有効です。2025/09/04時点では暗号化と通信保護を標準化し、鍵管理を分離する運用が推奨です。

• 冗長化、暗号化、転送エラー対策と保管ポリシー

冗長化は最低2拠点(ローカル+クラウド、またはクラウド+外部SFTP)を確保します。暗号化はアーカイブ自体のパスワード保護や保存先のサーバー側暗号化を併用し、鍵は管理者のみが保持します。転送エラー対策はSFTP/HTTPS利用、リトライ回数増、分割圧縮で再送コストを軽減します。保管ポリシーは日次7世代、週次4世代、月次6世代などを目安にし、容量監視と自動削除を設定します。

• 冗長化、暗号化、転送エラー対策と保管ポリシー

backwpup バックアップ できない時の対処

バックアップが失敗する場合はログを確認し、ボトルネックを特定します。タイムアウトはジョブの実行時間やHTTPタイムアウトを延長し、WP-Cronで不安定な場合はサーバーcronを使用します。大容量は分割ボリュームを有効化し、圧縮レベルを下げて処理時間とメモリ負荷を軽減します。除外設定でcacheやバックアップ自身のフォルダを除外し、無駄なI/Oを削減します。

• タイムアウト・分割ボリューム・除外設定・メモリ制限の見直し

メモリ不足はPHPのmemory_limit、max_execution_time、upload_max_filesize、post_max_sizeを段階的に引き上げます。特に画像が多い場合はサムネイル生成済みディレクトリの一部を除外する選択も有効です。アーカイブ方式をZIPからTarGZへ変更すると安定するケースもあります。保存先の接続失敗は認証情報と権限、残容量、APIレートを確認し、リトライとバックオフを設定します。

• タイムアウト・分割ボリューム・除外設定・メモリ制限の見直し

UpdraftPlusとAll-in-One WP Migrationの活用

updraftplus backup restore 使い方の要点

UpdraftPlusはWordPressのバックアップを自動化し、外部保存先へ安全に退避できる定番プラグインです。初回は設定から保存先を選択し、ファイルとデータベースのスケジュールを日次や週次で分けて指定します。Google DriveやDropbox、S3、SFTPなど複数の保存先を併用すると冗長化できます。復元は「既存のバックアップ」から対象コンポーネントを選ぶ部分復元が便利です。復元前後で操作ログを確認し、権限エラーやタイムアウトの有無をチェックします。2025/09/04時点では高容量サイトは分割バックアップと遅延実行を併用し、サーバー負荷を抑える運用が有効です。

• スケジュール、外部保存先、部分復元とログ確認

updraftplus 移行の手順と注意点

UpdraftPlusで移行する際は、ソースで完全バックアップを取得し、移行先に同プラグインを導入してリモートからバックアップを読み込み復元します。ドメイン変更を伴う場合は、復元後にURL置換を実施し、画像リンクや内部リンク、シリアライズ値の破損がないか検証します。移行直前に検索エンジン向けのインデックス制御を確認し、意図せぬ重複公開を避けます。ステージング環境でテーマやプラグインの動作、問い合わせフォーム、決済など重要機能を点検し、パーマリンク再生成とキャッシュ削除を行います。SMTPや外部APIキーの環境差異にも注意します。

• ドメイン変更時のURL置換とステージング検証

All-in-One WP Migrationの特徴と制限

All-in-One WP Migrationはエクスポートとインポートを中心に、サイト丸ごと移行を簡潔に行えます。エクスポートではデータベースとメディア、テーマ、プラグインを1ファイルにまとめ、簡易URL置換も指定できます。インポートは作成ファイルをアップロードするだけで、上書き復元が可能です。一方で無料版は容量上限があり、大容量サイトでは分割や除外設定、有料拡張の検討が必要です。クラウド連携や自動バックアップは拡張で対応します。本番前にはアップロード上限、PHP実行時間、空きディスク容量を確認し、失敗時の復旧計画を用意します。

• エクスポート/インポート手順、容量制限、有料拡張の判断軸

サーバーの自動バックアップ機能：活用と併用設計

自動バックアップの強みと限界（保持期間・世代数・範囲）

サーバー提供の自動バックアップは、運営者の操作ミスや突発的な障害に即応できる点が強みです。多くのレンタルサーバーで日次スナップショットや世代管理が行われ、管理画面から数クリックで復元依頼やロールバックが可能です。一方で、保持期間や世代数、対象範囲が事業者ごとに固定で、細かな除外設定や任意の保存先指定は制限されがちです。

下記を把握し、手動やプラグインと併用設計にします。（2025/09/04時点）

手動/プラグインの役割は、任意のスケジュールや保存先追加、細粒度の復元点確保です。自動バックアップは最後の保険として位置づけ、世代切れ前に重要アーカイブを外部へ退避します。テスト復元で可用性を定期確認し、復旧手順を更新します。

さくら レンタル サーバー 自動 バックアップやmixhostの実務

さくらレンタルサーバーやmixhostでは、管理画面から日次バックアップの復元やバックアップデータのダウンロードが可能です。実務では、まず対象日のバックアップを選択し、テスト用環境に復元して動作確認後に本番へ適用します。直接本番へ上書きするより、段階的検証でリスクを低減できます。検証後はアーカイブをローカルへ保存し、二重化します。

ワークフローの要点（2025/09/04時点）

• 管理画面で対象日と範囲（ファイル/DB）を選択

• テスト復元用にステージングやサブディレクトリを用意

• 動作確認後に本番へ反映（差分デプロイが理想）

• ダウンロードしたバックアップをローカルとクラウドへ二重保存

• 復旧後はプラグインの再認証やキャッシュ再生成を実施

併用設計として、サーバー自動バックアップを基軸に、プラグインで中間世代を細かく取得し、週次でローカル保管へエクスポートします。月次でリストアテストを行い、復旧手順書を更新すると復元成功率が高まります。

復元の確実化：プラグイン・手動・サーバー機能の手順

backwpup 復元と手順の整理

BackWPupで取得したバックアップからの復元は、手順の順序を守ることで確実性が高まります。まず、Webサーバーへバックアップアーカイブを配置し、解凍してファイル一式を展開します。次に、phpMyAdminなどを使い、バックアップSQLを対象データベースへインポートします。最後に、wp-config.phpのDB名・ユーザー・パスワード・ホストを点検し、接続情報が現行サーバーと一致しているか確認します。2025/09/04時点では、権限不足やタイムアウトが失敗要因の上位です。復元後はログイン可否、固定リンク再設定、プラグインの動作確認まで行います。

• アーカイブ展開、DBインポート、wp-config.php確認の順序

プラグインなしの手動復元（FTPとphpMyAdmin）

手動復元は、FTPで既存ファイルをバックアップ後、wp-contentやコアファイルを必要に応じて上書きします。データベースはphpMyAdminでインポートし、同名テーブルがある場合は事前に削除またはドロップして衝突を回避します。シリアライズ値を含むオプションやウィジェットは、サイトURL不一致で破損します。URL変更を伴う場合は、シリアライズ対応の検索置換ツールでhomeとsiteurlを整合させます。復元後はキャッシュ削除、固定リンク再保存、テーマ子テーマの整合性とアップロード権限の確認を行います。

• ファイル上書き、シリアライズ値とサイトURLの整合性に注意

All-in-One WP Migration バックアップ 復元の流れ

All-in-One WP Migrationでの復元は、事前バックアップの保持、容量対策、失敗時の切り戻しが鍵です。まず、現行サイトをエクスポートで取得し安全な保存先へ退避します。次に、インポート時の容量制限に備え、拡張の導入やサーバー側のアップロード制限緩和、分割エクスポートで対処します。復元が失敗した場合は、プラグインを一時無効化して再試行し、それでも不可なら取得済みエクスポートへ切り戻します。2025/09/04時点の一般的な対処は、一時ディスク容量確保とPHP制限値の見直しです。

• 事前バックアップ、容量対策、失敗時の切り戻し手順

保存先と運用：ローカルとクラウドの併用で可用性を高める

wordpress バックアップ 保存先の最適化

オフサイト保管は障害や災害時の同時被害を避ける基本です。ローカルPCやNASに一次保存しつつ、クラウドへ自動転送して地理的に分散します。バージョニングは世代管理を明確化し、日次・週次・月次を組み合わせて保持期間を定義します。アクセス制御は最小権限を徹底し、管理者のみ復元操作権限を付与します。暗号化は保存時と転送時の双方で実施します。2025/09/04時点でもクラウドの地域選択と鍵管理の分離は有効な対策です。

• 保存先はローカル+クラウドの二重化が基本です。

• バージョニングで誤操作や改ざんにも対応します。

• 復元権限は限定し監査ログを確認します。

• 転送経路と保存先の暗号化を併用します。

• 地理的分散でエリア障害に備えます。

保存先比較

wordpress バックアップ ローカルと外部の使い分け

3系統冗長はローカル、別拠点、クラウドの三段構えで、同時障害を避けつつ復元時間を短縮します。世代削除ルールは日次7世代、週次4世代、月次12世代などの多層保持で、改ざんや潜伏型インシデントに備えます。コスト/容量はフルと差分/増分を組み合わせ、クラウドは低頻度階層へ自動移行し費用を最適化します。復元訓練は四半期ごとに実施し、実測の復元時間と手順の欠落を洗い出します。

• ローカルは直近復元、外部は広域障害対策に使い分けます。

• フルは週次、日次は差分/増分で転送量を抑えます。

• 自動削除で上限超過や費用膨張を防ぎます。

• 復元テストで実効性を確認します。

• 認証情報は保存先ごとに分離管理します。

使い分け早見