今日はバックアップに関する最近の話題をつらつら語りたいと思います
みなさん、こんにちは！
株式会社カチカのオフサイト＆コールドバックアップ業務担当の村島です！
突然ですが、宇都宮に行ってLRTに乗ってみたいななんて考えています。
これまでお話ししたことありましたかねえ？実は私は軽い乗り鉄でして。
初めて「この路線に乗ってみたい」というだけの理由で電車に乗りに行ったときの目的路線が山万ユーカリが丘線でした。
通り道にあたるので、東葉高速鉄道線も。
新宿から西船橋までJRで行くよりも、西船橋から勝田台（東葉勝田台）まで行く方が料金が高い。あれ採算取れるのかなあ？
山万は何かおもちゃみたいな列車でかわいいと思った記憶がありますね。「公園」「女子大」「中学校」など、まさかの普通名詞が駅名になっているという。
このときにはさほど気にならなかったのですが、最近山万は乗り鉄界隈では注目を浴びてるようですね。
というのも、冷房設備がないんです。技術的に冷房設備を取り付けるのが非常に難しいんですね。
というわけで、わざと盛夏を狙って山万22時間耐久乗車というチャレンジをする人もいるとか。
宇都宮LRTは、最近できた路線ですが、上手く行くのかどうかと言われていましたが上手く行きましたね。盛況だそうです。
宇都宮LRTで餃子旅なんていうのもあるそうで、行ってみたいです。
栃木は十分魅力があるところだと思います。
もっと自信を持ってください。
さて、雑談が長くなりましたが、本題に入りましょう。
今日もレッツスタディセキュリティ！なのです。
サービスとしての災害復旧
*aaSという言葉がいまどんどん増えつつあるなあという感じが致します。それで、そのうち出てくるだろうなと思ったものがやっぱり出て来ました。
DRaaSです。DRというのは「ディザスタリカバリ」のことですね。念のために言っておきますとaaSというのは「アズ・ア・サービス」のことです。
なんだか「クラウド」とか「アズ・ア・サービス」とか唱えればIT関係の問題が全て解決するかのように言われているように思います。決してそんなことないんですって。
まあまあ、私の思いますDRaaSの問題点は後回しにしまして、DRaaSについて語ってくれているサイトを見てみましょう。記事の公開日が2023年の12月12日ということであんまり最近のものってわけでもないんですが、まあ読んでみて下さい。
簡単に言いますとユーザーが使っているサーバーが何らかの理由で利用できなくなってしまった際に、その事件が起きるまでに蓄えておいたバックアップデータからクラウド内に仮想サーバーを構築し、その仮想サーバーに付け替えることによって、迅速にリカバリーが可能である…ということのようですね。
その他いろいろ書いてあるんですが、内容としてはこのnoteで私が警鐘を鳴らしてきたことと変わりません。
このサービスは本当にディザスター（災害）に対応できるのか？
さっくり言ってしまうと、専門用語をこれでもかというほど使って読者に一種の暗示をかけているように、私からは見えます。
そして私が言いたいこともこれまでと全く同じです。
「通信とか電力とかのインフラが大々的にやられちゃった場合どうするのさ？」
ってことです。前々から何回も出している図ではあるのですが、
こういう↑具合にデータのひとつが飛びました…とか
こういう↑具合にPCが1台飛びました…とかなら*aaSシリーズの対策で何とかなると思うんですね。
このようにオフィス丸ごと使えなくなったらどうするのってことを私は強く強く訴えたいわけです。通信インフラが使えなくなっちゃったらクラウドの利用そのものができなくなるわけですよ。なんだったら、サーバーに繋いでローカルで使っていたPCも物理的に全部グヂャグヂャになってしまっている可能性さえあるわけですよ。
そこで弊社では、状況に応じて、お客さまの業務が最低限回るレベルにPCを用意し、お預かりしているバックアップを利用して環境を再構築してお届けすることができます。
上でリンクを張りましたIBMさんの「DRaaSとは」という記事をよく見てみて下さい。ランダムに書き出しますけども
目標復旧時点（RPO）
目標復旧時間（RTO）
災害復旧計画（DRP）
ランサムウェア攻撃
マルウェア攻撃
自然災害
データ損失の修復
事業継続計画（BCP）
というような具合で、単語そのものが丸々同じではないものもありますが、だいたい普段このnoteで私が同じことを言っているということをお感じいただければと思っています。
巨大企業による*aaS系のサービスは、非常にスマートで便利です。ですが、スマートで便利な方法だけで解決できないものというのもあるんですね。
いきなり何を言い出すんだと思われるかも知れませんが、私の車の免許証ではMTが運転できます。でも、いまMT免許を取る人ってほとんどいないんだそうですね？
まあ私はさほど車好きっていうわけでもないんですが、MT取って良かったと思っています。車がどういう仕組みで動くのか、それをより深いレベルで理解できるんですね。
私は自分のPCは自作することにしています。これをすることで、どのパーツはどういう目的を持って作られたもので、どういう風に動作するから、結果としてこういう動作が得られる、というのが理解できます。
その他機械類はだいたいそうなんですけど、ユーザーフレンドリーになればなるほど、一般的なユーザーと機械そのものとの距離ができてしまいます。機械の動きが見えなくなってしまうんです。
そうなるとどうなるか。トラブルになった時には、機械がどう動くかわかっている人なら当たり前にわかるような些細なトラブルにでもお手上げってことになってしまうんですね。
私にはこういう経験があります。あるオフィスで働いていました。PCに詳しい人はほとんどいませんでした。そこで1台のPCに「USB機器を挿しても認識されない」という異常が起こったんです。
私はそのPCを見て確認してみました。確かに認識しません。そこで私は「開けてみましょうか？」と普通に言ったんです。そうしたところ周囲の人たちが、まるでとんでもないことを私が口走ったようなテンションで「無理無理無理無理！」のコーラスになったんですよ。
PCを「PC」という1台の機械と思っている人からは私の言ったことはとんでもないことなんでしょう。ですが「機械の集合体」と認識している私の場合、USB機器を挿しても認識されないというトラブルは起こりがちなトラブルとして、だいたいどのあたりをチェックすればいいのかわかっています。
最近はクラウドの、*aaS系のサービスが利用できれば、オフィスの仕事は「日常的には」問題がないんだと思います。ですがその「日常」が壊れた時に、*aaS系の「S」、つまり「サービス」しか利用したことがない人は打つ手なし状態になってしまうわけですね。
あまり関係ないかも知れませんが、個人のネットユーザーもいまはPCではなくスマホからアクセスしている人がほとんどなんだと思いますが、それゆえにこんな疑問を持つ人が出て来ちゃったりするわけです。
大は*aaS系のサービスから小はスマホまで、ソフト的にもハード的にも泥臭い作業をやって「サービス」とか「アプリ」とかいう形に落とし込んでいる人がいるから末端ユーザーが利用できるわけです。
一般的には、*aaS系では「サービス」、小さい方では「アプリ」を利用できればいいんだと思います。それの利用に長けているという事を以て、ITのリテラシーが高いと判断されることも多いのかも知れません。
しかし「日常」が破壊されて「非日常」がITの世界を襲ったとき、そういう「ITリテラシーが高い人」はどこまで対応ができるのでしょうか？
私は、そういう好ましからざる非日常のときには、泥臭い作業ができる人間でありたいと思っています。私が常々思って、口にしている「最後は人の手」というのはそういうことです。
バックアップの自動化とオーケストレーション
バックアップの自動化というのはついこの間話題にしました。
正直、私も考えていなかったわけではないことが指摘されています。システムにしてもデータにしても巨大化の一途を辿るこのIT業界において「バックアップのためにこれだけの時間を用意しておこう」と腹づもりしておいた時間で本当にバックアップが終わるのだろうか？という話ですね。
オーケストレーションというのは、何もバックアップに限ったことではないのですが、何らかの、ある程度複雑で、単純に行ったらかなりの時間がかかってしまうような作業を、複数のシステムを連携させて使うことによって効率よく処理していこうという考え方のことですね。その名のとおり「オーケストラ化」するわけです。指揮監督者が、たくさんのシステムを協調させて動かすことにより全体的に効率化を図ろうと。
でもこれ、何らかの処理を早く行いたいという希望があるときには誰しもが考えることじゃないでしょうか。
古い話になりますが、PentiumⅡというCPUがかつてありました。
（画像はWikipediaより）
私の記憶が間違ってなければこのCPUからだったと思うのですが、ふたつのCPUを同時に使うという方向に進化が始まりました。
CPUがふたつある場合、ひとつのCPUがメモリ上のある場所のデータを書き換えても、もうひとつのCPUはそのことを知らないということがあり得ます。というわけで、IntelはこのCPUから「もうひとつのCPUとやりとりをするための信号線」というのを設けるようになりました。
互換CPUメーカーっていうのがこのころいくつかありまして、そのトップを走っていたCyrixという会社と、2番手のAMDという会社は協力してマザーボードの規格を定めました。
この2社のPentiumⅡ互換CPUにはふたつのCPUが息を合わせるための信号線はなかったので、ひとつのCPUを現場監督専任として使うことにより、最大32個（だったと思います）のCPUを1台のPCに載せることができると。
実際にはこれをやろうとするとCPU2個では意味がないわけで、最低3個CPUが必要、だけれどもそんなにたくさんCPUを実装できるスペースが物理的にマザーボード上には存在しないという理由で、結局は規格が制定されただけで終わったように思います。
PentiumⅡはPentiumⅡ側で、頻繁に使うデータをとりあえず置いておくための2次キャッシュと言われる部分がCPU同士の会話の間に入り込んでしまい、ひとつのマザーボードにふたつのPentiumⅡを載せられる製品は出なかったのですが。
ただ、PentiumⅡから2次キャッシュを除いたCeleron（初代）では実際に2台載せられるマザーボードが発売されまして、あれ欲しかったな～といまでも時々思い返します。
画像はWikipediaより
まあそんな感じで、ひとつの●●に任せてたら時間がかかる、というような場合にはたくさんの●●を使って高速化できないか、という考え方はずいぶん前から存在します。
このころに複数のCPUを使う商品の研究開発があったからこそ、いま複数コアのCPUが使えているということでもあるのですよ。
このようにプロセッサがたくさん載っていますね。
さてさて、前置きが長くなりましたが自動化とオーケストレーションを実現できるバックアップの方法はあるのか、ちょっと調べてみました。
…バックアップのオーケストレーションという記事はあまり見つかりませんねえ。あのVeeamがDRのオーケストレーションサービスを大々的に打ち出していますが、バックアップの方はやってないのかな？
…さらにちょっと深掘りしていろいろ見てみたんですが、バックアップのオーケストレーションというのを実現するソフトもWebサービスも見受けられませんでした。
どうもオーケストレーションというのは今のところリストアの文脈で使われることが多いようですね。ディザスタリカバリ（DR）では結構利用されているみたいですが。
でも、今回こうやって改めて調べてみて、私は自信を持ってしまいました。Veeam社のディザスタリカバリ・オーケストレーションと言えど、弊社のDRの方が早いと思います。と言いますのも、弊社ではバックアップは全てご利用中だった状態に戻して保管しております。例えば、フルバックアップのあと3回の差分バックアップがなされていた場合、フルバックアップと3回目の差分バックアップから現状のストレージと同じ状態に整えております。ですので、お客さまのご希望でなるべく早くということであれば、ストレージをリプレースしてしまえばそれでいいのですから。
復旧は迅速に行えるかと思います。よろしくお願いいたします。
オブザーバビリティという言葉もあります
最近はオブザーバビリティなんていう言葉もありますね。
ネットワークを介してつながっているコンピュータを多数使うのが当たり前の昨今、その全体（あるいは、自分の管理下にある範囲のコンピュータの集合体）の動きを見ながら動作をコントロールするというような意味になりますでしょうか。
監視と違うのは、監視はある事柄についてリアルタイムに、問題が起きないように、異常やパフォーマンスに問題がないかなどのことをチェックします。最初から、どこを中心にして異常がないかどうかということを注視するのが監視という事になります。
具体的には、CPU使用率、メモリ消費、レスポンスタイムなどを注視するわけですね。
一方でオブザーバビリティというのはシステム全体の状態を観測しながら可視化し、可視化した情報から予期せぬ何らかのトラブル・問題を発見しようという試みになりますね。
コンピュータS（つまり、連携して使用している複数のコンピュータというのがSの意味です）のいろんなところの状態がわかるように、できる限りいろんなところからその稼働状況を見られるようにしておいた上でそれを観測し、問題が出そうなところをあらかじめ特定しておくという事に意味がありますね。
まだ顕在化はしていないけれども、結構ここに負荷がかかっているというようなことを、その理由とともに明らかにしようという試みです。
バックアップにおけるオブザーバビリティとは
単にバックアップを行うことだけではなく、その健全性や復旧可能性を常に監視し、問題があれば早期に検知・対処するというのがバックアップにおけるオブザーバビリティというのが重要な概念だと言えましょう。
最近はAIによる異常検知などという試みもなされているようですね。本当にAIというのが最近大活躍です。
でも私はそこまでAIを信じる気にはまだなれません。そして、根本的には信じていないAIというものに情報を預けきってしまう気にもなれません。
↑の絵、とあるアニメのとあるキャラクターを描いてくれ、とGeminiにお願いしたら出力された絵なんですが、ビタ一文も似ていませんね。まあそのキャラクターがなんなのかは明かしませんが、美人ですががさつで元ヤンで食ってばっかりいる女性キャラクターです。
ちょっとリトライしてみましょうか。
↑これは緑色がイメージカラーの、和菓子屋の娘というキャラクターなんですが…もはや人間とは思えないレベルにまで崩壊してしまいました。
ほんまに誰やねん…。
同様にAIによる復旧テストなどもバックアップの信頼性を高めるための技術として現れてきてるっぽいですが、少々手前味噌をお許しいただけるのならばこういうことにこそ「最後は人の手」という考え方を持ち込むべきだと思うのですが。もちろん弊社は人の手ですよ。
小括
というわけで、日々量産されつつあると言ってもいいIT関連の用語について、バックアップ及びリストアという作業に近いものを3つ選びまして今回はお話しさせていただきました。
こうやって日々いろいろな新語、新しい概念が誕生してくるわけですが、視点をちょっと高くして、IT化の歴史をちょっと振り返ってみてそして考えたら案外これまでやってきたことの延長上っていうことは少なくありません。
ですので、日々現れる新語をひとつひとつ追うことは必要ないと私は考えています。
基本のラインさえきっちり押さえられているのであれば、新しい（ように見える）事態にも十分対応可能です。
わからないことがあればお問い合わせ下さい。
今後ともよろしくお願いいたします。
目次
クラウドストレージと遠隔地バックアップの相互補完性
クラウドストレージのデータ消失に関する責任の所在
ディザスタリカバリ手順をあらかじめ決めておくべき理由
弊社でお取り扱いしておりますデータ・OSにつきまして
クラウドストレージのメリット・デメリット
Windowsからの乗り換え先になるか？ Linux MintとChrome OS Flex
バックアップの方法 オフライン・オンラインバックアップとは？
IPAの言うセキュリティ対策の基本を見ていきましょう！ その1
IPAの言うセキュリティ対策の基本を見ていきましょう！ その2
IPAの言うセキュリティ対策の基本を見ていきましょう！ その3
IPAの言うセキュリティ対策の基本を見ていきましょう！ その4
IPAの言うセキュリティ対策の基本を見ていきましょう！ その5
IPAの言うセキュリティ対策の基本を見ていきましょう！ その6
IPAの言うセキュリティ対策の基本を見ていきましょう！ その7
IPAの言うセキュリティ対策の基本を見ていきましょう！ その8
IPAの言うセキュリティ対策の基本を見ていきましょう！ その9
IPAの言うセキュリティ対策の基本を見ていきましょう！ ラスト
内閣サイバーセキュリティセンター（NISC）を見ていきましょう！
内閣サイバーセキュリティセンター（NISC）を見ていきましょう！その2
内閣サイバーセキュリティセンター（NISC）を見ていきましょう！その3
内閣サイバーセキュリティセンター（NISC）を見ていきましょう！その4
ランサムウェア・インシデント発生時の組織向けガイダンスを見ていきましょう！その1
ランサムウェア・インシデント発生時の組織向けガイダンスを見ていきましょう！その2
ランサムウェア・インシデント発生時の組織向けガイダンスを見ていきましょう！その3
ランサムウェア・インシデント発生時の組織向けガイダンスを見ていきましょう！その4
ランサムウェア・インシデント発生時の組織向けガイダンスを見ていきましょう！その5
ランサムウェア・インシデント発生時の組織向けガイダンスを見ていきましょう！その6
ランサムウェア・インシデント発生時の組織向けガイダンスを見ていきましょう！その7
ランサムウェア・インシデント発生時の組織向けガイダンスを見ていきましょう！その8
ランサムウェア・インシデント発生時の組織向けガイダンスを見ていきましょう！その9
ランサムウェア・インシデント発生時の組織向けガイダンスを見ていきましょう！その10
ランサムウェア・インシデント発生時の組織向けガイダンスを見ていきましょう！その11
─事件を解決せよ─ CASE2：Webサイトのデータが消えた Part 1
─事件を解決せよ─ CASE2：Webサイトのデータが消えた Part 2
ランサムウェア・インシデント発生時の組織向けガイダンスを見ていきましょう！その12
─事件を解決せよ─ CASE3：火事でオフィスが焼失 Part 1
─事件を解決せよ─ CASE3：火事でオフィスが焼失 Part 2
ランサムウェア・インシデント発生時の組織向けガイダンスを見ていきましょう！その13（最終回）
今日はバックアップに関する最近の話題をつらつら語りたいと思います その2
オフサイトバックアップに関する最近の話題をつらつら語りたいと思います
バックアップがきちんとしていれば起きていなかった情報事故 その1
バックアップがきちんとしていれば起きていなかった情報事故 その2
中小企業のための簡単・安価なデータバックアップ戦略 その10
大企業における物理的媒体による遠隔地バックアップの重要性 その1
大企業における物理的媒体による遠隔地バックアップの重要性 その2
大企業における物理的媒体による遠隔地バックアップの重要性 その3
