データバックアップ　代表的な失敗例

データアックアップの失敗事例

失敗例その１　アクセス速度低下と同時被災によりデータ喪失リスク

A社ではデータ量が多く、バックアップシステムのクラウド化により、保管するデータ量を気にする必要がなくなりました。

ところがアクセス速度に問題があることが発覚しました。システムエラーや回線が混み合っているときには、バックアップの速度が非常に遅くなってしまう時がありました。業務外の時間にバックアップを終えることができず、業務中の時間にまでかかってしまっていました。そのため、社員が業務で使用するアクセスが遅くなる悪循環におちいってしまいますいたのです。

また、本社のある地域で災害が発生した際に、クラウドサーバ化の設置場所も本社から近い場所に置いていただったため、同時被災にあってしまいました。本社で何かあったときのために、すぐに対応できるように本社の近くに設置していましたが、震災などでは多少の距離の遠隔では意味がなかったのですありませんでした。そのため、データバックアップからのデータ復旧が叶わず、業務再開が遅れてしまいました。

失敗例その２　重複排除技術のリスク

B社では、データをバックアップする際に、重複排除技術を取り入れていました。新しいデータのみを付け加えて保存していけば、データ容量の削減や転送時間も短縮につながるからです。実際、その効果は計り知れないものでした。およそ毎回のデータ取り込みを、重複排除技術を取り入れることで、5％しか容量を増やさずに済むことが報告されています。100TBのデータ取り込みが5TBになるのです。

しかし、重複排除技術の運用で満足してしまい、決定的なリスクを見逃してしまっていました。それは、バックアップ先が1つであった場合、そこが喪失すれば、リカバリが効かなくなってしまうというリスクです。データを最小限に集約する必要はありますが、2~3箇所でもその他の媒体にバックアップしていれば、リスクは避けることができていました。

失敗例その３　データ圧縮時のリスク

爆発的に増大し続けるデータバックアップを、効率的に保存していかなければいけません。数年たてば消去することを決めているデータ量よりも、追加されていくデータ量のほうが多くなりがちでしょう。そこで必要なデータバックアップのシステム機能が、データ圧縮でした。

データ圧縮には2種類あり、ソフトウェアによって圧縮するものとハードウェアによって圧縮するものがあります。

ソフトウェアでの圧縮は、CPUを使用して圧縮作業を行うため、その分、業務で使用するタスクの処理速度が低下します。ただ、ストレージの消費を抑えられる可能性もあるため、有用性はあります。

ハードウェアでは、ソフトウェアと異なり圧縮専用チップなどを用いるため、業務で使用するタスクの処理速度が遅くなることはありません。

C社では、設定難易度が低いソフトウェアのデータバックアップを選びました。すると、上記のようなソフトウェアならではのタスク処理速度の低下が問題になってきてしまいました。1日に1回のバックアップであれば、問題視されなかったのですが、C社ではリアルタイムでバックアップする必要があったのです。

また、格納するファイルによっては、データ圧縮が機能しないことがあるということも、事前知識から抜け漏れていました。例えば、JPEGのような画像データやPDFなどが該当します。

このような認識の違いから、C社では、ソフトウェアのデータバックアップを断念し、ハードウェアのデータバックアップに移行し、専門のサポートの手を借りてリプレイスすることになりました。

まとめ：自社にあうデータバックアップのシステムを！

データバックアップの失敗例はいかかでしたでしょうか。たとえ今流行の手法でいて、現在の自社にあうものでも、自社の業務形態が変われば、活用するデータバックアップシステムも取り替える必要がでてきてしまいます。数年後の変化を見極め、導入を検討してみてください。