‘Linuxサーバ’ カテゴリーのアーカイブ

さくらインターネットのVPS環境へMondo Rescueでリストアする方法 (Interactively編)

サーバの運用 | by 管理者
4月 30日 2014 年

Interactivelyでのリストア

さくらインターネットのVPS環境へのInteractivelyによるリストア方法を備忘録として記録します。

尚、バックアップファイルをさくらインターネット環境にアップロードする方法はさくらインターネットのVPS環境へMondo Rescueでリストアする方法 (Automatically編)をご覧ください。

Mondo Rescueのリストア画面が表示されたら、interactiveを入力します。

100

以下のメニュー画面でInteractivelyを選択します。

101

DVD-disksを選択します。

102

この画面で既にover-allocatedとエラーが出ています。
実を言うとこのままリストアしても途中で容量を再計算して割り当てなおしてくれるため、問題なく成功しますが、自分でサイズを指定したいのでこの画面で指定しなおします。

103-ok

再描画が上手く出来てなくて画面が崩れていますが、何度か試すと変更箇所が分かるようになります。
ちなみに、/dev/vda3が98299、/dev/vda1が500、/dev/vda2が2055と入力しました。

104

これも分かりにくい画面ですが、「OK」を押します。2つ上の画面と比較すると「OK」ボタンの意味が分かりますよね。

105

「Yes」を選択します。

106

「Yes」を選択します。

106-1

リストアが始まります。

107

「Yes」を選択します。

108

2週間のお試し期間の別環境にリストアしますが、仮想サーバなのでバックアップもリストアも同じ環境のはず。
よってブートローダーを作りなおす必要は無いだろうと考えて「No」を選択します。

109

「Yes」を選択します。

110

サーバを再起動します。
本番環境を上書きでリストアしたのであれば、IPアドレスの変更は不要ですが、2週間のお試し期間を使って別の環境にリストアしたのでIPアドレスが重複するため、本来のIPアドレスに変更します。
サーバーのIPアドレスの変更方法はさくらインターネットのVPS環境へMondo Rescueでリストアする方法 (Automatically編)をご覧ください。

さくらインターネットのVPS環境へMondo Rescueでリストアする方法 (Automatically編)

サーバの運用 | by 管理者
4月 30日 2014 年

さくらインターネットのVPS環境のバックアップとリストア

バックアップとリストアはどちらか一方出来るだけでは全く無意味です。
Mondo Rescueによるバックアップは比較的簡単に出来ますが、リストアは幾つも罠が仕掛けられていて一筋縄ではいきません。
そこで本番環境であるさくらインターネットのVPS環境にMondo Rescueでリストアできるかどうかを確認したときの備忘録です。
とはいえ、いきなり本番環境にレストアして本番環境を壊してしまうのは非常に怖いので、新規に契約するときの2週間のお試し期間を使って別のIPアドレス環境へのリストアになります。
参考までに、Mondo Rescueによるバックアップは以下のコマンドで行っていますが、バックアップ方法は沢山のサイトで詳細に解説されているので省略します。

mondoarchive -Oi -L -N -s 4480m -d バックアップフォルダ -E 除外フォルダ -p sakura-`hostname`-`date +%Y-%m-%d`

そして、そのバックアップを予め作業用のパソコンにコピーしておきます。

バックアップファイルのアップロード

Mondo Rescueでバックアップしたファイルをさくらインターネットのサーバにアップロードします。アップロードは以下の画面の「ISOイメージインストールへ」で行います。

01

以下の画面で「アカウント作成」ボタンを押してバックアップファイルをアップロードするためのアカウントを作成します。

02

以下の画面の内容に従ってバックアップファイルをアップロードする準備を行います。

031

SFTP続できるツールを使用してisoディレクトリの下にバックアップファイルをアップロードします。ここではWinSCPを使ってアップロードしています。

041

バックアップファイルのアップロードが完了してから、「更新」ボタンを押すと以下の画面のようにバックアップファイルが認識されていることが分かります。
そして画面最下部の「確認」ボタンを押すとMondo Rescueのリストア画面が表示されます。
※ 後で必要になるため、ここでIPアドレスやゲートウェイ等の情報を書き留めておきます。

00

 フルオート:Automaticallyでのリストア

一番簡単にリストアするには以下の画面で「nuke」と入力して「Enter」を押します。

08

リストアが始まります。

09

「Enter」を押します。

10

以下の画面が表示されたらリストアが終了しています。右上の×ボタンを押してこの画面を消します。

11

以下の画面で「再起動」ボタンを押します。
本番環境へのリストアであれば、これで終了ですが、今回リストアしている環境は別のIPアドレスの環境になります。
そのため、このまま再起動したら本番環境とIPアドレスが重複するため、それを解消します。

12

リモートコンソールの画面で「Enter」を押します。
※ タイミングが遅いとOSが起動してしまうので、その場合は再起動する。

14

以下の画面が表示されたら、「e」を押します。

15

kernel***の行を選択し、「e」を押します。

17

「スペース」キーに続いて「1」を押して「Enter」を押してシングルモードで起動します。

18

シングルモードでの起動完了。

19

以下をタイプしてIPアドレス等のネットワーク環境を書き換えます。
vi /etc/sysconfig/network-scripts/ifcfg-eth0

20

前もって書き留めておいたネットワーク情報を元に修正してからリブートします。

21

ログイン画面が表示され、無事にリストアが完了したことが分かります。

120

試しにブラウザでIPアドレスを指定すると、ホームページが表示されます。

121-1

Automaticallyによるリストアは簡単にリストアできる半面、バックアップ前とパーティションの容量が違っていたりします。
これが嫌な場合はInteractivelyでパーティションの大きさを指定してリストアします。
今回、比較的簡単にリストアできたのは、さくらインターネットが標準で用意したOSを使用して特別なことをやらなかったからかもしれないです。
ここではさくらインターネットのメモリ1GB・ハードディスク100GBのVPS環境をバッアップ・リストアしましたが、メモリ1GB・ハードディスク100GBのVPS環境をバックアップして上位のメモリ2GB・ハードディスク200GBのプランにリストアすることで手軽にマイグレーションできるのではないかと思います。
これは時間を見つけて確認したいと思います。

Mondo Rescueによるリストアを失敗しないために。

セットアップ, その他 | by 管理者
4月 21日 2014 年

Mondo Rescueのリストアに失敗する?

Linuxの定番のバックアップツールであるMondo Rescueは使い難い、というかバックアップは割りと簡単に取れるのだが、それとは裏腹にリストアは難しい。バックアップアップもリストアも全く同じハードディスクであれば、成功するかも知れないが、たとえ同じ容量でもメーカーや型番が違えばリストア出来ないこともある。事実、SEGATEのST31000528AS(SATA 1TB)から日立のHDS721010CLS332(SATA 1TB)にリストアできなかった。ハードディスクの故障で全く同じハードディスクが用意できるとは限らないわけで、これはこれで大問題。

その時に発生したエラーがこれ。
この画面を見ると、/dev/vg_king/lv_homeをマウントできないと表示されているが、ログを調べるとこのLVMの論理ボリュームを確保するときに容量が足りなくてエラーになっているようだった。同じ容量のディスクなのに微妙に違うのか?

リストア失敗

ところで我が家のサーバでは1TBのディスクを使っていながら、中身のデータはその1/10も無いため、この論理ボリュームを縮小してバックアップ→リストアしたところ成功させることが出来た。つまりMondo Rescueによるリストアを成功させる鍵は、ハードディスク一杯に容量を確保しないことだろう思う。ここまで分かれば、実データの容量に見合う小さなハードディスクでも良いだろうと想像出来るし、今は使わなくなった120GBや160GBのハードディスクがあるので、これに戻してみた。

そのためには確保している論理ボリュームの容量が大きすぎるので、下の画面のように/dev/vg_king/lv_homeを50GBに縮小した。
※ /dev/vg_king/lv_rootが50GB、/dev/vg_king/lv_homeが50GB、/dev/vg_king/lv_swapが6GB、その他もろもろ合わせて全部で110GB程度になる。

容量の縮小

リストア方法

Mondo RescueによるリストアはAutomaticallyによるフルオートとInteractivelyによる容量を指定しながら行う方法がある(完全マニュアルのexpertは割愛)が、Automaticallyでリストアすると一見問題なく終了しているのに「Error 13: Invalid or unsupported executable format. Press any key to continue 」と表示されて何故か起動しなかったり、元の容量と大きく違ったりするので、そのような問題が発生したときはInteractivelyでリストアすれば良い。
しかしInteractivelyを選択した時に初期表示される容量はかなりデタラメ。

RIMG0671

ここで全ての値を入力する。

sda2とsda1の合計が一致するように値を変更し、論理ボリュームは120GBのディスクを使うことを考慮してSizeを適当に埋める。論理ボリュームが存在しないとdose not exitとエラーが表示されるが、ここでは無視。

RIMG0672

「パーティションを削除するか?」、「全てのデータをリストアするか?」の問い合わせに対して両方とも「YES」を選択。「boot loaderを初期化するか?」の問い合わせに対して「YES」を選択。

RIMG0680

initrdを再作成するか?の問い合わせに対して「YES」を選択。

RIMG0681

/にchrootして/bootの下で以下のコマンドを打つように指示されるが、エラーが出て上手くいかないので、そのまま以下のコマンドをタイプする。
# mkinitrd -f -v initrd-2.x.y.img 2.x.y
※ e.g.・・・はfor exapmleのことで無視。

RIMG0682

initrdを再作成中

RIMG0686

リブートするとUUIDが違うため、CentOSの起動途中でストップする。そこでrootパスワードを入れて一旦抜ける。そして以下のコマンドををタイプしてハードディスクのUUIDを確認する。
# blkid /dev/sda1

RIMG0688

CentOSのインストールディスクで立ち上げ、レスキューモードを選択して、/etc/fstabのUUIDを正しい値に編集してからリブートする。

RIMG0689

無事に起動完了

RIMG0690

AutomaticallyでリストアするとハードディスクのUUIDも自動で書き換えてくれるので楽だが、意外に思ったとおりにならないので、運が良ければ使える程度に考えておいた方が良いと思う。

後日、SEAGATEの160GBのハードディスクからMondo RescueでバックアップしたけどWesternDigitalの160GBのハードディスクにリストア出来なかった。

このパソコンは本番環境で障害が発生したときに使用する使用頻度の低い自宅サーバなので、普段はBIOSでハードディスクを切り替えてWindows7のパソコンとして嫁が使用しているが、Mondo rescueでバックアップするときもWindows7のハードディスクが繋がった状態でバックアップし、リストアするときはWindows7のハードディスクを外して行ったため、ハードディスクの構成が違っていたことが原因となってリストアに失敗した。
Windows7の入ったディスクだから大丈夫だろうと安易に考えてバックアップしたのが間違いだった。Mondo Rescueでバックアップするときにハードディスクを外す手間を考えると、電源付きのハードディスクのリムーバブルケースを購入した方が良さそうだ。

要注意、スパムに狙われるWordPressのフォーラムや掲示板。コミュニティサイトの危険性

Linuxサーバ-スパム | by 管理者
4月 22日 2013 年

不正アクセスがあったので、IPアドレスをアクセス禁止にしたらIPアドレスを変更して性懲りもなくやってくるしつこいスパムを紹介します。

IPアドレス69.197.189.8の前は69.197.189.11でした。

 

このエラーログを見ると、signup.phpとかjoin.php、member.php、register.phpの記述が至るところにあり、フォーラムや掲示板のスクリプトを決め打ちして探しています。

エラーログ

 

こいつの狙いはWordpressで開設できる掲示板やフォーラムにあるようです。

掲示板やフォーラムはブログと違ってスパムリンクを張り易いので、狙われるのでしょうね。

以前、掲示板を開設していた時も、直接cgiを叩いてスパムリンクを書き込まれました。

その度に消して書かれての繰り返し。

結局、掲示板の運営を止めてしまいましたが、ロボットがやっているので罪の意識すらないでしょう。

この手のスパムは月に3~4回有ります。

時々見ますが、途中で放置された無料ブログや掲示板は無法地帯と化し、こいつらのエサ場になります。

途中で投げ出すのなら、掲示板は閉鎖して後始末をきちんとお願いしたいと思います。

 

レンタルサーバの有料・無料を問わず、Wordpressでブログを開設していれば、こいつらに必ず狙われます。

このログはアパッチが吐いたものなのでサーバー管理者でなければ見ることができないログです。

そのため、多くのWordpressでブログ開設している運営者は、このようなスパムに狙われていることすら知らないと思います。

 

 

言い換えると、堅牢な鎧や甲冑を着て、暗闇の中でサンドバックのように叩かれているのだけど、それすら知らない状態!?・・・恐ろしい。

しかし、このようなログが見えれば攻撃してくる敵の姿が見えるため、こちらから攻撃しないまでも手を出して防御することが可能になります。

 

そこで何か対抗手段は無いのか、不正アクセスを検知して教えてくれるWordpressのプラグインを探しましたが無いみたいです、というかエラーにしているのはアパッチなのでWordpressで不正アクセスの検知は無理なはず。

それなら、このエラーログを見ることの出来るレンタルサーバ会社が不正アクセスを行っているやつらのIPアドレスを掲載するとか、こいつらが接続できないようにレンタルサーバ側で遮断するとかサービスを提供しても良いと思いますが、いかがでしょうか?

 

WordPressで簡単に開設出来るフォーラムを紹介をしているサイトが沢山有ますが、フォーラムを開設すると同時にスパムに狙われる危険性が増すことをお忘れなく。

完全ではなかったサーバー監視、ホームページに繋がらないのにhttpの監視ステータスOKって何故?

サーバトラブル | by 管理者
4月 17日 2013 年

先月サーバーが落ちて17時間ホームページに繋がらない障害が発生したばかりなので、サーバーに障害が発生したらメールで連絡する無料のサービスに加入したばかり。

これで安心だ!・・・ってほど楽天的な人間じゃないので、取り敢えず朝起きた時と寝る前はホームページを見て大丈夫であることを確認しています。

 

 

今朝も、メールに異常を知らせる連絡が無かったので、サイトは大丈夫と思い込んでホームページにアクセスすると・・・繋がらない。

リモートでサーバにアクセスするとCPUの負荷が異常に高くなっており、サーバを再起動したら元通りになりました。

 

さて、午前1時40分に障害が発生してホームぺージが繋がらなくなったにもかかわらず、サーバー監視ログの80ポートのステータスはOKになっています。

障害発生から1時間後に3秒の遅延が発生していますが、それでもOKのステータスです。

ここのサーバー監視は、2回続けてエラーにならないとメールが送られない仕組みになっており、監視時間の閾値を弄っても無意味。

というか、そこそも無料の監視サービスなので監視時間の閾値の変更すら出来ません。

さて、どうしたものか・・・

 

単なる高付加になって応答するのに時間がかかっているだけじゃないのか?って思ってサーバのシステムログを見ましたが、そうじゃなさそうです。

何故、http(80ポート)のステータスがOKになるのか良く分かりません。

サーバーの監視ログ

ウイルスバスターで有名なトレンドマイクロはスパム?

Linuxサーバ-スパム | by 管理者
4月 14日 2013 年

アパッチのエラーログを見ていたら、このようなエラーが記録されていた。

[Sun Apr 14 15:59:20 2013] [error] [client 150.70.97.118] File does not exist: /var/www/wordpress/undefined
[Sun Apr 14 16:00:09 2013] [error] [client 150.70.75.164] File does not exist: /var/www/wordpress/undefined

 

150.70.97.118はウイルスバスターで有名なトレンドマイクロのIPアドレス。

このIPアドレスをhttp://www.aguse.jp/で検索すると、以下のようにブラックリストに登録されていた。

トレンドマイクロはIPアドレスを詐称されているってことなのかな?

aguse

 

さらに調査すると、良く分からない以下のようなエラーがあった。

何をしたかったのだろうか?

いくつもも記録されているので、打ち間違いじゃないと思われるが、気味が悪い。

File does not exist: /var/www/html/page2.html

File does not exist: /var/www/html/https:

 

2chで質問しようと書き込んだら、コミュファが規制されていて書き込みできなかった。

誰か知っている人は教えて下さい。

サーバーに障害が発生すると、サーバー復旧後に検索順位は落ちるのか?

サーバトラブル, SEO | by 管理者
4月 05日 2013 年

先月17時間に渡ってサーバーが落ちてしまい、ホームページが繋がらないときがありました。

サーバーが何年間も問題なく動いていると油断してしまい、まさかサーバーが落ちているなんて夢にも思っていなかったため、こんな事になってしまった訳です。

 

webmastertool error

 

 

サーバーに障害が発生してホームページが繋がらなくなると、Googleの検索順位は落ちるのでしょうか?

サーバーを再起動する数分の間なら大丈夫です。これは何度も確かめています。

しかしネットで検索すると、繋がらない時間が1日~2日は大丈夫と言ってる方がおり、「その根拠はどこに?」と突っ込みたくなりますが、私の場合は17時間繋がらなかっただけで検索順位やアクセス数は10~20%位落ちました。

もちろん、すぐに回復することはありません。

このような検索順位やアクセス数の下落はアフェリエイト目的のサイトを運営している方にとって深刻な影響があると思います。

 

 

サーバー復旧後、暫くしてからの検索結果がいつもと違っていました。

例えば、普段5~6番目に検索されたキーワードが1位になり、サーバーに障害が発生したのに順位が落ちる事があっても上がることは考えられないので、この結果を不可解に思っていました。

すると、その翌日に順位がストンと落ちてしまいました。

おそらく、Googleがサイトの安定度をマイナス側に評価した上で、検索順位を再評価しているのではないかと思われます。

 

 

記事を投稿しても、すぐにインデックスしてくれない。

また、普段ならブログを投稿してから数分間でインデックスされるのに、インデックスに数日かかるようになりました。

これはおかしいと思ってアパッチのアクセスログを調べると、GoogleのBotが来ているのにインデックスされていないことが分かりました。

これはBotが何度もサーバーを訪れて、サーバーの安定度を再評価しているのではないかと思われます。

 

*** 2013年4月12日 追加  ***

結局、5日経ってもインデックスしてくれなかったので、ウェブマスターツールのFeach as googleを使ったところ、翌日インデックスされました。

といってもBotが既に来ているので効果は良く分からないですが、暫くの間、記事の投稿したらFeach as googleを使った方が良さそうです。

 

feach as google

****   ここまで   *******

 

計画的にサーバーを停止するのであれば、HTTPステータスコード503を返すようにすれば良いですが、今回のように予期できないトラブルの場合は503を返すことはできません。

サーバーが繋がらない時間が数分間なら大丈夫ですが、今回のように17時間も繋がらないのは非常に不味いです。

そのため、サーバーが繋がらなくなると、携帯にメールが届くように無料のサービスに加入しました。

これで何時間もサーバーが落ちていることを知らなかったなんてことは無くなるはずです。

サーバ管理者にできることは、一刻も早くサーバを復旧して繋がらない時間が1分でも少なくするように努力するしかないです。

 

 

また、これはサーバー管理者だけに限定した話ではなく、ホームページやブログのサイト管理者(運営者)も同じことです。

例えば、Wordpressのプラグインのアップデートでブログが繋がらなくなったとか、バックアップ中にブログが繋がらなくなったとか、ホームページやブログを管理しているだけでも今回と同様のことが起こる可能性があります。

※ 今回の障害はブログの自動バックアップがきっかけになっているみたいです。・・・あなたのサイトも自動バックアップしていませんか?

ホームページやブログのサイト管理者もサイトに障害が発生したら、速やかに復旧できるように何らかの対策を考えておいた方が良いでしょうね。

3月24日にホームページが数時間閲覧できませんでした。(自宅サーバ管理者が行う障害対策)

サーバトラブル | by 管理者
3月 25日 2013 年

昨日(3月24日)の昼はいろいろあって、夜になってからホームページを閲覧したら、アレッ繋がらない。

すぐにリモートでサーバにログインして再起動したら復旧しました。

 

障害が発生した理由はともかく、サーバの調子が悪くなったら即座に「調子が悪い」って知らせて欲しいですよね。

そこそこお金をかけたシステムなら、別のPCから定期的にPingを飛ばして「起きてるか?」って聞いてやるのですが、個人ではそうはいかない。

そこで何かその代わりになるような物が無いか調べたところ、ありました。

このサービスもPingを打ってサーバーから応答があるかどうかを確認して、応答が無いとメールで知らせてくれるサービスのようです。

しかも無料で利用できます。

http://www.cman.jp/network/

サーバー監視

 

 

監視する項目です。ホームページが生きているのか確認したいので、80(http)にチェックを入れます。

監視項目の指定

 

 

この設定を行ってから、暫くしてホームページを見ると、7回Pingを打って全て正常だったという調査結果が表示されました。

もちろん、これだけでなく、異常があればメールで連絡してくれます。

監視結果

 

1つのIPで沢山のホームページやブログを運用するレンタルサーバであれば、サーバの運用はその会社任せで良いでしょうが、自宅サーバやVPSサーバの場合は自分でサーバを管理しないといけないので、無料で利用できるこのサービスはお勧めです。

 

また、詳細はお話しできませんが、サーバーに障害が発生した時刻に怪しいIPアドレスがログに記録されていたため、念のためブログのデータを前日に戻すと同時にそのIPアドレス(190.196.5.82)をアクセス禁止にしました。

悪夢ふたたび?、ウェブマスターツールで自サイトのIPアドレスによる「サイトへのリンク」が急増

サーバトラブル | by 管理者
8月 09日 2012 年

しばらく前に収束したはずの自サイトのIPアドレスによるリンクですが、最近また復活してきました。

ふと気が付くと191個もあります。

ちなみに下画面の219.94.0.251はIPアドレスの3桁目と4桁目が入れ替わり、3桁目が0になるウェブマスターツールのバグと思われます。

 

わずか3ヶ月前のことですが、このときはgoogleから警告をもらったため対策して審査請求し、現在は解決済みです。

詳細は以下のリンクをご覧ください。

http://it.trend-ai.com/?p=5303

 

 

前回完全に修正したはずなのに、どうしてだろう?

※ 再度、Wordpressの全てのテーブルに対してMySQLからIPアドレスで検索してみましたが、1件もヒットしません。・・・当然です。

 

 

丁度googleがパンダアップデートやペンギンアップデートを適用したばかりなので、おそらくその影響だと思いますが、本当にgoogleが犯人なのか憶測だけで答えを出すわけにはいかないので、アパッチのログを調査しました。

するとhttp://123.123.123.123/hogehogeのようにIPアドレスでアクセスしている奴の正体は予想どおりgoogleでした。

IPアドレスでサイトへアクセスできれば、リンク数としてカウントしているのでしょうか?

 

下の画面の74.125.16.○○○はgoogleのIPアドレスです。

じゅうたん爆撃さながらgoogleのIPアドレスでログが埋め尽くされています。

 

 

 

googleはホスト名からIPアドレスを調べてURLを調べたIPアドレスに置き換えて見に来ている、もしくは過去に警告を受けたことのあるサイトはパンダアップデートやペンギンアップデートで念入りにチェックしている可能性があります。

 

本来なら何も対策する必要は無いはずですが、このままにしておくと、ドメイン名を使ったURLとIPアドレスを使ったURLで同じページを参照するため、タイトルタグの重複にカウントされる可能性があり、IPアドレスでアクセスがあったらドメイン名に変換するように.htaccessを修正(正規化)しました。

現在は、googleがhttp://123.123.123.123/hogehogeでアクセスしてもhttp://www.trend-ai.com/hogehogeに自動変換されます。

 

サイト直下の.htaccessの内容

Options +FollowSymLinks
RewriteEngine On
RewriteCond %{HTTP_HOST} ^123.123.123.123$
RewriteRule ^(.*)$ http://www.trend-ai.com/$1 [R=301,L]

 

WordPress直下の.htaccessの内容

Options +FollowSymLinks
# BEGIN WordPress
RewriteEngine On
RewriteCond %{HTTP_HOST} ^123.123.123.123$
RewriteRule ^(.*)$ http://it.trend-ai.com/$1 [R=301,L]
# END WordPress

 

私の環境ではWordPressとホームページが同一階層だったため、当初リダイレクトできませんした。

そこで、httpd.confを見直して以下を追加しました。

<Directory ”WordPressの階層”>
Options FollowSymLinks
AllowOverride All
</Directory>

主要なキーワードの検索順位を見ると、ようやくパンダアップデートの呪縛から開放される兆しが見えてきたので、これ以上のトラブルはマジに簡便して欲しいです。

台風が原因かな? ホームページが見れるようになったことのお知らせ。

サーバトラブル | by 管理者
6月 20日 2012 年

今日の午後8時頃に出先からホームページにアクセスするとホームページが表示されないことが判ったため、サーバが落ちているのだろうとサーバの状態を確認したところ「稼働中」になっており、DNSを疑って調査してみましたが問題なし。

取りあえずリモートでサーバを再起動したところホームページが見れるようになりました。

今日の午前0時事頃からサーバに異常が発生していたようですが、出先からサーバのログを確認することができないのでホームページが見れなくなった原因は判りません。

昨日の台風の影響でしょうか?

レンタルサーバーにはUPSが付いているはずなので、このようなときこそ安全だと思っていたのですが、違うのかな?

今日は帰ることが出来ないため、明日原因を調査します。

 

 

 

それにしても、昨日の台風は凄かったですね。

私が住んでいる愛知県豊橋市は台風に直撃されましたが、テレビを見ていると、テレビのテロップに愛知県豊橋市植田地区 2万XX世帯避難って表示されており、まさに私が住んいるところだったので、「おいおい」って感じでしたが、サイレンも避難の連絡も無かったし、何より避難場所はここより低い場所なので避難しませんでした。

今年は1発目の台風に直撃されたので、これ以上の台風は勘弁して欲しいです。

 

 

*** 2012/06/21 追加 ***

帰宅してからホームページが繋がらなくなった件の原因調査を行いました。

サーバの/var/log/messagesを見ると、以下のようなメッセージが記録されていました。

 

Jun 19 18:20:59 www kernel: httpd invoked oom-killer: gfp_mask=0x200da, order=0, oom_adj=0, oom_score_adj=0

 

oom-killer:を調べると、

「OOM Killer(Out of Memory Killer)は,システムが実メモリーと仮想メモリー空間(スワップ領域)を使い切り,必要なメモリー領域を新たに確保できない場合に,プロセスを強制 終了させて空きメモリーを確保する,Linuxカーネルの仕組みです。」

とあるので、何からの原因でこうなったのでしょうね。

アクセス数の増加が原因でれば嬉しい限りですが・・・

 

アパッチのアクセスログを見ると、このメッセージが出た後もIPアドレスが記録されていたので、サーバーが動き続けており、ブラウザから接続は出来ていたみたいですが、ホームページが表示されなかったみたいです。

さくらインターネットのVPS 1Gの格安プランですが、スペック的に厳しいのだろうか?