WordPressサイト2,000件以上のバックアップ設定から学んだこと
John Turner
ジョン・ターナー
バックアップが毎回同じ場所で停止します。
それで、あなたは助けを探しに行きます。あるフォーラムのスレッドでは、チャンクサイズを下げるように言っています。別のスレッドでは、圧縮を無効にするように言っています。両方を試します。
バックアップはまだ停止します。または、今は完了しますが、以前よりもはるかに時間がかかります。
そのアドバイスは確かに誰かのバックアップを修正しましたが、それは彼らのサーバー上での修正であり、あなたのサーバーでは同じことが許可されない場合があります。
そこで、逸話の交換ではなく、データを確認しました。Duplicatorに組み込まれている設定テスターであるAutoTuneは、サイトのサーバーで実際のテストバックアップを実行し、完了するまで続けます。2,000以上のサイトがどこに落ち着いたかを確認しました。
この記事では、これらの結果を詳しく説明し、バックアップ設定にとって何を意味するかを説明します。
目次
主な発見事項
まず数字を知りたい方のために、データが示すものをご紹介します。すべての数値は、Duplicator独自のAutoTune使用データに基づいています。
- AutoTuneは、約10回のチューニングセッションのうち9回で、少なくとも1つのバックアップ設定を変更しました。これは必ずしも以前の設定が壊れていたことを意味するわけではありません。
- Shell ZIPとmysqldumpは、成功した構成の約半分を占めました。
- PHP ZIPは成功した構成の10分の4弱を占め、DupArchiveは10分の1未満でした。
- Mysqldumpは、成功した構成の約3分の2に登場しました。PHPベースのデータベースエクスポートが残りを処理しました。
- 成功した構成のほぼすべてが圧縮と128MBのチャンクサイズを使用しました。
- 成功したチューニングセッションの約10回中9回が、最初のテスト試行で完了しました。
- チューニングセッションの10回中8回以上が、成功した構成を見つけました。
AutoTuneはどのようにサーバーをテストしますか?
DuplicatorのAutoTuneは、サイトで実際のテストバックアップを実行します。最も速い構成から開始します。テストが失敗した場合、設定を調整して別の構成を試します。
テストが成功すると、その設定は自動的に保存されます。問題が設定では変更できないサーバー制限である場合は、代わりにその旨を通知します。

AutoTuneは4つのバックアップ設定グループを調整します。それぞれの機能は次のとおりです。
- アーカイブエンジンと圧縮: ファイルがバックアップにパッケージ化される方法。
- ZIPモードとチャンクサイズ: アーカイブ処理がステップに分割される方法。
- データベースエンジンとダンプモード: データベースがエクスポートされる方法。
- サーバー負荷軽減: サーバーへの負荷を軽減するために処理速度が低下するかどうか。
また、サーバー概要は、PHP制限、エンジン可用性、バックグラウンド処理チェックなど、環境に関する情報も報告します。
ご自身のサイトで実行したい場合は、WordPressバックアップの失敗を修正する方法でステップバイステップで説明しています。
いくつのサイトが異なる設定になりましたか?
AutoTuneは、約10回のチューニングセッションのうち9回で、少なくとも1つのバックアップ設定を変更しました。
それはかなりの割合ですが、「変更」は「壊れた設定を修正した」という意味ではありません。
サイトではバックアップを確実に完了させる設定を使用していたかもしれませんが、AutoTuneはより高速でサポートされているオプションを見つけました。別のサイトでは、既存の設定が完了できなかったため、フォールバックが必要だった可能性があります。

バックアップ設定を再確認する理由はいくつかあります。
- サイトが別のサーバーに移動しました。
- ホストがPHP設定またはリソース制限を変更しました。
- ファイルまたはデータベースが大きくなりました。
- 別のサイトから設定をコピーしました。
- デフォルト以外の代替手段をテストしたことがありません。
データは、これらの状況がすべてのWordPressサイトでどれほど一般的であるかを示していません。ただし、AutoTuneを実行すると、それを使用したサイトの間で設定が変更されることがよくあったことが示されています。
もしあなたのホスティング環境が変更された場合、古い設定がまだ適合していると仮定するよりも、再テストする方がはるかに役立ちます。
WordPressに最適なバックアップ構成はありますか?
すべてのサーバーが使用できる単一の組み合わせはありません。
一部のホストは、コマンドラインアーカイブおよびデータベースツールを提供しています。他のホストはそれらのツールを制限していますが、PHPベースの代替手段をサポートしています。リソース制限も、どの設定が完了できるかに影響します。
成功したAutoTuneの設定はここに落ち着きました。
| セットアップ | 成功した設定の割合 | サーバーが必要とするもの | どこに適合するか |
|---|---|---|---|
| シェルZIPとmysqldump | 約半分 | アクセス可能なZIPツール、有効なPHPコマンド機能、およびmysqldumpへのアクセス | 独自のツールを許可するサーバー。サーバーがサポートしている場合、通常は最も高速な組み合わせです。 |
| PHP ZIP(mysqldumpまたはPHPエクスポートを使用) | 10分の4弱 | PHP ZipArchive拡張機能 | コマンドラインツールを制限するがZipArchiveが有効になっているホスト |
| PHPデータベースエクスポートを使用したシェルZIP | 約20分の1 | mysqldumpに依存しないシェルZIPサポート | ZIPツールは許可するがmysqldumpが利用できないサーバー |
| どちらかのデータベースエクスポート方法を使用したDupArchive | 10分の1未満 | Duplicatorの通常のサーバー要件。外部ZIP実行可能ファイルまたはZipArchive拡張機能は不要です | 他のエンジンが完了できなかったサーバー。多くのリクエストにわたってバックアップを小さな部分に分割して作成します。 |
これらはすべて、どこかで正しい答えです。問題は、どれがあなたのサーバーに適しているかです。
最も高速なセットアップが成功した構成の約半分を占めました
mysqldump を含む Shell ZIP は、成功した構成の約半分を占めました。PHPデータベースエクスポートペアリングを含めると、Shell ZIP は 50% 強を占めました。
Shell ZIP は、アーカイブ全体を PHP で構築するのではなく、サーバー固有の ZIP ツールを使用します。サーバーがサポートしている場合、PHP ZIP よりも高速であることがよくあります。
Duplicator の Shell ZIP オプションでは、zip および unzip ツールと、有効化された PHP の popen() および pclose() 関数が必要です。
Mysqldump は、データベースをエクスポートするための別のコマンドラインツールです。Duplicator はそれにアクセスして実行できる必要があります。
これらのツールが利用可能な場合、効率的な組み合わせになります。利用できないか制限されている場合、PHPベースの代替手段がより適している可能性があります。
PHP ZIPが残りのほとんどをカバーします
成功した構成の 10 件中 4 件未満で PHP ZIP がマルチスレッドモードで使用されていました。
PHP ZIP は外部 ZIP 実行可能ファイルに依存しませんが、PHP の ZipArchive 拡張機能がインストールされ有効になっている必要があります。
これにより、ホストがコマンドラインツールを制限している場合に便利な代替手段となります。
mysqldump または PHP データベースエクスポートのいずれかとペアにできます。アーカイブ作成とデータベースエクスポートは別々のタスクであるため、サーバーは一方のコマンドラインツールはサポートしていても、もう一方はサポートしていない場合があります。
DupArchiveは最も困難なサーバーのセーフティネットです
DupArchive は、成功した構成の 10 件に 1 件未満を占めました。
その小さな数字は重要です。なぜなら、誰が必要としているかを示しているからです。より小さなチャンクサイズとサーバー負荷の削減は、成功した構成のほんの一握りでしか見られず、そのほとんどが DupArchive を使用していました。これらは、データの中で最も制約の厳しいサーバーのようです。
DupArchive は Duplicator 独自のアーカイブ形式です。多くのリクエストにわたってバックアップを小さな部分に分割して作成するため、他のエンジンを途中で停止させる厳しい時間制限を回避できます。

このようなサーバーでは、バックアップを完了させることができます。
しかし、すべての遅いバックアップのデフォルトの修正ではありません。ほとんどのサーバーでは必要ありませんでした。
mysqldumpまたはPHP:どちらのデータベースバックアップ方法がより頻繁に機能しますか?
Mysqldump は、成功した構成の約 3 件に 2 件で見られました。PHP ベースのエクスポートは約 3 件に 1 件を占めました。
mysqldump が利用できない場合、PHP エクスポートは Duplicator にデータベースをエクスポートする別の方法を提供します。それでも、適切なサーバーリソース、データベースアクセス、および権限に依存します。
どの一般的な修正は通常不要でしたか?
遅いまたは失敗したバックアップに関するフォーラムのスレッドには、3 つのアドバイスが表示されます。ここでは、それぞれがデータ内の成功した構成と比較されています。
これらを読みながら、1 つのことを覚えておいてください。AutoTune はテストバックアップが完了するとすぐに停止するため、最終的な構成は、そのサーバーでバックアップを完了するために必要だったものを示しており、機能した可能性のあるすべての設定を示しているわけではありません。
- 「圧縮をオフにする」ほぼすべての成功した構成で圧縮が使用されていました。圧縮をオフにしても、失敗したバックアップが機能するようになることはめったにありません。バックアップが遅延している場合は、アーカイブエンジンとホストの制限により適した場所を探すことができます。
- 「共有ホスティングでは常にDupArchiveを使用する」成功した構成の10分の1未満でDupArchiveが使用されており、データ内のほとんどのサーバーはShell ZIPまたはPHP ZIPで完了しました。(ホストタイプ別の内訳がないため、これは共有サーバーだけでなく、すべてのサーバーを対象としています。)最も制約の多いホストでは、DupArchiveが適切です。
- 「チャンクサイズを下げる」ほぼすべての成功した構成で128MBのチャンクサイズが使用されていました。より小さいチャンクは、少数のサーバーでのみ表示され、ほとんどの場合DupArchiveと併用されていました。
各修正は誰かに役立ちました。お使いのサーバーでは、それは推測です。AutoTuneを使用して、サイトに最適な構成を見つけてください。
AutoTuneは何回試行する必要がありましたか?
成功したセッションの約10分の9は、最初の試行で正常に動作する構成を見つけました。
残りの10分の1は、バックアップが完了する前に少なくとも1回のフォールバックが必要でした。100分の1未満で4〜5回の試行が必要でした。
どのバックアップ設定も機能しない場合はどうなりますか?
チューニングセッションの20分の1未満で、AutoTuneはテストしましたが、そのサーバーで完了する構成を見つけることができませんでした。
最も多くのセッションを停止したことと、それぞれの修正方法を以下に示します。
サーバーのタイムリミットが切れました
これは、設定が完了できなかった最も一般的な理由の1つでした。
ホストは、単一のPHPプロセスが実行できる時間を制限します。バックアップがその制限内に収まるように作業を十分に小さなステップに分割できない場合、ホストは設定に関係なく途中で停止します。
修正はホストにあります。PHP実行時間制限(max_execution_time)を引き上げるように依頼するか、制限がそれほど厳しくないプランに移行してください。
AutoTuneのサーバー概要は、サーバーのPHPタイムリミットを表示するため、サポートチケットで引用できます。
ディスクがいっぱいになりました
ディスクがいっぱいだったため、一部のセッションは完了前に停止しました。サーバーの空き容量がないため、どのバックアップ設定でも修正できないため、これらは個別にカウントします。
修正はハウスキーピングです。不要になった古いバックアップを削除し、保持制限を設定して再度積み重ならないようにし、同じサーバーではなくオフサイトにコピーを保管してください。
古いバックアップがサーバーを静かに満たしていることは、Duplicatorのサポートチケットでも見られたパターンの1つであり、WordPressバックアップが破損する原因で説明しています。
ビルドがブラウザで停止しました
正常に動作する構成が見つからなかったセッションの約5分の1は、バックグラウンドではなくブラウザ経由で実行されていました。
これは、ホストがサイトからの自己呼び出し(「ループバックリクエスト」)をブロックした場合に発生します。Duplicatorはブラウザからバックアップを駆動するようにフォールバックします。つまり、ページが開いている間のみ移動します。タブを閉じたり、セッションをタイムアウトさせたりすると、ビルドが停止します。
修正はホストへの簡単な質問です。ループバックリクエストがブロックされているかどうか、およびサイトでそれらを許可できるかどうかを尋ねてください。
あなた自身のバックアップ設定をどうすべきですか?
このデータを暗記する必要はありません。ご自身の環境をテストする理由として使用してください。
次に実行することはこちらです:
- Duplicatorを更新します。 AutoTuneは、バージョン5.0以降のLiteおよびProで利用可能です。
- AutoTuneを実行します。サーバーがサポートする構成をテストさせます。
- その後、通常のバックアップを作成します。チューニングテストは復元可能なバックアップではありません。
- 復旧を確認します。通常のバックアップが完了することを確認し、次にステージングまたはテスト環境(ライブサイトではありません)で復元をテストします。
- ストレージと保持期間を確認します。十分なローカル作業スペースと、オフサイトの復旧コピーを保持してください。
- 自動化を設定します。 Duplicator Proで、バックアップスケジュールと選択したストレージの宛先を設定します。
何も機能しない場合は、ホストにAutoTuneレポートを持っていってください。サーバー概要にはサーバーのPHP制限が記載されており、あいまいな苦情を具体的な要求に変えます。
よくある質問(FAQ)
Shell ZipはZipArchiveより高速ですか?
通常は、サーバーが許可する場合です。Shell Zipはサーバー自身のzipツールを使用するため、PHP内からzipするよりも高速になる傾向があります。ただし、利用可能性が問題となります。サーバーのzipおよびunzipパッケージとPHPのpopenおよびpclose関数が必要ですが、多くの共有ホストでは提供されていません。そのため、データ内の成功した構成の半分強しか占めていないのはおそらくこのためです。
WordPressデータベースのバックアップにはmysqldumpとPHPのどちらを使用すべきですか?
サーバーがサポートしている場合は、mysqldumpを使用してください。これはサーバー自身のデータベースエクスポートツールであり、データ内の成功した構成の約3分の2に登場しました。ホストが許可しない場合は、PHPベースのエクスポートがフォールバックとなります。PHP内から実行されるため、サーバーに十分なリソースとデータベースアクセスがある限り、mysqldumpが機能しない多くのサーバーでも機能します。
圧縮を無効にすると、バックアップの失敗は修正されますか?
まれです。私たちのデータでは、ほぼすべての成功した構成で圧縮が使用されていました。これはフォーラムで最も頻繁に繰り返されるヒントの1つですが、失敗したバックアップと正常に機能するバックアップを分ける要因となることはめったにありません。まずアーカイブエンジンとホストの時間とディスクの制限を確認してください。
なぜ私のサーバーはShell Zipを使用できないのですか?
おそらく、ホストがzipおよびunzipパッケージをインストールしていないか、PHPのpopenおよびpclose関数を無効にしています。ホストに有効にするように依頼できます。それらが有効にならない場合は、サーバーにPHPのZipArchive拡張機能が有効になっている限り、PHP ZIPが代替手段となります。
次のバックアップの前に、サーバーに設定を選択させましょう
途中で停止したバックアップは、復元できるものが何も残らず、必要になるまで気づかない可能性があります。
AutoTuneは、すべての設定を手動で試すことなく、サーバーで完了する構成を見つけるのに役立ちます。しかし、チューニングは復旧計画の一部にすぎません。
その後、バックアップを作成し、復元を確認し、スケジュール、保持ポリシー、およびオフサイトの宛先を設定します。
AutoTuneは、無料版とプレミアム版の両方でDuplicator 5.0に含まれています。今すぐプラグインをアップデートしてください。
Duplicator Proは、その作業中のセットアップをスケジュールどおりに実行し、コピーを自動的にオフサイトに送信します。150万人以上のWordPressのプロフェッショナルがDuplicatorを使用して、サイトを復旧可能に保っています。
この投稿でバックアップ設定について考えさせられたなら、次に読む価値のあるガイドはこちらです。