社内のファイルサーバーの全てのデータを消し飛ばしてしまうという、人生史上最大のミスを犯してしまいました。二度とこのような失敗をすることがないよう強く反省し、記録を書き残すことにします。
- きっかけ
- 環境
- やっちゃったこと
- どのように乗り切ったのか
- そのとき何を考えていたか
- 惨劇はなぜおこってしまったのか
- 二度と惨劇を起こさないためにどうしたらよいか
- やっててよかったこと
- 補足
- 終わりに
きっかけ
まず、なぜこのような物をここに書いているのかと言えば、社内にはここまで精密な記録を残す予定が無いからである。
社内には、私の書いた技術的な記録を読める人は居らず、今度も採用されることはないだろう。
そして業務時間中に、このような丁寧な記録を残している時間など存在しない。
IT素人でも分かるような報告書をサラっと書いて、これでもかと言うくらいデフォルメした説明をして終わりである。
まあ実害がなければだが…
幸か不幸か、一度は間違いなくデータは消えたが、業務へのダメージは皆無だったので記録は残せさずに済んだ。残すことができなかった。
それはなぜなのか、初めから順を追って説明しよう。
せっかくなので、年末に話題になった Qiita - 本番環境でやらかしちゃった人のフォーマットを参考に書いてみた。
環境
(何故かここからデスマス調になってます)
職場ではとある簡易NASキットを使って、ファイルサーバーを運用しています。
通常時の構成は下図のようになっており、限られた予算の中でド素人が構築した割には、それなりに堅牢で安定した運用ができているつもりです。
早速、話がそれるが、教科書やISMSでは「差分バックアップをとれ」と書いてあるが、私は毎回フルバックアップ取れば良いと思っています。更新されたファイルだけを上書きコピーするなら時間かからないし、リストアする時もまるごとコピーするだけで済む。これほど楽な運用は無いと思うのです。(※一応素人意見です。)(ジョブ毎にフォルダ/ブロックを変える必要はないのでは無いかという意味)
さて、今どきのサーバー管理で最高に便利なのがスナップショットです。スナップショットは一定のデータボリュームを犠牲にして上書きされたり削除されたりして消えたデータを保持しておくことができます。(それっぽいイメージなので厳密には違う気がする)
私がサーバー管理で最重要視しているのは、壊れたら手軽に復旧できて、現場の作業を止めないことです。
だから、すぐに交代できるサーバー(ミラーサーバー)と、ユーザーが誤操作で消した過去のデータ復元手段(=スナップショット)を用意できれば、差分バックアップなんぞいらないのです。
これまでの経験から、ミラーサーバー+スナップショットの組み合わせが最強ということに気が付き、最近はこの構成で運用中です。
※一方通行の同期のことを、勝手にミラーバックアップと読んでいますが、これが業界に通用する言葉かは知りません。完全オリジナル運用ですので。
※ミラーバックアップと、単なるバックアップとの最大の違いは「コピー元で削除されたファイルをコピー先のHDDからも削除する」という点です。バックアップ後のサーバーのデータは元のサーバーと全く同じ状態になります。
なお、最近は世間がBCP対策しろとうるさいので、クラウドにも取るようにしました。(復旧にはクソ時間かかるけどね)
やっちゃったこと
と、偉そうに設計しておいて、やっていることは幼稚です。
やってしまったこと。
それはミラーバックアップの逆流です。
要はスケジューリングの設定で大ポカをやらかしました。
実は当時、サーバーの構成変更のため一旦データを全て消去して、ゼロから同期を取り直そうとしている最中でした。
この同期によるデータの流れる方向が、意図していた方向の逆になっていたのです。
自分で立てた計画ですから、今現在バックアップ態勢が脆弱になっていることは強く認識しており、かなり慎重に設定したつもりでした。
つまり、この図のような状態になっていました。そして、結果を見届けることなく帰宅します。
翌朝、出勤したらびっくり、サーバー上のファイルが跡形もなく消え去っています。
総従業員:数百名、大混乱です。
大混乱が起こるはずでした。
データ20TB以上使っていたはずのストレージは、今や使用済み容量0MB。
綺麗サッパリ、すっからかんです。
|←樹海| 人生オワタ┗(^o^ )┓三
どのように乗り切ったのか
幸いにして、稼働している人が少ないうちに復旧したので、問題とはなりませんでした。
なんと、20TB(数百万ファイル)もの膨大なデータを、10分程度で復旧させることができました。
復旧方法は、詳しい人なら上の図で一発でわかっちゃいますかね。
答えはスナップショットからの巻き戻しです。
本来は、ユーザーの誤操作から身を守るために設定していた機能によって、全データを復旧することができたのです。
今までスナップショットからの復元は、特定のファイル/フォルダの復元にしか使っていませんでしたが、ボリュームまるごと復元できることに気が付きまして、勇気を出してポチッとしたら復活したという幸運に恵まれた形になります。
そのとき何を考えていたか
障害が判明した時、そりゃもう焦りました。
心臓が縮み上がって、バクバク言ってました。
朝礼の間は、顔面蒼白でした。(想像)
「体調悪いでーす」とか言って、フェードアウトしたいな・・・とか
あーこれでもう、心置きなく会社をやめられるな・・・とか
考える間もなく
Twitterにつぶやきました。
上の図を描きました
つぶやいたのはその後です。←ぉぃ
図を書いて気持ちが落ち着いてきたところで、復元可能な選択肢は2つ
どっちの方法を取るにしても、皆に謝罪せずにはいられない重大案件になってしまいます。
でも、図ながらスナップショットが活用できないかなと、考えました。まあ普通は思いますよね。
最初の選択肢から外していたのには理由があって、某NASのスナップショットには「保護されたスナップショット」という領域があって、この枠に収まる容量までのデータが残ってるんです。(はずだったんです)
そして、保護されたスナップショットは5TBしか確保しておらず、「消えたデータは20TB。全然足りない。だから残ってるわけがない。」と思っていました。
それでも諦められずに「一応」と、確認してみたら使用済みスナップショット領域が1.5TBだったんです。
なぜか5TBも使い切られていない・・。
さらに、ストレージプールの容量も全く消費されていない。
だから私は思いました。これはわけがわからないぞと。
で、スナップショットの中身を見たら、全部のフォルダがあるじゃないですか。
これで空っぽのフォルダだったら笑い者ですが
藁にもすがるような思いで、見えた希望を掴むべく、復元手順を考えました。
それでUIを眺めていたら、ファイル・フォルダではなく、ボリュームまるごとの復元ができることに気がついたので、もう一台のNASで検証用のボリュームとスナップショットを作って、思ったとおりに復元できることを確認。
早速、本番環境にて実行。
そして10分後には復旧を確認
という流れでした。
多少は社内がザワつきましたが、すぐに復旧して沈静化。
私は落ち着いて設定をイチから見直すことになりました。
めでたし、めでたし。
で、終わっちゃダメですからね
惨劇はなぜおこってしまったのか
そもそもの問題は、このような事業に甚大な影響を与える業務を、私が単独・独断で行わせている組織運営に問題があるのですが、私としての反省点はいくらでもあります。
- 私がポンコツ
- ダブルチェックが甘すぎる
- 綿密なチェックリスト(計画)が作られていない
- 他事(ヘルプデスク等)と並行して設定を実施している
- 作業ログ(画面録画データ)を再確認していなかった
- 設定して初回の動作の監視を怠った
- 私がポンコツ
二度と惨劇を起こさないためにどうしたらよいか
- 私を修理に出す
- 計画を文章化し、理解されなくても良い。とにかく誰かに説明する
- サーバー設定中は着拒する。居留守を徹底する
- 作業ログ(画面録画データ)は、当日のうちに文章化する
- 「はじめてのおつかい」は、影から最後まで見守る
やっててよかったこと
- バックアップとは別でスナップショットを撮っていた
- データボリュームとシステムボリュームを分離しており、データ部分の復旧だけで済むようにしてあった
- 皆に移行期間は突発的に短時間の停止が起こることを説明済みであった
- チャットコミュニケーションツールが、連絡手段として定着済みであった
補足
- 文中、書く場所がなかったので最後に補足すると、10分というのはデータ復元に要した時間で、問題が発覚してから調査して復旧するまでは30分くらいかかりました。設定の見直しや記録の作成で半日かかりましたけど・・・ね。
- 表示上データは存在しないはずなのに、20TBのデータが復元できた理由は不明です。NASの仕様なのかバグなのか、「データは残ってるけど、管理上は空き領域扱いになっていて、空きが足りなければいつ消えてもおかしくない状態」になっていたのではないかと予想しています。
終わりに
ソロでやっている以上、完全にミスを無くすことは難しいでしょう。
でも、出来ることはあるはずです。
そういうところにこそ、頭を使いたいものです。
一人情シスの会社はあるかと思いますが、一人っていうのはこういうリスクが有るんだよというのを、上には理解していただきたいものですね。
以上
何か御座いましたらコメント欄、またはTwitterからどうぞ♪
それではまた来週♪ ちゅんちゅん(・8・)