ドライブとパーティションを監視し続けることは システム管理者の義務であると言えます。 どこかのパーティションが一杯になってしまえば、 パーティション容量の再配置がすむまで システムは正しく働かなくなってしまうのですから。
パーティションとディスクの監視は df コマンドによって簡単に行えます。 頻繁に行うべきですし、 cron や他の管理ツールなどを使って定期的に行うようにするのも良いでしょう。
スワップパーティションも忘れないようにしましょう。
free や procinfo, top
といったメモリ利用の統計表示ツールを用いることで監視できます。
ドライブの使用状況のモニタはもうちょっと難しいですが、 ドライブ利用の競合を避けてシステムの性能を上げるには重要な作業です。 アクセス要求がひとつのディスクに偏らないようにしましょう。
ソフトウェアのパッケージをインストールするとき、 どこにどのファイルを配置するかについて 明確な意図を持つようにすることも重要です。 先に紹介したように、 GCC は実行バイナリをライブラリのディレクトリに置きます。 他にも歴史的な経緯から、わけのわからない配置をするパッケージもあります。 X11 なんかがそうですね。
お使いのシステムのディスクが一杯になりかけたら、
まず古いログを探して消去しましょう。
core ファイルも探してみましょう。シェルのグローバルな設定に
ulimit を正しく用いておくと、
core でシステムをいっぱいにせずにすみます。
これまでの部分をじっくりと読んできた方は、 すでに何回かバックアップの重要性に触れてきたことに気付いたでしょう。 クラッシュに当たってバックアップが機能していなかった、 あるいは存在すらしなかった場合に管理者に降りかかる災厄については 恐ろしい話がたくさんあります。クラッシュが起こってからじたばたするよりは、 普段からバックアップに投資しておく方がはるかに話は簡単になるはずです。
バックアップには色々な手段が可能ですが、この辺りの詳細は Backup-with-MSDOS-mini-HOWTO に記述があります。 この文書には DOS に関する話だけではなく、 一般的な情報や、より詳細な情報へのポインタも書いてあります。
訳注: Backup-With-MSDOS.html の日本語訳 は JF にあります。同種の文書として dump and restore mini HOWTO もおすすめです。
ただバックアップをとるだけでなく、 バックアップデータをちゃんと復元できるかどうかも確認しておきましょう。 恐い話をひとつ。心掛けの良かった管理者がクラッシュに遭遇。 「ああ、普段からバックアップを取っていて本当に良かった」 バックアップデータの復元をはじめたら、何とそのデータが壊れていた... 気をつけましょうね。
Linux のバックアップソフトには、フリーなものも商用のものも存在します。 商用のものの例としては、ディスクイメージレベルでのバックアップシステムを QuickStart が提供しています。すべての機能を含む 30 日限定の Linux 用デモ版がオンラインで入手できます。
これはファイルシステムの設計によって随分違います。
早い段階からフラグメンテーションが起きてしまい、
しかもそれによって非常に速度が低下するようなシステムもあります。
幸いなことに ext2fs はそうではないので、
デフラグメントツールに関してもほとんど話題になることはありませんでした。
実はちゃんと存在しているのですが、これまではほとんど必要なかったのです。
なんらかの理由でデフラグメント作業が必要になった場合は、
バックアップとレストアを行なってしまうのが簡単でしょう。
例えばホームディレクトリのような小さな領域だけならば、
その領域を tar で別のパーティションに一時待避し、
アーカイブを確認して、
オリジナルを消してから再書き込みすれば良いでしょう。
ディスク領域の不足が、システムのあちこちに散らばっている
不必要なファイルを削除するだけで解消してしまうことも良くあるものです。
異常終了したプログラムは、さまざまなガラクタを、
思いもよらないような場所に残してしまうことが良くあります。
このような事故があった場合には、通常はコアダンプが残されます。
デバッグを行わないならば単に削除してかまいません。
コアダンプはどこにでも作成されますから、
ときどきグローバルに検索を行うと良いでしょう。
これには locate コマンドが便利です。
正常に終了しなかったプログラムは、
いろいろな種類の一時ファイルを残すこともあります。
これらは /tmp や /var/tmp に置かれ、
通常ならプログラムの終了時に自動的に削除されるはずのものです。
このような領域は再起動を行えばきれいにされるはずですが、
すべてがそうであるとは限りませんし、
uptime が長ければ大量のゴミが溜まることになってしまいます。
領域が足りなくなったら、注意しながら削除しましょう。
そのファイルが現在使われているものではないことを、
まず確認してから削除するようにしましょう。
file のようなユーティリティを用いれば、
そのファイルが何であるかわかることも多いです。
システムが動作している場合には、多くの記録が残されます。
それらの多くは /var/log ディレクトリに保存されます。
特に /var/log/messages は、
削除しないとどんどん大きくなります。
古いログファイルからなる小さなアーカイブを
いくつか用意しておくと良いと思います。
それらを比較すれば、
システムがおかしくなりかかっていないかをチェックできますから。
メールまたはニュースのシステムが正しく動作していないと、
スプール領域が余計に消費されます。
それぞれ /var/spool/mail と /var/spool/news です。
overview ファイルには注意すること。
このファイルには先頭にドットがついているので、
ls -l しただけでは見えません。
ls -Al を用いて、これらのファイルにも常に注意するように。
ユーザー領域のオーバーフローは特に難しい問題です。
システム管理者とユーザの間には、ずっと闘争が行われ続けています。
気転や交渉術が必要です。
時には実際に新たなドライブを購入してあげる必要もあるでしょう。
message-of-the-day の機能
(ログインしたときに /etc/motd の内容が表示される)
をうまく使いましょう。ディスクが足りなくなった場合は、
これでユーザーに知らせるようにしましょう。
また shell のデフォルトの設定で、
コアダンプファイルが作成されないようにしておけば、
余計な仕事がかなり減ると思います。
システムのあちこちに自分のファイルを隠そうとするような人たちもいます。
先頭にドットがつくファイルは ls コマンドでは見えませんので、
この点が良く利用されます。よくある例としては、 ... のような
ファイル名です。通常は見えませんし、 ls -al ではすべての
ディレクトリに存在している . や .. にまぎれてしまいます。
これに対する対抗策としては、 ls -Al を使うことです。
このオプションでは . と .. は見えませんが、その他の
ドットファイルは見えるようになります。
いかに大きなドライブと言えど、いずれは使いきってしまうときがやってきます。 そのころには技術の進歩によるコストパフォーマンスの向上も期待できるでしょう。 現在のところは 6.4 GB クラスが一番良いでしょうか。
訳注: いまは 60GB くらいでしょうか？ :-)
たいていのマザーボードでは IDE は二つ (あるいは四つ) までしか接続できないので、 IDE ドライブを増設する場合には古いものが無駄になってしまう可能性が高いです。 一方 SCSI は narrow (8 bit) SCSI で 7、 wide (15 bit) SCSI で 15 まで接続できます。 またホストアダプタによっては二つ以上のチャンネルを サポートしているものもありますし、 場合によっては二つ以上のホストアダプタを一つのシステムに使うこともできます。 筆者の個人的なお勧めですが、長期間に渡って利用するシステムには SCSI を選択しておく方が良いでしょう。
ここで問題になるのは、どこに新しいドライブをあてがうかです。
スプール領域の不足が増設の理由になることが多いので、この場合は
/var/spool 以下のどこかに
新しいディスクをマウントしてしまえば良いでしょう。
しかし一方、新しいディスクは高速でもあるでしょうから、
長い目で見た場合はシステム全体を再構成する方が良いかもしれません。
その場合は以前に使った設計書が役に立つでしょう。
システムのアップグレードが必要になった原因が /usr や
/var などのパーティションの容量の枯渇である場合には、
アップグレードの作業はやや面倒になります。
全体を好みの配布パッケージで
(おそらくこちらもアップグレードされてるでしょうから)
再インストールすることをまず考えてみると良いでしょう。
この場合には、現在の重要な設定を上書きしないように気をつける必要があります。
これらの多くは /etc ディレクトリにあるでしょう。
気を付けて作業を進め、
最新のバックアップとレスキューディスクを用意しておくようにしましょう。
もう一つの選択肢もあります。
新しいディレクトリを一時的なポイントにマウントして、
古いディレクトリの内容を単純にコピーします。
次に /etc/fstab を編集して新しい方を有効にし、
リブートしてちゃんと動いているかどうかをチェックします。
うまく行かなければレスキューディスクでリブートして
/etc/fstab を再編集し、もう一度トライしましょう。
ボリューム管理が Linux で使えるようになるまでは、 これらの手段はいずれも面倒ですし危険でもあります。 システムをバックアップからレストアするはめになることを覚悟しておくことです。
Tips-HOWTO ではディレクトリ構造を丸ごとコピーする方法として、以下
の例を挙げています:
(cd /source/directory; tar cf - . ) | (cd /dest/directory; tar xvfp -)
この手法によるディレクトリ移動は、すべての Unix システムで利用できますが、 覚えておくにはちょっと不便です。またツリーが深くなって、パス名が tar の扱える長さを越えてしまうと、この作業は失敗してしまいます (GNU tar では長いパス名も使えるように特別な拡張が施してあります)。
GNU の cp を使えるなら (Linux システムなら使えるはず)、 以下でも同じことができます。
cp -av /source/directory /dest/directory
GNU cp はシンボリックリンク、ハードリンク、FIFO、 デバイスファイルなどについてそれぞれ知識を持っていて、 正しくコピーを行えます。
ただし /dev や /proc を移動しようとするのは
あまり良い考えではないことも覚えておいてください。
Hard Disk Upgrade mini-HOWTO という文書もあり、 LILO を含む Linux システム全体を 別のディスクに移動する手順をステップバイステップで解説しています。
システムのクラッシュは、さまざまな (楽しい) かたちでやってきます。 特にパーティションテーブルが破壊されると、 たっぷりスリルを味わうことができます。 普通のスリルでかまわない人には、最近出た非常に便利なツール、 gpart があります。 「PC ハードディスクの形式を推定 (Guess PC-Type hard disk partitions)」の acronym です。 便利です。
さらに DOS で使える パーティションユーティリティ もいくつか存在しています。
カーネルやハードウェアのアップデートは、 Linux の世界では 珍しいことではありません。 したがって、最新のレスキューディスクを用意しておくことが重要です。 ハードウェアへのアクセスに特殊なドライバを使う場合にはなおさらです。 レスキューディスクはネットやディストリビューションから入手できますし、 自分で作ることもできます。 boot および root のカーネルパラメータを確認し、 カーネルがシステムをちゃんとブートできるようにしておくのを忘れないように。
復旧フロッピーを持っていない人は、ブートローダである GRUB を用いれば、ディスクのどこかにある Linux カーネルを引き数を指定してロードできます。