ファーストサーバ障害について基盤SEが利用者視点で考える。【その2】

未分類

前回からの続きです。安価であるにもかかわらず、稼働率が高くなんのリスクもないというのは不可能だというのが前回の主張でした。

なにもこれはITに限ったことではありません。高機能な家電や高性能の車が安いといったら「ワケあり?」と疑うのが普通でしょう。ITの世界でもそれは同じだといっているだけのことです。安いのにはそれなりに理由がありますから、その理由に応じて自らがリスクヘッジすることが必要です。

 

今回の場合、Webサーバとしての利用であればftpでローカルに定期的にデータをダウンロードすることでバックアップとなり得ますが、データベースが絡んでいたりすると少し複雑になります。cronと呼ばれる処理を定期実行するための仕組みを提供しているサービスも多いので、重要データだけでも定期的に他社のサーバなどに転送すべきなのかもしれません。双方でscpコマンドが使えれば暗号化してデータは転送出来ますから、最初だけはスキルがないと大変かもしれませんが一度設定をしてしまえば以降はほとんど全自動です。

なお、バックアップは自動化するのが基本だと筆者は考えています。唯一の例外はそれを業務として行う場合だけです。お金をもらうためにバックアップをしているのでない限り、バックアップというのは生産的な行為ではありません。あくまでリスクヘッジのための行為です。往々にしてそういう行為は面倒になって忘れたりサボったりするのが人間です。そして、そういう時に限って障害というのは発生したりするものです。したがって、多少最初に手間やコストがかかっても自動化しておくことが後々のためです。

 

さて、Webサーバとして利用している場合はバックアップをすることも割と容易ですが、ファーストサーバではASPサービスなども行っていたようです。ASPサービスはSaaSとそう変わりません。つまり今はやりのクラウドサービスということになります。クラウドサービスというのはアプリケーションと一緒にデータもクラウド内に預けてしまうのが基本なので、バックアップをどのように行っていくかというのはより難しくなるでしょう。

次回はクラウド時代のバックアップについても考えてみようと思います。

タイトルとURLをコピーしました