バックアップってさ。

  • 投稿日
  • 更新日
  • 著者 麗（urara）
  • カテゴリー 考察

こんちゃ、麗です。
最近ちょっとバタバタしてたので記事を書けてませんでした。
今回は先月（2012年6月）に起こった例のサーバー事故の教訓を交えて、「じゃ～どうすべな…」ってとこをツラツラと。

ちなみにこのタイミングで出したのは、ある程度報道やタイムラインが冷えてからにしたかったからです。
変な煽りとか一時の感情に流されたくなかったのもあります。

ファイル消失という事故を振り返る。

まず、ファーストサーバの障害で涙を飲んだ方、復旧に当たった方、本当にご苦労様でした。
各サイトが何らかの形で対応策をとり、現時点で何も復旧されてないサイトがあるなんていうことは信じたくもありません。
それが「元通り」という体なのか「新サイト」という体なのかはわかりませんけどね。

一連の流れに関してはすしぱくさんが意欲的にエントリーしてくださっています。
ご存知ない方は、一度ご覧になってください。
僕も機会あってインタビューに出ています。

タイムラインから目に飛び込んできた。

僕がWEBクラスタの方を多くフォローしてるのもありますが、クライアントやサーバー会社からのメールより先にタイムラインで知りました。普段扱うケースの少ないサーバーだったのでアンテナが鈍ってた感があり、そこは反省点でもあります。
不具合の発生というところから考えると、既に半日以上過ぎてたわけですしね。
初期化の威力は僕をたじろがせるのに十分でした。

なにもない。

不具合の発生に対し最終的に取られた対応、『初期化』。
使用していたサーバーは発見時点でサポートサイトに「納品完了しました」と記載されていましたので、管理ページにログイン。
この納品完了っていう記載もどうなの？と内心思っていてもそんなこと気にしてる場合ではありませんでしたし、現状把握の方が先です。
すると、さすがに初期化というだけあって、まっさら。
ファーストサーバにがコンフィグレータといういわゆるサーバー管理機能があって、大概の設定はそこからします。メール(POP)とかFTPアカウントの設定とかもコンフィグレータでの設定です。
そこがまっさらになったことで、メールも使えません。
電話でオーナーに連絡を取る傍、ファーストサーバのサポートページや公式アナウンスに目を通して(目を背けたくなるような)現状を頭にいれます。
障害発生からの時間と対応状況から取る行動をきめていきました。

何よりもまずメールを。

待てばボックスが復旧されるかも…とも思ったのですが、いつになるかわからない上にメールが動かないことの不便さやオーナーの事業への支障を考え、了承を取る前に以前と同じアカウント名/パスワードでアカウントを作りました。はっきり言って、僕の持つ権限を超えてます。判断を仰ぐのが正しかったのかもしれませんが、それで問題が出たら僕がゴメンナサイすればいいだけの話で、現状よりはマシって判断をしたんです。
結果、問題にはなりませんでした。運良く、ね。

サーバー会社の復旧を待っていられない。

アナウンスによれば、現在復旧中とのことだったのですが、正直待ってられませんでした。
静的ページは即時上書きで対応しました。
MovableTypeOpenSourceにしても、出力のバックアップから暫定復旧をしました。
MTOS自体の復旧は「今回のことを受けてサーバーを移転する」という話になったときのことを考えて据え置きに。
更新頻度がそこまで高いサイトではない（むしろ低いと言っていい）ので、そこは今後を考えて動いた方が無駄な工数は発生しないと踏みました。
それに、緊急対応ですから、まごついてる時間はないのです。

そして…

クライアントとのやりとりの時間もありましたし、暫定復旧がすぐに済んでたこともあって、「徹夜してでもなんとかしろ」という雰囲気ではありませんでした。
むしろその無茶を言わせないためにも暫定復旧って大事なんだと思います。
自分の睡眠時間や体力を奪う原因に直結してるわけですから。
そんな流れの中、浮上した全ての作業を完了させるまでには「暫定対応から+2営業日」で終わっています。
遅い、という意見もあるかもしれませんがそこはクライアントの更新頻度を見据えて問題ない範囲で終わらせているので大丈夫でしょう。
これが更新頻度が高いサイトやECサイトなら完璧アウトですけど。
その後、お打ち合わせもしてクライアントの意思疎通を再度はかったりして、無事”解決”です。

以上が発生当時の流れです。

そのバックアップは果たして本当に有用か。

今回の問題の詳しい経緯はファーストサーバ社のサイトを見ていただくことにするとして、じゃあユーザーはどうバックアップをするのかっていうお話。

それはそもそもバックアップなのか

すしぱくさんのインタビューに（後日加筆修正をしていただきましたが）「バックアップは取ってあたりまえということはない」としたことで多分反感は買うだろうなと思ってましたが、それが純粋に僕の思うところでもあるんですよね。
実際お答えするにあたって原稿を起こしましたけど、そのときは「サーバー会社が『バックアップを取っておいてね』というのは信頼度100％を謳ってりゃちょいと無理があるんじゃないのかしら」的な感じだったんですが、よくよく考えたら、「あぁ、サーバー会社側だけじゃないわ…。とってあって当たり前的に言う人も確かにいるし、技術者やプロとしてそれは当然なんだけど、広い意味でユーザーを考えたら決してそんなことないわ 」ってなったんですね。
「業界の常識≠世間の常識」ですから。
また、tumblrにもささっと書いたのですが、

そのバックアップデータで正常にレストアできることを試してる人は意外に少ない。
そして、バックアップをサーバーから取らずに、手元の制作データをバックアップと呼ぶ人がいる。バックアップは当たり前だと思えないんだよね。 – Urara’s Sonor

それが事実だと思うのですよ。
何かしらのデータがあることの安心感もわかりますし、それを得たことでチェックしなくなることも容易に想像できるわけですが。
詳細は記しませんが、実際に『phpMyAdminでMySQLのバックアップを取ったものの、それがレストアできない』という事態に遭遇したこともあります。
僕が入社したての新米で「CMSﾅﾆｿﾚ？」ってときでしたけど、その仕事に従事している者としては立派なミスです。
また、『定期バックアップの取得期間が短すぎて壊れたものをバックアップしてる』ということもありましたし、世代管理を怠ってデータの先祖返りを起こしただとか、復旧にまつわる不備はよく聞く話です。
バックアップっていう作業はバックアップデータを取得することだけを指すわけじゃないですよね。

そもそも制作データはバックアップではありません。
バックアップの代用品になる可能性はあるかもしれませんが、バックアップではありません。

だってバックアップしようと思ってないでしょ、それ。

自分以外が絶対に触れないってならわかりますけど、バックアップが作業だと思ってないのはどうなのかなって個人的には思いますね。
作業だと思ってないってことは誰かに頼まれても費用が発生しないってことですしね。

じゃあバックアップってどんなのを言うのよ

僕のバックアップとしての最低条件は

  1. 復旧できる
    あたりまえですけどレストアできないと意味がありません。これはデータの形式だったりエンコード方法だったり「データそのものに問題がある場合」と単に「スタッフの技術力が足りない場合」があります。 人間やらなきゃ忘れていくのは仕方のないことですし、定期的に復旧テストみたいな訓練はしておいた方がいいと思います。
    何かあったときのレストア先が、同じ設定を施された同じサーバーじゃない可能性だってあるんですよ？
    システム屋さんとかサーバー屋さんとかは多分ちゃんとマニュアル化されてるだろうしリテラシー高い人も多そうなイメージ（というか万が一が起こったときのリスクが普通に想像できるだけかもしれないけどね）なので自己訓練してる人も結構いらっしゃるんじゃないでしょうか。
  2. すぐに引き出せる
    要は整理するってことですね。何がどこにあるかわからなくて設定情報探してたら時間がどんどんなくなっていって、慌てて復旧しようとしたら必要なものまで消しちゃったりして…という事態を招かないとも限りません。
    緊急時に余裕を持たしてくれるのは日ごろの準備ということです。
  3. 孤立している
    他のファイル操作やテキストの検索/置換 などの影響を受けないようにしてあるということ。つまりは制作データから切り離されていること。
  4. 常に最新ではない
    バックアップは一定の時期に行われればそれでいいでしょう。リアルタイムで書き換わっていくのはバックアップというよりクローンだし、ある程度は世代管理も必要と考えています。また、安定していることが何よりだと思います。ファーストサーバでは脆弱性云々が挙がってましたが公開領域にそれがなければいいと思うんですよね。
  5. 公開ディレクトリはサーバーと同じもの。
    余計なファイルはいりません。邪魔なだけです。

加えて、「データがデジタルかアナログかは問わない。」というのもあります。
これはどっちかがいいではなくてどちらかはなくてはならないもの。

例えば今回の件ではメールが飛びました。
メールのアカウント一覧、手元にあったでしょうか？
パスワードは暫定的に振ってしまって対処するなり何なりできることなのでいいかもしれませんが、アカウント名はそういうわけにもいきません。名刺にのったりしてますしね。
あとでじっくり教えてもらえばいいじゃない？・・・だとしたらそれは暫定対処には含まれません。その間クライアントはメールが使えません。
僕は幸い以前作業したときにコンフィグレータの画面を印刷してあったので最低限アカウント名はわかりましたので事なきを得ましたけど、これもバックアップの一つだと思うのです。

そんなのうちの業務サポート対象外だ。

そう思うならやらなくていいですけど、僕はそうは思っていません。
あくまで緊急時において、ですが。
わからない部分をわかったふりする必要はありませんし、専門外なので専門家にお任せしますと言った方がいいことも多々あります。
実際今回だってメールに関してはウチは本来噛んでいません。
maka-veli.comのまさとさんの記事にもありますが、要望的にややこしいことになりかねません。

  • コーポレートサイトの構築/運営で最低限気をつけておきたい10のこと。 via maka-veli.com

ただ、クライアントがこういったことにあまり詳しくない方の場合、緊急性が高ければ高いほど「力になってくれそうな人」に連絡がいきます。
プロかどうかは余り関係ありません。だって、WEBに携わってる人でお客さんのPCサポーターみたいになってる方、結構いらっしゃるでしょ？
で、こういうちょっとしたことで印象が大きく変わったりするわけじゃないですか。
だって相手は緊急なんだもの。
設定の一覧を出力しておくだとかのちょっとしたことかもしれませんけど、それが役立つときがくるとしたら、それは結構重要な時だったりするんですよね。

それに、別にタダでやれと言ってるわけではないです。
そこは対価をいただけばいいのですから、普通に交渉しましょう。

世の中に完璧なものなんてないし、皆そこに近づけるように切磋琢磨してるわけですよね。
データはDVD-Rとかのメディアに焼いておけば大丈夫だ！とかHDDにいれてHDDごと保管しておけば大丈夫だ！っていう人もいますがそれだって経年劣化しますし、耐火金庫だって何でもいれられるわけじゃないでしょう。
まさとさん（また登場です。いやいつも有用な記事ありがとうございます）の仰るようにサーバーは安い物ではそもそもないですし、データもどんどん膨れ上がっていきます。

  • Webサイトは財産です。財産の置き場が貧弱で良いんですか？ via maka-veli.com

自分の打てる最大限、それでいいんだと思うんですよね。 ぶっちゃけそれ以上はできないし、逆にクライアントだからできることもあるだろうし。

今回の流れの（個人的な）結果

TLではクラウド万歳な流れが一気に静まり返った的なのをチラホラ見かけましたが、CMS云々もそうです。
すしぱくさんもWPよりMTの方がいいんですか的な質問を受けたと言っていました。
CMSを使わずに静的なサイトであれば復旧も楽だし～っていう流れにもなりかけました。
が、それは本末転倒で結局のところCMSの利便は捨てがたいものがありますし、CMSはどれが優れているとかではなくてどれを使うにせよそのバックアップ方法と再構築方法は知っておき、また試しておくべきところなのですよ。

サポート方法を考える

扱う物についてより理解を深めるのは、それを「おもしろいな！」って捕らえて楽しくできる人はストレスもないでしょう。
何に興味をもつかなんてそれぞれだから、そこに苦痛を感じる人もいるでしょう。
でも、仕事としてそれを扱う者の「やって当然なこと」だと僕は思います。

重ねて言いますが、もちろん無償でやることではないです。そのカードを手札として持っておきたいがためにこっそりバックアップを取っておくとかいう場合を除いて。
中には保守やコンサルがタダだと思ってる方も現実いるのは確かですが、慈善事業でやってるわけではないですし、「月々いくらかかりますよ」とちゃんと言っておかないと苦しむことになります。
それを自分が知ってるだけではなくてクライアントにも理解いただいて、出来ることは出来る、出来ないことは出来ないとした上で、では要望を満たすにはどうすればいいか、を考えるのは折衝の醍醐味でもありますしね。
無理はどちらにも得の無いものだと思うのです。

この記事を書いた人

麗（urara）

記事一覧