6/26　徴候

サーバのRAIDの調子が悪い。アレイが頻繁に外れ、復活をかけると戻るのだが、すぐまた外れてしまう。さすがにディスク寿命か。「計画的なメンテナンス」のため、メーリングリストに告知を出してディスク交換をスケジュールする。まあ、今までにもRAID1からのディスク交換は何度かやっている（その割には毎回手こずっている）から大丈夫だろう。
手こずる理由のひとつとして挙げられるのが、Software RAIDはOSレベルでの設定が必要で、それらがOSのディストリビューションの違い、バージョンの違いによってまちまち、ということがある。ただ、RAIDをハードウェアにしてしまうのは、それはそれでハード側に縛られてしまうのでちょっと躊躇するものがある。最近はむしろソフトウェアRAIDの方がパフォーマンスが良い（ハードウェアの方が一見有利だが、その機器での処理が結局ボトルネックになってしまう）ということもあるし、基本的にソフトウェアで処理したいものだ。
告知はした。仕事が詰まっていることもあるし、それなりに時間がかかる処理なので、深夜にやってしまうつもり。

6/27　発生

寝過ごして、予定の時間を大幅に押してしまった。障害の起きたディスクを外し、新しいディスクに入れ替えて作業を開始するが、どうしてもうまくRAIDの復旧がかからない。版元ドットコムのサーバは2004年導入。この数年間はLinuxの成熟期で、それ以前に比べてドラスティックな変化（USBへの対応とか、ext3が主流に、とか）は少ないのだが、RAID周りなどはかなり状況が変わってきていて、版元ドットコムサーバで使っていたVine Linux 3.2はそういった意味では少し「古い」仕様になっていて、RAIDはそこそこ簡単に組めるものの、運用レベルでの作り込みはお世辞にも良いとは言えない。ブートローダもLILOを使っているのでやたらと難易度が高くなっている。
しばらく作業を続けて、「まっとうなやり方」での再構築をあきらめ、OSのインストール時の設定オプションを利用して、RAIDを組み直す、という方針に切り替える。実際、このやり方でRAIDのディスク交換を何度かやったことがあるので、ある意味「確実」な戦術だ（今、思い返せば、「愚者は経験に学ぶ」とは正にこのことだ）。

作業を実行。インストーラの質問に次々と答え、設定を進めていく。

……おかしい。ディスクにフォーマットがかかってしまったようだ。

マシンの電源を落とし、確認してみる。ディスクは空っぽだ。どうも、Vine Linux4.xと、「今までうまくいった」マシンで使っていたCentOS（Linux）では、インストール時の挙動が違うようだ。Vineでは、ディスクは「必ずフォーマット」することになっているらしい。

まずいことになった。

ディスクのスーパーブロックを手がかりにいろいろ復旧の手だてを試みるが、全く効果がない。
そうこうしているうちに、夜が明けてしまった。
「OSを再インストールしたけれど、中身を完全に復旧できた」という記事をネットで見つけ、TestDiskというアプリを試してみる。記述をみる限り、かなり強力そうだ。こういうトラブルの時の常道、Knoppix CDで起動して……と思ったら、そもそもKnoppixにはこのアプリケーションが入っているらしい。さっそく試してみる。

「復旧」はできたものの、なにか完全に異なるものが出てきてしまった。ものすごく以前の、インストールして少し設定をかけたような感じのものだ。いずれにしろ、意味のあるデータはとれていない。

もう一つの手法を試してみることにする。サーバには二台のハードディスクがつながっており、故障したのはその一台。そのディスクは、作業開始の段階で取り外して、手つかずのままだ。このディスクに対して、「復旧」を試みる。まず、ddコマンドでまるごと別ディスクへの複製をかけてから作業を試みるが、この時点でエラーが頻発して、（このコマンドはもともと時間がかかるのだが）終了までに数日かかる見積もりだ。うまくいくかどうか分からない処理に、これだけ時間をかけるわけにはいかない。

この時点ですでに時計は正午を回り、夕刻が近づいていた。
石塚と相談して、方針を切り替え、復旧業者をあたってみることにする。

以前、個人的にwindowsマシンのデータを飛ばしてしまったことがあり、その時に復旧業者を当たったことがあるので、巷には「復旧業者」を名乗る会社が山のようにあることは知ってはいたが、ここ1、2年でさらに増えたようだ。中には入り口だけ複数あって実体は一緒なのではないか、と疑われるようなサイトもあり、なにやらアダルトサイトのような様相を呈しているのに辟易しながら、なるべく「真っ当そう」な業者を探す。
しかし、電話口で状況を説明すると、「難しいですね」という反応がほとんどである。

・Linux
・RAID

というこの二条件で、実態がどうか、という問題以前に担当可能な技術者がほとんどいないらしい、ということがよく分かる。

何軒かたずねてまわったのちに、とある業者が非常に好ましい対応だったので、話を詳しく説明してみる。かなり専門的なことまでやり取りした上で、「大丈夫です。そのようなケースでの復旧例は、あります」と力強く断言され、下駄を預けてみることを決意する。銀座にあるので、今なら持ち込めば「本日受付」に間に合う、ということで、マシンを抱えてタクシーに乗り込む。

技術者然とした白衣を身にまとった担当者が現れ、丁寧に対応してくれる。あざとい演出、とわかっていてもつい張りつめていた緊張が緩む。「大丈夫です」「弊社は個人でやっているような業者とは技術力が違いますから」「本日特急で診断して、明日、状況を連絡いたします」との力強い回答に安堵して会社に戻る。

不幸中のなんとやらで、版元ドットコムは新システムへの移行の真っ最中であるものの、登録・修正といった「入り口」の部分は完全に別のマシンにある。データ本体も、いったん別マシンのデータベースに入れた後、新サーバに「同期」をかけて表示する、という仕組みになっていた。つまり、テキストとしての書誌データは手つかずで、無事だ。とはいえ、新サーバにしかない情報も山のようにある。手元に複製が残っている部分はほんのわずかだ。特に、データベースに蓄積された「版元日誌」のような部分は壊滅的だ。もし復旧できなかったら……。しかし、業者に託した以上、とにかく今日やるべきことはこれ以上、ない。
善後の対策や最低限の告知を石塚が出したことを確認し、帰宅。

6/28　返事その1

業者からの返事が来る。メールでの報告書にはシビアなことが書いてある。「修復の難易度としては重度の部類」などといった記述はあるものの、電話での応対はあくまでも前向きだ。現物を確認した上での、「修復は可能と踏んでいます。作業が進めば、1〜2日で完了の特急コースでやります」との返答に、かなり安心する。早期に業者に任せず、自分であれこれ作業をしたことが悔やまれる。
さて、とはいえ、これでかなりの長期間（最低でも数日）に渡って、版元ドットコム、および関連している出版社のサイトが停止することが確定した。おそらく、版元ドットコム始まって以来最大の障害だ。

ポット出版、沢辺からのリクエストもあり、メーリングリストを暫定的に復旧する。版元ドットコムでは、基本的にすべての連絡をオンラインで行っている。日本各地の会員社はすでに90社を超えているし、とにかく、代替の連絡手段を確保しないことにはどうにもならない。確かに、メール連絡の復旧は速やかに行う必要がある。
ポットのサーバに間借りしてメーリングリストを立ててから、太郎次郎社エディタスの須田さんに指摘を受け、www.hanmoto.comのトップページも臨時のものをつくり、手元のサーバ環境をいじってなんとか表示されるようにする。
このトラブル下にあっても、ポットのサーバを始めとする、その他のサーバは問題なく動いているのは僥倖だ。過去、深刻なDDosクラックを受けてネットワーク全体が麻痺したことがあった。今回、同じような状態になっていたら、影響範囲はもっともっと拡大していたはずだ。まあ、比較してもしかたがないことではあるが……。

語研の高島さんから「組合員会議を緊急にやりましょう」との提案をもらう。たしかに、報告は入れているものの、運営責任を負っている組合員と情報を共有し、善後策を練るべきだ。眼前の状況への対応に手一杯で、そんなことすら思いつけなくなっていた。提案をありがたく受け入れ、仕切りは全部おまかせする。サーバの技術レベルのトラブルで、他の組合員の方々ができることはそうは多くない。互いにそんなことは承知している。それでも、できることを考えて、取り組んでくれている。自分が過労なり心神喪失なりで倒れるわけにはいかない。「自分から潰れたらしまいだ」と自分に言い聞かせる。この際、錯覚でもなんでもいいから、自分を奮い立たせなければいけない。

この日、「特急」で作業に入っているはずの業者からの連絡はなかった。

6/29　返事その2

状況を確認すべく、朝イチで業者に連絡を入れるがつかまらない。担当は、受付で話をした人から、「技術担当」の人に代わった。彼は実際の作業自体は行っていないようだが、とにかく「フォワード」ではないようだ。
午後になってから、連絡がつく。最初の担当者とは打って変わったトーンで、彼は、修復が思ったように進んでいないこと、当初の1〜2日でなんとか、というスケジュールは実現困難で、とにかく7/2に連絡をします、そこで一旦作業の区切りとして、報告をします、ということを告げた。

話が違う。

だが、自分でハードディスクを触っていた感触は、むしろそれに近いものがあった。修復は、もう、決定的に不可能なのではないか。だが、そう思ったからこそ、業者に連絡をし、依頼をしているのだ。「とにかく、進捗の報告をよろしく頼む」とだけ返すのが精一杯だった。

あまりにも話が二転三転するので、報告がためらわれる。いずれにしろ、7/2にならないと状況は見えないのだから、それまで待つことにする。

その間、データ復旧ができなかった場合に備えて、手元のデータなどの整理を石塚が進めてくれる。通常業務もこなしつつ、こういった細かな作業にお互い忙殺される。

7/2　返事その3

朝から連絡を取るが、業者の担当とは連絡がつかない。先方が告げた、「担当者の出社予定時刻」になっても連絡が来ないので再度電話をすると、「ミーティング中」。それからしばらくしても、連絡が来ない。電話をすると、別の人間が出てきて、「作業を進める際に、先払いでもらえないか」と、いきなり支払いの話を始めた。支払いについては、最初に来た書類には「分割払い可！」と、月々の支払額の数字がデカデカと書かれていた。作業の進展も見えないのに、前言を翻すような話をされて、かなり焦っていたこともあり、私は、電話口に出た業者に怒鳴り散らした。

「今日朝イチで、そちらから連絡することになっているのに、連絡が来ない、予定の時間になっても、ミーティング中、と言われた。まだ連絡来てませんよ。今、何時ですか？」
「作業の進展も見えてないのに、支払いの話ですか？　舐めてるんですか？」

……もしかしたら、「舐めてんのか？」と言ったかもしれない。業者に当たり散らして解決するものではないのは百も承知だが、第一印象からこっち、どんどん印象が悪くなっている。進捗がはかばかしくないときの対応は辛いものだが、それ以上に依頼者であるこちらの機嫌がいいわけはなく、一般論としてあまり褒められた対応ではないだろう。

昼すぎにようやく担当者と連絡がつく。彼は一層陰鬱なトーンで、
・論理障害ディスクの復旧が困難なため、物理障害の発生したディスクに対しての作業中
・分解して、ディスク自体からの読みとり作業を続けているが、難航中
・別の手段での作業に移っており、その結果が出るのは7/5頃
といったことを報告し、

・7/5の17時までには連絡を入れます
と通告した。「論理障害」というのが、誤ってフォーマットしてしまったディスクを指す。平たく言うと、彼らもギブアップしたのだ。
「何とかなりませんか」「作業は続けますが……」「分解読み取りの作業の後は、何をするんですか」「言えません」「は？」「どういう方法でやるのかは、お話できないのですが、とにかくその方法でやります」

なんだそれは、と思ったが、この際方法はどうでもいい。おそらく、他のもっと設備の整った業者に丸投げするのだろうが、個人情報保護レベルの話（依頼した翌日には個人情報保護についての書類が送られてきた。そういうところ、はしっかりしたところらしい）とか、技術提携時の契約とかが絡んで、言いたい事が言えないのだろうと（勝手に）推測して、「とにかく、よろしく」と電話を切る。

データは復旧できそうにない。

電話の感触からは、そう感じられた。

その日の「緊急組合会議」は、データ復旧は不可能、という前提で、話が進められた。こうなると、もう優先順位の問題だ。
あらためて、版元ドットコムの「システム」の最大の存在意義とは何か。書誌情報を登録・転送できる、ということだ。販売や情報公開も重要だが、登録・転送機能は業務に直結している。これを、長期間止めるわけにはいかない。

「どれくらいで、復旧できそうか」

ここで、日数を読み間違えるわけにはいかない。だが、転送システムは作りあげたのがかなり以前である、ということと、旧システムと新システムが複雑に混在している、ということもあり、かなり数字は読みづらい。新しいマシンを調達し、OSを入れ、ネットワーク設定やサーバのインストール・設定をしてから、作業に入るまでに一日以上はかかるだろう。そこから状況を読み解き、場合によっては転送先の書協や取次と連絡を取り合いながらシステムを再構築するには、やはり7日以上はかかる。だが、一週間以上、停止させるのはマズい（もちろん、事故が起きてから数日経過した今、結果としては一週間以上の停止にはなるのだが）。

「7/9までにはなんとかします」

幸い、ハードウェアトラブル対策として、常に予備マシンを用意するようにしていたので、新サーバはそれを流用することにした。サーバ用マシンは、いわゆるショップブランドのマシンを調達するようにしていたが、これらは一週間前後、時間がかかる。かといって、移ろいの激しいPCにおいて、せいぜい一年に数回のトラブルが起きるたびに、パーツの傾向などを調査し、自分で組み上げるのはリスクが大きすぎるので、このような体制にしていたのだ。トラブルがなくとも、3年〜4年ごとに数台のサーバマシンを順次交換するルーチンにしているので、マシンが「塩漬け」になるのは長くてもせいぜい1〜2年、陳腐化は充分避けられる計算だ。

新サーバ用に大容量ハードディスクだけ新たに調達し、帰宅する。

また、この場で改めて、沖縄の出版社、ボーダーインクへの「訪問サポート」行きをキャンセルすることを申し出る。7/5〜6の予定の沖縄出張が流れ、もともと同行する予定だった沢辺に後を託す。

7/3　転回

午後イチで、石塚が復旧進捗の報告を暫定メーリングリストに流す。あらためて、自分の引き起こした事態の重大さにたじろぐ。

いずれにしろ、方針は決まった。業者の報告待ち、は依然としてあるが、とにかく「新しいサーバ」を立てなければならない。

今までにない緊迫感の中、サーバの設定をはじめる。今までは、次期マシンのために徐々に設定をする、といったことがほとんどだった。トラブルが起きた場合にしろ、すべてが吹っ飛んでいる状態というのはなかったので、このような段取りを踏むのは初めてなのだ。

OSは、すでに数台に導入して安定稼働しているCentOSに切り替えることにした。Vineの安定感、これまでの信頼感は捨てがたいが、x86_64系のCPUへの対応やSATAドライバへの対応、といったハード面でのキャッチアップの遅さは、やはりリスクだ。自分で解決できる手腕があれば別だが、ここはインストールベースで圧倒的に有利なディストロに乗り換える、という決断を下した（まあ、いずれにしろゼロから作るのだから、ディストロの整合性もなにも気にしなくていい、ということは、もちろんこの選定に大きな影響を及ぼしている）。

7/4　作業

引き続き、作業。

7/11に「版元ドットコム勉強会」が予定されている。石塚が講師となってエクセル入門的なことをやるはずだったが、さすがにそちらに人員を割くのは難しい。だが、こんなときだからこそ、ちゃんとやるべき、ということもあり、講師は語研の高島氏に引き継いでもらう。実にありがたい。

月はじめは、会員各社に会費（その他サービス費用含むこともある）の請求書を発送している。だが、このサービス停止状態では、「サービスの対価として、会費をもらう」というのはおかしい。だが、状況がわからない中で決められることは少ない。とりあえず、請求自体は「保留」し、代わりにお知らせの文書を発送する。基本はメーリングリストで連絡、とはいえ、郵送でも通知しておいた方がいい。こんなトラブルの際はなおさらだ。事務局・寺門に文書の発送を依頼する。

そういえば、沖縄行きキャンセルの手続きをしていなかった。業務の一ヶ月以上停止、修復自体の費用などですでに数百万単位の損害が出ることが予想されている状態で忘れかけていたが、あわててキャンセルの手続きを調べる。半額くらいは戻ってきそうだ。なんともみみっちい話だが。

7/5　返事その4

朝起きて、PHSを手に取るかどうか、のうちに着信ランプが点滅した。

「作業完了の連絡が入りました」

担当者が言うには、技術の方から、データが取り出せた旨の連絡があったらしい。
障害が起きたハードディスクの復旧は、大きく分けて、
・普通に、障害が起きる前の状態に復帰する
・「データ自体」は戻るが、どのデータが、どのファイル名で、どのディレクトリに入っていたか、という情報は失われる
といった二つのケースがありうる（実際は両者の混在になることが多い）。

「データがバラバラに出てきたんですか？」
「いえ、ディレクトリ構造ごと復旧しているようです。データベース領域、webサイトの領域は取り出せたそうです」

どうやら、「やり方は言えない」方法だが、とにかく復旧はできたらしい。詳しい情報は追って、まとめて入れます、と告げて、電話は切れた。

予想外にも、データは戻って来た。いや、来そうだ。
だが、まだ素直には喜べない。確認がとれてから、だ。それが、担当者の務めだ。
午後、あらためて連絡が来た。データは復旧を終え、NTFS（Windowsのフォーマット）のディスクに収まっているらしい。これを取り出すのに一日かかる、というので、有無を言わさずこちらに送ってもらう手配をする。

13時頃、組合員に「業者の回答」の報告をした。
事態は大きく進展した。7/9までに復旧、はいずれにしろ必要だが、これに「復旧データの確認リストア」作業が付け加わる。だが、約束の日程を変えるわけにはいかない。この日できる作業を、できるところまで進めるだけだ。
Windowsのデータは、Linuxで直接には読めない。ntfs-3gとかを使う、という手もあるが、ここは大事をとって新サーバ側にsamba（windowsからのアクセスが可能になる、ファイルサーバのサービス）を立てて、ネットワーク経由で受け入れられるように準備をする。

7/6　救出

データ（の入ったハードディスク、およびマシン）が「着払い」で届いた。カードで一発で決済しようとしたら限度額に達して落ちない、という貴重な経験をする。補償金額の関係で小口に分けられていた荷物を、複数の支払いで個々になんとか決済して受け取って、解析を始める。

社内のwindowsマシンに、戻ってきたハードディスク（もちろん、障害が起きたディスクそのものではなく、まったく別の、新品ディスクである）をUSB接続し、ネットワークに繋いでコピーする。データベースやwebのHTMLファイルなどをテキストエディタでみる限り、ほとんどの部分が戻ってきている、と判断できそうだ。

データは戻ってきた。

ここ数日で一番、明るい顔をしていたと思う。

新サーバの設定を終え、暫定メーリングリストから新サーバでのメーリングリストに切り替える。

組合員に報告を入れた後、夜に復帰した会員メーリングリストを使って、データ復旧の第一報を流す。

その後、高島氏から連絡が入り、7/9にもう一度、組合会議をしよう、ということになった。

週末は、新サーバの復旧を進めつつ、転送の復旧も同時に進めるハードな進行になったが、TODOリストを作る必要すらない集中ぶりで作業を進めることができた。

7/9　告知

なんとか、約束の期日に間に合わせた。登録・転送については受付が可能になった。また、Linux側のデータベースの立ち上がりとともに、連動している会員版元サイトも表示がなされるようになった。暫定的に表示を止めていた部分を元に戻し、告知をかける。

組合会議は、一週間前とは打って変わった状況の変化の報告が主だった。とにかく、どこまでが復旧できそうか、その見積もりを取り決める。データ自体は戻ってきたものの、欠損部分はやはりかなりあるので、完全な復旧には一ヶ月くらいはかかりそう、と回答する。そのほか、LLPとしての対応などを検討する。

また、この日、障害発生後初めての、書籍の注文が来た。正式にはまだオープンしていないので、検索エンジン経由か、版元が自社サイトに貼ったリンクか、メルマガのバックナンバー経由か。いずれにしろ、「動き出した」ことをダイレクトに感じる。

7/13　復旧

復旧したデータからも救出できなかった、新システムの検索機能を書き直した。これにより、サイト全体が最低限、一通り動くようになったので、トップページを書き戻し、サイト復旧を宣言する。丸二週間以上、止めてしまったことになる。

8/8　記録

事務局長として、また今回のトラブルの当事者として、できるだけ客観的に「日誌」として記録をまとめてみた。
今回のことで、版元ドットコムに大きな障害を発生させてしまった。対処は充分だっただろうか。版元ドットコムへの信頼を傷つけてしまった事、会員社・組合員・クライアント・周囲にかけた迷惑、自社の業務を代表自身が滞らせてしまった責任をうまくとれるだろうか。トラブル復旧という得難い経験を通して、自分は成長し、「今後」に教訓を活かせるだろうか。自身に、厳しく問い続けるしかない。