WordPressのバックアップを破損させるもの：1,400件以上のサポートチケットから学ぶ教訓

見ている間に失敗するバックアップは迷惑ですが、数週間前に静かに停止したバックアップはサイトを失う原因となります。

ほとんどの人は、最悪のタイミングで自分がどちらの種類のバックアップを持っているかを知ります。

Duplicatorは、150万以上のサイトで実行されているWordPressのバックアップおよび移行プラグインです。人々がバックアップの問題に直面したとき、彼らは私たちに、彼ら自身の言葉で、詳細に伝えてくれます。

私たちは1,400件以上のバックアップ関連のサポートリクエストをレビューし、バックアップがどこで壊れるかを確認しました。パターンは予想以上に明確で、きれいに2つに分かれます。

バックアップは、ホストの制限によりビルドが停止するか、ファイルが作成されたものの、それをオフサイトに送信する別のステップが完了しないかのいずれかで問題が発生します。

これらのチケットが私たちに伝えたことは次のとおりです。

これらの数値はサポートチケットの件数を反映しており、顧客数、インストール数、販売数ではありません。

目次

主な発見事項

詳細の前にパターンを知りたいすべての人のために、チケットがWordPressのバックアップがどこで壊れるかについて述べていることを示します。すべての数値はDuplicator自身のサポート記録に基づいています。

• バックアップのトラブルは2つのクラスターに分かれます：ビルドを停止するホストの制限と、ファイル作成後に完了しないオフサイトアップロードステップです。
• ホストによるビルドの途中停止は、バックアップ作成で最も一般的な問題です。 チケットの約4分の1を占めます。これはWordPressの移行でも問題となるホスト制限と同じパターンであり、制限を引き上げればビルドはほぼ確実に完了します。
• ストレージ接続に関するチケットのうち、約10件中4件はクラウドプロバイダーでの認証または接続の失敗です。 ストレージへの接続は、プロバイダー側で時間とともに無効化されます。
• スケジュールされたバックアップの失敗には、2つの原因があります。 実行と実行の間にオフサイトアップロードが中断されること（約4分の1）、および保持期間の上限が設定されていない場合に古いバックアップがサーバーのディスクを使い果たすこと（約7分の1）です。
• ほとんどのスケジュールされたバックアップの問題は、正常に動作していたセットアップの後で発生します。 セットアップ中ではありません。スケジュールは初日から問題なく、後で接続が失われました。

要するに： バックアップエンジンは通常、その仕事をこなします。問題を引き起こすのは、ホストがビルドを制限するか、セットアップ後にオフサイトストレージへの接続が失われることです。どちらも、どこに注意を払うべきかを知れば予防できます。

これらすべてを読む上で考慮すべき1つの注意点があります。これらはサポートチケットであり、バックアップが問題に遭遇する場所を示していますが、その頻度を示すものではありません。

また、誰も気づかなかった問題を捉えることはできません。このデータ内の全員が問題を特定し、チケットを提出したからです。サイト所有者が決して見ることのない、静かなケースは、このデータセットには全く含まれていません。

バックアップが失敗する2つの方法

私たちが目にするバックアップの困難のほぼすべては、2つのシナリオのいずれかです。それらを区別できるようになれば、修正は明らかです。

最初の問題はサーバーに起因します。 ビルドは開始され、しばらく実行されますが、ホストは通常、最も負荷の高いステップで、完了する前にそれを停止します。

2番目の問題はオフサイトコピーに関するものです。 バックアップファイルは作成されますが、それをストレージに送信する別個のステップは、そのステップがWordPress外の接続に依存しているため完了しません。

問題1：ホストの制限によりビルドが停止する場合

バックアップを開始し、実行状況を確認しますが、完了せずに失敗します。

これは私たちが目にする最も一般的なバックアップの問題であり、ほぼ常にバックアップ自体ではなく、ウェブホストが原因です。ビルドは開始されますが、サーバーが途中でそれをカットします。通常は最も負荷の高い作業の時点です。

これらのビルドは、ホスト制限が引き上げられれば、ほぼ常に完了します。変動要因はエンジンではなく、サーバーの上限です。

1つの失敗が他のすべてを大きく上回っています。バックアップチケットの約4分の1では、ホストが最も負荷の高い瞬間にプロセスをカットしたため、ビルドが途中で停止します。リストの残りは、同じテーマのバリエーションです：

ビルドが停止する場所	おおよその頻度	通常、その背後にあるもの	どのように解決されるか
ホスト制限によりビルドが途中で停止する	4分の1	ホストのPHPタイムアウトまたはメモリキャップが最も負荷の高いステップ中に発生する	PHP制限を引き上げるか、大きなアーカイブ用に構築されたインストーラー（DupArchive）を使用する
制約のあるホストでアーカイブステップが失敗する	約8分の1	圧縮中のディスク容量またはPHP制限が不足する	ディスク容量を解放し、PHP制限を引き上げてから、チャンクビルドで再試行する
ホストが処理できないほどサイトが大きい	約12分の1	大きなデータベースまたはメディアライブラリがサーバー制限を超える	ビルドを分割し、バックアップに不要な大きなファイルを除外する
サーバーでのPHPタイムアウト	約20分の1	サイトサイズに対して実行制限が低すぎます	サーバーのmax_execution_timeを増やす
サーバーフォルダの権限	約22分の1	アーカイブをディスクに書き込めません	サーバーのフォルダ権限を修正する
サーバーのメモリ制限を超過しました	約25分の1	ビルドの実行中にメモリが不足します	memory_limitを増やす

同じ原因が繰り返し現れます：ホストです。アーカイブが組み立てられている最中にサーバーが制限したため、エンジンがギブアップしたのではなく、ビルドが停止します。

それもサイトサイズが非常に重要である理由です。大きなデータベースやメディアライブラリは、ホストの制限値ぎりぎりまでビルドをプッシュします。

Duplicator ProのスタンドアロンインストーラーとDupArchive形式は、大規模サイトのバックアップのために構築されています。DupArchiveには理論的なファイルサイズ制限がなく、400GBまでの実際のバックアップを処理してきました。

サイトのリソースの問題を解決するためのステップバイステップのヘルプについては、WordPressの大規模サイトをバックアップする方法に関するガイドをお読みください。

問題2：オフサイトアップロードが完了しない場合

数ヶ月間はすべて順調に見えました。先週のバックアップをGoogle Driveから取得しようとすると、フォルダが予想よりも空っぽでした。

バックアップは作成されていました。ただ、想定していた場所に保存されていなかっただけです。

バックアップファイルはサーバー上に作成されます。オフサイトへの送信は別のステップであり、そのステップはWordPress外のクラウドストレージまたはリモートサーバーへの接続に依存します。

その接続が切断されると、ファイルは存在しますが、オフサイトのコピーは存在しません。必要になるまでそのギャップに気づかないでしょう。

それは3つのことに集約されます。

プロバイダー側でストレージ接続が切断された

ストレージ接続に関するチケットの約40％は、クラウドプロバイダーとの認証に起因します。接続はセットアップ時には機能しましたが、その後プロバイダーがそれを尊重しなくなりました。

クラウドストレージ接続は、時間とともに期限切れになるか取り消されるアクセスに依存しており、これはWordPressではなくストレージプロバイダーによって制御されます。

Google Drive、Dropbox、OneDriveのようなOAuthベースの接続は、定期的な再承認が必要なトークンを使用します。

Amazon S3のようなキーベースの接続は、ローテーションまたは拒否される可能性のある認証情報に依存します。FTPとSFTPは、パスワードまたはパスが変更されると失敗します。

ファイルは作成されます。プロバイダー接続が切断されます。

接続を再承認し、定期的に再確認してください。トークンを使用する接続は、最終的には再承認が必要になるため、一度限りのセットアップではなく、ルーチンメンテナンスとして扱ってください。

古いバックアップがサーバーのディスクを使い果たした

約7件に1件のスケジュールされたバックアップの失敗はディスクの空き容量不足が原因であり、その修正はあなたが制御できる設定にあります。

保持期間の上限を設定しない限り、バックアップは蓄積されます。上限がない場合、スケジュールされたすべてのバックアップはサーバーの容量がいっぱいになるまで保持され、次の実行では書き込み場所がなくなります。

Duplicatorを使用すると、保持するバックアップの数を制限できるため、古いバックアップは自動的に削除され、ディスクはクリアされたままになります。

明確な保持期間を設定することで、サーバーをいっぱいにするゆっくりとした蓄積を停止できます。

実行間に接続が失効しました

初日には機能していた接続が、数週間後に静かに切断され、スケジュールされた実行もそれに伴ってダウンします。

通常、これには2つの原因があります。時々、タイムゾーンまたは頻度の混乱が原因です。他の times、ホストがバックグラウンドジョブをトリガーする前に終了させます。

いずれにしても、それについて知りたいはずです。Duplicatorは、スケジュールされたバックアップまたはアップロードが失敗したときに警告を発するため、壊れた実行は静かに座っているのではなく、あなたに届きます。

スケジュールがまだ接続されていることを確認し、ホストがサポートしている場合は、実際のサーバーcronを使用してください。サーバーcronは、誰かがサイトを訪問したときにのみトリガーされるデフォルトのWordPress cronよりも信頼性が高くなります。

定期的なバックアップ更新により、スケジュールが失敗し始めた正確な時期を認識するのに役立ちます。Duplicatorからの毎日の、毎週、または毎月の通知の電子メール概要を設定してください。

バックアップが現在安全かどうかを確認する方法

バックアップをベビーシッターする必要はありません。静かに発生する5つのことをキャッチするだけでよく、約2分でそれらすべてを確認できます。

• スケジュールが存在するだけでなく、最後のスケジュールされたバックアップが完了したことを確認してください。
• サイトを保持しているのと同じサーバーだけでなく、コピーがオフサイトにあることを確認してください。
• 特に設定から数ヶ月経過している場合は、ストレージ接続がまだ承認されていることを確認してください。
• ディスクがいっぱいにならないように、保持期間が設定されていることを確認してください。
• 失敗通知をオンにして、壊れた実行があなたに届くようにしてください。

初めて設定する場合、または既存のスケジュールを強化したい場合は、自動WordPressバックアップに関するガイドでセットアップの手順を確認してください。

このレポートは、その後の監視方法と問題を早期に発見する方法についてです。

Duplicator Proは、このデータが表示される2つの領域で役立ちます。バックアップまたはアップロードが失敗したときに失敗通知を送信します。また、クラウドストレージから直接復元するため、バックアップファイルをサーバーに再アップロードせずに変更を元に戻すことができます。

よくある質問（FAQ）

確認しないバックアップは失敗するバックアップです

このデータの値は単一の統計ではありません。注意を向けるべき場所を示しています。

バックアップのトラブルは2つの箇所に現れます。ビルドを停止するホスト制限と、オフサイトコピーが完了しないことです。前者はうるさく、すぐに気づくでしょう。後者は静かで、必要な時にオフサイトバックアップがない状態にしてしまうものです。

正直さを保つために、制限をもう一度述べます。これは人々が報告した問題の記録であり、実行されたすべてのバックアップの記録ではありません。誰も気づかなかったケースは見ることはできません。しかし、それは現実であり、直接的なものです。

ここに、これらすべてに勝る一つの習慣があります。一度、ステージングサイトにバックアップを復元し、サイトが復旧することを確認してください。復元したことのないバックアップは推測です。一度復元したバックアップは計画です。

次のバックアップの前に、ストレージに到達していることを確認してください

バックアップが停止したり、オフサイトへのアップロードが完了しなかったりすると、復元が必要になったときに問題になります。それは知るのに最悪のタイミングです。

Duplicator Proは、150万人以上のWordPressのプロフェッショナルによって、サイトのバックアップ、移行、復旧に使用されています。バックアップの失敗通知を送信し、クラウドストレージから直接復元するため、作成したコピーは取り戻せるコピーです。

ついでに、これらの他のWordPressリソースも一見の価値があります。

• 8,000件以上のサポートチケットが明らかにするWordPress移行が失敗する理由
• ウェブサイトのバックアップの間違いを犯すのをやめましょう（サイトを危険にさらしています）
• WordPressサイトはどのくらいの頻度でバックアップすべきか？
• WordPressサイトの安全なバックアップストレージを取得する方法
• WordPressサイトでバックアップ監視が必要な理由（バックアップだけでは不十分）