株式会社アイテック

検討の背景 - NAS バックアップの不具合

アイテックは Phoenix を導入する以前、2台のファイルサーバのバックアップを NAS に取っていました。バックアップ見直しのきっかけは、この NAS のバックアップの不調でした。

「気がついた時には 1ヶ月以上バックアップが完了していませんでした。ファイル数が多く、バックアップに時間がかかっていたようです。ファイルサーバと NAS が物理的に離れていて、トラフィックが不安定だったことも原因の一つでした。」

自社で機器管理をするよりもクラウドの方が手間がなく安全という観点から、「クラウドバックアップ」をキーワードにし、検討を開始しました。

「自社内では AWS を自社で構築したらどうか、という話も出ました。ですが、自社で AWS 上に万全なバックアップシステムを構築するのは手間と費用が非常にかかります。それは現実的ではない、ということで見送りになりました。」

検討から2ヶ月後、様々な最新のクラウドサービスやセキュリティサービスを取り上げるブログで、高評価を得ているクラウドバックアップサービス Phoenix を見つけました。

「まさに探していたようなサービスでした。他にもクラウドへバックアップするサービスはありましたが、Phoenix ほどバックアップに特化し、使い勝手のよいサービスはありませんでした。」

Phoenix のトライアルから運用開始まで

アイテックでは、早速 Phoenix のトライアルを行いました。トライアルの際、特に重視したのは重複排除率と使い勝手、RTO （Recovery Time Objective）の短縮でした。

「グローバル重複排除と、その排除後の容量が課金対象になるという料金体系は、当初から大きな魅力でした。実際に試してみると、重複排除後の容量は、ローカル側の容量よりも 3分の1 から 4分の1 に圧縮されました。無駄な料金が発生しないのは非常に良いです。」

従来の課題となっていた RTO の短縮も、Phoenix なら問題なく行えそうでした。Web 管理コンソールから必要なファイルを選択するだけで復元が完了します。現地での作業や複雑な操作は不要です。

「他のサービスと比べて、管理コンソールが使いやすいことが大きな魅力でした。操作感が優れているだけでなく、バックアップに使用する帯域なども時間や曜日によって調整できるため、自社の運用に合わせた細かい設定が可能です。」

本契約後、2台のファイルサーバに Phoenix エージェントをインストールし、本格的な運用をスタートしました。

「最初のサーバ登録も、ほとんどつまずくことはありませんでした。初回バックアップ中は夜間だけ帯域を大きくし、効率的に完了することができました。従来の NAS の運用では課題となっていたバックアップ時間も、現在は夜11時から始めて、1時間程度で完了しています。」

バックアップ対象を拡大 - テープバックアップから Phoenix へ

ファイルサーババックアップの本契約から 3ヶ月後、アイテックは従来 1ヶ月 2TBだった契約を 5TB に拡張しました。

「基幹サーバのバックアップも Phoenix で取ることにしました。他にも様々なソリューションを検討しましたが、Phoenix が一番コスト的にも機能的にも優れていました。」

基幹サーバは従来、イメージバックアップをテープに取っていました。バックアップの見直しに際して候補となったのは、他データセンターにテープバックアップ装置を設置する方法、同一データセンター内にテープバックアップの装置をハウジングする方法、Phoenix の3つでした。ですが、Phoenix 以外の候補はテープ装置代としての初期費用が Phoenix の2~3年分かかるだけでなく、運用の手間があり、拡張性もありませんでした。

「長い目で見ると、Phoenix の方がメリットがありました。テープバックアップは日々の運用負荷が非常に高く、復元にも不安がありました。」

テープバックアップの従来の運用では、毎週のテープの入れ替えと24時間監視が欠かせませんでした。

「週次でテープを入れ替えなくてはいけないため、毎週データセンターへ赴き、作業をする必要がありました。また、監視チームが24時間体制で監視を行い、何か不具合があったら、データセンターへ確認をしにいかなくてはいけません。」

一方、Phoenix で日々の運用が圧倒的に楽になることは、ファイルサーバのバックアップで確認済みでした。

「Phoenix では、日々必要な操作はありません。アラートに関しても、バックアップエラーなどが起こった時は通知メールが送信されます。これを社内のチャットツールに自動通知される設定にしているため、バックアップの成功可否を確かめるのに、管理コンソールを毎日確認する必要すらありません。」

また、復元もテープバックアップの大きな懸念となっていました。

「実際に復元できるかのテストを頻繁に行えないため、ちゃんと戻るかの確証がありませんでした。また、テープのイメージバックアップをバックアップツールで展開し、そこからさらに復元作業を行う、という複雑な手順が必要になります。前にテスト復元を行った時は、半日以上の時間がかかったということでした。自分たちだけではなく、テープバックアップの事業者も呼ばなくてはいけない可能性もあり、とにかく煩雑でした。」

従来のテープバックアップは、Phoenix のようなファイル単位バックアップではなく、イメージ単位バックアップだったことも課題の一つでした。

「丸ごと戻る、というと良いイメージもありますが、実際は小回りがきかず不便です。実際の復元の要望としては「一部が破損したのでそこだけ戻してほしい」というものが多いのですが、イメージバックアップだと、全て復元しなくてはいけません。Phoenix だと、まず必要なファイルだけを優先的に復元するなど、柔軟な復旧シナリオを実行することが可能です。」

さらに、Phoenix のクラウドならではの可動性も大きなメリットでした。

「ずっとこのデータセンターを使い続けるとは限りません。他のデータセンターや、AWS などのパブリッククラウドへ移行することもあり得ます。テープバックアップだとデータの移動が大変ですが、Phoenix なら、別のサーバや AWS への移行も簡単に行えます。」

今後の展開　クライアントパソコンのバックアップも視野に

サーバ保護の観点からは、サブシステムを含めた全てのサーバを対象にすることを考えています。

「現在バックアップをしている基幹サーバの他に、30台 10TB ほど、業務に必要なサーバがあります。今は同一データセンター内のサーバにバックアップしていますが、こちらもゆくゆくは Phoenix でバックアップしたいと考えています。」

またサーバだけでなく、クライアントパソコンのバックアップも Druva 社の inSync で取得することを視野に入れています。

「ファイルサーバにデータを入れる運用にはしていますが、やはりパソコンにデータは残っています。会社がバックアップを行わないと、自分で外部サービスを使ってバックアップを行う社員が出てきてしまい、統制の面で問題があります。またバックアップ方法を社内で統一した方が、データ管理も楽になります。Phoenix と同様、inSync もデータ移行が簡単なため、パソコンの入れ替えも簡単になります。」

特にアイテックは、ISMS の遵守や内部統制、コンプライアンス対策のため、遠隔地バックアップや万全なデータ管理が必要となります。inSync では、退職者データの管理や BYOD、テレワーク社員のデータ管理などが可能です。