orangeitems’s diary

40代ITエンジニアが毎日何か書くブログ

バックアップを取ること自体に、リスクがあるという現実

f:id:orangeitems:20211229131131j:plain

 

システム運用の仕事に関わって随分長いので、バックアップという行為についての危険性は十分に承知をしています。数年前にバックアップ絡みで大きな事故があったのを記憶していて、あの件から多くの人が学んで最近はもう聞かなくなったとおもったら、先日また、同様の事故が起こってしまったようです。

 

www.iimc.kyoto-u.ac.jp

2021年12月14日 17時32分 から 2021年12月16日 12時43分にかけて,スーパーコンピュータシステムのストレージをバックアップするプログラム(日本ヒューレット・パッカード合同会社製)の不具合により,スーパーコンピュータシステムの大容量ストレージ(/LARGE0) の一部データを意図せず削除する事故が発生しました.

 

正直言って、バックアップを取らない方が安全なんじゃないかと思うこともあります。何十テラバイトのデータをコピーするだけでもかなりの性能が必要になります。これを安全にバックアップし続けること、結構大変な要件です。

 

ファイル消失後にバックアップが実行されてしまった領域のファイルの復元ができない状況となったことから,将来的にはこれまでのミラーリングによるバックアップだけでなく,1世代分の増分バックアップを残す等の機能強化を検討いたします.機能面だけでなく,再発防止に向けた運用管理についても改善に取り組みます.

 

記事中に「ミラーリング」という記載もありますが、ミラー元を削除するとミラー先も削除されますので、これじゃバックアップにならないんですね。RAID1っていう話であれば、急に「1世代分の増分バックアップを残す等の機能強化」という言葉が出てくるのは意味が分かりませんでした。

 

なお、バックアップの制御を、ローカルで行うことってナンセンスです。ローカルにはエージェントを組み込み、結果はバックアップサーバーへ送り込む、というのが正しい考え方のように思います。

1つのOSの中でなんでもかんでもやっちまおうとするから、大変なことになるんです。

動いているサーバーには極力何もさせない。

外部から、指示を送り、結果は外部に返す。

こういったことを自然にやってくれるのが商用のバックアップソフトウェアです。

バックアップサーバーでバックアップ処理は集中管理する。バックアップイメージはため込むが、もしロストしてもバックアップがロストするだけ。

おぼえておきましょう。バックアップはローカルで取らないこと。

バックアップ要件を作り込んで、たくさんシェルスクリプトをスケジュール実行する人はいますが、これは時代遅れだと認識しましょう。

OSレベルでは極力何もしない。ミドルウェアレベルであれば、ミドルウェアレベルでバックアップの設定が組み込まれているのでそれを使う。OSまで踏み込まない。

バックアップ自体もミドルウェアと捉えれば、ミドルウェアのレベルで全て設計することが私は、運用を安全にするし、属人化も防ぐと思います。

エレガントなシェルスクリプトは解読が他人に難しく、かつ変更を加えた時に想定外が起こりやすいのです。

本番OS上で、できるだけ余計なことをしないことが大切。

今のOSのインストールイメージって、世界中で頭のいい人がベストプラクティスを集めて組み上げた設定になっているので、そこに処理を入れるたびに脆弱になっていくという発想で間違いないでしょう。

と、まあこういう配慮がないとぶっ飛ばしてしまうから、運用設計って実はシステムの肝だったりするんですが、「バックアップ=安全のために」という発想なので、なかなか利用者は危険だと思いません。レビューもそこそこに対応してしまうので、事故はなかなかなくなりませんね。

一方で、もう一つ別の考え方もあって、ストレージサーバーのスナップショット機能も使えます。これは、ボリュームのスナップショットを取ると、取った時点にまでファイルシステムを戻せると言う機能です。今回も数十TBを補完するストレージなので、そのような機能はついてそうなものですが、スナップショットの定期取得の実装はしていなかったんでしょうね。ま、何か変更作業をしたらデータごとぶっ飛ぶ、という感覚であれば実施して然るべきだとは思うのですが。

私もシステム運用をしていて、何か変更作業をするときは、かなり顧客には警告をします。この前のLog4Jの件だって、「暫定の修正パッチは!?回避策は!?」って話にはなりましたが、ベンダーから出ていた回避策自体が危険を伴うものだったので、「まあ、待て。この方法自体が危険だ」「回避している条件そのものが、今回のシステムでは起こりえない。」と言う話をしました。回避策についてはベンダーから決定版が出てからと考えています。

すぐに何でもやっちまうタイプの判断はありますが、私は変更作業自体が危険を伴うと考えています。だから相当保守的に見えると思いますが、運用における技術ってそういうものじゃないですかね。

横目で今回の事故を見ながら、これは他人事じゃない。来年も生き残るために教訓としていこう、そう思いました。