バックアップについて考える

データについてはバックアップを確保するのが至極当然になっている。
大型汎用機で開発していた頃は、ハードディスク（富士通製品はDASDとか呼んでいたか）も高額なので、テープデバイスに記録する設計にしていた。まあ、データベースが主流ではなかった時代でもあるのだが。現在、データといえばデータベースが主流だろう。データベースならバックアップを確保する機能はDBMS側で装備されていることが多く、開発者が設計上盛り込む機会は少ないかもしれない。もちろん、運用設計を考えると必要なことではある。

さてさて。仕事で「客先のバックアップを取って欲しい」という依頼が来た。こういうざっくりした依頼が営業担当者から来るのなら分かるが、技術者から来るのが困ったところだ。詳細を確認してもゼロベースだ、一から考えて欲しいとのこと。


別に、バックアップをどのタイミングでどこに取るのかの案くらいなら特に準備は要らない。しかし、バックアップを取る、というのは目的ではなく手段である。手段をいくら決めても、目的に適合していなければ顧客の期待には答えていることにはならない。

よって、万一のとき、その万一の程度がどのくらいかによってどこまで対応したいのかを顧客から引き出しておく必要がある。そのためには事象を例示し、この場合はどのくらいまでに復旧する必要があるのかを顧客と合意しておく必要がある、ということに他ならないのだ。その合意があって初めて、どの程度のバックアップが必要なのか、顧客にあった提案ができる。
もちろん、万一のときの役割分担も決めておく必要がある。「これだけのバックアップ取っています」としか決めていなければ、顧客側は「万一のときには無償で復旧してくれる」と思うかもしれない。しかし、対応側としては「そんなもの別料金に決まっている」と言いたいだろう。そこはあらかじめ協議のうえ、確定する必要があるだろう。


万一のときの避難訓練は実施している職場は多いが、万一のときの復旧訓練をしているところは知る限り皆無である。避難訓練の一環として、情報系の復旧訓練というのもやっておいたほうがいいだろう。
情報システムの復旧も、慣れていればたいしたことはないが、パニック状態では問題が起きやすいからだ。

顧客のバックアップの目的が「なんとなくデータ保全」なのか「万一の時でも決められた時間内に復旧し、事業継続性を担保するためのもの」なのか、その話もできておらず「バックアップを取る」というのは、木を見て森を見ずって感じであろうか。
バックアップ＝DBMSで設定して終わり、という考えしか持っていない技術者は結構多いかも知れないが、それだけでは顧客のニーズに合致していない可能性もかなり高い、といえる。