ウェブサイトのバックアップ速度：バックアップが遅い理由と修正方法

バックアップが45分間実行されています。何も壊れていませんが、プログレスバーが動き続けています。

あるいは、サイトが毎晩午前3時に極端に遅くなり、その理由がわからないのかもしれません。プラグインの設定を確認し、スピードテストを実行しても、明白なことは何も見つかりません。そのとき、誰かがバックアップについて言及し、腑に落ちます。

ウェブサイトのバックアップが遅いのは実際の問題です。バックアッププロセス自体に時間がかかりすぎているか、完了前にサイレントに失敗している可能性があります。一方で、バックアップは正常に完了しているかもしれませんが、実行中に消費されるリソースがライブサイトを遅くしている可能性があります。

修正方法は、直面している問題によって異なります。このチュートリアルでは両方について説明します。

終了時には、ウェブサイトのバックアップ速度の低下に対処し、それに対処するDuplicator Proの設定を検討し、実際のトラフィックと競合しないバックアップスケジュールを設定していることになります。

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

• バックアップ速度の問題には、遅いまたは壊れているバックアッププロセスと、バックアップウィンドウ中にライブサイトを遅くするバックアップの2つの異なる問題があります。それぞれに対する修正方法は異なり、この記事では両方をカバーしています。
• 完了したように見えても復元に失敗するバックアップは、破損の問題ではなくPHPタイムアウトの問題です。Duplicator ProのDupArchive形式は、1回の連続操作ではなく、ファイルをチャンクで処理することでこれを防ぎます。
• アーカイブサイズを削減することが、最も速く効果のある方法です。キャッシュディレクトリ、ログファイル、他のプラグインからの不要なバックアップアーカイブは除外しても安全であり、しばしば不要なバックアップ重量の大部分を占めています。
• 毎日のフルサイトバックアップは通常やりすぎです。毎日のデータベースのみのバックアップ（30秒未満）と週次のフルサイトバックアップを組み合わせることで、復元カバレッジを犠牲にすることなく、ビルド時間とサーバー負荷を削減できます。
• WordPressのcronは実際のスケジュールで実行されません。午前3時にスケジュールされたバックアップは、ピークトラフィック時間にサイレントにシフトする可能性があります。WP-Cronを実際のサーバーcronジョブに置き換えることが、スケジュールされたバックアップを実際に信頼できるものにします。
• 必要になる前に復元をテストしてください。ほとんどの人は、実際の災害時に壊れたバックアップを発見します。ステージングサイトでの復元の検証には20分かかり、迅速な復旧と苦痛な復旧を分ける唯一のステップです。

目次

WordPressのバックアップにはどのくらい時間がかかるべきか？

適切に設定されたサイトとまともなホスティングでは、フルバックアップは2分から10分で完了するはずです。共有ホスティング上の大規模なサイトでは、30分から45分、場合によってはそれ以上かかることがあります。そして、時間はサイトのサイズだけでなく、バックアップの実行方法、ホストが許可するもの、プロセスが開始されたときにサーバーが負荷下にあるかどうかによっても異なります。

4つの要因がほとんどの変動を駆動します。

• ホストI/O制限

共有ホスティングでは、アカウントが1秒あたりに実行できる読み書き操作の数に制限があります。バックアップはサイト上のすべてのファイルを読み込み、アーカイブに書き込みます。制限のあるサーバーでは、そのプロセスは非常に遅くなり、実行中はサイトの応答時間を低下させる可能性があります。

• サイトサイズ

大規模なメディアライブラリ、肥大化したデータベース、または長年蓄積されたプラグインファイルはすべて、ビルド時間を延長します。500MBのサイトと5GBのサイトでは、バックアップは同じようにはいきません。

• バックアップ方法

フルバックアップは毎回すべてをゼロから圧縮します。増分バックアップは、前回の実行以降に変更されたものだけを保存するため、最初のバックアップが完了した後は大幅に高速になります。Duplicator Proは両方の方法をサポートしており、このチュートリアルで紹介する2つのスケジュール戦略は、複雑さを伴わずに増分バックアップのほとんどの速度メリットを得ることができます。

• PHPタイムアウト

ほとんどの共有ホストでは、PHP実行時間の制限を30秒から60秒に設定しています。その制限を超えたバックアップは、処理中に終了します。ファイルは完了したように見えますが、実際はそうではありません。これは、バックアップが成功したように見えても、復元中に失敗する最も一般的な原因の1つです。

開始する前に必要なもの

設定を変更する前に、以下のものが整っていることを確認してください。

• WordPressバックアッププラグインがインストールされ、有効化されていること。このチュートリアルでは、すべての具体的な手順とUIの参照にDuplicator Proを使用します。Duplicator Proは、150万人以上のWordPressプロフェッショナルによって使用されているWordPressのバックアップ、移行、および災害復旧プラグインです。バックアップ、サイト移行、ステージング、復元を処理します。これには、共有ホスティングで一般的なPHPタイムアウト制限を回避するために特別に設計されたチャンクベースのアーカイブ形式が含まれます。
• WordPress管理画面へのアクセス（バックアッププラグインの設定にアクセスするために必要です）
• ホスティングコントロールパネルへのアクセス（cPanelまたはホストの同等のもの — サーバーのcron設定とPHP制限の変更に必要です）
• 現在のバックアップサイズ（バックアッププラグインのパッケージまたはバックアップ履歴画面で確認してください）
• ホスティングの種類：共有、VPS、マネージドWordPress、または専用。これは重要です。なぜなら、このチュートリアルのいくつかの修正にはホストの協力が必要になるからです。共有ホスティングでは、PHP設定を自分で変更できない場合があります。
• ホスティングサポートへのアクセス（ライブチャットまたはサポートチケットシステム — ステップ3と8で必要になる場合があります）

開始前にホスティングの種類を知っておくと時間を節約できます。Shell ExecとPHPメモリ制限の増加はサーバーレベルで制御されます。自分で変更できることは、プランに完全に依存します。

ウェブサイトのバックアップを高速化する方法

これらの手順を進めることで、最速の結果が得られます。最初のステップは診断であり、設定を変更する前に、どの修正が実際にあなたの状況に適用されるかを知ることができます。

以下を行います：

• ステップ1：バックアップパフォーマンスの問題を特定する：バックアッププロセスが遅いか壊れているのか、または完了したバックアップがライブサイトを遅くしているのかを診断します。それぞれ修正方法が異なります。
• ステップ 2: バックアップ対象を削減する: キャッシュディレクトリ、ログファイル、および残りのプラグインアーカイブを除外してアーカイブサイズを縮小します。これがビルド時間を短縮する最も速い方法です。
• ステップ 3: より高速なアーカイブエンジンに切り替える: PHPベースのZipArchiveをShell Execに置き換えて速度を向上させるか、PHP実行制限が厳しいホストではDupArchiveに置き換えて耐障害性を向上させます。
• ステップ 4: 低速なデータベースバックアップを修正する: SQLモードをPHPコードに切り替え、データベースクリーンアップを実行して、20MBを超えるデータベースのエクスポート時間を短縮します。
• ステップ 5: WordPressのcronを実際のサーバーcronジョブに置き換える: スケジュールされたバックアップが、最初の訪問者が到着したときにトリガーされるのではなく、設定した正確な時間に実行されるようにします。
• ステップ 6: 2つのスケジュールバックアップ戦略を設定する: 毎日データベースのみのバックアップと毎週フルサイトのバックアップを個別に実行し、重いビルドができるだけまれに発生するようにします。
• ステップ 7: より高いサーバーリソース制限を要求する: 他のすべての設定が最適化された場合の最後の手段として、PHPメモリと実行時間制限を増やします。

ステップ1：バックアップパフォーマンスの問題を特定する

「バックアップが遅い」という問題には、2つの異なる問題が隠されています。

• 問題 A: バックアッププロセス自体が遅いか、壊れている。兆候としては、20分以上かかるビルド、特定のパーセンテージでフリーズする進行状況バー、または完了したように見えるが復元中に失敗するバックアップなどがあります。
• 問題 B: バックアップがライブサイトを遅くしている。兆候としては、訪問者または管理者が定期的な時間枠中に応答性の低下を報告したり、監視ツールが予測可能なスケジュールで発生する応答時間のスパイクを示したりします。

それらを区別するには、まずバックアッププラグインのビルドログを確認します。Duplicatorの場合は、Duplicator Pro » Tools » Duplicator Logs に移動します。最新のバックアップのログを見つけます。

他のプラグインにも同様のログがあります。プラグインの詳細設定を確認してください。

一番下までスクロールします。タイムアウトエラー、メモリ不足エラー、またはプロセス中に途切れた行が表示された場合は、問題 A です。ログに完了と表示されてもサイトがまだ遅い場合は、問題 B です。

続行する前に名前を付ける価値のあるもう1つのシナリオがあります。ビルドログにバックアップが完了したと表示されても、復元中にバックアップが失敗する場合は、PHP実行時間制限がサイレントにビルドを終了させた可能性があります。

ファイルは存在しますが、切り捨てられています。問題 A のように見えますが、根本原因はホスティングリソースの制限です。ステップ 3 で直接カバーされています。

Duplicator のバックアップログの読み方についてサポートが必要な場合は、このガイドをお読みください。

ステップ2：バックアップするものを減らす

バックアップのメガバイトが増えるごとに、ビルド時間が長くなります。CPUとディスクI/Oがすでに制約されている共有ホスティングでは、肥大化したアーカイブはバックアップを遅くし、バックアップが失敗し始めるタイムアウトしきい値に近づけます。

バックアップを縮小する最も速い方法は、不要なファイルを含めるのをやめることです。

最も一般的な原因は次のとおりです。

• キャッシュディレクトリ
• ログファイル
• 一時ファイル
• 他のプラグインによって残されたバックアップアーカイブ
• CDNや外部サービスにも保存している動画などの大きなメディアファイル

これらはすべて、正常に動作するサイトを復元する能力に影響しません。訪問者がページを読み込むと、キャッシュは自動的に再生成されます。ログはサイトの一部ではありません。他のプラグインからの古いバックアップアーカイブは、単に負荷を増やすだけです。

Duplicator Proでバックアップをカスタマイズする方法を説明します。Duplicator Pro » Backups » Add Newに移動して、新しいバックアップを作成します。

Backupセクションには、プリセットとフィルターが表示されます。

ファイルフィルターを有効にします。まずキャッシュフィルターを選択して、キャッシュディレクトリを除外します。

WP RocketやW3 Total Cacheのようなキャッシュプラグインを使用している場合、wp-content内にプラグイン固有のサブフォルダがある場合もあります。それぞれに完全なパスを追加してください。

次に、ログディレクトリを追加します。一般的な場所には、wp-content/debug.logやプラグイン固有のログフォルダがあります。

CDNにすべてのメディアを保存しており、すべてのファイルの現在のコピーが確認済みである場合を除き、wp-content/ ஏற்படுத்துகிறதுを除外しないでください。他の場所でバックアップされていることが確実な特定のファイル拡張子のみを除外してください。ここでメディアを間違えると、復元は成功しても画像が半分欠落することになります。

フィルターを追加したら、バックアップを続行します。Duplicator Proはサイトをスキャンし、他の大きなファイルサイズを報告します。

ステップ3：より高速なバックアップエンジンに切り替える

バックアップファイルが可能な限りスリムになったら、次の変数はバックアップの作成方法です。デフォルトでは、PHPの組み込みZipArchiveが使用されます。これは機能しますが、すべてPHP内で実行されるため、ホストが設定するすべてのリソース制限（実行時間、メモリ、CPUスロットリング）の影響を受けます。

能力のあるサーバーでは、おそらく問題ありません。共有ホスティングでは、ボトルネックが発生する可能性があります。

2つの代替手段があり、どちらを使用するかはホストによって異なります。

オプションA：シェルZip

これにより、バックアップアーカイブエンジンがPHPからサーバーのネイティブシステムzipバイナリに切り替わります。オペレーティングシステムのzipツールは、ほとんどの圧縮タスクでPHPよりも高速であり、PHPの実行時間制限を同じようにはカウントしません。

切り替えるには、Duplicator Pro » Settings » Backups » Archiveに移動し、Shell Zipを選択します。

切り替える前に、これを知っておいてください。一部の格安共有ホストは、サーバーレベルでshell_execを無効にしています。設定を変更して次のビルドがすぐに0%で失敗した場合、それが原因です。

同じ設定画面でZipArchiveに戻し、ホストに連絡してアカウントでshell_execを有効にするように依頼してください。それでも解決しない場合は、オプションBに移行してください。

オプションB：DupArchive

これはDuplicator独自のアーカイブ形式であり、標準のZIPとは異なる動作をします。DupArchiveは、単一の連続した圧縮操作ではなく、ファイルを小さなチャンクで処理します。各チャンクは、次のチャンクが開始する前に完了します。

PHPの実行時間制限が30秒から60秒の共有ホスティングプランでは、その制限時間を超える標準のZIPバックアップはビルド中に中断されます。プロセスは停止しますが、ファイルはすでにディスクに書き込まれています。

バックアップは完了したように見えます。その後、復元しようとすると失敗します。ファイルは完了前に切り取られていました。

DupArchive はこれを完全に回避します。各チャンクが PHP の実行クロックをリセットするため、標準的な ZIP ビルドでは失敗する制限をバックアップは乗り越えることができます。この修正により、共有ホスティングで問題が解決されたのを何度も見てきました。

切り替えるには、Duplicator Pro » 設定 » バックアップ » アーカイブ に移動し、DupArchive を選択してください。

いずれかのオプションに切り替えた後、テストバックアップを実行してください。小さなバックアップを作成し、完了したらログを確認してください。ログの末尾までスクロールし、正常に完了したことを確認してください。

ステップ 4: 低速なデータベースバックアップを修正する

データベースが大きいと、データベースがエクスポートされる部分だけでなく、バックアップ全体のビルドが遅くなります。データベースが肥大化していると、プロセス全体でその影響を感じるでしょう。

データベースのサイズを確認するには、Duplicator Pro で新しいバックアップを開始し、セットアップウィザードを実行してスキャンさせてください。バックアップの作成をコミットする前に、データベースのサイズが表示されます。

20MB を超える場合は、これらの修正で目立った違いが見られます。

修正 1: SQL モードを PHP コードに切り替える

Duplicator Pro » 設定 » バックアップ » SQL モード に移動し、設定を MySQL ダンプ から PHP コード に変更してください。これにより、Duplicator がデータベーステーブルをエクスポートする方法が変更されます。

PHP コード方式は、テーブルロックのタイムアウトを引き起こしにくいため、共有ホスティングでは一般的に信頼性が高くなります。これは、大きなデータベースに対して意味のある効果をもたらす小さな変更です。

修正 2: 次のバックアップの前にデータベースをクリーンアップする

これには数分かかりますが、主要なバックアップの前に行う価値があります。

WP-Optimize または同様の データベースクリーンアッププラグイン をインストールし、投稿リビジョン、スパムコメント、期限切れの一時データ、孤立したメタデータを削除するために実行してください。これらはアクティブなサイトで静かに蓄積し、実際に復元する必要のないものを含んでいても、データベースの肥大化の 30 ～ 50 パーセントを占める可能性があります。

私の個人的なサイトでは、WP-Optimize を使用して簡単なデータベースクリーンアップの前後にバックアップを実行しました。バックアップ時間が 30 秒短縮され、ファイルサイズが削減されました。

ただし、データベースをクリーンアップした直後に初めてクリティカルなバックアップを実行しないでください。クリーンアップを実行し、サイトを閲覧してすべてが正常に機能することを確認してからバックアップしてください。信頼できるツールでクリーンアップを行えば安全ですが、バックアップにその状態をロックする前にサイトが正常であることを確認したいでしょう。

両方の変更を行った後、新しいバックアップを実行し、ビルド時間を以前のベースラインと比較してください。20MB を超えるデータベースでは、通常、違いが目に見えます。

ステップ5：WordPress Cronを実際のサーバーCronジョブに置き換える

バックアップがスケジュールされているのに、間違った時間に実行され続ける場合、または設定した静かな時間帯ではなく、営業時間中にサイトが遅くなる場合は、WordPress の cron が原因である可能性が高いです。

WP-Cron は実際のスケジュールで実行されません。誰かがサイトにアクセスしたときにのみトリガーされます。

トラフィックが到着すると、WordPress はスケジュールされたタスクが期限切れになっていないかを確認し、その時点で実行します。午前 3 時にスケジュールしたバックアップは、最初の訪問者が現れたときに実行されますが、それはピークトラフィックウィンドウの真ん中かもしれません。

サーバーのcronジョブでWP-Cronを置き換えることで、トラフィックに関係なく、バックアップが設定した正確な時間に毎回実行されるようになります。

https://cron-job.org/でアカウントを作成することから始めます。次に、新しいcronジョブを作成します。

新しいcronジョブに名前を付けます。これをURLとして設定し、サイトのドメインに置き換えます: https://example.com/wp-admin/admin-ajax.php?action=duplicator_process_worker

実行スケジュールを1分ごとに設定します。

サーバーのcronジョブがアクティブになり保存されたら、"That's all, stop editing!"と表示されている行の上に、この行をwp-config.phpファイルに追加します。

define('DISABLE_WP_CRON', true);

これにより、WordPressは独自のcronシステムを実行するのを停止します。

サーバーのcronジョブが確認され保存された後にのみ、wp-config.phpにdefine行を追加してください。先にWP-Cronを無効にすると、サイト上のすべてのスケジュールされたタスクはすぐに一時停止します。サーバーのcronがアクティブになるまで、スケジュールされたバックアップ、スケジュールされた投稿、WP-Cronに依存するものはすべて停止します。

WP Engine、Kinsta、FlywheelなどのマネージドWordPressホスティングを利用している場合は、wp-config.phpを編集する前にホストのドキュメントを確認してください。一部のマネージドホストは、サーバーcronを異なる方法で処理したり、お客様に代わって管理したりします。

セットアップ後、Duplicator Pro » 設定 » バックアップのスケジュールに戻り、次のスケジュールされた実行時間が設定した時間と正確に一致していることを確認してください。この確認が、引き継ぎが成功した合図です。

ステップ6：2つのスケジュールバックアップ戦略を設定する

共有ホスティングでのバックアップ速度とサイト速度の低下の一般的な原因の1つは、毎日のフルサイトバックアップです。また、ほとんどのWordPressサイトでは、実際に必要な量を超えています。

データベースは、新しい投稿、注文、フォーム送信、コメント、プラグインのアクティビティにより常に変化しています。対照的に、ファイル、テーマ、プラグイン、アップロードは時々更新されます。

毎日フルバックアップを実行するということは、最近変更されていないギガバイト単位のファイルを圧縮およびアーカイブすることを意味します。

この問題を解決するには、2つの別々のバックアップスケジュールを設定します。

• スケジュールA: データベースのみの毎日のバックアップ。データベースのみのバックアップは、ファイルに触れることなく、コンテンツ、注文、設定のすべての変更をキャプチャします。ほとんどのサイトでは30秒未満で完了します。これを毎日実行します。
• スケジュールB: 週に1回のフルサイトバックアップ。ファイルを含み、実際のトラフィックが最も少ない時間帯に週に1回実行します。これは、万が一問題が発生した場合に復元するバックアップです。

スケジュールを設定する前に、実際のトラフィックが少ない時間帯を見つけてください。典型的な週の中でセッション数が最も少ない2時間のブロックを探します。

ほとんどのサイトでは、これは午前2時から午前5時の間に収まりますが、ご自身のデータで確認してください。あなたのトラフィックパターンは他の誰とも同じではありません。

次に、Duplicator Pro » バックアップのスケジュール » 新規追加に移動します。スケジュールにデータベースバックアップのような名前を付けます。新しいバックアップテンプレートを追加します。

テンプレートに名前を付けます。データベースのみのバックアッププリセットを選択して保存します。

新しいスケジュールに戻り、作成したばかりのデータベースバックアップテンプレートを選択します。ストレージの場所を選択し、毎日実行するように設定します。

保存します。次に、2番目のスケジュールを作成し、プロセスを繰り返しますが、サイト全体のバックアップテンプレートを使用します。毎週実行するように設定してください。

両方のスケジュールが Duplicator Pro » スケジュールされたバックアップ に表示され、次の実行時間がリストされます。

ステップ7：増分バックアップを追加する

フルバックアップは、毎回サイト全体をゼロから圧縮します。これは毎週のサイト全体バックアップには適していますが、ほとんどのサイトでは毎日の保護にはそれ以上のものが必要です。

増分バックアップ は異なるアプローチを取ります。最初のフルバックアップの後、前回実行分から変更されたものだけを保存します。変更されていないファイルを再処理しないため、バックアップはより速く完了します。

Duplicator Pro は真の増分バックアップを実行しませんが、ステップ6の2つのスケジュールの戦略は、ほとんど同じメリットをもたらします。毎日のデータベースのみのバックアップは、通常のWordPressサイトで変更されたすべてをキャプチャし、30秒未満で完了します。毎週のサイト全体バックアップは、それ以外のすべてを処理します。

ほとんどのサイトでは、その分割により、増分バックアップが解決するように設計された実用的なニーズがカバーされます。

サイトが十分に大きい場合、毎週のサイト全体バックアップでさえ一貫して遅いか失敗する場合は、増分ファイルバックアップを実装する価値があるかもしれません。BlogVaultのようなツールは、サーバーではなくサーバー上でバックアップを処理するため、サーバー負荷の問題が解消されます。

ステップ8：より高いサーバーリソース制限を要求する

PHPのメモリと実行時間制限は実際の制約ですが、それらを変更するにはホストの協力が必要であり、肥大化したアーカイブやタイミングの悪いスケジュールなどの根本的な問題は解決しません。

まず前のステップを完了してください。バックアップがまだタイムアウトする場合は、ホスティングプランのリソース制限が上限である可能性があります。

バックアップ速度に最も影響する設定は2つです: memory_limit と max_execution_time です。

memory_limit は、PHPが単一のプロセス中に使用できるRAMの量を制御します。バックアップはメモリを大量に消費します。制限が64MBまたは128MBに設定されている場合、大きなビルドは容量不足になり、完了前に終了します。

少なくとも256MBを要求してください。ホストが512MBを提供している場合は、そちらを要求してください。

max_execution_time は、サーバーが終了する前にPHPプロセスが実行できる時間を制御します。多くの共有ホストではデフォルトで30〜60秒です。大きなバックアップにはそれよりも大幅に長い時間が必要です。300秒を要求してください。

ホストのサポートチームに連絡し、具体的な要求を伝えてください。memory_limit を512MB、max_execution_time を300秒に設定するように依頼してください。

ホストがこれらの制限を引き上げられない、または引き上げない場合、ステップ3のDupArchiveが実用的な解決策となります。プロセスをチャンク化することで、タイトなPHP制限内で動作するように特別に設計されています。能力のあるサーバーでのShell Execよりも遅いですが、標準のZIPビルドでは完了しない場所でも完了します。

制限を変更した後は、テストバックアップを実行し、ビルドログを開いてください。タイムアウトやメモリエラーなしでバックアップが完了したことを確認してください。

トラブルシューティング: バックアップがまだ遅い、または壊れている場合

上記のステップを完了することで、ほとんどのウェブサイトのバックアップ速度の問題が解決します。それでも問題がある場合は、最も可能性の高い状況と、それを乗り越える方法を以下に示します。

バックアップは完了するが、復元に失敗する

バックアップは成功したように見え、ビルドログに明らかなエラーは表示されませんが、インストーラーを実行するとエラーが発生するか、空のサイトが復元されます。

これは、PHP の実行時間制限により、ビルドが実際に完了する前に中断されたために発生します。ファイルはその時点までディスクに書き込まれ、その後停止しました。

DupArchive (ステップ 3 で説明) に切り替え、失敗したバックアップを削除して新しいバックアップをビルドします。インストーラーを実行し、復元が完了してから信頼できることを確認してください。

バックアップが特定のパーセンテージでスタックする

プログレスバーが特定のポイントでフリーズし、10 分以上動かずにそのままになります。

大きなファイルまたはロックされたデータベーステーブルが、ビルドのその正確なポイントでプロセスをブロックしています。バックアップログに移動し、ログが途切れる前にリストされた最後のファイルまたはテーブルを見つけるまでスクロールします。それが原因です。

ファイルの場合は、除外フィルター (ステップ 2) に追加して再ビルドします。データベーステーブルの場合は、SQL モードを PHP コード (ステップ 4) に切り替えてから再試行してください。

サイトが毎晩同じ時間に遅くなる

訪問者または監視ツールが、特定の期間中に応答が遅いと報告します。タイミングはスケジュールされたバックアップと一致します。

バックアップはアクティブなトラフィックの期間中に実行されており、訪問者にサービスを提供するのと同じ CPU およびディスク リソースを競合しています。Google Analytics で実際の低トラフィック時間を確認し、その時間にバックアップをスケジュールし直してください。

毎日フルサイトのバックアップを実行している場合は、ステップ 6 の 2 つのスケジュール戦略に切り替えてください。データベースのみのバックアップは十分に速く完了するため、中程度のトラフィック中でもパフォーマンスへの影響は最小限です。

Shell Execによりビルドが即座に失敗する

アーカイブ エンジンを Shell Exec に切り替えましたが、次のビルドが 0% で即座にエラーが発生して失敗します。

ホストがサーバーレベルで shell_exec を無効にしています。ZipArchive または DupArchive に戻してください。次に、ホストに連絡して、アカウントで shell_exec を有効にできるかどうかを具体的に尋ねてください。

彼らがノーと言った場合、DupArchive が長期的なアーカイブ エンジンになります。Shell Exec が解決したであろう同じタイムアウト問題を、異なる方法で処理します。

ステージングでは機能するが、ライブサーバーではバックアップが失敗する

バックアップはステージングサイトまたはローカルサイトでは成功しますが、本番環境ではタイムアウトするか、破損したファイルを生成します。

ライブサーバーにはより厳格な PHP 制限があるか、アクティブな CPU スロットリング下にあるため、ステージング環境にはありません。環境間の PHP 設定を比較してください: 両方で memory_limit と max_execution_time を確認してください。ライブホスト (ステップ 7) により高い制限を要求するか、DupArchive に切り替えて、存在する制限内で作業してください。

上記いずれでも問題が解決しない場合は、Duplicator Pro のサポート チームが次の適切なステップです。duplicator.com にアクセスしてサポート チケットを開きます。ビルドログ、PHP 設定、ホスト環境を含めてください。これら 3 つの情報があれば、一般的な問題の説明よりも早く解決に至ります。

よくある質問（FAQ）

ホストの制限時間を超える標準的なZIPビルドは、処理中に中断され、破損したパッケージが生成されます。DupArchiveは、各チャンクが時計をリセットするため、これらの制限を乗り越えます。

能力のあるサーバーではZIPよりも常に高速とは限りませんが、制約のある共有ホスティング環境では大幅に信頼性が高くなります。

より重要な質問は、最近復元をテストしたかどうかです。一度もテストしたことのないバックアップは、実際には機能するかどうかわからないバックアップです。ステージング環境を選択し、最新のバックアップを復元して、サイトが正しく読み込まれることを確認してください。

次回以降のバックアップを、うまくいくかどうかを気にせずに実行する

遅いバックアップは不便です。完了したように見えても復元できないバックアップは、まったく別の問題であり、ほとんどの人が予想するよりも一般的です。

このチュートリアルの設定は、共有ホスティングがWordPressのバックアップのために設計されていなかったために存在します。Duplicator Proはそうでした。

150万以上のWordPressのプロフェッショナルがDuplicator Proを使用して、あらゆる規模のサイトのバックアップ、移行、ステージング、および災害復旧を処理しています。DupArchive形式、2つのスケジュール戦略、およびファイル除外フィルターは、遅いまたはリソースを大量に消費するバックアップを回避するのに役立ちます。

このチュートリアルがお役に立った場合は、これらのガイドもブックマークする価値があります。

• WordPressのバックアップがサイトのパフォーマンスに与える影響（およびその修正方法）
• バックアップが失敗する理由を推測するのはやめましょう（代わりにこれらのログを確認してください）
• サイトがクラッシュしたばかりですか？完全なウェブサイト復旧計画はこちらです
• WordPressサイトでバックアップ監視が必要な理由（バックアップだけでは不十分）
• WordPressバックアップを動作中のウェブサイトとして表示する方法