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

昨年、サイトの遅延のトラブルシューティングをしていましたが、明らかな原因が見つかりませんでした。新しいプラグインもなく、トラフィックの急増もなく、エラーログにも目立ったものはありませんでした。

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

ほとんどのWordPressユーザーはバックアッププラグインをインストールし、スケジュールを選択したら、二度と触りません。アクティブになったら完了したと感じるタスクの1つです。

しかし、ほとんどのバックアッププラグインのデフォルト設定は、パフォーマンスのために最適化されていません。それらはシンプルさのために最適化されています。

Dropboxに保存される毎日のフルバックアップは、責任あるように聞こえます。小規模なサイトで十分なホスティングがあれば、それはそうです。大規模なサイトや予算の共有ホストでは、バックアップに接続していない可能性のある、繰り返し発生するパフォーマンスの低下です。

この記事では、バックアップが実行されると何が起こるか、なぜ一部の設定が他の設定よりもサーバーに負荷をかけるのか、そして影響をほぼゼロに抑える具体的な変更について説明します。

主なポイントは次のとおりです：

• バックアップはリソースを大量に消費します: ファイルの圧縮、データベースのエクスポート、クラウドへのアップロードは、CPU、ディスクI/O、帯域幅を同時に大量に消費します。
• 共有ホスティングの制限はサイレント障害を引き起こす可能性があります: 予算ホストのPHPタイムアウトやCPU/I/Oクォータは、長時間実行されるバックアップをプロセス中にしばしば中断させ、破損または不完全なファイルが残ります。
• バックアップ形式が重要です: 標準のZIPアーカイブは1回の連続パスで実行されるため、サーバータイムアウトに対して非常に脆弱です。DuplicatorのカスタムDupArchiveのようなチャンク化された形式は、これらの制約を完全に回避します。
• 最適化は簡単です: オフピーク時にバックアップを実行し、キャッシュファイルを除外し、サーバーのcronに依存し、フルサイトバックアップよりも頻繁にデータベースのみのバックアップをスケジュールすることで、パフォーマンスへの影響をほぼ排除できます。

目次

バックアップが実行されるとサーバーで何が起こるか？

バックアップは、ファイルを別の場所にコピーするだけではありません。それは、訪問者にサイトを提供するのと同じリソースを競合する、サーバー上で完全に実行される多段階のプロセスです。

バックアップが実行されている間、サーバーは同時に2つのジョブを実行しています。リソースがすでに数十の他のサイト間で分割されている共有ホスティングでは、それは重要です。

ファイル圧縮とCPU負荷

WordPressインストールのすべてのファイルは、バックアップ中に読み込まれ、アーカイブに圧縮されます。このプロセスはCPUを大量に消費します。

共有ホスティングでは、アカウントにはサーバーの処理能力の限られたスライスが割り当てられ、数百メガバイトのファイルを圧縮するバックアップはその一部を消費します。

より大きなサイトはこれを悪化させます。ファイルが多いほど圧縮ウィンドウが長くなり、CPUが圧力下にある時間が長くなります。

メディアが最小限の小さなブログなら、1分以内に圧縮できるかもしれません。長年アップロードされた画像があるサイトでは、それよりかなり時間がかかることがあります。

メディアライブラリのサイズを瞬時に半分にしたいですか？WP Media Cleanupで未使用の画像バリエーションを削除しましょう！

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

データベースのエクスポートは、しばしば隠れた原因となります。ほとんどのユーザーは、バックアップを想像するときにファイルのことを考えますが、WordPressは投稿、設定、ユーザーなどをMySQLデータベースに保存しており、それには個別のエクスポートプロセスが必要です。

ほとんどのバックアッププラグインは、読み取っているテーブルを一時的にロックする方法でデータベースをエクスポートします。それらのテーブルがロックされている間、WordPressへのクエリは待機する必要があります。

数秒間のテーブルロックでも、低速またはビジーなサーバーではタイムアウトを引き起こす可能性があります。

ディスクI/O: ほとんどの人が見落とすボトルネック

バックアップのために数千ものファイルを読み取ることは、かなりのディスクアクティビティを生み出します。サーバーのストレージには、1秒あたりに処理できる読み書き操作の回数に制限があり、WordPress全体をバックアップするプロセスは、その制限を押し上げます。

予算重視のホストや共有ホストでは、SSDではなく従来のハードドライブが依然として使用されていることがよくあります。それらのサーバーでは、バックアップ中の高いディスクアクティビティは、ストレージにアクセスするすべてを遅くし、ページを生成するデータベースクエリやファイル読み取りも含まれます。

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

パフォーマンスへの影響は、アーカイブの構築が完了しても終わりません。ほとんどのバックアップ設定では、その後、そのアーカイブをクラウドストレージにアップロードします：Dropbox、Google Drive、またはS3。そのアップロードは、訪問者にサービスを提供しているのと同じサーバー接続で実行されます。

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

なぜ低価格ホスティングのバックアップパフォーマンスは劣るのか？

低価格ホストや共有ホストは、ほとんどのユーザーがどこにも文書化されていないのを見るサーバーレベルの制限を課しています。

これらはバグや設定ミスではありません。それらは、1つのアカウントが同じサーバー上の他のすべてのサイトに影響を与えるリソースを消費することを防ぐための意図的な制限です。

問題は、それらの同じ制限がバックアッププロセスを妨げ、それによって引き起こされる失敗が常に明白ではないことです。

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 vs. ZipArchive

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

Shell Zipは、PHPを介して実行するのではなく、オペレーティングシステムに圧縮を委任します。OSはPHPプロセスよりも直接的に圧縮を処理するため、利用可能な場合は大幅に高速です。

予算ホストはShell Zipを無効にすることがあります。ホストが無効にしている場合は、有効にするように依頼するか、DuplicatorのDupArchiveチャンク処理が適切なフォールバックであるというシグナルと見なしてください。

これら2つのオプションは、ホストが許可する場合は速度のためのShell Zip、許可しない場合は信頼性のためのDupArchiveであり、ほとんどのホスティング環境をカバーしています。

サイトの速度を低下させずにバックアップを実行する方法

目標は、訪問者にバックアップが見えないようにすることです。バックアップは実行され、完了し、サイトの速度に違いがないことに気づかれずにアップロードされます。

これは、ほとんどのセットアップでいくつかの設定変更を行うことで達成可能です。ホストを切り替えたり、開発者を雇ったりする必要はありません。

サイトの速度を低下させずにバックアップを実行する最も効果的な方法：

• トラフィックの少ない時間帯にバックアップをスケジュールする：タイミングがすべてです。サイトの最も静かな時間帯を特定することで、バックアップがサーバーリソースを実際の訪問者と競合しないようにします。
• バックアップする必要のないファイルを除外する：キャッシュディレクトリ、ログ、一時ファイルを削除すると、バックアップサイズが劇的に減少し、CPUパワーとディスクI/Oが節約されます。
• フルバックアップよりも頻繁にデータベースバックアップを実行する：データベースは常に変化しますが、ファイルはそうではないため、高速な毎日のデータベースバックアップを実行することで、重いフルサイトバックアップを週に1回だけに減らすことができます。
• WP-CronではなくサーバーCronを使用する：WordPressのトラフィック依存のスケジューリングから専用のサーバーCronジョブに切り替えることで、バックアップが予定通りに確実に実行されます。

トラフィックの少ない時間にバックアップをスケジュールする

ホスティングティアに関係なく、タイミングは最も効果的な修正方法です。静かなサーバーで午前3時に実行されるバックアップは、実際の訪問者トラフィックと競合する正午に実行される同じバックアップよりもはるかに多くのヘッドルームがあります。

標準的な推奨事項は、現地時間の午前2時から5時です。これはほとんどのサイトに当てはまりますが、実際の分析を確認する価値はあります。

MonsterInsightsを開き、時間ごとのトラフィックを確認して、実際の谷を見つけてください。国際的なオーディエンスにサービスを提供する一部のサイトには、クリーンな低トラフィックウィンドウがありません。他のサイトでは、夜間ではなく夕方早い時間に最低値が見られます。一般的なルールではなく、データに基づいてスケジュールを設定してください。

トラフィックの多い時間帯にバックアップをスケジュールしないでください。火曜日の午前9時にニュースレターを送信する場合は、火曜日の午前9時にバックアップを実行しないでください。キャンペーンからのトラフィックの急増は、追加のサーバー負荷を避けたいまさにその時です。

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

バックアップ負荷を軽減する最も速い方法は、バックアップされるものを減らすことです。より小さなアーカイブは、より速く圧縮され、より速くアップロードされ、プロセス全体でディスクI/Oへの圧力を軽減します。

キャッシュディレクトリは最大の成果です。キャッシュプラグインはサイトがロードされるときに自動的にそれらを再生成するため、バックアップする回復値はありません。

除外する価値があるもの：

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

Duplicatorでは、ファイルとデータベースのフィルターを使用して不要なデータを除外します。組み込みのキャッシュフィルターをお勧めします。

バックアップ前のスキャンレポートは、ビルドが実行される前に大きなファイルを表面化します。定期的なスケジュールを設定する前に確認する価値があります。そのレポートで数分間確認するだけで、バックアップサイズを大幅に削減できます。

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

メディアライブラリはほとんど変化しません。データベースは常に変化します。

新しい投稿、コメント、注文、フォーム送信はすべてデータベースに入力されます。それが頻繁にバックアップする必要があるものです。

毎日のデータベースのみのバックアップは高速で、多くの場合30秒未満で完了し、サーバーへの負荷は最小限です。フルサイトバックアップ（ファイルとデータベース）は、オフピーク時の週次の実行のために予約してください。

このアプローチにより、最も重要なデータに対して頻繁にリカバリポイントを取得しつつ、サイト全体の重い処理はまれに行うことができます。

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

WordPressにはWP-Cronという組み込みのスケジューリングシステムがあります。ただし、これは誰かがサイトを訪問したときにのみ実行されます。

午前3時に誰も訪問しなければ、バックアップは実行されません。さらに悪いことに、正午に来た訪問者が、本来夜間に実行されるはずだった遅延バックアップを誤ってトリガーしてしまう可能性があります。

実際のサーバーのcronジョブは、トラフィックに関係なく固定スケジュールで実行されます。ほとんどのホスティングコントロールパネルでは、cronの設定にアクセスできます。

バックアッププラグイン用に1つ設定するのは数分で済み、WP-Cronの予測不可能性を完全に排除できます。Duplicatorのドキュメントには、サーバーサイドcronの設定プロセスが記載されているので、以前にやったことがない場合は参照してください。

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

サイトの遅延とバックアップを関連付けられないかもしれません。なぜなら、タイミングが明白ではないからです。奇妙な時間に実行されるバックアップは、それ自体を通知しません。しかし、サイトが遅く感じられ、原因を特定できなかった場合、調べる価値のあるパターンがあります。

これらは、バックアップがサイトを遅くしていることを示す兆候です。

• サイトの遅延が毎日または毎週同じ時間に急増し、バックアップスケジュールと一致する
• バックアップログに失敗、不完全、または欠落した実行が表示される
• ホスティングコントロールパネルに、予測可能なスケジュールでCPUまたはI/Oのスパイクが表示される
• 訪問者が、通常のピークトラフィック時間とは一致しない遅延を報告する

これらのうち2つ以上が、現在見ている状況と一致する場合は、他のことを調べる前に、まずバックアップスケジュールを確認してください。

何も変更する前にサイトを保護する

バックアップスケジュールを調整したり、アーカイブ形式を変更したり、サーバー設定を変更したりする前に、まず完全なバックアップを取得してください。

それは明白に聞こえますが、トラブルシューティングの途中で何かを修正したいと焦っていると、スキップしやすいものです。私はまさにそれをやってしまい、予期せぬ変更を加える直前にバックアップ履歴にギャップを作ってしまいました。

バックアップ設定時の構成ミスにより、まったく機能しないバックアップしか残らない可能性があります。バックアップ設定を改善しようとしている最中に、バックアップのセーフティネットを壊してしまうという皮肉は現実です。

ライブサイトに適用する前に新しいスケジューリングまたはバックアップファイル設定をテストしたい場合は、ステージングを使用すると、すべてが最初に機能することを確認できる分離された環境が得られます。

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

ステージングエリアを構築したら、リスクなしで自由にトラブルシューティングできます。

よくある質問（FAQ）

あなたのサイトは、それと連携するバックアップに値します

バックアップはサイトを保護するためのものであり、負担をかけるためのものではありません。不適切に構成されたバックアップによるパフォーマンスの低下は現実ですが、ホストを切り替えたり、何も再構築したりすることなく、ほぼ常に修正可能です。

最も重要な3つのレバーは、バックアップの実行時期、含めるもの、および使用する形式です。ほとんどのサイトは、これら3つのことを対処することで、パフォーマンスへの影響をほぼゼロにすることができます。

バックアッププラグインは、サイトと競合することなくサイトを保護する必要があります。これは、特に制約が現実的で、常に文書化されているわけではない共有およびバジェットホスティングでは、サウンドよりもストライクするのが難しいバランスです。

150万以上のWordPressプロフェッショナルが、バックアップ、移行、および災害復旧のためにDuplicator Proを使用しています。DupArchive形式は、PHPタイムアウト、CPUクォータ、I/O制限のある制約の多いサーバーなど、標準のZIPベースのバックアップが最も頻繁に失敗するホスティング環境向けに特別に構築されました。

また、ライブサイトに適用する前に構成の変更をテストしたい場合は、ワンクリックステージングにより、別のホスティングアカウントなしで既存のバックアップからサイトのコピーをすぐに作成できます。

この投稿を読んで、バックアップのパフォーマンスとサイトの健全性について考えるようになった場合は、これらのガイドを読む価値があります。

• あなたのWordPressサイトは、遅い秒ごとにあなたのお金を失っています（修正はこちら）
• ウェブサイトのバックアップファイルを最大限のデータセキュリティで暗号化する方法
• サイトがクラッシュしたばかりですか？完全なウェブサイト復旧計画はこちらです
• ウェブサイトのバックアップ保持ポリシー：バックアップをどのくらいの期間保持しますか？
• WordPressサイトでバックアップ監視が必要な理由（バックアップだけでは不十分）