ケース2統合バックアップ環境を整備したものの
……サイジングの落とし穴
舞台は、都市部を中心に多くの店舗を展開する、中堅小売業の情報システム部。システム基盤はデータセンターのラックを借りて運用しており、ここから各店舗や取引先、顧客などへのサービスを提供している。さまざまな規模のシステムが混在しており、それぞれ個別にバックアップを行っていたため、ジョブやデータの管理に伴う情報システム部門の負担は大きかった。個々のバックアップデータの健全性チェックなどに割く時間も確保できず、確実に復旧できるかどうかの確証も得られずにいたほどだ。
情報システム部長は、このような状況を打開し管理を効率化させ、定期的な健全性チェックなども行えるようにと、バックアップ統合を決断した。統合に向けて新たなバックアップソフトを選定する一方、コストを抑えるためサーバは自社でサイジングして構築するという計画だ。将来的なデータ増加に備えてバックアップサーバのディスク容量には拡張の余裕を持たせたものの、コストを抑えるため他の仕様は控え目に設定した。そして入念な準備のおかげで導入も無事に完了し、運用を開始するとバックアップジョブやデータの管理負担も大幅に軽減されている。
情報システム部ではさらに、新たに導入したバックアップソフトに備わっている重複排除機能の活用も計画していた。空き容量に余裕を作ってバックアップ世代数を増やしたり、将来的に検討したりしているクラウドバックアップにおいて回線帯域を節約するといった効果を期待したものだ。
ところが、いよいよその重複排除をオンにしてみた情報システム部は、予想外の問題に直面することになったのである。一体それは、どういうことだったのか？
ダイジェスト
情報システム部が陥った落とし穴とは？
- 重複排除処理の負荷でバックアップジョブ所要時間が大幅に伸びてしまった
- 通常ではありえないほどの時間がかかり、通常業務に支障が出てしまうほど
- 処理の遅延を招いたのは、選定時の思わぬ落とし穴だった
- 重複排除を使えるようにするためには、追加投資が必要だと判明
- バックアップに関する将来的な計画は凍結を余儀なくされる
情報システム部は、どのような選択をすべきだったのか？