fedora

/homeディレクトリに「lost+found」というディレクトリがある。

/homeディレクトリをバックアップしようと思ったら、ものすごい大量のファイルがあった。しかも、/homeの中身とほとんど一緒。

　で、「lost+found」ディレクトリってそもそもなんなの？って調べてみた。

• 各ディレクトリの役割を知ろう（ルートディレクトリ編）（2/2）
• Linux初心者の基礎知識
• Linux Tips 集
• /home/lost+foundを消してしまった -OKWave
• [linux-users:85710] Re: FSCKで修復した後、lost+foundから全データを復活するには?

　どうも、ディスクに障害があり、その際にバックアップ？としてこのディレクトリの中にファイルが生成されるようだ。（なんかそんな感じ）

　で、なぜ、/homeの中身がそのまま入っていたのかというと、先日/homeとして使用しているハードディスクが物理的におかしくなり交換したことを思い出した。
　おそらく時に/homeのファイルが大量にlost+foundの中に入ってしまったのであろう。。。

Continue reading

MySQLのデータをデータベース毎ちまちまバックアップするのではなく、全体を丸ごと定期的にバックアップしたいと思い、検索していたらすばらしいスクリプトを見つけました。

• AutoMySQLBackup

設定も簡単で、MySQL全体を一気にバックアップしてくれます。

まずは下記のサイトからスクリプトをダウンロードしてきます。

• SourceForge.net: AutoMySQLBackup

ダウンロードしたスクリプトファイルの中身を編集します。
すぐに使いたいのであれば、修正ポイントは4つだけ。

USERNAME = mysqlのユーザ名
PASSWORD = 上記ユーザのパスワード
DBNAMES = “all” ※存在する全てのDBのバックアップを取りたい場合はallを指定する
BACKUPDIR = “/var/mysql-backups”

Continue reading

このブログを運営しているのは、自宅サーバーなのですが、そのサーバーのデータ用ハードディスクがお亡くなりになった。。。(ToT)

数日前から、このサーバーへのアクセスが非常に重くなっていたのです。

WEBページの表示が遅いだけでなく、メールの送受信も遅くなっていました。

で、MRTGを見たら、確かにWEBのセッション数は減っている。しかし、それほどサーバーが重くなるほどの負荷はかかっていないし、アクセスログを見てもそんな感じでもない。コンソールからtopコマンドでシステムの負荷をモニターしていたが、全然負荷がかかっていない。

で、何が原因かわからないまま、数日が過ぎ、ふと、/var/log/messageのログをみたら。。。

Σ(ﾟ□ﾟ*)ナニーッ!!

以下のようなログメッセージが延々と出続けている。

May 21 05:21:30 sv1 kernel: ide: failed opcode was: unknown
May 21 05:21:30  sv1 kernel: end_request: I/O error, dev hdd, sector 173408911
May 21 05:21:34  sv1 kernel: hdd: dma_intr: status=0x51 { DriveReady SeekComplete Error }
May  21 05:21:34 sv1 kernel: hdd: dma_intr: error=0x40 { UncorrectableError },  LBAsect=173408911, high=10, low=5636751, sector=173408911

あわてて、ネットで「DriveReady SeekComplete Error」を検索してみると。。。。

Continue reading

自宅のサーバー2号機をFedora5からFedora7までアップグレードした後から、cron.dailyのエラーメールが来るようになった以下のメール。

You have old files in your logwatch tmpdir (/var/cache/logwatch):
logwatch.rE4Mi4Ul
logwatch.Qfi5gXzF
logwatch.xQnDxLOO
logwatch.juCeq0kn
logwatch.RjE3S4Zx
：
(略)
：
logwatch.BQ9ezTDa
logwatch.LF9qTrSI
logwatch.5RTdLEHX
logwatch.1NwJSb3U
logwatch.XiB0q5Wo
logwatch.jUY1V1Kh
The directories listed above were most likely created by a
logwatch run that failed to complete successfully.  If so, you
may delete these directories.

特に致命的な問題でもなさそうだったので、ほっといたのですが、さすがに毎日送られれてくるので、ちょっと調べてみたら、見つけました。
↓

Continue reading

先日、Rescue CDで起動しなくなったFedoraのgrub.conf、fstabを修正する方法というエントリーを書きましたが、なにをやっていたかというと、LinuxのCoreのアップグレードです。今回は、Fedora Core 6 から Fedora 7 へのアップグレード。

今回は、というかいつもですが、yumを使ってアップグレードしてみました。

まず下記のようにコマンドラインからrpmファイルをダウンロードします。

wget http://ftp.iij.ad.jp/pub/linux/fedora/releases/7/Fedora/i386/os/Fedora/fedora-release-7-3.noarch.rpm wget http://ftp.iij.ad.jp/pub/linux/fedora/releases/7/Fedora/i386/os/Fedora/fedora-release-notes-7.0.0-1.noarch.rpm

次に上記ファイルをインストールします。

Continue reading

このエントリーは、自宅サーバーのOSを、fedora core 6(以下FC6) から fedora 7(以下FC7)へアップグレードしたときに陥ってしまった時の対処の仕方です。(またの名を備忘録)

FC6からFC7へyumを使ってアップグレードするときには、ファイルシステムのマウントポイントが変更されてしまう、というのをよく聞きます。具体的には「hd*」だったディスクが「sd*」になってしまうという。

参考URL

• ずんWiki – Fedora upgrade
• yum で Fedora Core6 から Fedora7 へのアップグレードには注意が必要？

結局の所、うちの環境では？、hdの記述をsdに変更しなくても良かったのですが、FC6からFC7へアップグレードというページを検索しているとほとんどがその問題にぶち当たっているので、私も事前にgrub.confの内容の中で「hd」の箇所を「sd」に書き換えたのですが逆に起動しなくなってしまいました（＾＾；）
ということで、起動しなくなったLinuxをRescue CDディスクを使って、grub.confファイルの再編集をするやり方です。

Continue reading