「何もしていないのにサーバーが止まった」――ログとバックアップでディスクが満杯になる仕組みと、定期監視・ローテーションの重要性
目次
【AIによる要約】
– サーバーは触っていなくても、ログとバックアップが毎日積み上がるため、ディスクは知らない間に満杯へ向かいます。
– ディスクが100%になるとサイト表示、メール、データベース更新まで連鎖的に壊れ、復旧よりも被害のほうが大きくなります。
– 使用率の定期監視とログローテーション・バックアップ世代管理をセットで仕組み化し、残容量の基準は先に決めておきましょう。
はじめに：「誰も何もしていないのに」という言葉の落とし穴
朝、出社してみると社内サイトが真っ白。「何かした？」と聞かれても、誰もサーバーには触っていない。ECの受注も止まり、お問い合わせも届かない。サポートに連絡すると、帰ってくるのは意外な答えです。
「ディスクが満杯です」
「誰も何もしていないのに」という認識は、実は正しくありません。誰も触っていなくても、サーバーのディスクは毎日確実に膨らんでいます。むしろ「何もしていないからこそ」満杯になったと言えます。
当社カジヤは業界歴10年以上、300社以上の企業サイト・Webシステムの支援に携わってきましたが、「突然サイトが止まった」として持ち込まれる障害の中には、ディスク容量不足が原因のケースが安定して存在します。大きな攻撃でもバグでもない、地味で静かな障害です。しかし静かなぶん、誰も警戒していません。
本記事では、なぜディスクは知らない間に満杯になるのか、満杯になると何が起きるのか、そしてどう仕組みで防ぐのかを解説します。
なぜ「何もしていない」のにディスクが満杯になるのか
ディスクを満杯にする犯人は、主に3つです。どれも放置していると必ず増えるもので、逆に言えば「何もしていない」こと自体が最大のリスクになります。
1. アクセスログ・エラーログ
サーバーは、サイトにアクセスがあるたびに記録を残します。1日数万ページビューのサイトなら、ログは1か月で数GBになることも珍しくありません。
さらに厄介なのはエラーログです。そしてここには現場ならではの盲点があります。当社が実際に立ち会った障害では、同時多発型のサイバー攻撃（パスワード総当たりなど）が数時間で数十GBのログを書き出し、ディスクを一気に押し上げたケースがありました。攻撃自体はブロックできていたのに、その「防御の記録」がサーバーを止めた。この「正しい仕組みが原因で落ちる」構図は、ログを減らさない運用をしている限りどこでも起きます。
2. 自動バックアップの積み上がり
「バックアップは毎日自動で取っている」——これは良いことですが、古い世代を消していないなら、毎日少しずつディスクを食いつぶしているのと同じです。バックアップ1世代がサイト全体の2〜3倍の容量になることもあり、毎日1世代ずつ残していくと、あっという間に追い上げます。
バックアップの世代管理そのものについては、別の記事で詳しく解説しています（→ホームページのバックアップは何世代必要？）。
3. キャッシュ・一時ファイル・メディアの追加
WordPressのキャッシュプラグイン、システムの一時ファイル、アップロードされた画像なども静かに積み上がります。単独では小さくても、3つ目の犯人として「残り容量」をじわじわ削っていきます。
ディスクが100%になると、何が起きるのか
「ディスクがいっぱい＝画像がアップロードできない」で済めば話は簡単です。実際はもっと深刻です。
連鎖で止まる
ディスクはサーバー内のあらゆる処理の「書き込み先」です。満杯になると、書き込みに失敗した処理が順番に壊れます。
| 影響 | 内容 |
|---|---|
| サイト表示 | ページ生成時のキャッシュ書き込みに失敗し、500エラーになる |
| データベース | 更新・注文データの書き込みに失敗し、受注が取れない |
| メール | 受信箱やログが書き込めず、メールが届かない・消える |
| SSL更新 | 証明書の自動更新が失敗し、後日ブラウザ警告へ発展する |
| ログ | 障害の記録すら残せず、「いつから壊れていたか」が分からない |
最後の行が一番厄介です。ディスクフルは自分自身の調査用ログも消すため、復旧後も被害の範囲を特定しにくい障害なのです。当社はこれまで何度も深夜・休日の障害復旧に立ち会ってきましたが、ディスクフルの復旧は「空き容量を作る」こと自体は数十分でできます。時間がかかるのはその後で、壊れている間に受注やフォーム送信を取りこぼしていないかの確認のほうです。
攻撃の「燃料」にもなる
さらに見落とされがちなのが、ディスクの余裕がないサーバーは障害対応に追われてセキュリティ更新が後回しになることです。本来入れるはずだった更新を「ディスクが足りないから中止」とする現場は実在します。容量不足は単体の障害ではなく、セキュリティリスクを増幅させる燃料になるのです。
IPA（情報処理推進機構）も「情報セキュリティ10大脅威」で中小企業のシステム運用リスクを毎年取り上げており、日々の運用・監視の重要性は公的にも指摘され続けています（出典：IPA「情報セキュリティ10大脅威」）。
どう防ぐのか：監視とローテーションを「仕組み」にする
対策は大きく2つに割れます。「減らす仕組み」と「気づく仕組み」です。片方だけでは不十分で、セットで初めて機能します。
減らす仕組み①：ログローテーション
ログローテーションとは、ログを日次や週次でファイルを切り替え、古いものを圧縮・削除する仕組みです。多くのレンタルサーバーやLinuxでは標準機能として備わっており、保存期間（例：90日分を残し、それより前は削除）を決めて設定すれば、あとは自動で回ります。
- ログの保存期間は「法的・運用上必要な最小限」に設定する
- 圧縮保存を使うと容量を1/10以下に抑えられる
- ローテーション設定は、障害対応でログを調査する時に備えて確実に残す
減らす仕組み②：バックアップの世代管理
バックアップは取ることと、捨てることがセットです。「毎日バックアップ × 7世代 + 週次 × 4世代 + 月次 × 3世代」のように、残す方針を先に決めて、超えた分を自動で消す設定にします。バックアップがディスクを圧迫して本番が落ちるのは、本末転倒です。
気づく仕組み：使用率の定期監視
そして防げなかった増加に「気づく」のが監視です。判断基準は明確に言い切ります。
ディスク使用率は80%を超えたら対応。90%は警報。
なぜ100%を待たずに80%なのか。ログは1晩で数GB書き込むことがあり、90%から100%までは数日で到達し得るからです。通知が飛んでも翌営業日まで動けない会社は、80%通知を「今週中に減らす作業」と受け取れるように余裕を持たせる設計が現実的です。
落とし穴チェックリスト：現場でよく見る4つの盲点
-
「ディスクは増やせるから大丈夫」で済ませている
容量プランの追加は有効ですが、原因（無制限のログ・バックアップ）が残る限り、増やした分もいつか満杯になります。増設とローテーションはセットで。 -
共用サーバーの「無制限容量」を信じ切っている
「容量無制限」の表示はあっても、実際にはDBやファイル数の実質的な制約があり、満杯障害は起きます。表示額ではなく、使用率の監視で管理してください。 -
監視があっても、通知が届く先がない
「使用率90%の通知は出たのに、誰も気づかなかった」では意味がありません。通知先と、動ける人（または依頼先）まで含めて設計します。検知と復旧の違いについては、死活監視の記事で詳しく解説しています（→サイトの「死活監視」とは？）。 -
バックアップを「同一サーバー内」にしか取っていない
バックアップが本番サーバーと同じディスク上にあると、ディスクフルを早め、サーバー障害時には本体と一緒に消えます。世代管理と保存先（別サーバー・クラウド）はセットで決めます。
自社でやる範囲と、任せる範囲の境界線
ここも見解を明確に述べます。
- 自社でできる範囲: 月1回のディスク使用率確認、不要な古いメディアの整理、大きなメディアファイルの見直し。管理画面から確認できる範囲です。
- 外部に任せるべき範囲: ログローテーションやバックアップ世代管理の設定、深夜・休日の障害検知と一次対応、「ディスクフルで止まった」時のデータ整合性の確認（取りこぼした受注の有無など）。
次のどれかに当てはまるなら、外部体制の検討をおすすめします。
- ディスク使用率を確認したことがない（または毎月の確認が継続できない）
- ログ・バックアップの保存期間を誰も把握していない
- 止まった時に、データ欠損の確認まで含めて動ける人がいない
当社カジヤは、300社以上の支援実績の中でディスクフルを含む数々の突然の障害に立ち会ってきた経験と、自社でもEC・Webサービスを運営している当事者としての目線を持っています。「何もしていないのに止まった」は、実は何も仕組んでいなかったから起きます。代理店を挟まない直接取引で、社内の専任エンジニアが監視から障害対応まで一貫して担うのが私たちのやり方です。
「今、ディスクがどれくらい使われているか分からない」と感じた方は、まず現状の確認からご相談ください。Webサイト保守管理サービスでは、容量監視・ログ・バックアップの運用設計まで一括して引き受けます。
問題が発生している場合は、お問い合わせフォームからお気軽にご連絡ください。
