【失敗事例】本当にあったSEの失敗談 バックアップからディスクを上書きデータ消失の巻

IT関連雑談
スポンサーリンク

以前にも失敗談を紹介しましたが、今回も過去に経験したトラブルを赤裸々に紹介していきます。

人は必ずミスをするし、間違えるし、完璧ではいられません。
ただ、ITの仕事において、些細なミスが大きな障害やトラブルに繋がります。

SEの能力では、プログラミングの技術や、ネットワークやサーバー構築に関する技術だけが取りざたされますが、それらと同様、又はそれ以上に重要な能力としては、様々なパターンのシステム障害やトラブルを経験し、それを失敗事例として学び、同様の失敗を起こさない能力です。

この様な経験を積み重ねることで、様々な失敗を予め想定することができるようになり、未然にトラブルを防いだり、トラブルが発生した場合にも的確に行動できるようになります。
ただ、この失敗経験を積むのは容易ではありません。

現在のドイツが生まれる前の国で首相を務めた「オットー・フォン・ビスマルク」という人物がある有名な言葉を残しています。

愚者は経験に学び、賢者は歴史に学ぶ
オットー・フォン・ビスマルク – Wikipedia –

自らの失敗で学んだことは掛け替えのない経験です。
また、失敗を恐れていては何もできません。
ただ、先人には同じような失敗を既に起こしており、そういった知識を歴史から学ぶことができます。
賢い人は、歴史として他人の失敗を学んでおくことで、自身は同じ失敗を起こさない。

私はこの様な意味で解釈しています。

よって、今回の記事では、私がSEの仕事のなかで経験した失敗事例を紹介します。
賢者である皆さまは私の歴史から学び、自身の経験値として吸収してもらえれば幸いです。

ディスクバックアップからリストアしたら大事なデータを上書きしたお話

今回紹介する事例は、ディスク全体のバックアップからリストアを行った際に、上書きしてはいけないファイルまで上書きしてしまい、大事なデータが消失したお話です。

当時の私は、非IT事業会社の情報システム部署に転職し半年程度経過した頃でした。
その為、まだ部署内での業務は、比較的責任の小さい業務や雑用的な業務も多く、実際に発生したトラブルについては、私はただの傍観者でした。
同じ部署の上司Aと同僚Bが今回の話の主役です。

あるシステム障害からデータ消失までの流れ

事の始まりは、とあるシステム障害から始まりました。
そのシステム障害から、最終的にデータ消失してしまうまでの流れを当項で紹介していきます。

OracleDBサーバーで障害発生

当時の会社では、社内システムのメインデータベースとして、Oracleを使用しておりました。
そのOracleは基幹システムや、その他の幾つかの業務システムで使用しており、とても重要なデータベースでした。

そのOracleのデータベースサーバーですが、何故か時々調子が悪くなることがあり、その状況が発生すると、各テーブルが開けなくなり、基幹システムや各業務システムが一斉に使用できなくなります。
その原因について調査しましたが、いつも原因は特定できず、最終的にOracleのサービスや、又はサーバー自体を再起動することで復旧させていました。

ある日、業務システムが使えなくなったと社内から連絡が入り、調べると、またいつものようにOracleの動作がおかしいのが確認できました。

Oracleが復旧しない

その日はOracleのサービスを再起動しても、サーバー自体を再起動しても改善しなかったようで、上司Aと同僚Bが検討した結果、以下の様に対応することになったようです。

  • DBサーバーはバックアップソフトで30分毎にディスク全体のバックアップを取っている。
  • 本番用DBサーバー環境とは別に、検証用兼待機系DBサーバーがあり、そこにもOracleが構築されている。
  • 本番用DBサーバーと検証用兼待機系DBサーバーはともに、CドライブもOracle本体がいて、Dドライブにデータ。
  • 検証用兼待機系DBサーバーのDドライブのディスクを、バックアップデータで丸っと復元することで障害前に戻る。
  • 当作業は過去に試しているので、検証はできている。

サーバーのバックアップやリストアの流れをイメージした図が以下になります。

バックアップとリストアのイメージ図

本番DBサーバーのOracleが復旧しない以上、他に手立てはないため、検証用兼待機系DBサーバーへのリストア案を実施することになりました。

バックアップデータをリストアしたら想定外の事態が

システムをいつまでも止めるわけにはいかない為、前項で解説した復旧作業を同僚Bが実施しました。

バックアップソフト自体は非常に優秀で、1時間程度の時間は掛かりましたが、検証用兼待機系DBサーバーのDドライブに対して、本番DBサーバーのDドライブを丸っと復元することができて、Oracle自体も正常に動作することが確認できました。

Oracleが復旧すれば、また社内の各システムが使用できることになる為、社内の各部署にシステム障害から復旧した旨の連絡を入れて、システムの利用が再開されました。

その後、また社内のユーザーから問い合わせがありました。

〇〇システムで画像が表示されない

社内で使用している業務システムのなかには、ユーザーが紙の書類をスキャナーで電子化し、その画像ファイルをシステムにアップロードしてシステム内で管理するといった仕様のシステムがありました。

そのシステムで画像が表示されないといった問い合わせでした。

その第一報の時点では、これが大きな問題になるとは誰も考えていませんでした・・・。

上書きしてはいけないデータをリストア時に上書きした

なぜ、リストア作業後に、〇〇システムで画像が表示されなくなったのかを、上司Aと同僚Bは調べました。

その調査した結果、驚愕の事態が判明しました。

  • 〇〇システムでは、特定の共有フォルダ上に置かれている画像ファイルを参照している。
  • その共有フォルダには画像ファイルを大量に保管することから、十分なサイズが確保されたディスクに配置する。
  • 現在の環境下だと、十分にサイズが確保されたディスクはDBサーバーにマウントしていたDドライブ。
  • 画像ファイルを置いていた共有フォルダは”検証用兼待機系DBサーバーのDドライブ“に作ってあった

よって、本番用DBサーバーのDドライブをまるっと取ったバックアップデータで検証用兼待機系DBサーバーのDドライブを上書きした結果、画像保管用の共有フォルダが消滅してしまいました・・・。

前項でバックアップとリストアのイメージ図を紹介しましたが、本当のイメージ図は以下になります。

バックアップとリストアの本当のイメージ図

誰もが、待機系サーバー側に共有フォルダが作成されており、そのなかに大事な画像ファイルが大量に保管されていたことを理解していなかったということです。

その後、更に追い打ちをかけるように、残酷な現実が判明します・・・。

画像ファイルフォルダのバックアップが存在しない

消えてはいけないデータが消えたのなら、通常はバックアップを取っているため、そこから復元ができるはずです。
今回もすぐにバックアップからデータの復元を試みる必要があります。

ただ、システム上重要なファイルである今回の画像ファイル群ですが、この共有フォルダのバックアップは一切存在しなかったのが判明しました。

完全に画像データが消えてしまったのです・・・。

トラブル発生後の対応

当項では、前項までで発生した最悪の事態に対して、どの様に対応したのかを紹介していきます。

社員全体で紙の書類の再スキャン実施

消えてしまったデータを復元するには、再度全ての紙の書類をスキャナーでスキャンして画像データを作成するしかありません。

データを消失してしまったのは情シスですが、再作成すべきデータ量は情シスだけで対応できるボリュームではありません。
また、紙の書類はすべて一か所にまとまっている訳ではなく、全国の拠点に点在していました。

その為、社内全体にアナウンスをしたうえで、他部署の業務も止めて協力してもらい、紙の書類を引っ張り出してスキャナーでスキャンし直す作業が全社で始まりました。

終わらない作業

午後にトラブルが発生し、データの消失が起こってから数時間経過し、本来の終業時刻になりましたが、消失したデータはあまりに多く、まだまだ作業が終わる気配はありません。

そもそも当時私は最初に記載したとおり、今回の障害に一切関与しておりません。
また、書類の再スキャン作業を手伝うといった指示もなく、自身の通常業務をやっており、それであれば私が居ても仕方ないので帰りたかったのですが、そんな空気では無いため、残業して会社に残ります。

定時から2時間が過ぎ、4時間が過ぎ、まだまだ帰れる雰囲気ではありません

社内では必死に書類を再スキャンする作業をしているなか、私はこの状況で特に今やる必要のないネットワーク構成図を作っていました。

そして、退社へ

今回の障害で画像データの全ては消えてしまいましたが、その原本である紙の書類は保管されています。

そのため、過去の古い画像データなどは必ずしも再スキャンしなくてよく、業務システム内の現時点で処理が必要なデータに関連した画像データだけを復元すれば、社内の業務は回るようになります。

その場合、当然古いデータに紐付いていた画像データは復元されないままなので、業務システム内では参照できず、もしその書類を確認する必要がある場合は、その書類が保管されている場所まで物理的に取りに行く必要があります。

業務システム内の古いデータに紐付く画像データが欠けた状態にはなりますが、それはもう仕方ないものとして諦めることになりました。

その様な判断もあって、結局我々情シスは、日付も変わった真夜中に無事退社できたのでした。

今回のケースにおける教訓

今回の失敗事例では、幾つかの教訓があり、それらを徹底していれば発生しなかったトラブルです。

システムを構成するファイルやデータを把握する

今回のトラブルの要因の一つとして、対象のシステムを構成しているファイルやデータの配置に関する理解が不完全だったところがあります。

システムを構成するファイルやデータとしては、アプリケーション本体であるプログラムファイル、使用しているデータベースに関するファイル、今回のように、システムがデータベースとは別で管理や使用しているその他の副次的なファイルなど。

そのすべてを正確に作業担当者やその上司が把握していれば、今回の事態は起こりませんでした。

中の人
中の人

もし、貴方の会社のシステムで、構成の認識に不安なものがあれば、早急に確認しておきましょう!

システムの構成要素すべてを漏れなくバックアップ

今回のトラブルでは、画像ファイルのバックアップが適切に取られていれば、社内全体で再スキャン作業という事態は発生しませんでした。

システムのバックアップと言われて真っ先に思い付くのは、データベースのバックアップですが、システムはそれだけでは動きません。

それ以外にも、アプリケーション本体のプログラムファイル群や、今回の画像データの様な副次的なファイル群など、そのすべてのデータやファイルのバックアップを漏れなく取る必要があります。

さらに言えば、バックアップを取っていたはずだが、いざ必要な事態になったら、実はバックアップが適切に取れていなかったといった事態もあり得ます。

中の人
中の人

バックアップ対象のデータに漏れがないか確認するとともに、バックアップが適切に取られているか確認する運用も必ず設けましょう!

作業内容を手順書などで明文化して共有する

今回発生したトラブルでは、実施した作業の手順書は存在せず、同僚Bが上司Aに作業内容を事前に口頭で説明して了承を取り、作業を実施しました。

システムが停止している緊急事態であり、ドキュメントを作成する時間が無かったのも仕方ないのですが、もし作業内容を手順書などで明文化し、それを元に今回実施する作業を上司に確認していれば、上司が画像ファイルを上書きする可能性に気付いたかも知れません。

また、同僚Bと上司Aだけで作業内容を共有するのではなく、情シス全体で作業内容を共有していたら、別のメンバーが画像ファイルに存在に気付いたかも知れません。

作業内容を手順書等で明文化して共有することは、単純に作業ミスをなくすといった目的だけではなく、作業内容に対して相互チェックが行われることになり、作業におけるトラブル時の責任の分散や移譲にも繋がり、作業者を助けることにもなります。

中の人
中の人

作業手順書を作成して作業内容を明文化して共有することは、作業者自身を守ることに繋がります。

作業の大小に関わらず、システムへの変更が発生する作業では必ず手順書を作成し上司の承認を取りましょう!

最後に

今回は、私が過去に経験した失敗事例を紹介しました。
後から冷静になって回想するからこうしておけばよかったと評価もできますが、システム障害が発生している状況では、なかなか冷静な判断をすることは難しいです。

その為、やはり、予め障害が未然に防げるような手立てをどれだけ打っておけるか、また、万が一障害が発生した場合の備えをどれだけ用意しておけるのかはとても重要です。

少なくも今回紹介したトラブルに遭遇してからは、システムのバックアップに関しては繊細な注意を払って設計しますし、上書きしてはいけないデータを上書きすることのないように、サーバー上のデータ構成やバックアップ対象の選定もそういった配慮をしたうえで決定していくようになりました。

皆さまにおかれましては、今回の恐ろしい失敗事例を教訓にしていただき、自身や自社で同様の障害を起こすことの無いように、十分に留意していただけると幸いです。

それでは今回も読んでいただきましてありがとうございました。
皆さまごきげんよう。

タイトルとURLをコピーしました