今回のエントリーは半分、自分の失敗談です。
うちの会社では、とある会員制サイトを運営しているのですが、そのサイトのファイルは自社のファイルサーバーに入っており、開発者のPCからはネットワークドライブとしてアクセスし、ファイルを更新するようになっています。サイトは本番環境の他にテスト環境として一般に後悔していないサイトも用意しており、まずはテスト用のファイルを変更してから本番用のほうにアップするという流れをとっています。なお、テスト環境のファイルは本番環境と同じサーバーに入っており、ディレクトリが違っているだけです。
そうして、11月13日木曜日の夜、営業から依頼を受けて更新を頼まれていることもあり、まずはテスト環境のほうを変更することにした。ただし、少し問題があり、数カ月前にテスト版のほうで更新したものの、今回の更新ではまだ更新してはいけない箇所があった。そのため、その更新してはいけないファイルのみを本番環境からテスト環境のほうにもってくることにした。そしてあろうことかそのファイルを本番環境からテスト環境にもってくるのに、ドラッグアンドドロップでもってきてしまいました。普段、ファイルサーバーからローカル環境にファイルをコピーするのにドラッグアンドドロップでもってくるようにしているので思わずそうしてしまいました。そうして、テスト環境が本番環境のファイルでもちゃんと動いていることを確認し、一旦そのファイルは削除して、もともとテスト環境で使っていたファイルに戻しました。
結果、どうなったか。本番環境からテスト環境に持ってきたファイルを消してしまい、さらにそのファイルはほぼ全てのページに共通のヘッダー部分についての記述について書いてあるファイルだったため、見れない状態となっていました。いつまでか。11月14日金曜日の12時までです。お客さんの電話で見れないことが発覚しました。
幸い自分のローカルPCにバックアップをとっていたのですぐに復旧することができ、被害もたいしたことなかったものの、1日ずれていれば大変なことになっていました。実は、このサイトは木曜日によく使われるサイトなのです。なので、木曜日にサイトが止まってしまうとかなり大変なことになり、被害も莫大です。さらにいうと、木曜日は自分は昼からの出勤だったため(ただし夜遅くまで働くことになる。だから、夜に作業していた)、復旧に時間がかかった可能性もあります(バックアップはあると思いますし、そんなことはないと信じたいのですが、そうやって注意されました)。よくよく考えたら、木曜日以外でも月曜日から水曜日はよく使われるので、ある意味で金曜日にトラブルが発生したのはラッキーでした(あくまで、他の曜日だった場合と比較しての話。トラブル自体はもちろんかなりアンラッキーです)。
正直、今考えただけでゾッとします。自分の性格なら、また似たような過ちを犯してしまうんじゃないかと不安です。
そこで、今回は今後もこんなことが起こらないよう、再発防止のために自分が使っている(もしくは、使い始めた)フリーソフトを紹介します。何をやっているかを簡単に説明すると、バックアップとフォルダ監視です。
バックアップ
まずは何よりもバックアップです。今回もバックアップをとっていたからすぐに復旧することができました。特に自分がオススメしたいのがBunBackup。このソフトを使えば全てのファイルではなく、更新があったファイルのみのバックアップをとることできます。さらに、特にすばらしいと思う機能が、世代管理機能があるということ。なんと、変更があったファイルについては、変更前のファイルを指定のフォルダフォーマットのフォルダに入れて保存されます。
ただし、初期状態では世代管理機能が設定できないようになっています。世代管理を有効にするには、ツールバーの[設定]から[機能表示設定]を選択し、開いた『機能表示設定』というダイアログの『世代管理』のチェックボックスをつけなければいけません。
その後、バックアップフォルダの設定にて世代管理を有効にする必要があります。
ここで例えば、”C:\test”以下のフォルダを”D:\backup\test”に世代管理機能を有効にしてバックアップを行う例を説明します。
例えば、下記のように”C:\test”に”test.txt”というファイルがあるとします。
続いて、このフォルダをBunBackupでバックアップするように設定するようにします。まず、BunBackupの画面内のツールバーの+ボタンか、適当な場所で右クリックしてでてきたメニューから『追加』を選びます。
そうして表示された『バックアップ設定』というダイアログの『タイトル』に適当な名前、『バックアップ元フォルダ』にバックアップ元のパス(今回の場合は”C:\test”)、『バックアップ先フォルダ』にバックアップ先のパス(今回の場合は”D:\backup\test”)を入力して、『OK』ボタンではなく、『詳細』ボタンを押します。ここで『OK』ボタンを押してしまった場合は、BunBackupの画面のリストに先ほど入力した内容が追加されるので、その箇所を右クリックしてメニューから『変更』を選び、でてきた『バックアップ設定』ダイアログの『詳細』ボタンを押します。
すると、『バックアップ詳細設定』というダイアログが開くので、そこの『世代管理』タブを選択します。なお、この最初に表示される『バックアップ方法』の画面でサブフォルダもバックアップするか、更新があったファイルとはどういうファイルなのかを指定できます。後、自分は使ってませんが、更新対象ファイルや除外ファイルもここで設定できます(参考:バックアップ容量を少なくする)。
世代管理設定の画面から『世代管理する』のチェックボックスにチェックをつけます。こうすることで、世代管理ができるようになります。必要であれば、フォルダフォーマットを変更しておきましょう。初期値では、『’世代’ yyyy-mm-dd』となっていると思いますが、今回は『’世代’ yyyy-mm-dd-hh-nn-ss』としておきます。
では、バックアップを実行します。リストから先ほど登録したバックアップタイトルを選択して、右から二番目のボタンを押すか、F11キーを押します(右から4番目の『バックアップ開始』ボタンを押すと、登録しているすべてのバックアップが実行されます)。
すると、バックアップ結果が表示され、”D:\backup\test”のフォルダにtest.txtがバックアップされました。
そうしてもう一度BunBackupにてバックアップボタンを押すと、”D:\backup\test”のフォルダに新しく『世代』とついたフォルダが追加され、test.txtは新しいファイルに更新されました。
中を見てみると、更新前(最初にバックアップを取った時)のtest.txtと『BunBackup世代管理フォルダ』というログファイルが入っているのが分かります。無事、世代管理できたようです。
さて、ここまで読んで、「何でバックアップを前から取っていたのに、バックアップ環境ではなく本番環境からファイルを持ってくるという危険な行為をしたんだ?」と疑問に思う人もいると思います。まさにそのとおりで、今後はそうしようと考えています。いや本当、なんでバックアップ環境からもってこなかったのかと・・・。あたしって、ほんとバカ(冗談を言っている場合ではありません)。
フォルダ監視
さて、バックアップをとっていたとしても、今回の自分の例のように、変更したことに気づかなければ意味がありません。そこで、今回導入したのがフォルダ監視ソフトです。
ネットワーク監視 フリーソフト [フォルダ監視]
上記のソフトでは最大255か所まで監視フォルダ(とそのサブフォルダ)を監視対象として登録することができ、登録したフォルダ以下のファイルにて、追加・変更・削除があった場合に通知する機能があります。これで、本番環境のフォルダを登録しておけば、間違えてファイルを消してしまっても通知してくれるのですぐに気づくことができ、今回のように次の日の昼まで気づかないという事態になりません。
ここで、先ほども利用した”C:\test”を登録した例を説明します。まず、上記ソフトを開くと左下に『追加』ボタンがあるのでそれをクリックします。
そうして開いたダイアログにて監視したいフォルダを選択し、『OK』ボタンを押します。もしくは、先ほどの画面で『直接入力して追加』ボタンを押して開いたダイアログのテキストボックスにファイルパスを記入してもOKです。
そうすると設定画面のリストに指定したフォルダが追加されるので、右上の監視する間隔を設定し、サブフォルダも監視したい場合はそこにチェックし、『監視開始』ボタンをクリックします。
では、試しに”C:\test”内に”hoge”というフォルダを作成し、そこにtest.txtを移動します(ファイルをドラッグしてたら間違えて下位フォルダのうえで離してマウスを離してしまったという設定)。
しばらくすると、フォルダ監視ソフトが下記のような通知をだしてきます。この通知を見ると、監視対象のフォルダからtest.txtがなくなり、その下のhogeフォルダにtest.txtが追加されているということが分かります。
こんな感じで、本番環境のフォルダを監視フォルダに設定することにしました。
本当ならチームでGitなどのソースコード管理ツールを使って徹底しておくのがいいんでしょうけどね。上司もソースコード管理ツールの重要性は分かっているようなのですが、なかなか利用にまでは至っていません。
でも本当、なんでこんな失敗をやってしまったのかと反省してもしきれません。こういう時は自分以上にひどい失敗した人の話を聞いて、「自分はまだマシだった」と安心したいものです(下衆の考えです)。
というわけで、今度、神戸ITフェスティバルにて、ファーストサーバ株式会社のデータ消失事故について話すようなので聴きに行こうと思います。
「データ消失事故を振り返って~あの時、社内で何が起こっていたか~」村竹 昌人(ファーストサーバ株式会社) | 講演・セミナー | 神戸ITフェスティバル2014
どういう再発防止策を行っているかとか参考になるかもしれませんしね。多分、下記連載と似たような話だとは思うのですが、実際に話を聴いたらまた違うと思うので(記事に書いてないことも話すかもしれませんしね。最後の質問タイムなどで)。
ASCII.jp:データ消失事故から2年!ファーストサーバ、再生への第一歩
コメント