WordPressのバックアップが遅い、または失敗する理由（およびその修正方法）

WordPressのバックアップが45分間実行されています。何も壊れていませんが、プログレスバーが動き続けています。または、1時間前に63％で停止し、それ以来動いていません。

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

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

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

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

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

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

目次

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

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

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

• ホストI/O制限

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

• サイトサイズ

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

• バックアップ方法

フルバックアップは、毎回すべてをゼロから圧縮します。増分バックアップは、最後の実行以降に変更されたもののみを保存するため、最初のバックアップが完了した後はより高速になります。

Duplicatorは真の増分バックアップを実行しませんが、このチュートリアルの2つのスケジュール戦略は、ほとんど同じメリットをもたらします。毎日のデータベースのみのバックアップは、通常のサイトで実際に変更されたものをキャプチャし、重いフルサイトビルドは週次で実行されます。

• PHPタイムアウト

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

開始する前に必要なもの

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

• インストールされアクティブ化されたWordPressバックアッププラグイン。このチュートリアルでは、150万以上のWordPressプロフェッショナルによって使用されているWordPressバックアップ、移行、および災害復旧プラグインであるDuplicatorを使用します。バックアップ、サイト移行、ステージング、復元を処理します。これには、共有ホスティングで一般的な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メモリと実行時間制限を増やします。

ここから始める：AutoTuneで設定を見つける

ウェブサイトの設定を変更する前に、Duplicatorにテストさせてください。

DuplicatorのAutoTuneは、サーバーで実際のテストバックアップを実行します。最も高速な設定から開始し、テストが失敗すると、失敗の原因となった設定のみを変更して再度試行し、バックアップが成功するまで続けます。

これは、手動で実行するのと同じプロセスですが、数分で完了し、午後を費やす推測と検証の必要はありません。

バックアップページの最上部にあるAutoTuneをクリックするか、ツール » AutoTuneに移動します。次の項目を処理します。

• アーカイブエンジンと圧縮
• ZIPモードとチャンクサイズ
• データベースエンジンとPHPダンプモード
• サーバー負荷の軽減

また、サーバー概要パネルもあり、ワーカーモード、ループバックリクエスト、HTTP認証、プロセスロック、PHPの時間とメモリの制限をチェックします。

各項目は合格または不合格となり、注意が必要な場合はアドバイスが添付されます。一部の問題はサーバーレベルにあり、プラグインの設定では修正できません。AutoTuneはそれらをフラグ付けし、ホストに何を依頼すべきかを伝えます。

スケジュールされたバックアップを実行している場合、AutoTuneがテストしている間は一時停止し、完了すると再開されるため、チューニング実行が夜間のビルドと衝突することはありません。

ほとんどの人にとって、これで完了です。AutoTuneの結果がまだ十分に速くない場合、何が変更されたのかを理解したい場合、または各オプションを自分で設定したい場合は、読み続けてください。

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

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

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

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

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

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

ビルドログにバックアップが完了したと表示されても、復元中にバックアップが失敗する場合、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

DupArchiveはDuplicator独自のアーカイブ形式であり、標準のZIPとは異なる動作をします。1つの連続した圧縮操作の代わりに、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: 次のバックアップの前にデータベースをクリーンアップする

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

DB Optimizerをインストールし、実行して、投稿リビジョン、スパムコメント、期限切れの一時データ、孤立したメタデータを削除します。これらはアクティブなサイトで静かに蓄積し、復元する必要のあるものは何も含まれていないにもかかわらず、データベースの肥大化の30〜50％を占める可能性があります。

DB OptimizerはDuplicator Proに無料で含まれています！

ただし、データベースをクリーンアップしてすぐに初めての重要なバックアップを実行しないでください。クリーンアップを実行してから、サイトを閲覧してすべてが正常に機能することを確認し、その後バックアップしてください。

信頼できるツールで行われるクリーンアップは安全ですが、バックアップにその状態を固定する前に、サイトが正常であることを確認したいはずです。

両方の変更を行った後、新しいバックアップを実行し、ビルド時間を以前のベースラインと比較してください。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 » スケジュールされたバックアップ に表示され、次の実行時間がリストされます。

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

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

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

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

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

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

バックアップは作成されるが、ストレージに到達しない

ビルドログにはアーカイブが完了したと表示されますが、ファイルはDropbox、Google Drive、またはS3バケットに表示されません。バックアップはローカルに存在します。転送が失敗しました。

3つの原因で、これらのほとんどをカバーできます。

• ストレージアカウントがいっぱいのため、アップロードが開始されても途中で失敗します。
• 接続トークンが期限切れになりました。これは、パスワードの変更後や、アプリの権限が取り消された後に発生します。
• アーカイブが、宛先が単一のアップロードで受け入れられるサイズよりも大きいです。

最初にストレージアカウントの空き容量を確認し、次にDuplicatorで宛先を再接続してトークンを更新してください。両方が正常に見える場合は、ファイルサイズが原因である可能性が高いです。ステップ2の除外フィルターを使用してアーカイブを縮小するか、日次実行がデータベースのみになるようにスケジュールを分割してください。

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

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

最初にDuplicatorのAutoTuneを実行してください。推測することなく、サーバーに対してチャンクサイズとエンジンをテストします。

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

ファイルの場合は、除外フィルター (ステップ 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バックアップを動作中のウェブサイトとして表示する方法