WordPressのバックアップストレージサイズ：必要な容量と削減方法

バックアップは87パーセントに増加して停止します。

もう一度実行します。ほぼ同じ場所で失敗します。そのため、バックアッププラグインが壊れていると仮定して無効にし、別のものをインストールして、それも失敗するのを見ます。

プラグインが問題であることが多いことを知るには、このシナリオを十分に見てきました。問題は、サーバーにサイトとバックアップアーカイブを同時に保持するスペース（または時間）がないことです。

それはサイジングの問題です。

サイジングの問題は良い種類です。なぜなら、それらが発生する前に解決できるからです。これは、ほとんどのWordPressの障害について私が言えること以上のことです。

この記事では、バックアップの失敗を引き起こす前にWordPressのバックアップストレージのサイズを決定する方法を説明します。

短いバージョンは次のとおりです。

• バックアップのほとんどは画像です。アップロードフォルダはアーカイブの70〜90％を占めることが多く、データベースが大きくなる原因であることはめったにありません。
• 圧縮は、最も必要な場所で最も効果がありません。テキストは約70％縮小し、メディアはほとんど動きません。そのため、最も重いサイトほど割引率は小さくなります。
• バックアップの作成には、サイトサイズのほぼ2倍の空き容量が必要です。サイトと増え続けるアーカイブは、同時に同じディスクを占有します。
• 大きなバックアップは時間切れで失敗し、スペース切れではありません。 Duplicatorのバックアップ作成チケットの約3分の1は停止またはタイムアウトに関係していますが、明示的なディスクスペースのレポートは30分の1未満です。
• 保持期間は、誰も考えない乗数です。 10GBのサイトに3つのローリングコピーがあると40GBを消費し、完全な3層ポリシーでは約20個のアーカイブが保存されます。
• スケジュールを分割すると、他のすべての修正よりも優れています。毎日データベースのみ、および毎週のフルバックアップにより、WooCommerceストアは注文の同じ保護で140GBから約42GBに削減されます。
• 最新のバックアップが自動的に最も安全とは限りません。マルウェアは数週間検出されずに潜伏する可能性があるため、疑わしい侵害の前に毎月のコピーを保持してください。

目次

WordPressのバックアップのサイズはどのくらいですか？

WordPressのバックアップのサイズは、ほぼ完全にメディアライブラリに依存します。実践で見られる範囲は次のとおりです。

• 新規WordPressインストール：投稿を1つも追加する前のディスク上のサイズは約110MB（ダウンロードはジップで37MB、展開すると約3倍になります）
• 小さなブログまたはパンフレットサイト：数百MB
• フルメディアライブラリを備えたビジネスサイト： 1GB〜5GB
• 商品画像付きWooCommerceストア： 3GB以上が一般的

これらはルールではなく、観測された範囲として扱ってください。200ページのサイトが10ページのサイトよりも小さくバックアップされるのを見たことがありますが、一方はビデオライブラリがあり、もう一方はありませんでした。

重要なのはあなた自身の数字だけです。

WordPressのバックアップのスペースを占めるものは何ですか？

ほとんどの人は、データベースがバックアップの大部分を占めると想定しています。それはほとんどの場合ありません。

典型的なバックアップアーカイブの内訳は次のとおりです。

• アップロードフォルダ：ほぼすべてのサイトで最大の割合を占め、アーカイブ全体の70～90％を占めることが多い
• 生成された画像サイズ：テーマが登録する画像サイズごとに、アップロードのコピーがさらに作成され、ほとんどのテーマはサイトが実際に使用するよりも多くのサイズを登録しています
• データベース：通常数十MBですが、投稿の改訂、期限切れの一時データ、孤立したメタデータによって予想よりも速く肥大化します
• プラグインとテーマ：通常のサイトでは50MB～150MB、ページビルダーとWooCommerceが関与すると250MBを超えます（Elementor単体で約80MB、WooCommerceで約57MBに展開されます）
• コア：最も小さい部分であり、気にする必要のない部分

一文で言うと：バックアップのほとんどは画像です。

圧縮はバックアップサイズをどのくらい削減しますか？

バックアップの圧縮は役立ちますが、その効果は均一ではなく、最も必要としているサイトに対して不利に働きます。

バックアップは元のサイトより約70％小さくなることがあります。テキストはよく圧縮されます。データベースダンプ、PHPファイル、CSS、JavaScriptは、繰り返しが多いので、どれも大幅に縮小されます。

しかし、JPEG、PNG、MP4はほとんど動きません。これらはすでに圧縮されています。

そのため、最も重いサイトほど恩恵は少なくなります。500MBのテキスト中心のブログは150MB近くになる可能性があります。5GBの写真ポートフォリオは4.5GB近くになり、バックアップ圧縮ではそれを変えることはできません。

WordPressのバックアップを作成するには、どのくらいの空きディスク容量が必要ですか？

バックアップのサイズ以上のディスク容量が必要です。

バックアップを実行している間、サイトとそれが構築しているアーカイブは同じディスク上に一緒に存在します。サイトはスペースを確保するために縮小されません。そのジョブの間、すべてを2回保存することになります。

すべてをバックアップすると、完了するためだけにホスティングアカウントの3分の2近くを空き容量として確保する必要があるかもしれません。サイトとそのアーカイブのためのスペースを予算計上してください。

移行も同じルールに従います。50GBのサイトは、元のサイトとアーカイブが転送完了まで共存するため、移動中に約100GBのヘッドルームを必要とします。

ご自身の数値をチェックするには約1分かかります。確認場所はこちらです：

• ホストのコントロールパネル：ディスク使用量またはストレージ画面を見つけ、現在の使用量とともに合計クォータが表示されます
• wp-adminのツール » サイトヘルス » 情報：アップロード、テーマ、プラグイン、データベースサイズのディレクトリとサイズパネルを開きます
• 最後の正常なバックアップ：次のバックアップを予測する最も正確な指標です

Duplicatorでバックアップを作成すると、実行前にバックアップのサイズが正確に表示されます。サイトスキャンでは、問題がないかサイトチェックの下を確認してください。

ディスク容量が心配な場合は、大きなファイルやディレクトリを除外できます。

バックアップ保持ポリシーにはどのくらいのストレージが必要ですか？

必要なストレージ = アーカイブサイズ x 保存コピー数 x 保存場所数

これを10GBのサイトで実行します。ホスト上に3つのローリングコピーがあると、アーカイブが30GBになり、10GBのライブサイトと合わせて40GBのディスクが消費されます。

誰もその数値を計画していません。10GBのサイトをお持ちの場合、おそらく10GBのストレージを計画しているでしょう。

ストレージ容量の枯渇を防ぐために、バックアップ保持ポリシーを設定できます。これにより、一定量のストレージがある場合に古いバックアップを自動的に削除できます。

保持期間のアドバイスは、業界全体でほぼ同じ範囲に収まる傾向があります。つまり、日次バックアップは7日から14日間、週次バックアップは約4週間、月次バックアップは3ヶ月から6ヶ月保持されます。

それは妥当なアドバイスです。また、3つのティアすべてに従うと、約20個の保存済みコピーになり、それらをすべて格納するのに十分なスペースがない可能性があります。

一般的な設定がどのようになるかを示します。

サイトサイズ	推定アーカイブ	保持ポリシー	総ストレージ
400MBのブログ（テキスト中心）	約150MB	14日次コピー	約2GB
4GBのビジネスサイト	約3GB	7日次 + 4週次	約33GB
12GBのWooCommerceストア	約10GB	4週次フル + 14日次データベースのみ	約41GB

下の2行を一緒に見てください。ストアはビジネスサイトの3倍のサイズですが、毎晩フルアーカイブを取得する代わりにスケジュールを分割しているため、ストレージコストはほぼ同じです。

それがレバーです。プラグインや圧縮設定ではなく、スケジュールです。

保持期間を過度に短縮することに抵抗する理由の1つ：マルウェアは自己申告しません。感染は数週間静かに潜伏する可能性があり、これは直近の3つのバックアップすべてに感染が含まれている可能性があることを意味します。月次コピーを1つか2つ保持することが、クリーンな状態にフォールバックできるものを与えてくれます。

Duplicator Proを使用すると、保持期間を簡単に調整できます。ストレージの場所を設定する際に、最大バックアップ数の値をカスタマイズします。

これを5に設定すると、6番目のバックアップをアップロードしようとすると、Duplicatorは最も古いバックアップを削除します。

バックアップの場所によってサイズ計算は変わりますか？

それは、最初にぶつかる壁を変えます。計算は同じですが、制約は異なります。

各バックアップ先が実際にどのくらいのコストがかかるかを示します。

• ホスト上：すべてのアーカイブはホスティングクォータを消費し、サーバー障害が発生しても何も残りません。バックアップを保存するのに最も安い場所ですが、唯一のコピーを保持するには最悪の場所です。
• コンシューマー クラウド（Google Drive、Dropbox、OneDrive）：クォータは、そのアカウントの他のすべてのものと共有されるため、寛大に見えた無料ティアは、3GBのアーカイブが写真ライブラリの隣に着地したときに最初にいっぱいになります。
• オブジェクトストレージ（Amazon S3など）：GBあたりの価格設定で、取得時に料金が発生するため、保持期間は監視できる月次項目になります。復元にも費用がかかります。
• 専用（Duplicator Cloud）：ドキュメントではなくバックアップファイル用にサイズ設定されたストレージで、2GBから150GBまでのティアがあります。

WordPressのバックアップストレージサイズを削減するにはどうすればよいですか？

WordPressのバックアップストレージサイズを削減するための最良の方法を以下に示します。

• 圧縮する前にクリーンアップする: 未使用の画像バリエーションとデータベースの肥大化を削除すると、将来のバックアップが縮小されます。
• 復元する必要のないものを除外する: キャッシュ、ログ、ビルドディレクトリは自己再構築されるため、アーカイブには含めるべきではありません。
• 部分バックアップとフィルタリングバックアップを使用する: 毎晩同じデータをコピーする代わりに、データベースは毎日、サイト全体は毎週バックアップします。
• メディアをクラウドストレージにオフロードする: アップロードフォルダをサーバーから移動することは、利用可能な最大の削減であり、最大のプロジェクトです。
• 増分バックアップを検討する: 変更されたものだけを保存すると、頻繁に更新されるサイトの実際のスペースが節約されますが、完全な復旧中に影響が出るトレードオフがあります。

圧縮前にクリーンアップする

今削除した不要なデータは、将来バックアップする必要がなくなります。ストレージスペースを節約でき、おそらくウェブサイトの速度も向上します。

通常、未使用のままになっているものは次のとおりです。

• 未使用の画像バリエーションと孤立したメディア: ほとんどのサイトで最大の成果。
• 投稿リビジョン、スパムコメント、期限切れの一時データ: データベースを数百MB以上に押し上げるもの。
• 無効化されたプラグインと未使用のテーマ: 無効化してもデータは削除されず、使用していません。

メディアは量が多い場所です。WordPressは、サイトで表示されていなくても、アップロードするすべてのものに対して複数の画像バリエーションを自動的に作成します。

WP Media Cleanupは、ライブラリ内の未使用の画像バリエーションをスキャンし、バッチで削除します。長年稼働しているメディアライブラリでは、アーカイブに二度と入らない数GBが頻繁に発生します。

データベースも同様の問題を抱えています。DB Optimizerは、100点満点でスコアリングし、リビジョン、自動下書き、ゴミ箱内のコンテンツ、スパムコメント、期限切れの一時データ、oEmbedキャッシュをクリアします。

WP Media CleanupとDB Optimizerは両方とも、Duplicator ProとEliteに含まれているか、個別に年間29ドルです。

復元する必要のないものを除外する

一部のディレクトリはバックアップに含めるべきではありません。これらは自動的に再生成されるか、まったく別のものに属しています。

ほとんどのサイトで一貫して安全な除外項目は次のとおりです。

• キャッシュディレクトリ: 復元後数分で自己再構築されます。
• ログファイル: 無制限に増加し、サイトのコンテンツに関する情報は何も提供しません。
• 開発ワークフローを持つサイトのnode_modulesおよびビルドディレクトリ
• 他のバックアッププラグインのストレージフォルダ: これが、バックアップのバックアップを作成してしまう理由です。

Duplicatorを使用すると、フィルタを使用して特定のファイルやフォルダを除外できます。

注意点1: アップロードフォルダを除外するとアーカイブは小さくなりますが、復元は不完全になります。

何かを除外した場合は、何を除外したかと、失われたピースがどこにあるかを書き留めてください。正常に完了した復元が、画像なしで戻ってくるのは、大音量で失敗したバックアップよりも悪いことです。

部分的およびフィルタリングされたバックアップを使用する

あなたのスケジュールは、ページ上のどの設定よりも多くのストレージを移動させます。

ほとんどのサイトが実行すべき分割は次のようになります。

• 毎日のデータベースのみのバックアップ：ほとんど重みがなく、投稿、ページ、注文、設定をキャプチャします。
• 毎週のフルサイトバックアップ：ほとんどのサイトではメディアの変更はゆっくりなので、毎日のコピーはほとんど役に立ちません。

Duplicator Proを使用すると、選択したコンポーネントからバックアップを作成できます。データベース以外のすべてを除外するには、データベースのみボックスをチェックしてください。

同じシステムを使用してカスタム自動バックアップを設定します。フルサイトバックアップテンプレートから1つ作成し、毎週実行します。

毎日実行されるデータベースのみのバックアップテンプレートについても、このプロセスを繰り返します。

ただし、トレードオフに注意してください。データベースのみのバックアップはコンテンツを復元しますが、メディアは復元しません。これは復旧計画の半分であり、それを支える毎週のフルアーカイブが必要です。

メディアをクラウドストレージにオフロードする

アップロードフォルダをAmazon S3または同様のサービスに移動すると、その日から取得するすべてのバックアップが縮小されます。メディアが多いサイトでは、利用可能な最大の削減量です。

また、サイトが依存できなくなる依存関係が追加されます。

メディアはバックアッププラグインが監視していない場所に保存されるため、独自のバックアップと復旧計画が必要です。多くのサイトにとっては妥当な取引ですが、無料の勝利ではなく、通常は午後の作業というよりはプロジェクトです。

増分バックアップを使用すべきですか？

時々。増分バックアップは、最後のフルコピー以降に変更されたものだけを保存するため、頻繁に更新されるサイトでのストレージ節約は現実的です。

コンテンツが頻繁に変更され、メディアが変更されない場合に最も効果的です。安定した画像ライブラリに対して1日に10件の投稿を公開するニュースサイトは、理想的なケースに近いでしょう。

それらは、あなたが保険をかけている状況で最も弱くなります。サーバーの完全な損失、ホストの移行、または空白のコンピューターへの復元はすべて、どこかに持ち運べる完全なアーカイブを必要とします。

WordPressバックアップストレージのサイジング：3つの例

これらは独自の数値で実行するためのテンプレートであり、自分自身を測定するためのベンチマークではありません。すべて同じ4つのステップを使用するため、WordPressバックアップストレージのサイジングは4つの空白を埋めることになります。

解決すべき4つの数値は次のとおりです。

• サイトサイズ：ファイル+データベース。ホストのコントロールパネルまたはツール »サイトヘルス »情報から取得します。
• 推定アーカイブサイズ：サイトのメディアの量。圧縮を考慮して割引されます。
• 作業用ヘッドルーム：サイトサイズ+アーカイブサイズ。バックアップが完了するために必要な空きスペース。
• 総ストレージ：アーカイブサイズx保持されるコピー数。各場所に。

小さなブログ：400MBのサイト

ほとんどがテキスト、数百枚の画像、および50MBのデータベースです。

テキストは非常に圧縮されるため、この400MBのサイトは150MBに近いアーカイブを生成します。作成するには約550MBの空き容量が必要ですが、これは400MBのサイトと150MBのアーカイブがディスク上に一緒に配置されるためです。

150MBの毎日のコピーが14個で、2GB強になります。

このサイズのサイトは、無料のクラウドティアまたは最小の有料ティアに快適に収まり、何年も収まり続けます。ストレージの問題を抱えているサイトではありません。

ビジネスサイト：4GBのサイト

メディアライブラリ全体、ブログ記事の画像10年分、少数の動画。

ほとんどが既に圧縮されたJPEGであるため、圧縮はほとんど役に立ちません。アーカイブは約3GBになると予想されます。作成には約7GBの空き容量が必要です。

保持期間がこの問題を高価にします。7つの日次コピーと4つの週次コピーは、それぞれ3GBのアーカイブが11個、つまり約33GBになります。

ホストに最近のコピーを3つ（9GB）、オフサイトにフルセット（33GB）を配置すると、50GBのクラウドティアになります。これは、ほとんどの人が中規模と呼ぶサイトの正直な数字です。

WooCommerceストア：12GBのサイト

商品画像、注文履歴、日々成長するデータベース。

アーカイブは約10GBになり、作成には約22GBの空き容量が必要です。予算重視の共有ホスティングでは、その要件だけでバックアップが失敗します。

ここで2つのスケジュールを比較します。14日間の日次フルバックアップは140GBのストレージになります。4週間の週次フルバックアップと14日間のデータベースのみのバックアップは約42GBで、過去2週間に受けたすべての注文に対して同日復元ポイントを提供します。

注文に対する保護は同じですが、ストレージは3分の1です。

それがスケジュールを分割する議論全体であり、前の表のストアがそのサイズの4分の1のサイトと同じくらいのコストがかかる理由です。

よくある質問（FAQ）

バックアップサイズはプラグインの問題ではなく、計画の問題です

ストレージの決定は一度静かに行われ、通常は他の何かを設定している間に行われます。復元が必要な最悪の日に、それが正しかったかどうかを知ることになります。

それがサイジングを計画する価値がある理由です。この記事のすべての数字は、事前に計算できるものであり、毎月ほとんど変化しません。

修正が迅速であるとは言えません。2018年から蓄積されてきたメディアライブラリのクリーニングは面倒な作業であり、メディアをクラウドストレージにオフロードすることは、それ自体の障害モードを持つプロジェクトです。

スケジューリングの変更は例外です。毎日のデータベースバックアップを週次のフルバックアップから分割するには約10分かかりますが、ストレージにとっては他のすべてを合わせた以上の効果があります。

以前に言及しなかった、構築する価値のある習慣が1つあります。月に一度、バックアップアーカイブのサイズを書き留め、数字ではなく成長率を監視してください。

月に15パーセント成長するサイトは、計算可能な日付でストレージの上限に達します。これにより、障害が発生する前に、より大きなストレージに移行できます。

次のバックアップが失敗する前に、必要な空き容量を知っておきましょう

復元時に、バックアップが3週間前にオフサイトへのアップロードを停止していたことや、ホストの容量が不足して復元できなかったことを発見するのは最悪のタイミングです。

Duplicator Proは、あらゆるサイズのサイトを処理し、バックアップを好みのクラウドストレージにオフサイト送信し、設定した保持スケジュールに従って古いバックアップを自動的に削除します。

また、フルサイトバックアップを数回のクリックでステージングサイトに変換できるため、必要になる前に復元を適切にテストできます。

150万以上のWordPressのプロフェッショナルがDuplicatorを使用してサイトを復旧可能にしています。彼らに加わって、バックアップと移行をより簡単にしましょう！

バックアップストレージのサイジングに関して他に質問がある場合は、次に読む価値のある記事はこちらです：

• 大規模なWordPressサイトのバックアップ方法
• WordPressサイト所有者にとってのクラウドストレージ制限の本当のコスト
• インクリメンタルバックアップはウェブサイトのストレージ問題を解決できるか？
• 3-2-1バックアップルール explained: それは何であり、2026年に何が変わったか
• WordPressバックアップのためのベストクラウドストレージサービス12選（専門家ピック）