WordPressのバックアップがサイトのパフォーマンスに与える影響（およびその対処法）

昨年、サイトの動作が遅い原因を調査していたのですが、明らかな原因は見つかりませんでした。新しいプラグインの追加もなければ、トラフィックの急増もなく、エラーログにも特筆すべき点は見当たりませんでした。

それから、バックアップのスケジュールを確認しました。共有ホスティングアカウントで、毎日正午に実行されるように設定されていました。それだけの話でした。

多くのWordPressユーザーは、バックアッププラグインをインストールしてスケジュールを設定すると、その後は二度と触れることはありません。プラグインを有効にすれば、その作業は完了したと感じられる類のものだからです。

しかし、ほとんどのバックアッププラグインのデフォルト設定は、パフォーマンスを重視して最適化されているわけではありません。それらは、使いやすさを重視して最適化されているのです。

Dropboxに毎日フルバックアップを保存するのは、責任ある対応のように思えます。ホスティング環境が充実した小規模なサイトであれば、確かにそうでしょう。しかし、大規模なサイトや低価格の共有ホスティングでは、パフォーマンスへの継続的な負荷となり、バックアップが正常に実行されているかどうかも確認できなくなる可能性があります。

この記事では、バックアップの実行時に何が起こるのか、なぜ環境によってはサーバーへの負荷が他よりも大きくなるのか、そしてその負荷をほぼゼロにまで抑えるための具体的な対策について解説します。

以下はその要点である：

• バックアップには多くのリソースが必要です。ファイルの圧縮、データベースのエクスポート、クラウドへのアップロードは、CPU、ディスクI/O、帯域幅を同時に大量に消費します。
• 共有ホスティングの制限は、目に見えない障害を引き起こす可能性があります。低価格のホスティングサービスでは、PHPのタイムアウトやCPU・I/Oの割り当て制限が隠れており、長時間実行されるバックアップが途中で中断され、ファイルが破損したり不完全な状態になったりすることがよくあります。
• バックアップ形式は重要です。標準的なZIPアーカイブは一度に処理されるため、サーバーのタイムアウトが発生しやすいという大きな弱点があります。一方、Duplicatorの独自形式であるDupArchiveのようなチャンク形式であれば、こうした制約を完全に回避できます。
• 最適化は簡単です。利用の少ない時間帯にバックアップを実行し、キャッシュファイルを除外し、サーバーのcronを活用し、サイト全体のバックアップよりもデータベースのみのバックアップをより頻繁にスケジュールすることで、パフォーマンスへの影響をほぼ解消できます。

目次

バックアップが実行されると、サーバーでは何が起こるのでしょうか？

バックアップとは、単にファイルを別の場所にコピーすることではありません。これは、サーバー上で完全に実行される複数のステップからなるプロセスであり、訪問者にサイトを配信するために使用されるリソースと競合することになります。

バックアップの実行中は、サーバーが2つの処理を同時にこなしています。リソースがすでに数十もの他のサイトと共有されている共有ホスティング環境では、この点が重要になります。

ファイルの圧縮とCPU負荷

WordPressのインストールに含まれるすべてのファイルは、バックアップ中に読み込まれ、アーカイブに圧縮されます。この処理はCPUに大きな負荷をかけます。

共有ホスティングでは、アカウントごとにサーバーの処理能力の一部しか割り当てられていないため、数百メガバイトものファイルを圧縮するバックアップ処理を行うと、そのリソースを大幅に消費してしまいます。

サイトが大きくなるほど、この問題は深刻になります。ファイル数が増えると圧縮処理の範囲が広がるため、CPUへの負荷がかかる時間が長くなります。

メディアファイルが少ない小規模なブログなら、1分もかからずに圧縮できるかもしれません。一方、長年にわたって画像をアップロードしてきたサイトの場合、圧縮にかなり時間がかかることがあります。

メディアライブラリの容量を即座に半分に減らしたいですか？「WP Media Cleanup」で不要な画像バリエーションを削除しましょう！

データベースのエクスポートとテーブルのロック

データベースのエクスポートは、往々にして見落とされがちな要因です。多くのユーザーはバックアップといえばファイルのことを思い浮かべますが、WordPressでは投稿、設定、ユーザー情報など、あらゆるデータがMySQLデータベースに保存されており、これらをバックアップするには別途エクスポート作業が必要となります。

ほとんどのバックアッププラグインは、読み込むテーブルを一時的にロックする方式でデータベースをエクスポートします。テーブルがロックされている間、WordPressへのクエリは待機しなければなりません。

サーバーの処理が遅かったり負荷が高かったりする場合、テーブルのロックが数秒間続くだけでもタイムアウトが発生する可能性があります。

ディスクI/O：多くの人が見落としがちなボトルネック

バックアップのために何千ものファイルを読み込むと、ディスクへの負荷が大幅に増加します。サーバーのストレージには、1秒あたりに処理できる読み取りおよび書き込み操作の数に制限があり、WordPressのインストール全体を対象としたバックアップを実行すると、その制限に達してしまいます。

低価格プランや共有ホスティングでは、依然としてSSDではなく従来のハードドライブが使用されていることがよくあります。こうしたサーバーでは、バックアップ中のディスクアクセスが活発になると、ページ生成に関わるデータベースクエリやファイル読み取りなど、ストレージに関連するすべての処理が遅くなります。

クラウドへのアップロードと帯域幅

アーカイブの作成が完了しても、パフォーマンスへの影響はそこで終わりではありません。多くのバックアップ環境では、そのアーカイブをDropbox、Google Drive、あるいはS3といったクラウドストレージにアップロードします。このアップロード処理は、訪問者へのサービス提供に使用されているのと同じサーバー接続上で実行されます。

一般的な共有ホスティングのアップロード速度では、2GBのバックアップをDropboxにアップロードするのに数分かかります。その間、利用可能な帯域幅が他の用途と競合する可能性があります。

なぜ格安ホスティングのバックアップ性能は劣るのか？

格安ホスティングや共有ホスティングでは、サーバーレベルで制限が設けられていますが、その詳細がどこにも明記されていないため、多くのユーザーは気づくことがありません。

これらはバグや設定ミスではありません。同じサーバー上の他のすべてのサイトに影響を及ぼすようなリソースの過剰消費を防ぐために、意図的に設定された上限です。

問題は、これらの制限がバックアップ処理の妨げとなり、それによって引き起こされる障害が必ずしも明らかではないという点です。

PHPのタイムアウト

PHPには最大実行時間の設定があります。低価格の共有ホスティングでは、この時間が30秒から60秒に設定されていることがよくあります。大規模なサイトでのバックアップ処理は、それよりもはるかに長い時間がかかることがあり、制限時間に達すると、ホスティング事業者は処理の途中でそのプロセスを強制終了させてしまいます。

その結果、アーカイブファイルが不完全な状態になっています。バックアップは存在するようですが、ファイル自体は存在しているものの、書き込みが完了する前に途中で切り詰められてしまったため、復元することができません。

そのサイトは、バックアップの実行によるパフォーマンスの低下をまともに被ったにもかかわらず、信頼できる結果は何も得られなかった。破損したバックアップファイルは、バックアップがない場合よりもさらに深刻だ。なぜなら、実際には保護されていないにもかかわらず、保護されているという誤った安心感を与えてしまうからだ。

CPUおよびI/Oのクォータ

ほとんどの共有ホスティングサービスでは、アカウントごとのCPU使用率に制限を設けています。上限に達しても、ホスティング事業者はプロセスを完全に停止させるわけではありません。代わりに、処理速度を低下させます。その結果、そのアカウントで実行されているすべての処理、訪問者からのページリクエストを含め、動作が遅くなります。

I/Oの制限も同様の仕組みです。アカウントごとに、1秒あたりの読み取りおよび書き込み操作数に上限が設定されます。大規模なメディアライブラリをバックアップして圧縮する場合、この上限に頻繁に達することになります。

これが、まったく同じ設定でも、午前3時にはバックアップが成功するのに、正午には失敗してしまう理由です。利用が集中しない時間帯はサーバーのベースライン負荷が低いため、クォータが適用されるまでの余裕がより大きくなるからです。

バックアップファイルの形式は重要ですか？

ほとんどのバックアッププラグインは、デフォルトでZIPアーカイブ形式を採用しています。リソースが豊富なサーバー上の小規模なサイトであれば、これは悪い選択ではありません。しかし、ZIPはファイルを1つずつ順番に処理し、一度に中断することなく処理を行います。

リソースに制約のある共有ホスティング環境において、その一度きりの中断のない処理こそが、PHPのタイムアウト機能が阻止するように設計されている対象そのものです。

バックアッププラグインが使用するアーカイブ形式によって、サーバーへの負荷の度合いや、低コストのホスティング環境の制約下でも正常に動作するかどうかが決まります。この点は、バックアップのパフォーマンスに関する議論ではほとんど取り上げられることがありませんが、バックアップが確実に完了するか、あるいは何の前触れもなく失敗するかの分かれ目となることがよくあります。

DupArchiveによるサーバーの制約への対応

Duplicatorは、独自のバックアップ形式「DupArchive」を採用したWordPress用バックアッププラグインです。このプラグインは、WordPressのバックアップと移行を目的に開発され、低コストのホスティング環境における制約を設計上の重要な考慮事項として組み込んでいます。

標準的なZIP処理が1つの連続した操作として実行されるのに対し、DupArchiveはより小さなチャンク単位で処理を行います。各チャンクはサーバーの実行時間制限内に完了し、その後、処理は中断した箇所から再開されます。

ZIPベースのバックアップ実行中にタイムアウトが発生しても、各チャンクは制限時間が切れる前に完了するほど短いため、PHPのタイムアウトによる影響は生じません。

また、ZIP形式ではファイルサイズの上限により失敗してしまうような大規模なサイトでも処理可能です。DupArchiveを使用した実際の移行事例では、400GBを超えるデータでも完了しています！

多くの共有ホスティングユーザーにとって、この余裕があるおかげで、ZIP形式ではタイムアウトしたりファイルが破損したりするような場合でも、この形式なら問題なく動作するのです。

バックアップの速度を向上させる設定の完全なリストはこちらをご覧ください。

Shell Zip 対 ZipArchive

Duplicator では、バックアップアーカイブエンジンを選択できます。

Shell Zipは、PHP経由で圧縮処理を行うのではなく、OSに圧縮処理を委ねます。OSはPHPプロセスよりも直接的に圧縮処理を処理できるため、OSでの圧縮が利用可能な場合は、処理速度が大幅に向上します。

Budgetホストによっては、Shell Zipが無効になっている場合があります。もし無効になっている場合は、有効にするよう依頼するか、DuplicatorのDupArchiveによるチャンク処理が適切な代替手段であると考えてください。

これら2つのオプションを組み合わせることで、ほとんどのホスティング環境に対応できます。ホストが許可している場合は高速な「Shell Zip」を、許可していない場合は信頼性の高い「DupArchive」を使用します。

サイトの表示速度を落とさずにバックアップを実行する方法

目標は、訪問者にバックアップ作業を気づかれないようにすることです。バックアップは実行され、完了し、アップロードされますが、サイトの表示速度に変化があることに誰も気づくことはありません。

ほとんどの設定環境であれば、いくつかの設定を変更するだけで実現可能です。ホストの変更や開発者の雇用は必要ありません。

サイトの表示速度を落とさずにバックアップを行う最も効果的な方法：

• アクセスが少ない時間帯にバックアップをスケジュールする：タイミングがすべてです。サイトのアクセスが最も少ない時間帯を特定することで、バックアップ処理が実際の訪問者とサーバーリソースを奪い合うことを防げます。
• バックアップ不要なファイルを除外する：キャッシュディレクトリ、ログ、一時ファイルを削除することで、バックアップのサイズを大幅に削減し、CPU負荷とディスクI/Oを軽減できます。
• 完全バックアップよりも頻繁にデータベースのバックアップを実行する：データベースは常に変化しますが、ファイルは変化しないため、高速なデータベースのバックアップを毎日実行することで、負荷のかかるサイト全体の完全バックアップを週1回に抑えることができます。
• WP-Cronの代わりにサーバーのcronを使用する：WordPressのトラフィックに依存するスケジュール機能から、サーバー専用のcronジョブに切り替えることで、バックアップが予定通りに確実に実行されるようになります。

アクセスが少ない時間帯にバックアップをスケジュールする

ホスティングプランのレベルに関わらず、タイミングの調整は最も効果的な対策です。利用者が少ない午前3時にバックアップを実行する方が、実際の訪問者トラフィックと競合する正午に同じバックアップを実行するよりも、はるかに余裕があります。

一般的な推奨時間は、現地時間の午前2時から5時です。これはほとんどのサイトに当てはまりますが、実際のアクセス解析データを確認してみる価値はあります。

MonsterInsightsを開き、時間ごとのトラフィックを確認して、サイトにとっての本当のトラフィックの谷を見つけましょう。海外ユーザーをターゲットにしているサイトの中には、明確なトラフィックの少ない時間帯がないものもあります。また、深夜ではなく夕方の早い時間帯にトラフィックが最も少なくなるサイトもあります。一般的なルールではなく、データに基づいてスケジュールを調整しましょう。

トラフィックが集中する時間帯にはバックアップをスケジュールしないでください。例えば、毎週火曜日の午前9時にニュースレターを送信している場合は、その同じ火曜日の午前9時にバックアップを実行しないでください。キャンペーンによるトラフィックの急増時こそ、サーバーに余計な負荷をかけたくないタイミングなのです。

バックアップの必要がないファイルを除外する

バックアップの負荷を軽減する最も手っ取り早い方法は、バックアップ対象のデータを減らすことです。アーカイブサイズが小さければ、圧縮やアップロードが速く完了し、プロセス全体を通じてディスクI/Oへの負荷も軽減されます。

キャッシュディレクトリは最も手間のかからない部分です。キャッシュプラグインがサイトの読み込み時に自動的に再生成するため、バックアップを取っても復元する価値はありません。

また、除外すべきものとして：

• ログファイル
• 一時的なアップロードフォルダ
• 他のバックアッププラグインによってサーバーに残されたアーカイブファイル

Duplicatorでは、ファイルフィルターやデータベースフィルターを使用して、不要なデータを除外してください。組み込みの「Cache」フィルターをお勧めします。

バックアップ前のスキャンレポートでは、ビルドの実行前に大容量ファイルが特定されます。定期的なスケジュールを設定する前に、このレポートを確認しておくことをお勧めします。このレポートに数分間目を通すだけで、バックアップの容量を大幅に削減できます。

完全バックアップよりも頻繁にデータベースのバックアップを実行する

メディアライブラリはほとんど変化しません。一方、データベースは絶えず変化しています。

新しい投稿、コメント、注文、およびフォーム送信のすべてがデータベースに保存されます。実際に頻繁にバックアップを取る必要があるのは、まさにこれらです。

データベースのみのバックアップは毎日実行でき、処理は迅速で、多くの場合30秒以内に完了し、サーバーへの負荷も最小限に抑えられます。サイト全体のバックアップ（ファイルとデータベース）は、利用が集中しない時間帯に週1回実行するようにしてください。

このアプローチにより、最も重要なデータについては頻繁に復旧ポイントを確保しつつ、負荷の高いサイト全体のバックアップ処理は低頻度に抑えることができます。

WP-Cronの代わりにサーバーのCronを使用する

WordPressには「WP-Cron」と呼ばれる組み込みのスケジュール機能があります。ただし、この機能は誰かがサイトにアクセスしたときのみ実行されるという点が注意点です。

午前3時にアクセスがない場合、バックアップは実行されません。さらに悪いことに、正午にアクセスがあると、本来は夜間に実行されるはずだった遅延バックアップが、意図せずトリガーされてしまう可能性があります。

実際のサーバーのcronジョブは、トラフィックの状況にかかわらず、決まったスケジュールで実行されます。ほとんどのホスティングコントロールパネルでは、cronの設定を行うことができます。

バックアッププラグイン用にこれを設定するのは数分で済み、WP-Cronによる不安定さを完全に解消できます。これまで設定したことがない方のために、DuplicatorのドキュメントにはサーバーサイドCronの設定手順が記載されています。

バックアップがサイトのパフォーマンスに影響を与えている兆候

サイトの動作が遅い原因をバックアップと結びつけないかもしれません。なぜなら、そのタイミングがはっきりしないからです。深夜や早朝などに実行されるバックアップは、そのことを自ら知らせてはくれません。しかし、サイトの動作が重く感じられ、原因を特定できていない場合は、注目すべきパターンが存在します。

サイトの表示速度が低下していることを示す兆候は以下の通りです：

• サイトの表示速度の低下は、バックアップのスケジュールに合わせて、毎日または毎週決まった時間帯に急増します
• バックアップログに、実行の失敗、不完全な実行、または実行の欠落が記録されています
• ホスティングのコントロールパネルに、予測可能なスケジュールでCPUやI/Oの急増が表示されています
• 訪問者からは、普段のピーク時のアクセス状況とは一致しないほどの動作の遅さが報告されています

もしそのうちの2つ以上が現在発生している現象と一致する場合は、他の原因を調べる前に、まずバックアップのスケジュールを確認してください。

変更を加える前に、サイトを保護しましょう

バックアップのスケジュールを変更したり、アーカイブ形式を切り替えたり、サーバーの設定を変更したりする前に、まずフルバックアップを実行してください。

当たり前のように聞こえるかもしれませんが、トラブルシューティングの最中で、早く問題を解決したいと焦っていると、ついこの手順を飛ばしてしまいがちです。私自身もまさにそうしてしまい、期待通りにいかなかった変更を加える直前に、バックアップ履歴に空白期間を作ってしまったことがあります。

バックアップの設定中に設定ミスをすると、バックアップがまったく機能しなくなってしまう可能性があります。バックアップ環境を改善しようとした結果、かえってバックアップという安全網を壊してしまうという皮肉な事態は、実際に起こり得るのです。

本番サイトに適用する前に、新しいスケジュール設定やバックアップファイルの設定をテストしたい場合、ステージング環境を利用すれば、隔離された環境で事前にすべてが正常に動作するかを確認できます。

Duplicator Pro を使えば、既存のバックアップからわずか数クリックでステージングサイトを作成できます。別途ホスティングアカウントを用意する必要はありません。

ステージング環境を構築すれば、リスクを冒すことなく自由にトラブルシューティングを行うことができます。

よくある質問 (FAQ)

あなたのサイトには、そのサイトに最適なバックアップが必要です

バックアップはサイトを保護するためのものであり、負荷をかけるためのものではありません。設定が不適切なバックアップによるパフォーマンスの低下は確かに起こり得ますが、ほとんどの場合、ホスティング業者を変更したり、システムを再構築したりすることなく修正可能です。

最も重要な3つの要素は、バックアップの実行タイミング、バックアップの対象範囲、および使用する形式です。これらの3点に対処することで、ほとんどのサイトにおいてパフォーマンスへの影響をほぼゼロに抑えることができます。

バックアッププラグインは、サーバーリソースをサイトと奪い合うことなく、サイトを保護すべきです。これは、言葉ほど簡単にはいかないバランス調整です。特に、制約が現実のものとなり、必ずしも文書化されていない共有ホスティングや低価格ホスティングではなおさらです。

150万人以上のWordPress専門家が、バックアップ、移行、災害復旧の処理にDuplicator Proを利用しています。DupArchive形式は、標準的なZIPベースのバックアップが最も頻繁に失敗するホスティング環境、すなわちPHPのタイムアウト、CPUクォータ、I/O制限があるリソース制約のあるサーバー向けに特別に設計されました。

また、本番サイトに適用する前に設定の変更をテストしたい場合は、ワンクリック・ステージング機能を使えば、別途ホスティングアカウントを用意することなく、既存のバックアップからサイトのコピーをすぐに作成できます。

この記事を読んで、バックアップのパフォーマンスやサイトの健全性について考えさせられたなら、次のガイドもぜひ読んでみてください。

• あなたのWordPressサイトが遅くなるたびに資金が流出している（これが修正策です）
• ウェブサイト・バックアップファイルを暗号化してデータを最大限に保護する方法
• サイトがクラッシュ？ウェブサイト完全復旧プラン
• ウェブサイトのバックアップ保持ポリシー：バックアップの保存期間
• WordPressサイトにバックアップ監視が必要な理由（バックアップだけではない）