インクリメンタルバックアップはどれくらいのストレージ容量を使用しますか？実際のサイト3つで測定しました
Joella Dunn
Joella Dunn
John Turner
ジョン・ターナー
毎時のバックアップは、日中に変更があるサイトに適しているようです。次に計算すると、1日あたり24回のフルサイトバックアップは、サーバーリソースとストレージの両方で増加し始めます。
インクリメンタルバックアップはそれを解決するはずです。
インクリメンタルバックアップは、ベースラインと呼ばれるサイトの1つのフルコピーから始まります。それ以降の各バックアップは、変更されたものだけを保存するスナップショットです。これらが連携してチェーンを形成し、いつでもサイト全体を復元できます。
ほとんどの節約額は推定値ですが。そこで、私のチームと私は、静かなブログ、非営利のコースサイト、そして賑やかなオンラインストアの3つの実際のWordPressサイトで、Duplicatorの新しい増分バックアップをテストしました。
3つすべてで、増分バックアップは同じスケジュールでのフルバックアップよりもはるかに少ないストレージを使用しました。
賑やかなストアは、約85 GBから約12.8 GBになり、85％削減されました。毎日のフルバックアップと比較して、トラフィックの少ない2つのサイトでも優位性は保たれました。ストアはそうではなく、その理由はこの記事の最も有用な部分です。
主なポイントは次のとおりです：
- 典型的な増分スナップショットは、ブログとコースサイトではサイト全体の約1％、ストアでは約12％でした。
- トラフィックの少ないサイトでは、1時間ごとの増分バックアップは、同じ期間の毎日のフルバックアップを保持するよりもストレージが少なくなります。 10日間で、ブログでは約68％、コースサイトでは10％から56％削減されると予測され、1日あたり24回の復元ポイントがありました。
- 賑やかなストアでは、増分バックアップは、同じ2時間ごとのスケジュールでのフルバックアップよりも85％少ないストレージを使用しました。データベースは、実行間に多くのテーブルが変更されるため、スナップショットサイズを左右します。毎日のフルバックアップと比較して、1日あたり12回の復元ポイントと引き換えに、約46％多くのストレージを使用すると予測されました。
- 3つのサイトすべてで、10日間で同じ頻度で取得されたフルバックアップよりも88％から99％少ないストレージを使用すると予測されました。
- トラフィックの少ないサイトでは、1時間ごととは、実際のcronジョブによる1時間ごとを意味します。
目次
- 主な発見：インクリメンタルバックアップはどれくらいのストレージ容量を使用しますか？
- インクリメンタルバックアップのストレージをどのように測定しましたか？
- ストレージの計算：インクリメンタルバックアップ対デイリーフルバックアップ
- 静かなブログでの毎時スナップショットはどれくらいのストレージを使用しますか？
- コースサイトでプラグインが更新されるとどうなりますか？
- 賑やかなストアでインクリメンタルスナップショットが大きくなるのはなぜですか？
- Duplicatorではインクリメンタルバックアップはどのように機能しますか？
- インクリメンタルバックアップを最大限に活用するにはどうすればよいですか？
- よくある質問（FAQ）
主な発見：インクリメンタルバックアップはどれくらいのストレージ容量を使用しますか？
3つのサイトの比較は次のとおりです。
| 静かなブログ | コースサイト | 賑やかなストア | |
|---|---|---|---|
| サイト全体（ベースライン） | 約390 MB | 約540 MB | 約3.5 GB |
| 典型的なスナップショット | 約3.5 MB | 約7.5 MB | 約400〜460 MB |
| スナップショット対サイト全体 | 約1％ | 約1％ | 約12％ |
| スケジュール | 1時間ごと | 1時間ごと | 2時間ごと |
| スキップされた実行（変更なし） | 約20分の1 | 約半分 | なし |
短いバージョン：サイトの更新が主に投稿やページで行われる場合、1時間ごとの差分バックアップは、同じ期間の1日ごとのフルバックアップを保持するよりもストレージ使用量が少なくなります。終日注文を受ける場合は、各スナップショットは大きくなりますが、それでもその頻度でフルバックアップを実行するよりもはるかに少ないストレージで済みます。
インクリメンタルバックアップのストレージをどのように測定しましたか？
デフォルトのテーブル設定で、3つのサイトすべてでDuplicator Proの差分バックアップを実行しました。すべてのサイズは、Duplicatorの「スナップショット」テーブルの「サイズ」列から取得したもので、Duplicator Cloudが報告するものと一致します。
注意：これらは3つの実際のサイトであり、Duplicatorユーザー全体の平均ではありません。ストアのスナップショットサイズは約2日間、コースサイトは約6日間、ブログは約10時間（約1週間の実行履歴あり）をカバーしています。ブログはDuplicator Pro 5.2ベータ版を実行し、他の2つは5.1.0を実行しました。リアルタイムバックアップ、その他のストレージ、または復元速度はテストしていません。
ストレージの計算：インクリメンタルバックアップ対デイリーフルバックアップ
ほとんどの節約額は、差分バックアップと、それと同じ頻度で取得されたフルバックアップを比較したものです。ただし、1日に24回のフルバックアップを実行するユーザーはほとんどいないため、1日1回のフルバックアップとも比較しました。
ここでは、各サイトの履歴を同じ10日間に投影した結果を示します。
| 10日間の履歴 | 差分バックアップチェーン | 1日1回のフルバックアップ10回分 | 同じ頻度のフルバックアップ |
|---|---|---|---|
| 静かなブログ（1時間ごと） | 約1.2 GB | 約3.9 GB | 約93 GB |
| コースサイト（1時間ごと、すべての実行がトリガーされた場合） | 約2.4～4.9 GB | 約5.4 GB | 約130 GB |
| 忙しいストア（2時間ごと） | 約52 GB | 約35 GB | 約425 GB |
この予測について：これらは測定値ではなく推定値です。すべての実行がトリガーされ、典型的なスナップショット（ストアの場合は平均約400 MB）がアップロードされ、すべてのフルバックアップがベースラインと同じサイズであり、保持するバックアップ数に達すると古いスナップショットがベースラインに折りたたまれることを想定しています。コースサイトの範囲は、静かな日から更新のある日までをカバーしています。
3つのサイトすべてで、同じ頻度で取得されるフルバックアップよりもはるかに少ないスペースで済みます。ストアは425 GBから約52 GBに削減されます。1日1回のフルバックアップと比較すると、ブログとコースサイトは依然としてスペースが少なくなります。ストアは1.5倍のスペースを使用しますが、その見返りに1日1回の復元ポイントではなく12回の復元ポイントが得られます。
スナップショットサイズがその差を説明しています。各復元ポイントは、フルバックアップ1回ではなくスナップショット1回を消費するため、スナップショットが小さいほど節約効果が高くなります。スナップショットが1%の場合、チェーンが長くなるにつれて最大約99%節約できます。スナップショットが12%の場合、上限は約88%です。
短いチェーンでは節約額が少なくなります。これは、ベースラインが総量の大部分を占めるためです。ブログは10回のバックアップで89%節約しました。
差分バックアップはDuplicator Cloudにのみ送信されるため、合計ストレージはクラウドプランに直接対応します。10日間の履歴で、ブログは2 GBプラン、コースサイトは10 GBプラン、ストアは100 GBプランに収まります（約52 GBは50 GBプランをわずかに超えます）。
サイトのバックアップストレージをどのように計算しますか？
数日分のスナップショットが取得できたら、これを実行できます。まだ開始していない場合は、まず差分バックアップの実行ガイドに従ってください。
両方のサイズは、Duplicator Pro » Incremental Backups の Snapshots テーブルにあります。Baseline の行と、他のスナップショット（最大値ではない）の中間値を使用してください。
まだ増分バックアップを実行していませんか？ 最新のフルバックアップサイズをベースラインとして使用してください。スナップショットについては、静的なサイトの場合はその1%、アクティブなストアの場合は12%を試してください。
この計算機に入力して、独自の増分バックアップストレージを推定してください。
増分バックアップストレージ計算機
数値を入力して、増分バックアップが使用するストレージ量を推定してください。
| 保持する履歴 | |
|---|---|
これは、スケジュールされたすべての実行が増分スナップショットをアップロードし、古いスナップショットがベースラインに折りたたまれると仮定した推定値です。アップデート日や大規模なインポートのために十分な余裕を残してください。
たとえば、1 GBのサイトで10 MBのスナップショットと1週間の時間ごとの履歴（168回のバックアップを保持）が必要な場合、約2.7 GB必要です。1週間の日次フルバックアップでは7 GBかかります。
静かなブログでの毎時スナップショットはどれくらいのストレージを使用しますか？
ブログのベースラインは約390 MBで、時間ごとのスナップショットは約3.5 MBでした。
これはサイトの約1%に相当します。
驚いたのは、スキップがどれほどまれだったかということです。新しい投稿がない日でも、バックアップするものが何もないと判断されたのは約20回の実行に1回だけでした。ほとんどすべてのスナップショットで「ファイル変更なし・8テーブル」と表示されました。これは、プラグインがバックグラウンドでデータベースに書き込むためです。
それは正常であり、非常に少ないスペースしか使用しません。
スナップショットを減らしたい場合は、Duplicator Pro » Incremental Backups » Settings に移動し、ノイズの多いテーブル（プラグインが常に更新するもの）を「監視しない」に設定してください。それらはバックアップに残りますが、その変更は新しいスナップショットをトリガーしません。
コースサイトでプラグインが更新されるとどうなりますか？
コースサイトのベースラインは約540 MBで、典型的なスナップショットは約7.5 MBでした。これも約1%です。
アップデートの日は異なりました。2つのスナップショットで数千の変更されたプラグインファイルがキャプチャされ、サイトの約7%と11%を占めました。これらは通常の活動からの最大のスパイクでしたが、それでもフルバックアップよりはるかに小さいものでした。
実行の約半分がスキップされました。何も変更されなかった場合、Duplicatorは実行を「スキップ済み」とマークし、何もアップロードしませんでした。
1つの落とし穴がありました。スケジュールは時間ごとでしたが、1か月で約4時間に1回しか実行されませんでした。WordPressは、誰かが訪問したときにのみスケジュールされたタスクを実行し、小さな非営利サイトは毎時間訪問があるわけではありません。
修正策は、実際のcronジョブ（誰も訪問していないときでも、ホストがタイマーで実行するタスク）です。ホスティングコントロールパネルで「Cron Jobs」を探し、サイトのwp-cron.phpを毎時間ポイントしてください。
それが機能していることを確認するには、無料プラグインのWP Crontrolをインストールしてください。時間ごとのイベントのロギングをオンにし、「Cron Logs」を開いて、実行されるたびに確認します。数時間のギャップは、cronがまだ追いついていないことを意味します。
賑やかなストアでインクリメンタルスナップショットが大きくなるのはなぜですか？
ストアのベースラインは約3.5GBでした。通常のスナップショットは約400〜460MB、つまりサイトの約12％でした。
理由はデータベースです。2つのスナップショットの間で、31〜58のテーブル（注文、顧客、ログ）が変更されました。変更されたテーブルはすべて保存されるため、ビジーなマルチGBデータベースは実行ごとに数百MB追加されます。
ファイルはほとんど動きませんでした。約600個のファイルが変更されても、目立ちませんでした。
24回以上のスナップショット（2時間ごと）で、チェーンは約12.8GBを使用しました。フルバックアップと同じ24回の復元ポイントでは約85GBかかっていたでしょう。
同じ復元ポイントでストレージが85％少なくなります。
Duplicatorではインクリメンタルバックアップはどのように機能しますか？
Duplicatorがチェーンを処理します。Duplicator Cloudに接続したら、Duplicator Pro » Incremental Backupsに移動し、Create Baseline Snapshotをクリックします。
次に、バックアップの頻度と保持するバックアップの数を選択します。
そこから、Duplicatorはサイトを最後のスナップショットと比較します。変更があった場合、その差分のみをバックアップします。
チェーンが保持するバックアップ数に達すると、古いスナップショットはベースラインに折りたたまれ、合計は永遠に成長するのではなく安定します。
以下がその内容です：
- 毎時の保護：最大1時間ごとにバックアップできるため、1日の作業よりもはるかに少ない作業量で済みます。
- フルサイトの復元：任意のスナップショットを選択すると、Duplicatorはサイト全体をその時点まで再構築します。Cloudが最初にアーカイブを準備する必要がある場合、数分かかり、メールが届きます。
- 明確な記録：各スナップショットには、キャプチャされたファイルとテーブルがリストされます。
- 無駄なアップロードなし：何も変更がなかった場合、実行はスキップされます。
インクリメンタルバックアップを最大限に活用するにはどうすればよいですか？
合計は主に保持するバックアップの数に依存するため、少なく保持することがストレージの使用量を減らす最も簡単な方法です。他のいくつかの選択肢も役立ちます。
どのサイトでも私がやることは次のとおりです：
- 必要な履歴のみを保持します。保持するバックアップ数 × バックアップ間の時間 が履歴となります。ただし、すべての実行がトリガーされることが前提です。
- 実際のcronジョブを設定します。これにより、毎時実行が文字通り毎時実行されます。ストレージは削減されませんが、期待通りの復元ポイントが得られます。
- 「設定」タブでノイズの多いテーブルの監視を解除します。これにより、バックグラウンドアクティビティが追加のスナップショットをトリガーしなくなります。
- 大きな変更を行う前に、別のオフサイトの場所に別のフルバックアップを保持します。
よくある質問（FAQ）
インクリメンタルバックアップはストレージを節約できますか？
はい。最初のフルベースラインの後、各スナップショットは変更されたものだけを保存します。私たちのテストでは、典型的なスナップショットはブログとコースサイトではサイト全体の約1%、賑やかなストアでは約12%でした。ストアでさえ、同じスケジュールでのフルバックアップよりも85%少ないストレージしか使用しませんでした。節約できる容量は、実行間でデータベースがどれだけ変更されるかによって異なります。
なぜインクリメンタルスナップショットがこんなに大きいのですか？
通常はデータベースです。スナップショットは新しい投稿だけではありません。常に注文があるストアでは、実行間に多くのテーブルが変更されるため、スナップショットごとに数百メガバイトが追加される可能性があります。プラグインの更新も一度に数千のファイルを増やします。
1つのスナップショットからサイト全体を復元できますか？
はい。任意のスナップショットを選択すると、Duplicatorはベースラインとそれまでのすべての変更からフルサイトを再構築します。Duplicator Cloudがまだダウンロード可能なアーカイブを準備していない場合、アーカイブをリクエストプロンプトが表示されます。数分かかる場合があり、準備ができたらメールが届きます。
インクリメンタルバックアップはGoogleドライブやAmazon S3に保存できますか？
いいえ。Duplicatorの増分バックアップはDuplicator Cloudにのみ送信され、ストレージプランが必要です。標準のバックアップは引き続きGoogle Drive、Amazon S3などに送信できるため、別の場所にコピーを保持できます。
インクリメンタルバックアップを実行する場合でも、フルバックアップは必要ですか？
通常は減らすことができますが、完全に削除しないでください。インクリメンタルスナップショットはサイト全体を復元できるため、日常的な復元に対応できます。別の場所にコピーを保持しておくのは賢明なので、別のオフサイトの場所に、より長いスケジュール（週次など）で、再設計、移行、またはメジャーアップデートの前には、個別のフルバックアップを保持してください。
毎時のバックアップは予想よりも容量を使いません：データベースが眠らない限り
テストした静かなサイトでは、1時間ごとの差分バックアップは、毎日フルバックアップを保持するよりもストレージ容量が少なくて済みました。それを決定するのはサイトのサイズではなく、データベースの何％が1時間ごとに変更されるかです。
忙しいストアではスナップショットあたりのコストが高くなりますが、同じスケジュールでフルバックアップよりもストレージ容量が85％少なくて済みました。これは、1日の注文を失う代わりに2時間の注文を失うこととの公平な取引です。
ヒント：1週間後、通常のいくつかのスナップショットの変更リストを開きます。静かなサイトで毎回同じテーブルが表示される場合は、Duplicatorの差分バックアップ設定で確認してください。
1日に24回のフルコピーの料金を支払うことなく、毎時のバックアップを取得する
毎日のバックアップでは、最大1日分の注文、フォームのエントリ、またはコースの進捗状況を失う可能性があります。1時間ごとの差分バックアップは、ストレージを使い果たさずにそのギャップを埋めます。
差分バックアップはDuplicator ProおよびEliteプランで利用可能であり、Duplicator Cloudストレージプランが必要です。Duplicatorを使用してサイトを保護している150万人以上のWordPressプロフェッショナルに参加しましょう！
この投稿でバックアップストレージについて考えるようになった場合は、これらのガイドを次に読む価値があります。
- WordPressのインクリメンタルバックアップとは？（実行方法）
- WordPressサイトはどのくらいの頻度でバックアップすべきか？
- ウェブサイトのバックアップ保持ポリシー：バックアップをどのくらいの期間保持しますか？
- バックアップが失敗する理由を推測するのはやめましょう（代わりにこれらのログを確認してください）
- WordPressのバックアップストレージサイズ：必要な容量と削減方法
- WordPressバックアップの失敗を修正する方法：設定とサーバーの制限
