データバックアップの要件定義をせよ
社内SEのメイン業務の1つが”IT機器導入時の要件定義”です。
要件定義といっても幅は広く、技術的な内容から技術全く関係ない運用管理の内容だったりします。
その中でも今回はサーバーやNAS導入時には必ずついてくるデータバックアップの要件定義に注目してみます。
なお、本記事では”データのコピーを主な手段とするバックアップ”に限定します。RAIDとかホットスタンバイとかクラスタの話は出てきませんのであしからず。
バックアップの目的
データのバックアップをとる目的は”何かあってもデータを消失させずに事業継続するため”です。
一言でいえばそれだけですが、もう少し具体化してくると様々なパターンがあります。
- データが残っていればソフトウェアは消えてもいいのか
- コピーを保存しておくだけで過去の状態は必要ないのか
- 災害対策はできてもマルウェア対策は必要ないのか
などなど、一口にデータバックアップと言っても目的によって必要な条件はかなり変わってきます。
とはいえ、目的をどのレベルまで設定するべきか迷ってしまいます。
当然に目的のレベルが高度になればなるほどお金はかかりますし、どのあたりでバランスをとってよいか悩む社内SEさんも多いのではないでしょうか。
そこで本記事ではバックアップ要件定義で決めないといけないこととどんな選択肢があるのかご紹介します。
どこまでバックアップ対象とするか
データをコピーするにしても、どこまでのデータをコピーするのか決める必要があります。
ユーザー目線の”データ”とはエクセルやメールといったファイルレベルのことを指す場合が多いですが、実際にはそれ以外にも多くのデータが存在します。
どこまでを対象としてどれぐらいのデータ容量があるのかが分かると、バックアップにかかる時間も見えてきます。
ファイル単位でバックアップ
この方法はまさしくファイルそのものをコピーするという方法です。
ファイルの保存が主目的であるNASやファイルサーバーでは、バックアップ対象をここまでとする場合があります。
発生する費用も他の方法に比べれば低めで、場合によっては標準ツール（Windowsではrobocopy、Linuxではrsync）だけで完結することもあります。
注意点としてバックアップ時間は長くなりがちなこと、共有権限のバックアップを忘れがちな場合があることです。
まずバックアップ時間ですが、ファイルやフォルダ単位のコピーは記憶装置にアクセスするときにランダムアクセスという種類のアクセスを行います。
このランダムアクセスは1つ1つのファイル容量が小さく（KBレベル）、ファイル数が多いと記憶装置への読み書きが遅くなるという特徴があります。
そのため、バックアップ時間が他のバックアップ対象と比較すると長くなります。
そして注意点その2は共有権限のバックアップを対象にしていない（できない）場合があることです。
データとしてのファイルコピーができていても、共有権限のコピーができていないとデータ復旧しても誰も見れません。
かといって復旧した時に誰でもアクセスできるようになっていてはいけないので、復旧時にちまちま共有権限の設定作業をすることになってしまいます（そもそも元の共有権限がどうなっていたか分からないと元には戻せない）。
ソフトウェアの設定をバックアップ
目に見えてコピーをする発想になりやすいデータファイルと違い、ソフトウェアの設定はバックアップ対象から漏れがちです。
この方法はサーバー上で業務アプリケーションが動いている場合に必要となります。
例えばワークフローシステムが動いているサーバーがあり、そのデータのバックアップを取得するとします。
ここでバックアップ対象としては、過去に承認されたり承認中の帳票類が真っ先に浮かんできます。
しかし実際にはワークフローシステムにユーザーの情報（マスタ情報）やフローの設定情報があります。
仮にサーバーが故障してデータが消失した場合に、帳票データの復元ができてもユーザー情報やフロー設定情報が消えてしまってはワークフローシステムとして利用することができなくなります。
そのため、業務アプリケーションの設定をバックアップすることは非常に重要です。
方法としては業務アプリケーション付属のバッチファイルや機能を利用することが多いですが、これらの設定は実態としてデータベースファイルとして保存されている場合があります。
このデータベースファイルを上述のファイルコピーの方法でバックアップを取ることも可能な場合があります。
サーバーやOSまるごとバックアップ
この方法はサーバーOSが動いているシステムの場合に利用されることがあります。
特徴としてはOSの設定やファイルを丸ごとバックアップとりますので、複雑な設定を何もせずともデータファイルもシステム設定値もバックアップが取れます。
デメリットとしてはバックアップ容量が大きくなりがちですが、専用のソフトウェア（ArcserveやAcronis等）を使えば圧縮バックアップしてくれるのでファイル単位コピーより容量が少なくなることが多いです。
デメリットは専用のソフトウェアとそのソフトウェアが動くOS環境が必要なので、このようなOS環境が無いサーバーには使えません。
BIOSやハードウェアRAIDもバックアップ
OSレベルでバックアップを取得すれば基本的には安心ですが、BIOSやハードウェアRAIDの設定値は対象外です。
このレベルのバックアップを取得するのは容易ではなく、得られる効果もそれほど高くないので手段として使われることは社内SE目線ではほぼ無いと思います。
サーバー保守サービスを契約していれば設定状況は遠隔にて監視されますし、どこか故障が発生しても設定値を吸い上げて予備パーツに同じ設定をして対応します。
サーバーの運用管理サービスを提供する側は守備範囲ですが、社内SEの守備範囲とは少し離れるのかなと思います。
どこまで復旧できる必要があるか
バックアップ用語でいうところのRPO（Recovery Point Objective：目標復旧時点）です。ここをおろそかにすると、いざ復旧するときに”復旧したいデータが無い”という悲しいことになります。
バックアップはサーバーの状態を複製しておけばよいと思われがちですが、ただ右から左に複製するだけだと複製した時に複製する前のデータは消えるという特徴があります。
例えば1日1回夜10時にサーバーの複製をしているとします。7月1日に複製して、その翌日の7月2日も問題なく複製しました。
さらにその翌日7月3日に”7月2日に間違えて消したデータの復元をしたい”ときに問題が発生します。
7月2日の11時にユーザーがデータを消したとして、そのデータは7月1日のバックアップにありました。
しかし7月2日に”ユーザーがデータを消した”という状態も複製されてしまうので、このユーザーはデータを復元できません。
また、1日に1回のバックアップなので終業間際にサーバー障害が発生してデータが消えると、その日の業務データはすべて消失します。
そのため、観点としては以下の点になります。
- 障害発生時にどれぐらいの期間のデータ消失が許容できるか
- いつバックアップを取得して何世代残すのか
1については常にアクセスがあって最重要な基幹業務系だと1分たりとも許されない場合があります。
一方、データアーカイブや重要度の低いシステムだと1日や数日は許容される場合もあります。
経営者視点では『すべてのシステムは1分たりとも消失を許せない』という考えをする方がいますが、これほどの短期間のバックアップを取り続けることは費用がかなり発生するので全てのシステムで実装することは現実的ではありません。
2についてはバックアップを取得する時刻と世代数の話です。
特に世代数は多くなればなるほどバックアップを保存する容量も大きくなります。
サーバーにもよりますが、1日1回30世代（1か月分）ぐらいが一般的ですが、容量を抑えつつ復旧可能時点を長くとるために1週間に1回、12世代（3か月分）とする場合もあります。
どこにバックアップを保存するか
こちらは物理的な位置も関係してきまして、どこからどこへバックアップを保存するかです。
どこへ保存するかによってバックアップにかかる時間や費用も大きく変わってきます。
同じ拠点内でバックアップ
もっともオーソドックスな方法が同じ拠点内にバックアップを保存する方法です。
当然、オンプレシステムで使える方法ですが、最大のメリットは低コストかつバックアップ速度が速いことです。
コストについては現存する自拠点内に設置するので場所費用も発生せず、テラバイトクラスのストレージサーバーの価格も下がってきて手に入れやすいです。
バックアップ速度についても拠点内ということで1Gbps、場合によっては5Gbpsや10Gbpsのネットワークが利用できるので高速です。
業務に使うネットワークとは別にバックアップ用ネットワークを利用すれば、バックアップという巨大な通信をしても他の通信への影響もなくなります。
ランサムウェアの感染に対してもバックアップ領域を隔離しておけば、バックアップ領域まで浸食されることはなくなります。
デメリットは同一拠点内にあるため、火災や浸水といった天災が発生するとサーバー本体とバックアップデータもろとも犠牲になるのでデータ復旧ができなくなります。
特に近年は日本国内で災害が多発していますので、重要なバックアップを同一拠点に保存する選択はあまりされなくなりました。
別の自社拠点にバックアップ
同一拠点にあると天災に弱いということで、別の拠点にバックアップを保存します。
この手段は拠点を複数持っている組織が取りうる手段ですが、別拠点とはいえ自社拠点なので追加費用は発生しません。
天災が発生しても別拠点からバックアップを復旧できますが、両方の拠点が同じような災害の影響を受けないかどうかはハザードマップなどで事前確認が必要です。
もし同じ災害の影響を受けやすい立地だと、2拠点程度では共倒れするリスクがあります。
また、別拠点に大容量データを転送するので自社専用線でも引いていなければ通信はインターネットを経由します。
そのため通信速度の上限が100Mbpsや1Gbpsだったり、契約がベストエフォートだとバックアップ時間が長くなります。
また、バックアップ専用のインターネット回線があれば話は別ですが、なければ業務用インターネット回線でデータ転送することになるので、日中にバックアップが実行されてしまうと業務通信に影響が発生します。
この方法もオーソドックスな方法ではありますが、転送データ量を削減するために専用ソフトでバックアップデータの圧縮をするなど工夫しましょう。
データセンターを借りる
適切な自社拠点が無い場合はデータセンターを借りる選択も可能です。
データセンターは災害の少ない立地や24時間警備員による監視、停電しても利用可能な蓄電体制が整っているので、ファシリティの品質はかなり高いです。
ただし、借りれるのはデータセンターの場所なのでバックアップ用のストレージサーバーは自前で準備します（ストレージサーバー含めたオールインワンサービスもあり）。
ですが、最近は後述のクラウドバックアップ方法も低価格化してきたので、セキュリティ要件上問題なければクラウドバックアップの方が契約の手間や費用面からするとメリットがあります。
クラウドに保存する
いろいろなものがクラウド化される世間の波に乗って、バックアップの保存先をクラウドにすることもできます。
クラウドバックアップのメリットは、サービスとしてバックアップを保存する領域を提供してもらえるので運用管理の手間がかなり少なく社内SEには大助かりです。
また、大抵のクラウドサービスはデータセンターにサーバーがあり、バックアップのさらにバックアップを確保していたり、自社で準備するよりはるかに高級な高信頼サーバーを使っていたりします。
とはいえ、サービスを利用する側からするとその実態は見えないので、契約するクラウドを選定する際にはどれぐらいバックアップを保存しているのか、バックアップは国内にあるのか国外にあるのか、契約しているユーザーが多くサービスとして安定稼働しているか等を評価する必要があります。
なお、自社が利用しているクラウドシステムのバックアップを保存するときも、その保存先をクラウドにするパターンがあります。
こちらの理由としては、クラウド to クラウドにすれば自社は何も準備する必要がありません。さらに著名なクラウドサービス同士だと連携する専用のソフトウェアや設定が準備されているので非常に容易に実装することができます。
復旧にどれぐらい時間をかけてもよいか
さて、今度は復旧にかかる時間であるRTO（Recovery Time Objective：目標復旧時間）です。
実は発注時の要件としてはこれまでの内容を決めれば大抵は導入を進められます。
そのため、この目標復旧時間はあまり分からない状態や気にしない状態でバックアップ体制を組んでしまいがちですが、障害発生時にここが重要になります。
あるサーバーで障害が発生してデータが消えると、当然バックアップから復旧させようとします。
しかし、この目標復旧時間を先に確認しておかないと、いざ復旧しようとしたときに『復旧まで1週間かかります』とか『修理作業者が到着するのは5日後です』ということが判明します。
この場合、重大なシステムの場合は1日停止するだけで事業運営の損失がジャブジャブ発生することがあり、いざ復旧するときに大変な目にあうことがあります。
そのため、何か新しいサーバーやバックアップ方法を導入するときは、必ず障害発生時にどれぐらいの時間で復旧できるのかを見積もっておいてください。
仮にそれが業務遂行上、許容できないレベルの場合はバックアップ体制の見直しや契約の変更が必要になります。
もし日常的なバックアップ処理に4時間かかっているとすると、復旧時のデータ転送も4時間かかります。しかもインターネット通信の少ない夜間で4時間だと日中ではもっと時間がかかるかもしれません。
データ転送速度という技術面だけでなく、なんらかのサーバーサポートを契約している場合は営業日のみ対応なのか、24時間365日対応なのかも確認が必要です。
サーバー復旧を休日にやっているときにサポート連絡してもつながらないこともあります。
こういった事態を招かないためにも復旧にかかる時間というのは予め確認しましょう。
まとめ
バックアップの目的は単純かもしれませんが、考えていくと決めないといけないことは意外と多いです。
また、要件定義が終わって導入した後もバックアップ手順の確認のために復旧訓練を定期的に実施するように心がけましょう（色々兼任している忙しい社内SEさんはなかなか難しいかもしれませんが）。