WordPressのディスク容量不足で更新できない時の復旧手順

WordPressの更新や保存が急にできなくなり、サーバーの管理画面でディスク容量不足が表示されたら、
最初に行うべきことは、目についたファイルを片端から削除することではありません。

書き込み処理をいったん止め、使用量と増加原因を記録し、戻せる方法を確保してから空き容量を作るのが正解です。
順番を守れば、公開中の画像やデータベースを誤って消す危険を抑えられます。

よこやま良平

20年以上ITエンジニアとしてWordPressの制作・保守・復旧に携わっている、よこやま良平です。
容量不足の現場では、削除量よりも「何を残し、何を止め、どう戻すか」を先に決めています。

容量不足は、管理画面が重い、画像を追加できない、更新が途中で止まるなど、別の不具合に見える形で現れます。
エラー表示だけで原因を決めず、サーバー全体の使用量とWordPress内の増加場所を分けて確認してください。

この記事では、共有サーバーの管理画面で確認する方法と、SSHを使える環境での確認方法を分けて説明します。
コマンドが使えない場合でも、同じ判断順でサーバー会社へ問い合わせれば、安全に状況を共有できます。

【無料プレゼント】
WordPress緊急チェック50

「自分のサイトは今、安全なのか？」
自信を持って答えられますか？

こんなお悩みはありませんか？

• ある朝、サイトを開いたら真っ白画面になっていた
• 管理画面にログインできなくなって手が止まった
• 身に覚えのない記事やページが勝手に増えていた
• プラグインを更新したらサイト全体が崩れてしまった
• 以前バックアップを取ったか自分でも覚えていない

累計1,000件以上のWordPressトラブル対応の経験から、「壊れる前に備える」ためのチェックリストを1冊にまとめました。
ログイン・本体・バックアップ・サーバー・運用の5分野を、50項目で「危険度・確認方法・対処法」まで解説しています。

セキュリティプラグイン・WordPressの教科書も含めた3大特典を、
今なら無料で受け取れます。

今すぐ無料ダウンロードする →

※登録後すぐにメールで特典をお届けします

WordPressのディスク容量不足は削除前の保全が最優先

WordPressのディスク容量不足を復旧する時は、削除より先に現在の状態を記録し、書き込みを増やす処理を止めてください。
空き容量がほぼゼロの状態でバックアップや更新を繰り返すと、残量をさらに消費し、被害範囲が広がるためです。

更新・バックアップ・一括処理をいったん止める

最初に、自動バックアップ、画像最適化、インポート、検索索引の再作成、キャッシュ事前生成など、
短時間に大量の一時ファイルを作る処理を確認します。実行中なら、新しい処理を重ねないことが重要です。

プラグイン更新が止まっている場合も、何度も更新ボタンを押さないでください。
展開途中のファイルや一時ディレクトリが増え、正常な更新ファイルと失敗した残骸の区別が難しくなります。

エラー時刻と直前の操作を残す

サーバーの使用量、表示されたエラー、発生時刻、直前に行った操作を、削除前に保存します。
容量グラフがある場合は、合計値だけでなく、いつから急増したか分かる画面も残してください。

現場では「昨日まで正常だった」という情報より、増加開始時刻と同時刻に動いた処理の方が原因特定に役立ちます。
バックアップ時刻、アクセス急増、プラグイン更新、メール大量送信などを時系列で並べると判断しやすくなります。

WordPressの管理画面が急に重い原因とは？初心者でもできる切り分け手順

外部に退避できる最小限の保全を考える

空き容量がない時に、同じサーバー内へ大きな圧縮ファイルを作るのは危険です。
サーバー会社の自動バックアップ、既存の外部ストレージ、直近の正常なダウンロード済みデータを先に確認します。

新たに保全する必要がある場合は、対象を分けて外部へ転送できるか検討します。
wp-config.php、使用中テーマ、独自プラグイン、uploadsの必要範囲、データベースなど、復旧に必要なものを優先してください。

WordPressのディスク容量不足で起こる症状を見分ける

ディスク容量不足は、WordPress全体が完全停止する前から、保存・画像・更新・メール・バックアップへ個別に現れます。
複数の書き込み系機能が同時に失敗しているなら、プラグイン競合だけでなく容量を疑うべきです。

投稿保存と画像アップロードが失敗する

投稿の更新に失敗する、下書きが保存されない、メディア追加でHTTPエラーが出る場合、
アップロード上限とは別に、保存先や一時領域へ書き込める空きがあるか確認します。

小さい画像は通るのに大きい画像だけ失敗する時は、PHPのアップロード上限や画像処理メモリも候補です。
一方、投稿保存やログ出力まで同時に止まるなら、ディスク・inode・契約容量の確認を優先します。

WordPressでメディアのアップロード上限を変更する方法｜php.iniとサーバー設定

プラグインやWordPress本体の更新が止まる

更新処理では、ダウンロードした圧縮ファイル、展開先、一時ディレクトリ、旧ファイルの置換に容量を使います。
配布ファイルの容量だけ空いていても、展開中のピーク使用量を確保できなければ途中で失敗します。

「インストールに失敗しました」「ディレクトリを作成できません」などの表示は、権限でも発生します。
容量と所有者・パーミッションを分けて確認し、777のような広すぎる権限へ変更してごまかさないでください。

ログ・セッション・データベースの書き込みが止まる

ディスクが満杯になると、エラーログを書けず、障害の記録自体が残らないことがあります。
ログインセッション、フォーム送信記録、注文処理、データベースの一時ファイルにも影響するため、表示確認だけでは不十分です。

MySQLやMariaDBが別領域にある環境では、Web領域に空きがあってもデータベース側が満杯という場合があります。
契約全体、Web、メール、データベース、バックアップの使用量を分けて確認してください。

WordPressのディスク使用量を安全に調べる方法

使用量の確認は、契約全体から大きな領域へ絞り、最後にWordPress内のフォルダを見る順番が安全です。
いきなりファイルマネージャーで並べ替えるより、増えている場所を先に特定した方が誤削除を防げます。

共有サーバーでは契約全体と内訳を見る

レンタルサーバーの管理画面で、Web、メール、データベース、バックアップ、ログの使用量を確認します。
複数ドメインを同じ契約で運用している場合、別サイトや別メールボックスが原因のこともあります。

管理画面の集計には反映遅延があるため、削除直後に数値が変わらなくても追加削除を急がないでください。
ゴミ箱や世代バックアップへ移動しただけでは、契約容量が減らない仕様もあります。

SSHが使える環境では大きな階層から絞る

VPSやSSH対応サーバーでは、まずファイルシステムの使用率とinode使用率を読みます。
次に、対象ドメインの上位ディレクトリから容量を比べ、バックアップやログなど大きい階層を絞ります。

df -h
df -i
du -sh /path/to/site/* 2>/dev/null
du -sh /path/to/site/wp-content/* 2>/dev/null

上のコマンドは確認用です。実際のパスはサーバーごとに異なります。
結果を読めない場合は削除へ進まず、対象パスと使用量だけを記録して管理者へ相談してください。

増加時刻と更新時刻を照合する

大きいファイルを見つけても、それだけで削除対象とは限りません。
作成時刻・更新時刻・所有者・拡張子を確認し、容量が増え始めた時刻と一致するかを見ます。

たとえば同じ日時の圧縮ファイルが連続していれば、バックアップの重複生成を疑えます。
ログが数分ごとに増えていれば、同じPHPエラーやボットアクセスが繰り返されている可能性があります。

WordPressの空き容量を作る安全な復旧手順

空き容量は、所有者と用途を確認でき、再生成または外部保管できるデータから小さく確保します。
一度に大掃除せず、削除前後の容量とサイト動作を比べられる単位で進めてください。

手順1：停止できる生成処理を止める

バックアップ、ログの大量出力、キャッシュ生成、画像最適化、メールキューなど、増加中の処理を特定します。
安全に止められる機能だけを一時停止し、停止時刻を記録してください。

停止後も容量が増え続けるなら、別サイト、サーバーログ、メール、マルウェアによる大量生成も確認します。
WordPressプラグインだけを見て終了しないことが大切です。

手順2：古いバックアップを外部へ移す

バックアップは日付、対象サイト、復元方法、保存先を確認し、必要な世代を外部へ複製してから整理します。
最新だけを残せばよいとは限らず、感染や改ざんがあったサイトでは正常だった過去世代が必要です。

移動後は、外部側のファイルサイズと一覧を確認します。
ダウンロードが完了していない状態でサーバー側を削除すると、どちらにも正常なデータが残らない事故になります。

WordPressバックアップの完全解説｜UpdraftPlus / BackWPup / all-in-one-wp-migrationを図解

手順3：再生成できるキャッシュと一時ファイルを整理する

使用中プラグインの公式な削除機能から、期限切れキャッシュや一時ファイルを整理します。
キャッシュ名に見えても、手動編集データや最適化済み画像を保存している場合があるため、フォルダ名だけで判断しないでください。

更新失敗で残った一時ファイルも、更新処理が完全に止まっていることを確認してから扱います。
削除前の一覧と容量を保存し、復旧後に同じ残骸が再び増えないかを確認します。

手順4：ログを保全してからローテーションする

debug.log、Webサーバーのエラーログ、アクセスログなどは、原因特定に必要な範囲を外部へ保存します。
その後、サーバーのログローテーション機能や正式な管理画面から整理してください。

ログを空にして終えると、同じエラーが再発してすぐ満杯になります。
最も多いメッセージ、発生元ファイル、アクセス元、発生間隔を確認し、出力原因も直す必要があります。

手順5：最低限の空きを作ったら書き込みを段階確認する

空き容量が増えたら、いきなり全更新や完全バックアップを実行しません。
管理画面ログイン、下書き保存、小さい画像の追加など、負荷と変更が小さい操作から確認します。

更新を再開する場合は、対象を一つに絞り、更新前後の容量、エラー、公開画面を比べます。
複数プラグインを一括更新すると、再び容量が減った時に原因を特定できません。

WordPressプラグイン更新でエラーが出る時の復旧方法と安全なアップデート手順

WordPressで削除してよい候補と危険な削除を区別する

削除してよいかは、ファイル名ではなく、作成元・用途・復元方法の3点で判断します。
再生成できるデータでも、生成元の設定や原本が残っていることを確認してから整理してください。

確認後に整理しやすい候補

共有サーバーのゴミ箱、バックアップ保管領域、メールの迷惑メール・送信済みも確認します。
画面上で削除しても別の保留領域に残り、契約容量へ計上され続けることがあります。

勝手に消してはいけないデータ

WordPress本体は再取得できる場合がありますが、動作中のファイルを途中まで消すと公開サイトが停止します。
uploadsは同名ファイルを戻しても、メタデータや生成サイズとの関係が崩れることがあるため慎重な扱いが必要です。

急増の原因が不明ならマルウェアも確認する

不審なPHP、ランダム名のファイル、大量のスパムページ、異常なメールキューが増えている場合、
単なる運用ミスではなく、侵入後のファイル生成や不正送信を疑います。

この場合は、怪しいものを消して容量を戻すだけでは再発します。
更新時刻、配置場所、アクセスログ、管理者ユーザー、侵入口を保全し、サイト全体を調査してください。

WordPressを安全に保つためのセキュリティチェック項目45選｜毎月・毎週・毎日でやるべきこと一覧

WordPressの容量不足から復旧した後の確認項目

空き容量が増えただけでは復旧完了ではありません。
容量不足で失敗した書き込みが正常に戻り、壊れた一時状態や未完了処理が残っていないことまで確認します。

公開画面と管理画面を分けて確認する

未ログインの公開画面、管理画面、投稿編集、メディア一覧を別々に確認します。
キャッシュされた公開画面だけ正常に見えても、管理画面の保存処理が直っていないことがあります。

主要ページの画像、CSS、JavaScriptも確認してください。
容量確保のためにキャッシュや最適化ファイルを整理した場合、再生成が終わるまで一時的に表示が変わることがあります。

保存・画像・更新を小さい操作で試す

テスト用下書きを保存し、小さい画像を1枚だけアップロードします。
タイトル、本文、画像のalt、サムネイル生成が保存され、再読み込み後も残っているかを確認してください。

プラグイン更新は、バックアップと切り戻し方法を確認した後、重要度の低い対象から一つずつ行います。
更新前後で空き容量を比べ、展開用ファイルが片付くことまで見ます。

ログと容量が再び増えないか観察する

復旧直後だけでなく、数時間後と翌日にも使用量を確認します。
バックアップやCronなど決まった時刻に動く処理が原因なら、直後は正常でも次回実行で再び満杯になるためです。

エラーログの同じ行が増え続けていないか、メールキューが滞留していないか、
バックアップの保存先と世代数が設定どおりかを確認し、増加原因まで解消してください。

問い合わせ・注文・バックアップを実動作で確認する

フォームはテスト送信し、画面の完了表示、管理者メール、ユーザー控え、送信ログを確認します。
ECや予約サイトでは、実データへ影響しないテスト手順を用意し、注文・予約・決済連携の保存まで確認してください。

最後に新しいバックアップを外部保存し、ファイルとデータベースの両方が含まれるかを確認します。
バックアップ成功の表示だけでなく、ファイルサイズ、一覧、復元先、保持期間まで確認して完了です。

WordPressのディスク容量不足を再発させない運用

再発防止は、空き容量を増やすことより、増加を早く検知し、自動生成物の保持上限を決めることが重要です。
正常時の使用量と毎月の増加量を記録すれば、突然の満杯になる前に対応できます。

警告しきい値と確認担当を決める

サーバーの容量通知を有効にし、誰が通知を見るか、どの残量で調査を始めるかを決めます。
通知先が退職者のメールや見ていない共有アドレスのままでは、警告機能があっても事故を防げません。

容量だけでなく、inode、データベース、メール、バックアップ領域も監視対象にします。
可能なら週次または月次で数値を記録し、急増した項目へ早く気づけるようにしてください。

バックアップとログの保持ルールを固定する

日次・週次・月次の世代数、外部保存先、削除時期、復元テストの担当を決めます。
複数のバックアッププラグインとサーバー機能を重ねると、同じデータを何重にも保存するため棚卸しが必要です。

ログは無期限に残さず、調査に必要な期間とローテーション方法を決めます。
ただし、セキュリティ事故や法的確認が必要な期間は、通常の保持期間より長く保全する判断も必要です。

更新前に必要容量と切り戻し方法を確認する

WordPress本体、テーマ、プラグインの更新前に、現在の空き容量、バックアップ先、復元方法を確認します。
大きな移行や画像再生成では、通常運用より多い一時容量が必要です。

「空きがあるから実行する」ではなく、「処理中のピークを含めて足りるか」で判断してください。
余裕を確保できない場合は、外部環境やステージングで作業し、完成物だけを反映する方法を検討します。

WordPressのディスク容量不足でよくある質問

WordPressのディスク容量不足は安全な順番で復旧する

WordPressのディスク容量不足では、削除量を競うのではなく、増加中の処理を止め、証拠と復元手段を確保し、
用途を確認できるデータから小さく空きを作ることが重要です。

容量を確保した後は、下書き保存、画像、更新、フォーム、バックアップを段階的に確認します。
さらに翌日まで増加量を観察し、バックアップ・ログ・キャッシュ・不審ファイルの原因まで直して完了としてください。

判断できないファイルを消す前に、サーバー会社や専門家へ、発生時刻、使用量、増えた場所、直前操作を共有しましょう。
削除前の情報が残っていれば、復旧の選択肢を大きく減らさずに済みます。

WordPressの容量不足が自分で直せない時は

WordPress保守・不正アクセス対策・マルウェア駆除・WordPressクイックレスキュー365

ワードプレスのWordPressエラートラブル解決をしたいなら
クイックレスキューが解決します。

これらでお悩みなら最短30分ですぐに解決します！

いまなら期間限定で