Site裏の整理整頓

　新たな環境構築も何とかひと段落して等速直線運動なIrrlichtです。
今回は管理作業における備忘録記事です。無駄に長く興味がある人にしか意味を成しませんがそれでも何方かの参考になればという事で。

ログバックアップ体制
　サーバ側で定期的にcronでScriptを回してblogで使用しているMySQLのデータとWikiのログをバックアップしています。ただ、完全に全てをバックアップすると圧縮しても100MB以上のサイズになります。そこで、毎日ではなく例えばWikiでは月1で全ログ¹をバックアップ、週1で重要ログ²をバックアップという工夫を行ないました³。この工夫自体はcronで走らせるScriptに組み込みました(理由は後述)。まぁ、サーバ容量は150GBも有るので実際はあまり気にしなくても良いのですが節約の精神は大事でしょう。
　また、全てのバックアップを同時に行なうのはサーバにとって宜しくありません⁴。ならばバックアップ対象のWiki&blog毎に時間帯を変えて分散化すれば良いとなりますがここで問題があり、利用しているプランでは設定できるcronのjob数は5つまでなのです。そこでcronで走らせるScriptに時間判定を行なう工夫も突っ込みました(これが上で省略した理由の内容)。cron job自体はバックアップを行なう時間帯に1時間おきで走らせ、その時々で行なう処理を決めるという方法です。

上記二つをあわせて当初はこんな感じに記述しました⁵。

#!/bin/sh

# ---------- Setting
WWW_BASEDIR=/home/ACCOUNT_ID/www
PATH_WIKI_BACKUP_BASEDIR=/home/ACCOUNT_ID/Backup/PukiWiki

BACKUP_ALL_TARGET="attach/ backup/ counter/ wiki/"
BACKUP_NORMAL_TARGET="backup/ wiki/"

# ---------- 日時取得
DATE=`date +%F-%H%M%S`
DAY=`date +%d`
HOUR=`date +%H`

# ---------- FLAG初期値
BACKUP_FLAG_WIKI01=OFF
BACKUP_FLAG_WIKI02=OFF

# ---------- 実行
# ----- FLAG決定
# 月2回バックアップ：毎月1日には完全Backup、15日には通常バックアップ
# YYYY-MM-01
if [ ${DAY} = 01 ]
    then
    # Target dir
    PARAM=${BACKUP_ALL_TARGET}
    MODE=ALL

    # AM 04
    if [ ${HOUR} = 04 ]
        then
        BACKUP_FLAG_WIKI01=ON
    # AM 05
    elif [ ${HOUR} = 05 ]
        then
        BACKUP_FLAG_WIKI02=ON
    fi

# YYYY-MM-15
elif [ ${DAY} = 15 ]
    then
    # Target dir
    PARAM=${BACKUP_NORMAL_TARGET}
    MODE=NORMAL

    # AM 04
    if [ ${HOUR} = 04 ]
        then
        BACKUP_FLAG_WIKI01=ON
    # AM 05
    elif [ ${HOUR} = 05 ]
        then
        BACKUP_FLAG_WIKI02=ON
    fi
fi

# ----- Backup
# Wiki01
if [ ${BACKUP_FLAG_WIKI01} = ON ]
    then
    PATH_CD_DIR=${WWW_BASEDIR}/Wiki01_dir
    PATH_ARCHFILE=${PATH_WIKI_BACKUP_BASEDIR}/[${DATE}][${MODE}]wiki01.tar.bz2

    cd ${PATH_CD_DIR}
    tar jcf ${PATH_ARCHFILE} ${PARAM}
fi

# Wiki02
if [ ${BACKUP_FLAG_WIKI02} = ON ]
    then
    PATH_CD_DIR=${WWW_BASEDIR}/Wiki02_dir
    PATH_ARCHFILE=${PATH_WIKI_BACKUP_BASEDIR}/[${DATE}][${MODE}]wiki01.tar.bz2

    cd ${PATH_CD_DIR}
    tar jcf ${PATH_ARCHFILE} ${PARAM}
fi

　ご覧の通りシェルスクリプトを利用しています。ここで注意する事があり、さくらはFreeBSDで動いているのでtarで作成される書庫がちょっと違う事です。一応統合アーカイバプロジェクトのTAR32.DLLでも処理できますが、見慣れない”PaxHeader”というディレクトリ⁶が出てきたりディレクトリ構造がおかしくなったりします⁷。これはTARが”–format=pax”のオプションで動いているせいっぽいです。現在のところは困ってませんし、必要になったとしてもサーバ上で展開すれば良いのでなんら気にする必要は有りませんが、気になる場合は上のコードの圧縮処理部分をちょっと書き換えれば良いと思います⁸。

2010-07-04追記)
　最新のTAR32.DLL(v2.34)に更新しましたらば”POSIX形式のTAR書庫に対応”という更新情報がありました。そこで上述のアーカイブに試してみた所、上手く展開できずディレクトリ構造が壊れる問題は解決しました。サブディレクトリ内に”PaxHeader”というフォルダも出てきてしまう事例は観察されますけどそれ以外の問題はないようです。

tar jc --format=gnu -f 出力アーカイブ名 アーカイブ対象

　一応上のコードでも期待通りの動作をするのですが、なにせシェルスクリプトは記述法の自由度が高い訳ではないので保守性に乏しいという欠点が挙げられます。上の例でも、動作する時間帯や対象Wikiが増える度にコードを追記していく必要があり面倒です。そこで手っ取り早い解法としてPHPでリライトする事にしました。

<?php
// ---------- Setting
$LGBCK['PATH_WIKI_BACKUP_BASEDIR'] = '/home/ACCOUNT_ID/Backup/PukiWiki';

// 各Wikiのサーバ内Path
$LGBCK['TARGET_WIKI_DIR']['WIKI01']   = '/home/ACCOUNT_ID/www/Wiki01_dir';
$LGBCK['TARGET_WIKI_DIR']['WIKI02']   = '/home/ACCOUNT_ID/www/Wiki02_dir';

// Backup対象
$LGBCK['BACKUP_TARGET']['ALL']        = 'attach/ backup/ counter/ wiki/';
$LGBCK['BACKUP_TARGET']['NORMAL']     = 'backup/ wiki/';

// "DD-HH"で設定。設定値頭に#が有る場合は全Backup(ALL)。それ以外は最小Backup(NORMAL)
$LGBCK['EXEC_DAY']['WIKI01']       = array('#01-04', '11-04', '21-04', );
$LGBCK['EXEC_DAY']['WIKI02']       = array('#01-05', '09-05', '17-05', '25-05', );

// ---------- 日時取得
date_default_timezone_set("Asia/Tokyo");
$date0 = date('Y-m-d-His');
$date1 = date('d-H');

// ---------- Backup実行
while (list($key1, $array) = each($LGBCK['EXEC_DAY'])) {

    $mode_flag = 'NORMAL';

    while (list($key2, $exec_date) = each($array)) {
        
        if (substr($exec_date, 0, 1) == '#') {
            $mode_flag = 'ALL';
            $exec_date = str_replace('#', '', $exec_date);
        }
        
        // Backup時間ではない
        if ($date1 != $exec_date) {
            continue;
        
        // Backup時間
        } else {
            $param       = $LGBCK['BACKUP_TARGET'][$mode_flag];
            $arc_path    = $LGBCK['PATH_WIKI_BACKUP_BASEDIR'] . '/' . "[$date0][$mode_flag]$key1.tar.bz2";

            chdir($LGBCK['TARGET_WIKI_DIR'][$key1]);
            $cmd = "tar jcf $arc_path $param";
            exec("$cmd");
        }
    }
}

?>

　これならばバックアップ時間の変更や対象Wikiの増加が発生しても設定を変えるだけでOKなので極めて楽です。ただし気になる問題も有り、それはPHPを利用する事で発生するオーバーヘッドです。場合によってはバックアッププロセスを叩き落されるかもしれません⁹。しかしながら、メンテナンス性とても魅力なのでとりあえずやってみて上手く行くなら後者のPHPを利用した方法に乗り換えようかとは思っています。

　ところで、バックアップファイルはSiteと同一サーバ内に作成しています。これは多少不安要因に成ります。例えば、サーバのデータが完全に吹っ飛ぶという事態になったらどうしようも有りません¹⁰。以前は定期的にローカルに保存していたのですが、現在は常時そんな事は出来ない状況です。バックアップファイルサイズも小さくは有りません。更に、サーバとの接続をftpで行なうには危険過ぎます(特に信用できない環境で行なう場合)。そこでscpやsftpを使うべきなのですが、自動化¹¹を行なうに良いツールが今の所見当たりません。一応今まで自動化処理で多用していたlftpにもsftpが利用できるらしいので今後検討するべきかもしれませんが、バックアップファイルのDL自動化に限るならば、無駄に苦労するよりはhttpからアクセス出来る場所に置いてwgetという手の方が楽かもしれません¹²。別解として、別にバックアップデータ置き場にもう一つ別のサーバを借りてcronで定期的にバックアップファイルを引っ張ってくるという案も有ります¹³。この方が楽なので良いのですが、バックアップファイルのサイズがどうしても大きくなる事を踏まえるとそれなりのサーバスペースを利用できるサービスが要求されます。よって非現実的でしょう。そういう訳で、バックアップの自動化が一番現実的かと思います。

ログ保存階層の整理
　管理下のSite群のScript等で作成されるログを出来る限り管理しやすいように整理統合を行ないました。それがどうしたって方も多いでしょうが、管理側から言えばとても重要です。ある程度の規模のSiteを管理されている方には分かりやすいと思いますが、複数のScriptを使用した場合、ログファイルがこれまた複数発生します。勿論Script毎に保存される場所が異なります。これを定期的にバックアップするのは正直面倒です。サーバ内のパスをあっちこっち行ったり来たりしてその間に大事な物を忘れるとか十分に有り得ます。lftpを使用する等して自動化を図るという手も有りますが、サーバ側でログの置き場をまとめちゃうのが一番です。という訳で今まではこんな感じの構成にしていました。現在のログディレクトリ構成はこうなっています。

/Log_Dir/oblivion.z49.org/ログファイルA
/Log_Dir/oblivion.z49.org/ログファイルB
/Log_Dir/oblivion.z49.org/ログファイルC
/Log_Dir/oblivion.z49.org/ログファイルD
/Log_Dir/fallout3.z49.org/ログファイルA
/Log_Dir/fallout3.z49.org/ログファイルB

ご覧の通り、Site毎にログ保存階層を作って全部突っ込むという方法です。これならば手動だとしてもSiteの数だけバックアップを行なえば良いのでかなり楽になります。Script設置時にその設定をきちんと変えなければいけませんが、後で楽が出来る事を考えたら大した苦労じゃ有りません。

　ところが、これでも不便を感じるようになってきました。その原因は、月毎に作成されるようなログファイルが複数有るのでそれを含めたバックアップがとても煩雑になってしまうという事です¹⁴。よってこれの改善も図りました。

　改善の方法は単純で、cron jobで使わなくなった旧ログを定期的に保存用ディレクトリに移動させるという方法です。管理側はその保存用ディレクトリだけDLしてくればOKというとてもお手軽な感じになります。ただ、この移動処理を行なうScriptが作業をしやすいように以下のようにログディレクトリの構成を変えました。

/Log_Dir/スクリプトA/oblivion.z49.org.ログファイル
/Log_Dir/スクリプトA/fallout3.z49.org.ログファイル
/Log_Dir/スクリプトB/oblivion.z49.org.ログファイル
/Log_Dir/スクリプトB/fallout3.z49.org.ログファイル
/Log_Dir/スクリプトB/game.z49.org.ログファイル
/Log_Dir/スクリプトC/oblivion.z49.org.ログファイル

ログファイル名に利用しているSiteのドメインを識別用文字列として入れました。そして保存用ディレクトリはこんな感じです。

/Backup_Dir/201001/スクリプトA/oblivion.z49.org.ログファイル
/Backup_Dir/201001/スクリプトA/fallout3.z49.org.ログファイル
/Backup_Dir/201001/スクリプトB/oblivion.z49.org.ログファイル
/Backup_Dir/201001/スクリプトB/fallout3.z49.org.ログファイル
/Backup_Dir/201001/スクリプトB/game.z49.org.ログファイル
/Backup_Dir/201001/スクリプトC/oblivion.z49.org.ログファイル

　ログの日付(月毎)で仕分けを行なうようにしたのでローカルへのバックアップは1回の作業で済む様になりました。バンザイ。また、月毎に仕分けされる為、もう保存しておく必要のない物も明確になるので削除も容易でサーバ内の整理整頓にも繋がります¹⁵。ここまで整理すればlftpを使ったような自動化処理もとても楽になります。

Wikiの自動Namazu化
　これは現在停滞しています。当初は深夜にcronでmknmzを一回走らせて自動的にINDEXを更新するようにしようと考えていました¹⁶。そこでサーバに既にインストールされているNamazuを利用しようと思ったのですが、なんとkakasi¹⁷が入っていませんでした(代わりにMeCabが入っている)。kakasiベースで既にINDEXを構築しているのでここでMeCabに変更するのは手間と時間が必要です¹⁸。しょうがないのでNamazuとkakasiを自前でインストールです。ここまでは上手く行きましたし、Namazuとkakasiの連携も取れているようでした。で、あとはサーバにPukiWiki用のフィルタをアップしてmknmzrcでちょいちょいと指定してやれば…と思ったのですが話はそう上手くいきませんでした。INDEX作成自体は始まるのですが、すぐにそれが終了してしまいます。これは恐らくサーバ側の制限で叩き落されているのだろうと推測しました¹⁹。ならばそれを回避できるText::Kakasiを導入するしかないと思い試行錯誤したんですがこれが上手く行きません。多分些細なミスが原因だと思うのですが。
　…という訳でWikiの自動Namazu化はしばし保留です。

VirtualPC & VirtualBox
　以前はVirtualPCを利用していましたが、結局使い慣れたVirtualBoxに戻しました。確かにVirtualPCはD&Dも出来て便利です。ですがLinuxをゲストとしては利用しにくい問題がありました。更に一般には多く使われているWindows XP homeはホストPCとしては対象外になっている事があげられます。特に後者のせいか一番の目玉のD&Dが出来ませんでした。VirtualBoxでのホストとゲストのファイルのやり取りはゲスト側に”Guest Additions for Windows”を導入する事で実現できますので多少面倒ですが致命的な程ではありませんし。
　尚、VirtualBoxはVirtualPCで利用したディスクイメージも利用できるので戻すのは簡単でしたが今後の事も考えてNHCでVDMK形式に変換しました。この時、VirtualPCで”バーチャルマシン追加機能”を使用していた場合はそれを削除しておかないとVirtualBoxではゲストOSが立ち上がらない現象が観察されました。当たり前かもしれませんが。

spamホイホイ
　Internetにはspamメールを送信するためにE-Mailアドレスを収集するCrawlerが跳梁跋扈しています。そこで、当方が管理するサイトにはそういうCrawlerのアクセスを捕捉する工夫をして有ります。具体的に言いますと、アクセスログを取れるページを一つ作り、そこへ管理下のサイトからリンクを張ります。このリンクの張り方が味噌で通常のブラウザでは見えないようにします²⁰。これでソースを解釈する事でリンクをたどるCrawlerのみがそのページに来るようになる訳です。でもってそのアクセス解析ページにダミーのメールアドレスを記載して置き、そのダミーアドレスにspamが来たらそのアクセスはE-Mail収集Crawlerであると断定できるというわけです。ダミーアドレスはそのページへアクセス時間から自動的に作成しており²¹、メールアドレスの文字列を見る事でどのアクセスか特定できるようにしています²²。これでどのアクセスがそういうCrawlerか断定できたらおもむろにそのIPをアクセス禁止すればいいという流れです。
　で、ここ最近そのダミーアドレスに同一人物からと思われるspamが舞い込んで来るようになったので保存していたログを調べてみる事にしました。

1) 200811022303
Date        : 2008/11/02 23:03
REMOTE_ADDR : 89.161.75.190 (PL)
REMOTE_HOST : 75-190.89-161.tel.tkb.net.pl
USER_AGENT       : Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)
REFERER          : 
CONNECTION       : close
ACCEPT_LANGUAGE  : en
ACCEPT_ENCODING  : 
ACCEPT_CHARSET   : 
ACCEPT           : */*
備考             : mailtoタグのアドレスを拾われる


2) 200812211256
Date        : 2008/12/21 12:56
REMOTE_ADDR : 118.127.214.76 (KR)
REMOTE_HOST : 
USER_AGENT       : Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7
REFERER          : 
CONNECTION       : close
ACCEPT_LANGUAGE  : en
ACCEPT_ENCODING  : 
ACCEPT_CHARSET   : 
ACCEPT           : */*
備考             : mailtoタグのアドレスを拾われる


3) 200904122359
Date        : 2009/04/12 23:59
REMOTE_ADDR : 88.189.244.202 (FR)
REMOTE_HOST : bot35-1-88-189-244-202.fbx.proxad.net
USER_AGENT       : Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)
REFERER          : 
CONNECTION       : close
ACCEPT_LANGUAGE  : en
ACCEPT_ENCODING  : 
ACCEPT_CHARSET   : 
ACCEPT           : */*
備考             : mailtoタグのアドレスとべたで書いたアドレスを拾われる

　赤字で強調しましたが、該当するアクセスは2008/2009頃の物という結構古い物でした。これは長期的にCrawlerを走らせていたのか、それともようやくその収集アドレスを買ってspamする奴が出てきたのかなのかもしれません。昔のE-Mailアドレス収集Crawlerは分かりやすいUSER_AGENT文字列の物が多かったのですが、これらはそうではありません。事前に対策するのは難しそうです。IPに関してはProxyの可能性も有りますが面倒ですし一括でアクセス禁止でよいでしょう。

　ところで、上で言及したように全て同一人物による送信と見ています²³。そこでそのspamのメールヘッダも見てみました(“******”は伏字)。

Return-Path: 
Delivered-To: ******
Received: (qmail 90391 invoked from network); 12 May 2010 07:50:56 +0900
Received: from unknown (HELO mgw5.zenno.net) (192.168.0.150)
  by mail7.zenno.net with SMTP; 12 May 2010 07:50:56 +0900
Received: from s104.xrea.com (s104.xrea.com [220.151.238.229])
	by mgw5.zenno.net (Postfix) with SMTP id B99FD2401B1
	for <******>; Wed, 12 May 2010 07:50:55 +0900 (JST)
Received: (qmail 12933 invoked by uid 89); 12 May 2010 07:50:54 +0900
Delivered-To: ******
Received: (qmail 12925 invoked by uid 89); 12 May 2010 07:50:53 +0900
Received: from 91-64-245-209-dynip.superkabel.de (HELO qskxq.superkabel.de) (91.64.245.209)
  by 192.168.1.96 with SMTP; 12 May 2010 07:50:53 +0900
Received-SPF: none (192.168.1.96: domain at bullelesite.com does not designate permitted sender hosts)
MIME-Version: 1.0
Content-Type: multipart/related;
 boundary="-59de248419ce705d5dcdb2ec33d7c8eb"
From: Gasior Yorks 
List-Unsubscribe: 
List-post: 
List-Subscribe: 
List-id: Were already several succes
Message-ID: 
Date: Wed, 12 May 2010 00:51:00 +0200
Subject: Ere to accept, in 1861, the alternative of war rather than dissolution. The course of Do
To: Gouras Bashi <******>
X-EdMax-Attachment-File: 20100519_155048_pfwh2o\Attach$.html,
                         20100519_155048_pfwh2o\angelical.bmp,
X-EdMax-Status: 0

xreaのcatch all機能を使って無限アドレス²⁴を実装しています。手持ちの他のxrea経由のメールのヘッダを踏まえると上の青字の部分も信用できる行です²⁵。意味は『”192.168.1.96″というサーバが”qskxq.superkabel.de”と自称する”91.64.245.209 (91-64-245-209-dynip.superkabel.de)”からメールを受け取ったよ』という感じです。ここで192.168.1.96はローカルアドレスとされる物ですが、恐らくxrea内のサーバではないかと推測されます。つまりspam送信元は”91.64.245.209″と分かります。ところが他のspamも見ますと、それ以外のIP/HOSTも多いです。よってBotnet等の利用が考えられます。また、HOST名に”dynamic”や”dynip”という文字列も多く見られることより²⁶、その推測を補強しそうです。
　加えて、メールヘッダ内にメールマガジンの購読停止で良く有りそうな文字列”“が有ります。これはspamの停止が出来るのではなく、購読停止手続きとして誤解した人がそこに返信する事で『生きているメールアドレス』である事を判別する物かと思います。ただ、全てのspamでそのアドレスのドメイン名が違ったので気休めのダミーかもしれません²⁷。

.htaccess管理
　先日さくらから『コメントは行頭開始じゃ、ごるぁ』と怒られたのをきっかけに.htaccessの更新を自動化するものも作ってみました。基本は元々適当に作っていた、各サイト用の.htaccessのテンプレートを作っておきそれを元に更新Scriptがアクセスコントロール情報を記入した新しい.htaccessを作るといった仕組みを書き直して拡張しました。キモは特にアクセス禁止＆禁止除外IP付近です。さくらに言われた時に思い付いたのですが、チェックすべきIPをきちんとデータベース化してそちらで管理すれば.htaccessにコメントを書きまくる必要は全然無いじゃないか、と。そのDBに規制/解除の日時や理由等を情報として入れておけば調べるのも.htaccessで利用するにも容易じゃないか、とも。
　そうやってKIANで書き直したScriptですがかなりの省力化に繋がりました。追加しようとするIPから既出のものをはじき出したり、そのIPの所属するCIDRや所属国²⁸を出力したりと便利便利です。何で今までやらなかったんだろうと思うくらい²⁹。
　『手を抜くためには努力を惜しまない』、ヤッパリ大事な事ですね。

メインPCのCPUを換装
　ここからは完全に雑談です。
　今までAthlon 64 X2 5600+ (Windsor)を利用していたのですが、Phenom II X4 965 (C3)に換装してみました。何でThubanやZosmaじゃ無いのって話も有りますが、別に6コアなCPUを生かせるアプリを使ってもいませんし。
　Oblivionへの効果は…やはり良く言われている様にあんまり差が有りませんでした。それよりも日常的に行なう作業への効果の方が重要という事で、管理SiteのサーバのApache logの統合&分割処理³⁰を換装前と後で実行し、比較してみました。

[実際の処理]
1) 日毎に作成されているapache logを展開 (例：access_log_20100201.gz -> access_log_20100201)
2) 対象月のapache logを統合  (例：access_log_20100201 ～ access_log_20100228 -> access_log_201002.log)
3) 統合ログをドメイン毎に切り分け (例：access_log_201002.log -> z49.org.201002.log, oblivion.z49.org.201002.log ...)
4) 切り分けたログをgzip圧縮 (例：*.201002.log -> *.201002.log.gz)

実際の結果です。ついでにアンチウイルスソフト(Avira AntiVir)の常駐機能のON/OFFも比較してみました³¹。因みに処理対象のログは1ヶ月分、圧縮状態での合計サイズ約200MBです。

[分割処理]
・PHP Scriptを使用 (PHP 5.2.9 (cgi), Cygwinでコンパイル)
・GIGABYTE MA790GP-UD4H 
・DDR2 2GB*2 (但しOSからは3.25GBの認識)

[Athlon64 X2 5600+ (AntiVir Guard ON)]
　1) 展開         78s
　2) 統合        258s
　3) 分割      4,157s
　4) 圧縮        335s
　   Total     4,828s

[PhenomII X4 965 (AntiVir Guard ON)]
　1) 展開         35s
　2) 統合         74s
　3) 分割      2,186s
　4) 圧縮        197s
　   Total     2,492s

[PhenomII X4 965 (AntiVir Guard OFF)]
　1) 展開         43s
　2) 統合         80s
　3) 分割      1,899s
　4) 圧縮        188s
　   Total     2,204s

　利用しているPHPはマルチコアを上手く利用できる訳ではない筈なのでほぼコア対決になっていますが、Phenomでは処理時間が半分近くまで短縮しています。PhenomでのAntiVir Guard ON/OFFの結果が腑に落ちませんが色々な細かい理由でもあるのでしょう。ともあれ、細かい理屈なぞ抜きにしても当方にとってはIYH!の意味は十二分に有りました。懸念はこの夏をどれだけ受け流せるか、位でしょう。一応それなりの対策はして有るので乗り越える分には無問題でしょうけど。

HDD換装
　メインPCの起動ドライブが不調に陥りましたので換装しました。今まではST3500320AS (500GB, 7200.11)だったのですが倍の容量のST31000528AS (1TB, 7200.12)になりました。起動ドライブにはOSとアプリしか入れてないのでそんなに大容量はいらないのですが、かといってSSDやRaptorを導入する程速度に飢えている訳でもないので無難な選択にしました。SeagateならRMAも楽ですし³²。
　その不調とは時々唐突にOSの反応が凍ったかと思うくらい無反応になる症状です。暫く放置していると『遅延書き込みに失敗た』という内容のエラーが出ました。もしやとデバイスマネージャを覗くと転送モードがPIOに落ちてました。また、イベントログを見ると”ページング操作中にデバイス \Device\Harddisk0\D 上でエラーが検出されました。”(イベントID 51)という内容がずらずらずらと出ていました。再起動すれば転送モードは元通りになり何事も無かったかのように順調さを取り戻すのですが、そのうちまた唐突に同じような症状を発生させるのです。SMARTには何も異常は出ていませんでしたし暫くはめんどくささから騙し騙し使用していましたが、とうとうMFTをぶっ壊してくれました。幸い緊急時用にUltimateBootCDをRに焼いておいたのでその中にあるtestdiskで修復、復活できました。備え有れば何とやら。
　しかし流石にもう堪忍出来ません。おもむろにPCショップから上記の新HDDを確保して元々所有していたTrue Image 2009で移植を行ないました。面倒くさがりなので新HDDはUSBアダプタで接続、Windows上からTrue Imageを起動して移植を図りました。True Imageデフォルトの移植プランではHDDが倍になっているので各パーティションも素直に倍にするようになっていましたが自分なりのレイアウトに調整してみました。設定後、実行させてみたらやはりWindows上では完結できず、再起動後にOS起動前にTrue Imageが立ち上がり移植作業を行なっていました。ソフト側のチップセット等への対応が出来ているのかちょっと心配でしたが問題なく認識・進行しました³³。ところが、何かTrue Imageさん、凄い面倒くさい事してます。まず、新HDDを旧HDDの割合でパーティションを設定・ファイル移動、その後パーティションのサイズを調整といった感じに動きました。最初から設定どおりに切ればいいじゃん！と思いつつものんびり眺めていました。しかしここでまたびっくり、終わったはずなのにまた最初から同じ事を繰り返しています。なんでー。結局その作業セットを10回くらい繰り返していたようです(途中から放置)。もしかすると、Windows上のTrue Image上であれやこれやと新HDDのパーティション設計を色々こねくり回していたその過程を全て再現したのかしらん、という気もしますが良く分かりません。それを確認するだけにまたやるのは面倒なので真相は不明ですが若し今度やるときは気をつけねばなぁ、と思います。そのときは新OSと新VersionのTrue Imageを使っていそうですが。

　ただ、不調に陥ったHDDの症状が当方には未経験のものだったのが多少気になります³⁴。もっとも使用時間は1,566時間(約652日)だったので元は取れたというべきでしょうか。それに、とりあえずは普通に動くのでデータを消去する事も可能ですし、もう1基死亡しているHDD³⁵が有るので一緒にRMA送りするのに丁度良かったです³⁶。そもそも今回いかれたHDD(7200.11)はFirmwareバグによるロック問題が発生した物なので厄介払いをするには丁度良い機会だったのかもしれません。…まぁ大抵は同じ機種で戻ってくるので期待はしていませんが³⁷。

まとめ
　管理の関係上、見えないところに大きく手を入れました。　しかし当然のように、問題が1つ有りまして。サーバ内のログディレクトリを大幅に整理した関係で(ぽんこつ属性持ちの私にはよくあることですが)Scriptがまともに動かなくなってしまっているところがあるかもしれません。その時は遠慮なく当方まで教えて頂ければ嬉しく思います。

attach/ backup/ counter/ wiki/ [↩]
backup/ wiki/ [↩]
バックアップ間隔は夫々のWikiの編集頻度を見て個別に設定 [↩]
サーバ設定でプロセスが叩き落されバックアップが完走しない可能性も [↩]
記事用に書き直した物で実際のものとは異なる [↩]
書庫内のファイル情報が記述されたファイルが格納される [↩]
Explzh等で確認。DLL側とアプリ側のどちらが理由かはよく分からないが恐らくDLL側。7-zipが提供するアーカイバやCygwinのTARでは正常に展開できる事は確認済 [↩]
未検証 [↩]
ビジネスプロプランを利用しているので考慮しなくてよいが、もしそうでなかったのなら大抵PHPはセーフモードで動作しているのでexec等がしにくいという問題もあった [↩]
実はさくらさんの方でサーバ内データの定期的バックアップは行なわれているらしいが、そういうものは過信すべきではない。データが吹っ飛ぶような事態は以前使っていたxrea/CoreServerではぼちぼち発生していた様だがさくらでは殆ど無かったと思う [↩]
やる事多過ぎで手動でなんかいちいち面倒くさ過ぎだが手順はほぼ決まっている為自動化が適用可能 [↩]
バックアップファイル名は基本的に不定(∵月ごと等に新生される)のでちょっと工夫が要る [↩]
この場合もftpは危険で、scp/sftpも使えないのでhttpがベスト [↩]
spam対策の投稿記録ログ等は基本的にサイズがとても大きくなるので月毎に新生している。ただ、同じ階層にばらばらっと現行ログと旧ログが混在する形になっているので旧ログだけを選びながらDLをするのはしち面倒くさい [↩]
テキトー管理をやっていると案外サーバ内は汚れていくんです。気の利くお掃除メイドさんでもいたらなーっ。…え？私がだらしないだけだろ、って？ノーコメントっ [↩]
投稿毎に走らせるのは負荷の上で問題 [↩]
Namazuが利用できる分かち書きプログラム [↩]
しかも、以前はMeCabを利用していたがどうも検索が上手く行かないのでkakasiに変更したという経緯もある [↩]
1文書毎にkakasiをその度に起動させているのでプロセス数の上限に引っかかった物と思われる [↩]
CSS等を利用 [↩]
2001_05_01_230205@example.com というような感じ [↩]
記述もメールタグを利用した記述法や数値参照を用いた方法等を色々用いてそのCrawlerがどの記述法のアドレスを拾うかで収集能力を探る事も行なう [↩]
内容がほぼ同じなので [↩]
メールアドレスの@の前が何であっても受信し、特定アドレスに転送する [↩]
時には偽装ヘッダを入れるspamも有るので解釈は気をつける必要がある [↩]
DDNS等を利用して自鯖を建てる時に割り振られるHost名にもそういうのは多いが、そうでない通常ISP利用者のHost名もそんなものになることが多い [↩]
ドメインも安いとはいえspamの為に何個も取るのは非効率的。ただ、そのアドレスが少なすぎる場合はメールヘッダを解釈するspamフィルタ等で簡単に対策出来てしまうのでそのバランスが難しいだろうと推測 [↩]
GeoIPを使っても良かったがライブラリ要求とか面倒くさかったので各NIC(AFRINIC, APNIC, ARIN, LACNIC, RIPE-NCC)のIPリストをDLしてきて自前でIPのDBを作成、処理に利用している [↩]
今にして思えば更新が面倒で、メンテはかなりサボってた [↩]
利用プランでは同居させているSite群のApache logが全てまとめて日毎に出力される(xreaではドメイン毎に分割されて出力される)。これはログ分析上不便なので、月毎にログを統合させた後、ドメイン毎に分割するという処理をローカルで行なっている [↩]
NamazuのINDEXを作成する時では如実に差が出て来る [↩]
WDだとシンガポールに送る必要があるがSeagateなら国内でOK [↩]
True Imageの中身はLinuxなのでどうしても新しいチップセットに対応しない事例が出て来る [↩]
『カッコンカッコン』とか『きゅいーーーん』とか『かかかかかかっ』という異音でご臨終した経験は夫々1回づつ有りますが [↩]
Seagate ST3300622A1, 300GB, 7200.9, PATA [↩]
両方ともRMA対象期間5年の機種 [↩]
時々容量がもとより多い機種で返ってくる事もある模様。逆に容量同じでもプラッタ数が増える事とかもあるらしい [↩]

Andante scherzoso

z49.org上のWebsite群の管理blog…と様々な雑記

コメントを残すコメントをキャンセル

コメントを残す コメントをキャンセル

コメントを残すコメントをキャンセル