こんにちは。私の収集したインフラ設計の知識を少しでも役に立てればと思い記事にしています。今回はバックアップ設計を取り上げます。裏方処理で忘れがちですすが、バックアップ設計はシステムの安全運航にはとても重要です。
バックアップ設計って何？
まずバックアップ設計とは何か？というところに触れたいと思っています。ここで言うバックアップ設計は、データのバックアップ処理のことを指します。対象データ、手段は問いません。何かトラブルがあった時に備えてデータを本体とは別のところに退避しておくことバックアップ設計と指しています。
大きくバックアップを取得する目的は２つです。
- HDD障害や天災などにより物理的にデータが消失することを防ぐ
- ユーザやSEの作業の語作業によるデータ消失を防ぐこと
バックアップは必要か？
最近はハードウェアも丈夫でDISK障害が発生するケースも少なくなってきます。さらにRAID構成をとることもあたりまえの世のa中です。またクラウドした場合のSLAで定められている故障率は非常に低いです。 そうするとバックアップって必要なの？どうせ壊れないでしょ？と思う人もいるかもしれません。
ここで声を大にして言いたい。それでもバックアップは必要です。
限りなく100%に近い信頼性のHDDでも同時に壊れる可能性はゼロではありません。一度ロストしたデータの復旧は、ユーザ・SE含め復旧は非常に大変です。一からデータの再入力が必要になります。それが1件や2件すまず何万何十万件となってきたらどうでしょうか？とても耐えれません。
これは2019年度末頃に発生した役所のクラウドシステムのデータロスト事件をみてもわかります。
さらにバックアップを取得しないと作業ミスによる論理的なデータ消失からは復旧できません。
そのため、繰り返しになりますが、だからバックアップ設計は必要です。
バックアップ設計ポイント
バックアップ設計で決める必要のあるポイントは以下３つです。
- バックアップ目的の決定 (なぜ）
- バックアップ方法の決定（どこに、どのように）
- バックアップ頻度の決定（いつ）
どの設計もそうですが、目的を決めた後に手段に話を進めてゆくことが重要です。
バックアップの目的を考える
どんな設計でもそうですが、まずなぜこの処理が必要なのか考えましょう。バックアップ設計では、どういう事象からデータを保護したいのかです。各組織においてどこまでのデータ破損から復旧させたのか検討しましょう。
データ破損のバリエーション
物理破損
物理破損は大きくは２つに分かれます。
HDD/SDDの破損
要するにデータを保存しているディスクが壊れたケースです。とても想像しやすいケースだと思います。RAIDでも壊れる時は壊れます。これを救うためにはほかのHDD/SSDにデータを保存しておく必要があります。
データセンタの破損
これは災害等によりシステムを構築しているセンタが倒壊した状態を想定することになります。 ディザスタリカバリー(Disaster Recovery)ということもあります。これは、自然災害等の影響によりダウンしたシステムを復旧させるための準備のことを言います。ビジネス目線では業務継続策(BCP)と呼ばれることもあります。
これを救うためには、データを別のセンターデータで保管する必要があります。
論理破損
論理破損は、ユーザなりSEがデータを間違って削除してしまった。誤って更新してしまったことを指しています。人的ミスが多いかと思います。もしかいたらアプリケーションの誤作動もあるかもしれません。
これは同一のHDD内でもよいのでデータをコピーすればよいです。
どうやってスコープを決めるのか？
続いてスコープの決め方です。一番被害の大きいデータセンタ側の破損に備えた別データセンターへのバックアップを行えば全て防げると言えば防げます。しかし、別データセンターのバックアップは一番お金がかかる可能性が高いです。また復旧時間がかかるかもしれません。
そのため、そのシステムのビジネス上の優先度を考えてバックアップの目的を考える必要があります。私としては、論理破損とHDD/SSDの破損に備えたバックアップは必須だと考えています。
この二つであれば同じ手段で余計なコストも抑えられながら最低限のバックアップできるケースが多いかと思います。
ただし、ユーザやプロジェクトの上位層とこのシステムは、どういったトラブルまで想定してバックアップを取得するのかを合意することが必要です。
後からなんでしてないの？やりすぎじゃない？と言われる可能性がないようにしましょう。
そのほかに決めること
そのほかにもバックアップの目的と一緒に以下は決める・確認が必要になります。しっかりとして要件確認の対象です。
- バックアップ先としてクラウドなどの外部の拠点は採用できるか？(社内ルール）
- 復旧処理時間: RTO (Recovery Time Objective)
- どの時点のデータまで復旧させるのか: RPO (Recovery Point Objective)
- どのレベル（範囲）まで: RLO (Recovery Level Objective)
復旧時間を短くしたり、データを１分前まで復旧させたいなどしたらバックアップ処理はかなりレベルの高いものとなり、コストなども増えます。
また復旧対象データ範囲もどこまで復旧させるのか？で、バックアップ処理の規模も変わるのでかならず確認しましょう。
次回予告
後編では、バックアップの目的を決めたあとに考える必要のあるバックアップ方式をご紹介します。
