BackupBuddyのタイムアウトを解決する方法

BackupBuddyバックアップでタイムアウトが発生するのを見ると、非常にストレスがかかり、混乱する可能性があります。 この投稿では、BackupBuddyのタイムアウトを引き起こす最も一般的なタイプの問題とその解決方法について説明します。

BackupBuddyのタイムアウトが発生するのはなぜですか？

BackupBuddyのタイムアウトはさまざまな理由で発生する可能性があるため、Webサイトが実行されているサーバーを理解することが重要です。 BackupBuddyのタイムアウトは、BackupBuddyがバックアップのZIPアーカイブを作成しているときはいつでも、サーバーがバックアップを処理する方法を中心に展開することがよくあります。

バックアップを実行しているサーバーがプロセス全体を処理できない場合、BackupBuddyは圧縮プロセスを停止し、タイムアウトになります。 バックアップの圧縮はバックアップの重要な部分であるため、トラブルシューティングの手順をいくつか知っておくとよいでしょう。

たとえば、最も一般的なタイムアウトは、サーバーソフトウェアの一種であるLitespeedで実行されているWebサイトで発生します。 どうして？ Litespeedは、指定された時間が経過すると、実行時間の長いPHPプロセスをキャンセルすることがよくあります。 たとえば、25秒後にプロセスを停止するように設定されている場合、バックアップがチャンクあたりの最大時間に達していない場合、結果はタイムアウトになります。

チャンクあたりの最大時間を変更する

デフォルトでは、BackupBuddyがプロセスを完了するための最大実行時間は、サーバー構成によって定義されます。 これをオーバーライドするには、チャンクあたりの最大時間設定を20秒に変更することを検討してください。 これにより、バックアップが分割され、各チャンク処理が20秒未満で実行され、25秒のタイムラインが短縮されます。

私のサーバーは大丈夫のようです、それで次は何ですか？

サーバーが正しく構成されていてもタイムアウトが発生する場合は、サーバーがスクリプトを実行しているか、ZIPアーカイブを処理しているときに問題が発生している可能性があります。 この例は、ほとんどのサイトで推奨されているzip圧縮の実行です。

Zip圧縮を有効にする

Zip圧縮により、バックアップに保存されるファイルのサイズが減少しますが、サーバーの実行時間が長すぎる可能性があり、タイムアウトが発生します。 zip圧縮を無効にすると、ZIPアーカイブ全体のサイズが大きくなる可能性がありますが、サーバーで圧縮に問題がある場合は役立ちます。 これは、タイムアウトを解決する最も一般的なトラブルシューティング手順です。

BackupBuddyタイムアウトのトラブルシューティング

Litespeedサーバー

バックアップがタイムアウトしないようにするための最初の賭けは、サーバー構成を確認することです。 以下のこのコードスニペットにより、BackupBuddyをLitespeedの制約外で実行できるようになります。

Litespeedで実行している場合は、これを.htaccessファイルに追加してみてください。

 <IfModule LiteSpeed>
DisableCgiOverride On
RewriteEngineオン
RewriteRule（wp-cron | backupbuddy | importbuddy）\。php- [E = noabort：1、E = noconntimeout：1]
</ IfModule>

注：.htaccessファイルが見つからない場合は、隠しファイルを表示するオプションがあることを確認してください。

コードを追加したら、ファイルを再アップロードして、古いファイルを新しい変更で上書きします。

チャンクあたりの最大時間

BackupBuddyのモダンモードは、wp-cronを利用してバックアップをチャンクに分割しますが、一部のサーバーはチャンク時間を途中でカットし、タイムアウトにつながる可能性があります。 タイムアウトが発生している場合は、値を変更して、サーバーの報告時刻より前にBackupBuddyが各チャンクを実行する必要があるようにすることを検討してください。

Zip設定

Litespeedで実行していない場合は、BackupBuddyのタイムアウトを回避するためにBackupBuddyのzip設定を構成することをお勧めします。 これらの設定は、BackupBuddyがバックアップを圧縮する方法に厳密に関連しています。

最初のステップは、zip圧縮を実行しているかどうかを確認することです。 zip圧縮を実行していてタイムアウトが発生している場合は、無効にしてみてください。 これにより、サーバー（特に共有サーバー）に圧縮能力がないため、約70％の確率で問題が修正されます。

Zip設定内からzip圧縮を無効にしてから、バックアップを再試行してください。 ZIPアーカイブが少し大きく見えるかもしれませんが、これはアーカイブが圧縮されていないためです。

代替ZIPシステム

代替Zipシステムは、zip圧縮を無効にした後もバックアップでタイムアウトが発生する場合に最適なソリューションです。 標準のZIPシステムは、実際のZIP実行可能ファイル（コマンドライン）またはライブラリ（PclZip）です。 バックアップルートディレクトリと除外リストを指定すると、サイトがスキャンされ、ZIPアーカイブのファイルリストが内部で決定されてビルドされます。 プロセスが進行中になると、中断することはできず、ほとんどの場合、完了するまで実行されます。これにより、一部のサーバーでタイムアウトが発生する可能性があります。

Alternative Zip Systemは、ZIPアーカイブのファイルのリストを作成するためにスキャンを実行します。 それを制御できるため、ZIPアーカイブに追加されるファイルの実行可能ファイル/ライブラリリストを提供できます。 これにより、Alternative ZIPシステムは、ファイルの各セットが追加された後に制御を取り戻したいので、「バースト」を実行できます。 これは、圧縮プロセス中にサーバーで発生する可能性のあるタイムアウトを軽減するのに役立ちます。

Alternative Zip Systemを有効にすると、これらの設定がデフォルトで適用されます。

• 先に進み、 Zipビルド戦略を「マルチバースト/シングルステップ」のままにします。これにより、ZIPアーカイブのビルドが速くなります。「マルチバースト/マルチステップ」戦略は、ビルド中にタイムアウトしたサーバーに対して作成されます。 ZIPアーカイブ。 ZIPアーカイブの構築中にバックアップがタイムアウトする場合は、「マルチバースト/マルチステップ」に変更する必要があります。
• [チャンクあたりの最大時間]オプションは、新しい継続ステップを一時停止してスケジュールする前に、BackupBuddyがZIPアーカイブビルドの実行を許可する最大時間です。 一部のサーバーは通知なしに時期尚早にタイムアウトするため、ZIPアーカイブが停止する可能性があります。 圧縮プロセス中にZIPアーカイブがタイムアウトした場合は、ここで値を設定するとタイムアウトを軽減できます。 サーバーの最大実行時間が30秒の場合は、値を25秒に減らしてみてください。 これにより、BackupBuddyは25秒未満で各プロセスを実行し、サーバーによって設定された30秒の実行時間を超えません。
• zipビルドバースト間のギャップオプションは、各ZIPアーカイブビルドバースト間に適用されます。 一部のサーバー/ホスティングでは、バースト間の期間を短くして、サーバーが操作に追いつくことができるようにしたり、CPUとディスクの使用量を分散することで、時間の経過に伴う平均負荷を軽減したりできるというメリットがあります。 このオプションは、デフォルト（2秒）のままにしておくのが最適です。
• シングルバースト（MB）オプションの最小コンテンツサイズは、 BackupBuddyにバースト要求ごとに追加する必要のあるコンテンツの最小量を指示します。 デフォルト値は10MBで、ほとんどのサーバーが処理できるのに十分です。 サーバーが最小量のコンテンツを処理できない場合を除いて、この値を同じに保つのが最善です。
• シングルバースト（MB）オプションの最大コンテンツサイズは、 BackupBuddyにバースト要求ごとに追加する必要のあるコンテンツの最大量を指示します。 デフォルト値は100MBです。 ただし、一部の安価なホスティングプランでは、要求されているこれだけのコンテンツを処理できない場合があります。 代替Zipシステムを有効にしてもタイムアウトが発生する場合は、最大で50MBから開始して、この設定を微調整することをお勧めします。

データベースのダンプ中にタイムアウトするバックアップ

データベース部分でバックアップがタイムアウトする場合があります。 データベースステップは、すべての行をそれぞれのテーブルにダンプし、バックアップ内に追加される.sqlファイルを作成します。 このステップでは、主に2つの理由でタイムアウトが発生する可能性があります。ダンプされるテーブルが何らかの形で破損しているか、wp-cronに問題があります。

破損したデータベーステーブル

どのテーブルがタイムアウトを引き起こしていますか？ 破損している可能性があるため、タイムアウトの原因となっているテーブルを確認することをお勧めします。 テーブルはPhpMyAdminから表示できます。または、ホスティングプロバイダーがデータベース管理ソリューションを提供している場合は、そこで表示できます。

• テーブルをバックアップから除外してみて、問題が軽減されるかどうかを確認してください。 含まれている場合は、テーブルが破損している可能性があります。

WP Cron

データベースの最初のテーブルがタイムアウトしている場合は、wp-cronに問題がある可能性があります。 wp-cronとその機能に慣れていない場合は、ドキュメントWPcronを確認してください。

BackupBuddyは、データベースダンプに対して実行するcronジョブをスケジュールするcronPassステップを実行するため、この時点でcronジョブを実行している別のプラグインがあると、競合が発生する可能性があります。

• サイトでキャッシュを使用している場合は、これがcronの一般的な問題であるため、キャッシュをフラッシュします。
• BackupBuddyを除くすべてのプラグインを一時的に非アクティブ化して、この競合の原因となっているプラ​​グインを見つけることもできます。
• また、サーバーでwp-cronが有効になっているかどうか、wp-cronが無効になっていないか、cronジョブが作成されていないか、正しく設定されていないかを確認することもできます。 これにより、cronの問題が発生する可能性があります。

サーバーでwp-cronが有効になっているかどうかは、BackupBuddyサーバーツールページ（BackupBuddy->サーバーツール）にアクセスして確認できます。 「サーバー」タブの下に、サーバー環境に固有の構成のリストがあります。

BackupBuddyタイムアウト内のエラー

エラーはバックアップ中にも発生する可能性があり、ほとんどの場合、タイムアウトのように見える圧縮プロセスです。 トラブルシューティング中にステータスログを確認し、タイムアウト前にエラーが発生したかどうかを確認することをお勧めします。

一般的に、最も一般的なタイプのエラーはPHPから報告されます。 最も一般的なタイプのエラーは、PHPメモリに関するものです。 サーバーがexec（コマンドライン）ZIPメソッドまたはZipArchiveをサポートしていない場合、サーバーはPclZipを使用します。 PclZipはPHPをZIPユーティリティツールとして使用するため、PHP構成に依存してZIPタスクを実行します。

PHPを実行するすべてのサイトでは、php.iniファイルにPHPメモリが設定されており、メモリを超えると、次のエラーが返されます。

 致命的なエラー：許可されたメモリサイズ33554432バイトが使い果たされました（2348617バイトを割り当てようとしました）

サーバーがexecをサポートしていない場合は、バックアップが完了するまで実行できるように、PHPメモリを増やす必要があります。

まとめ

ご覧のとおり、BackupBudyのタイムアウトが発生した場合に考慮すべきさまざまな要因があります。 トラブルシューティングを行うときは、このタイムアウトが発生した理由に関する詳細情報が提供されるため、ステータスログを読み取ることが重要です。 また、サーバーとその構成を理解することで、バックアッププロセスを実行する際のサーバーの機能についてより多くの洞察を得ることができます。 上記の手順を実行すると、タイムアウトを処理するための最も一般的なトラブルシューティング手順が提供されます。

それでもBackupBuddyのタイムアウトで問題が発生する場合は、サポートチームが待機しています。 今すぐiThemesヘルプデスクにアクセスして、サポートチケットを開いてください。