”バックアップが取得出来ていなかった”
インフラエンジニアとしては身につまされる話。
日本電子計算は2019年12月16日、自治体向けIaaS「Jip-Base」を利用中の自治体でシステム障害が発生している問題について記者会見を開き、山田英司社長が「大変申し訳なく思っている」と謝罪した。同社によると、15％のデータはIaaS内のバックアップも見つからず、単独での復旧が不可能。残りの70％は復旧、15％は復旧作業中であることが明らかとなった。
ちなみに現時点の報告書はこちら。
・全1318の仮想OSのうち、70％がIaaサービスとして復旧完了。
・バックアップデータが特定出来ないものがあり、調査の結果、一部についてバックアップが取得出来ていなかったことが判明（12月15日）。その状況を踏まえ、現時点バックアップデータの見つからない15％に関し、Iaaサービスとして自社のみでの復旧が不可能と判断
・残り15％、バックアップデータからの復旧待ちおよび確認
考察
仮にIaaSを運用するインフラエンジニアの立場で考えてみます。
バックアップとして必要な要素は何でしょうか。レイヤーが低いものから考えてみます。
（１）ストレージのボリューム
（２）仮想OSイメージ
（３）データ（データベースを含む）
この３つとなります。どのバックアップなのかを考えないと間違いなく話が食い違います。
今回、損傷を受けたのは間違いなく（１）です。ストレージのボリューム自体が破損ました。
推測ですが仮想環境を動かすハイパーバイザーからマウントすらできなくなったのではないかと思われます。もしくは、幸いマウントできたとしても、中の仮想ディスクの中身が壊れてしまい（２）の仮想OSイメージが破損してしまったものと思われます。
そして、（３）データについては、ユーザーが能動的にバックアップを取っていたと思われますが、これは基本的にはユーザー任せになっていたと思われます。
IaaSの感覚から考えると、ストレージのボリュームが破損したときのことを考えて、（２）仮想OSイメージを月次などで別ストレージに取得していたはずです。
今回のようにレイヤーの低いレベルでストレージにアクセスできなくなったとき、別ストレージを用意してバックアップしていた（２）仮想OSイメージをリストアします。仮想OSイメージが戻ったとしても、それはバックアップを取ったタイミング（月次など）のデータに戻ってしまいます。あとはユーザーが（３）データを戻してリストアが完成する算段です。
データ（３）のバックアップまで請け負うと、これはシステム運用のマネージドサービスの範疇となり、IaaSではなくなります。IaaS+システムマネージドサービス、というビジネスになってきます。文中にはIaaS内のバックアップとはっきりありますので、そこまでは含まれていないと推測します。あくまでも仮想OSのボリュームの中にデータが含まれている、というロジックだと思います。
つまり、私の推測では、（２）仮想OSイメージ、について全てのOSについて何らかの理由でバックアップ計画に含まれておらず、リストアできない、というふうに見ています。
なぜ含まれていなかったのか。これについてあいまいな書き方がされているために憶測を呼ぶ結果となっています。15%というのは多すぎるため、運用に穴があったのではないかと率直に思いますが真実は今後明らかになると思います。
さて、そもそも（１）ストレージのボリューム、についてバックアップはないのかという議論があります。2つ考え方があります。
・スナップショットのバックアップ
・レプリケーション
スナップショットのバックアップについてはDell EMCが仕組みを解説してくれています。
スナップショットを使用すると、バックアップの処理をスナップショット側で行うことができます。バックアップ専用のサーバを用意し、このサーバからスナップショットへアクセスし、バックアップを行うことで本番サーバにバックアップをさせなくても良いようになります。スナップショットは、「ある時点」のデータがすべて取得できるので、いつでもフル・バックアップのイメージが取得でき、しかもスナップショットは本番サーバのデータ容量が大きくても一瞬で作成することができるので、大容量データのバックアップに非常に向いています。
もしこの仕組みを利用して、テープなどでバックアップが取られていれば、とは思いますが、運用負荷は大きいです。
また、ファームウェアのバグがひどくて、スナップショットのデータにすら損傷を与えるような内容である可能性もあります。テープやその他の媒体ででバックアップしていなければアウトです。
いろんな運用制約の中で、そこまで厳密にバックアップ設計をしているかというと、現場によってまちまちだと思います。
レプリケーションについては、netappのページを引用します。
一方のレプリケーションは簡単に言えば「複製を作る」というデータ保護方式です。スナップショットとは違い「データ自体」を保存し、ある時点、またはリアルタイムでストレージとまったく同じ状態を別のストレージに複製します。
レプリケーションもスナップショット同様に、サーバ稼働に影響の少ないバックアップ方法の一つです。ただし、同じデータを丸々複製するので、複製先のストレージコストがかかります。
レプリケーションの場合、もし今回のようなファームウェアのバグで論理データそのものを壊すと、別の筐体にもそれをコピーしてしまう恐れがあり、無力である場合があります。
報告書にはレプリケーションの存在はないのですが、もしあったとしても、今回の件を救えたかは不明です。
また、単純計算でストレージのコストが倍になるので、レプリケーションを用意していない現場も多いのではないでしょうか。
ユーザー側の立場とすれば
私もパブリッククラウドを使うユーザーの立場でもありますが、ストレージについては100％信用していません。
クラウドベンダーが全損を告白してきたときにどうするか。
そのために（２）仮想OSイメージは自力で取るようにしています。また、（３）データは、別のデータセンターのストレージに自力で移すようにしています。
そのうえで、バックアップが、想定した通りに定期的に取られているか確認すること。
・・・なんて言っていますが、不安は常に持っています。
本当にそのバックアップはバックアップなのか。
ちゃんとリストアできるのか。
バックアップデータにバックアップが含まれているのか。
取るべきものを忘れていないか。
人の振り見て我が振り直せ、とは今回の件で私も痛感しているところです。
