SCS★3に向けて、「戻せるバックアップ」を実際に作ってみた
世代バックアップを設定し、初回約9時間、2回目約20分の差分動作を確認。さらに過去世代のファイルを実際に取り出して開き、「バックアップがある」から「戻せる」へ進めた記録です。
以前、この技術ノートで、「要求される前に、SCS★3を目指してみようと思う」と書きました。
その後、SCS★3の要求事項・評価基準を見ながら自社の状態を確認していく中で、「バックアップがあること」と「実際に戻せること」は同じではないと気付きました。
この違いに気付き、世代バックアップを追加しようと考えるまでの経緯は、前回のバックアップ記事に整理しています。
当社では以前から、社内NASとクラウドを使ってデータを守ってきました。
ただ、
昨日の状態へ戻れるか。
数日前の状態へ戻れるか。
という視点で考えると、それまでの運用だけでは足りない部分がありました。
今回は、その続きです。
実際に世代バックアップを設定し、差分で動くことを確認し、本当にファイルを戻せるところまで試しました。
世代バックアップを実際に設定した
今回追加したのは、NASへ直接接続する外付けのバックアップ用機器です。
既存のNASに履歴差分バックアップの機能があったため、その機能を使うことにしました。
設定した内容は、次のとおりです。
- 毎日1回、自動で実行する
- 30世代の履歴を保持する
- 主要な業務データを対象にする
- 多くのファイルに変更があった場合は通知する
毎日正常に動けば、30世代はおおむね過去1か月分へ戻れるイメージです。
最初は、もっと長く残した方が安全なのではないかとも思いました。
ただ、今回の世代バックアップの目的は、何か月も前の状態を日単位ですべて残しておくことではありません。
誤って削除した。間違えて上書きした。直近のデータが壊れた。
そうした日常的な事故から、少し前の状態へ戻るためのものです。
長期保存とは役割を分けた方が分かりやすいと考え、まずは30世代で運用することにしました。
初回は約9時間、2回目は約20分だった
初回バックアップは、対象データを一通り保存する必要があります。
実際に動かしてみると、初回は約9時間かかりました。結果は正常終了で、失敗したファイルもありませんでした。
その後、自動実行された2回目のバックアップは、約20分で終了しました。
NASのログを見ると、初回は full、2回目は diff と表示されていました。
つまり、このNASのログ上では、初回がフルバックアップ、2回目が差分バックアップとして、想定していたとおりに動いていることを確認できました。
もちろん、9時間と20分は当社のデータ量、機器、接続方法、変更されたファイル数での結果です。別の環境でも同じ時間になる、という意味ではありません。
それでも、毎日フルバックアップを繰り返すのではなく、2回目以降は現実的な時間で動かせることが分かりました。
見た目では全部ある。でも実際には全部増えていなかった
ここで少し戸惑いました。
バックアップ先を見ると、日付ごとに世代フォルダーが作られ、その中には毎回すべてのファイルがあるように見えます。
最初に見たときは、
これ、毎回全部コピーしているのでは？
と思いました。
ところが、ログでは2回目が diff になっています。
さらに、NAS側で外付け機器の実使用量を確認すると、複数世代分のデータが、そのまま丸ごと積み上がっているわけではありませんでした。
見た目としては、それぞれの時点の全データへアクセスできる。一方、保存容量は毎回フルバックアップと同じ量だけ増えてはいない。
内部でどのように差分を持っているかまで検証したわけではありませんが、ログと実使用量の両方を見たことで、世代バックアップの動きがかなり具体的に分かりました。
本当にファイルを戻してみた
今回、一番確認したかったのはここです。
設定画面で「正常」と表示される。ログにも「成功」と出る。
それだけでは、まだ「戻せる」とは言えません。
そこで、過去の世代バックアップから任意のファイルを一つ選び、PCのデスクトップへコピーしてみました。
結果は問題なく、ファイルを普通に開くことができました。
これで初めて、
バックアップがある
から、
実際に戻せる
ところまで確認できました。
前回の記事では、
バックアップがあることと、復旧手順を実行できることの間にも、まだ一段あります。
と書きました。
今回、その一段を実際に試したことになります。
ただし、今回確認したのは、一つのファイルを取り出して開くところまでです。大量のデータをまとめて戻す時間や、NAS本体が使えない状態からの全体復旧までを確認したわけではありません。
一つ戻せたことと、どのような障害からでも会社の環境を完全に復旧できることは、分けて考える必要があります。
RAID、世代バックアップ、クラウドの役割が実際の運用になった
世代バックアップを動かしてみると、それぞれの役割もさらに分かりやすくなりました。
RAIDは、NAS内部のディスク故障に備え、業務が止まる可能性を下げるものです。
世代バックアップは、誤削除や上書きなどから、過去の状態へ戻るためのものです。
クラウドは、事務所側の機器をまとめて失った場合にも、別の場所から戻せる可能性を残すものです。
RAIDもデータを守る仕組みではありますが、バックアップそのものではありません。
今回の構成によって、
ディスクが壊れても止まりにくいこと。
過去へ戻れること。
早く戻せること。
そして、戻し方を選べること。
という状態に近づきました。
前回の記事では、考えていた構成がCISAの資料で紹介されている3-2-1ルールに近いことにも触れました。
その時点では、世代バックアップはまだ構想の段階でした。
今回は、
- NAS上の運用データ
- 別媒体に残す世代バックアップ
- 事務所外にあるクラウドバックアップ
が、実際の運用としてそろいました。
3-2-1という言葉を知っただけではなく、自社の運用として、その考え方に沿う形を作れたところまで進んだことになります。
ただ、3-2-1という形をそろえること自体が目的ではありません。
大事なのは、一つの機器障害や操作ミスで、すべてを失う可能性を下げること、そして、必要なときに本当に戻せることだと思っています。
「設定した」ではなく「確認した」まで
今回行ったのは、バックアップ用の機器を追加しただけではありません。
- 世代バックアップを設定対象、実行間隔、履歴数、通知条件を決める
- 初回のフルバックアップを確認正常終了し、失敗したファイルがないことを確認する
- 2回目の差分動作を確認ログの表示と実行時間を確認する
- 保存先の実使用量を確認毎回同じ容量が増えていないことを確かめる
- 過去世代からファイルを取り出す任意のファイルをPCへコピーする
- 取り出したファイルを開く実際に利用できる状態であることを確認する
つまり、
設定した。
だけではなく、
動いたことを確認した。
さらに、
戻せることも確認した。
というところまで進めたことになります。
今後は、たまに実際のファイルを戻してみる。バックアップが正常終了しているかを確認する。必要なら履歴数や運用方法を見直す。
担当者が不在でも手順が分かるか、大きな単位で戻す場合にどの程度の時間が必要かなど、まだ確認したいこともあります。
一度成功したから終わりではなく、このくらいの運用を続ける必要があると思っています。
SCS★3に、一歩近づいたのかもしれない
もちろん、今回のバックアップ対応だけでSCS★3を取得できるわけではありません。
IT資産の一覧化、インシデント対応、情報の分類、アカウント管理、訓練や記録など、まだ整理しなければならないことはあります。
それでも、バックアップと復旧については、考えている段階から、実際に運用して確認する段階へ一つ進むことができました。
SCS★3に一歩近づいた、と言ってもよいのかもしれません。
ただ、今回も認定そのものが目的ではありません。
認定を目指したことで、昨日の状態へ戻れるようになった。復旧方法を選べるようになった。そして、実際に一つのファイルを戻せることを確認できた。
それだけでも、会社としては以前より少し強くなっています。
こうした取り組みを技術ノートに残しておけば、DX認定の更新を含め、後から「何を考え、何に気付き、何を実際に行ったのか」を時系列で振り返れます。
もちろん、公開する技術ノートだけで、認定に必要な管理記録になるわけではありません。設定内容や実行ログなどの詳細は、社内の記録として別に管理していきます。
今回の記事は、単なるバックアップ設定の記録ではなく、SCS★3に向けて、会社の情報管理を実際に一つ改善した記録として残しておこうと思います。
認定を目指す過程で、実際に少し強い会社になっていく。
SCS★3についても、引き続きその方向で進めていきます。