概要
- FalconStor の価値は、回復記録によって最もよく判断される。すなわち、バックアップカタログ、仮想テープメディア、レプリケーション状態、不変コピー、およびオペレーター手順が、障害、ランサムウェア、または移行の圧力の下で、受け入れ可能なリストアを生成できるかどうかである。
- StorSafe の適合性は、企業、マネージドサービスプロバイダー、および IBM Power チームが、ストレージコストを削減し、クラウド保持を追加し、またはワークロードを移動させながら、使い慣れたバックアッププロセスを維持する必要がある場合に最も強くなる。ただし、この製品は、リストア訓練、カタログの規律、ネットワーク計画、サポート境界、およびコストガバナンスの必要性を取り除くものではない。
回復記録こそが真の製品である
バックアップソフトウェアは、リカバリーが始まるまでは単なる安心感に過ぎない。スケジュールされたジョブは完了し、ストレージターゲットは重複排除を行い、オフサイトコピーはコンソールに表示され、クラウドバケットは正常なオブジェクトを報告するかもしれない。これらの事実のどれも、それだけではビジネスが依存するシステムを再起動できることを証明しない。重要な瞬間にチームが必要とするのは、回復記録である。すなわち、特定のワークロードを使用可能な状態に戻すことができることを示す、カタログエントリー、仮想メディア、レプリケーションチェックポイント、資格情報、ネットワーク経路、リストア手順、検証ノート、およびビジネス受領のセットである。
これが FalconStor Software を評価する際の枠組みである。同社は、プライマリアプリケーション、データベース、クラウドプラットフォーム、またはインシデント対応プログラム全体を販売しているわけではない。データ保護を最適化し、テープライクなバックアップフローを仮想化し、バックアップイメージを重複排除し、保護データを複製し、保持用コピーをオブジェクトストレージに配置し、オンプレミスシステムとクラウドまたはマネージドサービス環境の橋渡しを支援するソフトウェアとサービスを販売している。問われるべきは、FalconStor がバックアップデータを受け取れるかどうかではない。問われるべきは、その連鎖の中での位置づけが、顧客が回復を証明するのに十分な真実を保持しているかどうかである。
この区別が重要なのは、FalconStor がバックアップシステムが古く、手続き的で、政治的に変更が難しい環境で動作するからである。IBM i、AIX、Linux on IBM Power、長期にわたるテーププロセス、BRMS の習慣、Fibre Channel や iSCSI リンク、クラウドオブジェクトストレージ、マネージドサービスプロバイダー、そして災害復旧演習は、グリーンフィールドの SaaS デプロイメントのようには振る舞わない。バックアッププロセスは単なる技術ではない。それは、システムの例外、月末スケジュール、ネットワークウィンドウ、保持ルール、テープラベル規則、そして最新のコピーがクリーンかどうかを尋ねるエグゼクティブを熟知した管理者によって所有される、繰り返しの生産儀式である。
FalconStor の機会は、すべての顧客にその儀式を書き換えさせることなく、その儀式を近代化することにある。StorSafe は、クラウド、物理、仮想環境で動作し、既存のバックアップソフトウェアと連携し、テープライブラリをエミュレートし、重複排除によって冗長なバックアップデータを削減し、オブジェクトストレージへの長期アーカイブをサポートし、IBM Power チームがバックアップ、災害復旧、移行にクラウドターゲットを使用できるよう支援するソフトウェアとして提示されている。StorSight は、StorSafe インスタンス全体の集中管理を追加する。Habanero は、同じロジックを、基盤インフラをすべて自分で展開・運用することなく、安全なオフサイトコピーを求める IBM Power 顧客向けのマネージドオフサイト保護サービスへと拡張する。
魅力は明らかだ。銀行、製造業、医療機関、マネージドサービスプロバイダー、または IBM Power ワークロードを実行する地域企業は、何年もシステムを保護してきた運用バックボーンを置き換えたくないかもしれない。それでも、より優れたランサムウェア耐性、より低いストレージコスト、IBM Power Virtual Server への経路、より迅速なオフサイト保持、あるいは物理テープだけが唯一の答えであるかのように扱うのをやめる方法を必要としているかもしれない。FalconStor の売りは、プロセスの背後に位置し、データを馴染みのある形で受け入れ、それを縮小し、複製し、移動させ、オンプレミスとクラウドターゲットにわたって管理可能にすることができるという点である。
リスクも同様に明らかだ。回復チェーンは、その中で最もテストされていない仮定と同じ強さしかない。重複排除は容量を節約できるが、リポジトリの整合性とインデックスの可用性を極めて重要にする。仮想テープはプロセスの親しみやすさを保つことができるが、これまで適切にテストされてこなかった古い習慣も保存しかねない。クラウド保持はハードウェア負担を軽減できるが、ネットワーク、オブジェクトストレージ、エグレス、アイデンティティ、リージョンの決定を導入する。不変性はコピーを改変から保護できるが、そのコピーがすでに汚染されていたか、不完全だったか、不適切にカタログ化されていたか、依存関係を欠いていたかを判断することはできない。マネージドサービスはスタッフ負担を軽減できるが、信頼をサービス条件、運用の透明性、エスカレーション品質、ベンダーの継続性に移転する。
したがって、FalconStor を汎用的なバックアップベンダーとして評価すべきではない。同社のソフトウェアが、保存されたコピーと受け入れられた回復の間の最終マイルに挿入される企業として評価すべきである。重要な証拠は運用上のものだ。すなわち、バックアップイメージがどのようにシステムに入り、カタログがどのように使用可能に保たれ、レプリケーション完了がどのように監視され、オフサイトコピーがどのように不変化または保護され、管理者がどのようにリストア経路を証明し、移行実行がどのようにダウンタイムを回避し、重複排除ストレージ、クラウドオブジェクトストレージ、ネットワーク転送、サポート、スタッフ時間を合わせたコストがどのように推移するかである。
FalconStor が実際に自動化するもの
FalconStor の中核的な自動化は、抽象的な「バックアップの実行」ではない。多くの顧客環境では、バックアップアプリケーションはすでに存在している。ジョブスケジューラ、データベース保存プロセス、BRMS ルーチン、テープポリシー、保持ルール、リストアコマンドは、すでに長年の運用に組み込まれている可能性がある。FalconStor の自動化は、それらのバックアップストリームがより良いターゲットと、回復可能性へのより安全な経路を必要とする地点から始まる。
第一のタスクは取り込みである。StorSafe は、仮想テープライブラリとして振る舞うか、あるいは既存のアプリケーションやシステムからバックアップデータを受け取ることができる。IBM Power ユーザーにとってこれが重要なのは、多くの運用プロセスがテープのセマンティクスに基づいて構築されてきたからだ。VTL の目的は懐古趣味ではない。リスク低減である。バックアップ管理者が既知の保存プロセスを維持し、それをソフトウェアターゲットに向け、すべてのオペレーターを一度に再訓練する必要がなければ、近代化の負担は低くなる。これは商業的に強力であり、特に一人か二人の経験豊富な管理者がリストア知識の大半を担っている中小チームにおいて顕著である。
第二のタスクはデータ削減である。バックアップストリームはしばしば高度に冗長である。日次コピーは、同じオペレーティングシステム、アプリケーション、データベース、ログ、ファイル内容の多くを含んでいる。FalconStor は大幅な重複排除能力を主張しており、公式資料では適切な条件下で最大95%のデータ削減が繰り返し説明されている。この主張の有用な読み方は、すべての環境でそれが達成されるわけではないということだ。重複排除が FalconStor の経済的ケースの中心にあるということである。顧客がセカンダリストレージやクラウドオブジェクトストレージに移動するボリュームを削減できれば、容量コスト、帯域需要、バックアップウィンドウのプレッシャー、長期保持コストを削減できる可能性がある。
第三のタスクは移動である。本番システムの隣に残る保護コピーは、サイト障害にさらされ、攻撃者の到達範囲にさらされる可能性がある。FalconStor の資料は、レプリケーション、オフサイト保護、クラウドアーカイブ、ハイブリッドクラウド採用を強調している。IBM Power 環境では、これは多くの場合、重複排除されたバックアップデータを IBM Cloud Object Storage、PowerVS、別のクラウドサポートロケーション、またはマネージドサービスセットアップに移動することを意味する。ここで回復記録がより複雑になる。バックアップジョブが終了したことを知るだけではもはや不十分である。チームは、どのコピーが移動したか、レプリケーションが完了したか、ターゲットが到達可能だったか、保持ポリシーが適用されたか、ターゲット環境からのリストア経路がたどられたかを知らなければならない。
第四のタスクは管理である。StorSight は、管理、レポート、分析、予測、アラート、テナンシースタイルの制御を含め、StorSafe インスタンス全体の可視性を統合することを意図している。これは、複数の保護ターゲットが運用上不可視になりうるために重要である。プライマリサイトの VTL、PowerVS 内のもう一つの VTL、オブジェクトストレージリポジトリ、MSP 管理サービス、そしていくつかのバックアップアプリケーションが断片化された環境を作り出す可能性がある。単一の管理面は回復可能性を証明するものではないが、バックアップと保持状態がどこにあるかを把握する監視コストを削減できる。
第五のタスクは保持の強化である。FalconStor は、不変ストレージ、WORM スタイルの仮想テープ、暗号化、クラウドオブジェクトストレージ統合をランサムウェア対策の一部として位置付けている。最も良い解釈は具体的である。これらの制御は、後の改ざんや削除から回復ポイントを保護するのに役立つ。それ自体では、クリーンルームの準備状況、再構築シーケンス、アイデンティティ回復、アプリケーション整合性、あるいは管理者がどの時点がクリーンかを知るかどうかを決定しない。回復された状態は、ストレージのアーティファクトであるだけでなく、ビジネスのアーティファクトである。
第六のタスクは移行である。FalconStor の IBM との関係と製品資料は、移行に中心的な役割を与えている。IBM i、AIX、または Linux ワークロードを PowerVS または別のサポートされたクラウドコンテキストに移行する顧客は、大量の保護データと過去のバックアップメディアを、その移行を特注のコンサルティングプロジェクトに変えずに運ぶ必要があるかもしれない。仮想テープと重複排除レプリケーションは、その経路をより秩序だったものにできる。しかし、移行は最も困難な種類の回復テストである。なぜなら、ターゲット環境がソースと異なるからだ。成功する移行には、データ移動だけでなく、ブート可能性、ネットワーク到達可能性、アプリケーション整合性、アイデンティティ、バッチスケジュール、周辺依存関係、監視、およびロールバック計画が必要である。
これら六つのタスクが FalconStor の実用的な価値を定義する。それは、バックアップ規律全体を取り替えるものというより、古くハイブリッドな回復チェーンのための近代化レイヤーである。顧客が自らの保存プロセス、リストア依存関係、コンプライアンス義務をよく知っていればいるほど、FalconStor を梃子の支点として使用できる。それらを知らなければ知らないほど、FalconStor は、実際の回復記録が不完全なままであるのに、グリーンと報告する別のシステムになる危険性がある。
IBM Power が角度をより鋭くする理由
FalconStor の現在の市場ストーリーは、IBM Power と密接に結びついている。同社は最近の製品および投資家向けメッセージングで、IBM Power、PowerVS、IBM Cloud Object Storage、MSP、チャネル提供を強調している。IBM 自身のパートナーおよびクラウドドキュメントも、FalconStor VTL を Power Virtual Server コンテキスト向けの最適化されたバックアップおよび重複排除ソリューションとして説明しており、テープライブラリエミュレーション、S3 クラウドアーカイブ、グローバル重複排除、レプリケーション、コンテナアーカイブ機能を挙げている。
この焦点は偶然ではない。IBM Power エステートはしばしばミッションクリティカルで、長寿命で、運用が保守的である。それらは中核的な銀行業務、保険、流通、製造、小売、物流、または医療のワークロードを実行している可能性がある。その多くは、流行のクラウドネイティブになろうとしているわけではない。すでに機能しているシステムの信頼性を維持しながら、より良いオフサイト保護、より柔軟な災害復旧、そしてハードウェアリフレッシュ、データセンター変更、または事業継続計画が必要なときにクラウド容量への道筋を自分たちに与えようとしているのである。
まさにそこが、回復記録のレンズが有用になる場所である。単純なクラウドアプリケーションでは、バックアップの近代化はスナップショット、マネージドデータベース、または組み込みのサービスレプリケーションを中心に組み立てられるかもしれない。IBM Power 環境では、運用の現実は異なる。ワークロードは、IBM i の保存操作、BRMS ルーチン、AIX ファイルシステム、アプリケーション固有の一貫性ポイント、テープライクな保持期待、そして特定のリストア手順を何年も使ってきた管理者を含むかもしれない。方法全体を置き換えることは、背後にあるターゲットを改善するよりも危険になりうる。
したがって、FalconStor の IBM 関連の主張は、単に技術的な互換性だけではない。それはプロセスの継続性についてである。StorSafe は、既存のバックアップおよび回復プロセスが馴染み深いままであるように、仮想テープターゲットとして導入できる。これは、スタッフの能力が限られており、組織が長期の再訓練期間を許容できない場合に重要である。また、顧客ごとの一回限りのエンジニアリングではなく、複数のクライアント環境にわたって反復可能なパターンを必要とするマネージドサービスプロバイダーにとっても重要である。
同じプロセスの継続性は、悪い規律を保護する場合、弱みになりうる。チームが定期的にリストア手順をテストしてこなかった場合、より効率的な VTL を導入してもそのギャップは修正されない。バックアップオペレーターが、どのビジネスサービスがどのテープセット、データベース保存、アプリケーション設定、DNS エントリ、アイデンティティプロバイダーに依存しているかをマッピングできなければ、重複排除はそのマップを作成しない。リストアランブックがローカルのテープライブラリを前提としているが、新しい回復ターゲットがクラウドホストの PowerVS 環境である場合、チームは古い手順が依然として使用可能なシステムを生成することを検証しなければならない。
これが、受け入れられた回復記録がバックアップカバレッジよりも優れたテストである理由である。バックアップカバレッジは、適切なシステムが含まれているかどうかを問う。回復記録は、命名されたサービスが、命名された時点、命名された場所、既知の資格情報、既知の依存関係、測定された経過時間、文書化されたビジネス受領をもってリストアできるかどうかを問う。FalconStor は、その記録のための技術的条件を作り出すのを助けることができる。その記録を維持する顧客の責任を置き換えることはできない。
IBM Power はまた、ユニットエコノミクスを鋭くする。バックアップ近代化プロジェクトの価値は、ハードウェアリフレッシュ、テープ処理、ストレージ増大、ダウンタイム、クラウド移行の労力、コンプライアンス違反、ランサムウェア回復の混乱といった回避コストに依存する。StorSafe が保存または移動されるバックアップデータ量を削減し、既存の保存プロセスをサポートし、PowerVS へのサポートされた経路を開くならば、経済性は説得力のあるものになるかもしれない。環境が小さく、変化に抵抗的で、軽くテストされており、よりシンプルなバックアップメカニズムを使用できる場合、同様のライセンスと運用オーバーヘッドを正当化するのは難しいかもしれない。
FalconStor の2025年および2026年の財務メッセージングは、同社が経常収益、マネージドサービスプロバイダー採用、ハイブリッドクラウドの年間経常収益成長へとシフトしていることを示している。これは重要である。なぜなら、回復インフラを評価する顧客は、ベンダーの継続性も評価するからだ。回復プラットフォームは使い捨てのツールではない。それは監査証跡、サポートエスカレーション、運用の筋肉記憶、更新計画の一部となる。FalconStor の経常収益および MSP 主導モデルへの移行は、同社にとって予測可能性を改善するかもしれないが、顧客は更新エクスポージャー、サービス範囲、専門知識の長期的な可用性を理解する必要があることも意味する。
クリーンなリストアの背後にある繰り返される作業
FalconStor の価値を決定する作業は反復的で地味である。それはインシデントの前に始まる。管理者は、何が保護されるか、どのくらいの頻度で保存されるか、どのバックアップアプリケーションがジョブを所有するか、仮想メディアがどこに置かれるか、重複排除リポジトリのサイズはどのように決まるか、どのリンクがレプリケーショントラフィックを運ぶか、どのオブジェクトストレージバケットまたはストレージデバイスがデータを保持するか、どの保持制御が適用されるか、誰がポリシーを変更できるかを定義しなければならない。これらの決定はプロダクションワークである。それらは一回限りのデプロイメントノートではない。
すべてのバックアップサイクルは、一連の記録を作り出す。プライマリシステムは一貫性のある保存を作成しなければならない。バックアップアプリケーションは完了しなければならない。StorSafe または関連するターゲットはデータを取り込まなければならない。重複排除は意図されたモードで終了しなければならない。カタログは一貫性を保たなければならない。レプリケーションまたはアーカイブは完了しなければならない。アラートはレビューされなければならない。容量トレンドはチェックされなければならない。失敗したジョブは、次の障害がその失敗をデータ損失に変える前に調査されなければならない。これは日々の回復可能性の製造である。
FalconStor のソフトウェアはその連鎖の一部を自動化できるが、それ自身の状態も追加する。リポジトリ、インデックス、設定データ、ネットワーク接続性、管理サービス、サポートされるオペレーティングシステムバージョン、ライセンス登録、ストレージ互換性、サポートポリシーがある。IBM Power 向けの公式デプロイメント資料は、サイジング、IBM Cloud アクセス、オブジェクトストレージ資格情報、StorSight インストール、ネットワーク設計、iSCSI または Fibre Channel の知識、セキュリティ計画の必要性を明示することで、これを明確にしている。それらは些細な前提ではない。それらはスキルの境界である。
監督コストは製品間の隙間に存在する。バックアップ管理者はジョブスケジュールを所有するかもしれない。ストレージ管理者はリポジトリ容量を所有するかもしれない。ネットワークチームは Direct Link、VPN、VLAN、またはレプリケーションパスを所有するかもしれない。クラウドチームはオブジェクトストレージ、資格情報、キー、リージョン、請求を所有するかもしれない。セキュリティチームは不変性、特権アクセス、ランサムウェア隔離、監査要件を所有するかもしれない。アプリケーション所有者は受け入れテストを所有するかもしれない。FalconStor は中間の摩擦を減らすことができるが、それでも誰かがそれらの所有者にわたって記録を調整しなければならない。
その調整は、ランサムウェアにとって特に重要である。セキュリティ当局からの公開ガイダンスは、オフラインまたはその他の方法で保護されたバックアップと、バックアップの可用性と整合性の定期的なテストを強調している。教訓はシンプルだ。攻撃下で信頼できないバックアップは、回復計画ではない。FalconStor の不変およびオフサイトコピー機能は、ランサムウェアのオペレーターがしばしばバックアップシステムを探し出し、到達可能なコピーを削除または暗号化し、被害者を時間的プレッシャーのある決断に追い込むため、関連性がある。WORM スタイルまたは不変コピーは、防御側の立場を改善できる。しかし、ランサムウェアからの回復には依然として、クリーンな時点の選択、信頼できるインフラの再構築、アプリケーションデータの検証、依存関係の再接続、再感染の回避が必要である。
同じパターンが移行にも当てはまる。FalconStor の仮想テープアプローチは、バックアッププロセスの完全な再設計を必要とせずに、レガシーバックアップメディアや保護されたワークロードをクラウドインフラストラクチャに移動させることができる。しかし、受け入れられた記録は、移動されたワークロードが起動し、ユーザーが到達でき、バッチプロセスが実行され、コンプライアンス保持が損なわれず、古いメディアが必要なときに依然として読み取れ、カットオーバーが失敗した場合にロールバックが可能であることを示さなければならない。危険は、データ移動を移行の成功と見なすことである。データ移動は原材料である。機能するサービスが結果である。
マネージドサービスプロバイダーにとって、繰り返される作業は変化するが消えはしない。MSP は、デプロイメント、監視、オフサイト保持、顧客レポートを標準化できる。これは、深い IBM Power および回復の専門知識を社内に保持できない小規模チームにとって魅力的でありうる。Habanero のマネージドサービスの枠組みは、予測可能な価格設定と管理された運用でオフサイト保護を約束することにより、このニーズに適合する。しかし、顧客は依然として、サービスが何をカバーするか、どのような回復シナリオが含まれるか、どのようなリストアテストの頻度が利用可能か、サポートエスカレーションの速さはどうか、顧客側の資格情報とアプリケーション依存関係がどのように処理されるか、監査人や経営陣向けにどのような証拠が生成されるかを知る必要がある。
したがって、最も強力な FalconStor のデプロイメントは、製品が規律ある運用ループの一部となるものである。それは、確立された手順を不安定にすることなくバックアップストリームを受け取る。保持の経済性を変えるのに十分なほどストレージと転送コストを削減する。オペレーターが理解できる方法でコピーを複製し保護する。盲点を減らすのに十分な状態を公開する。リストア訓練に含まれる。明確なサポート境界を持つ。クリーンなデモンストレーションだけでなく、実際の障害に似たシナリオの下でテストされる。
コピー数ではなく、カタログの真実
バックアップで最も犯しやすい間違いは、コピーを数えて真実を無視することだ。企業はローカルコピー、オフサイトコピー、クラウドコピー、不変コピー、月次アーカイブコピーを持つかもしれない。しかし、リストアが始まるとき、重要な質問はより狭い。どのコピーが必要なデータを含んでいるか？どのカタログエントリがそれを記述しているか？どのアプリケーションバージョンがそれを読み取れるか？どのキーがそれを解除するか？どのリポジトリインデックスがそれを再構築できるか？どの仮想テープがビジネスサービスに対応するか？どのネットワークパスがそれを回復目標内に戻せるか？誰が手順をリハーサルしたか？
FalconStor の製品境界は、カタログの真実を中心的なものにする。StorSafe はしばしば、上流のすべての記録を置き換えるのではなく、既存のエンタープライズバックアップアプリケーションと並んで動作する。つまり、複数のカタログやインベントリ概念が存在しうる。バックアップアプリケーションのカタログ、仮想テープビュー、StorSafe 自身のリポジトリおよび管理情報、オブジェクトストレージのメタデータ、そして任意の MSP または顧客レポート層である。回復記録は、これらのビューを調整しなければならない。
ビューがずれれば、リストアは探索作業になりうる。バックアップアプリケーションは仮想テープが存在すると思うかもしれない。仮想テープはデータがオブジェクトストレージに移動されたためにスタブ化されているかもしれない。オブジェクトストレージのコピーは別の資格情報によって管理されるリージョンまたはバケットにあるかもしれない。重複排除インデックスは特定のストレージの健全性を必要とするかもしれない。クラウドルートが変更されているかもしれない。元のマッピングを理解していたスタッフが去っているかもしれない。これらのどれも FalconStor が弱いことを意味しない。それは、製品がメタデータの規律が回復と遅延の違いとなるインフラストラクチャの部分に存在することを意味する。
FalconStor 自身のサポートおよび認証資料は、この運用上の現実を強化する。同社はハードウェアとソフトウェアの組み合わせに関する認証マトリックスを維持しており、正確なサイトバージョンがテストされた組み合わせと異なる可能性があることに注意している。サポート資料はまた、テクニカルサポートをデプロイメント作業、ネットワークトラブルシューティング、ストレージ設定、メジャーバージョンアップグレードから区別している。これらの境界はエンタープライズソフトウェアでは普通だが、経済的に重要である。ベンダーがすべての環境問題を所有すると仮定する顧客は、デプロイメントのコストを誤って見積もるかもしれない。認証、バージョン整合、プロフェッショナルサービスを回復システムの一部として扱う顧客は、より良く準備されるであろう。
したがって、受け入れられた回復記録は、ベンダーとバージョンのコンテキストを含むべきである。どの StorSafe バージョンが使用されているか、どのバックアップアプリケーションとオペレーティングシステムが認証されているか、どのストレージデバイスまたはオブジェクトストレージターゲットが使用されているか、どのクラウドリージョンがオフサイトデータを保持しているか、どの保持制御が有効か、どのサポートプランが適用されるか、どのプロフェッショナルサービスが使用されたか、どのリストアテストが完了したか、を記述すべきである。その記録がなければ、組織は証明可能な回復態勢ではなく、有望なコンポーネントの集まりを持つことになる。
ここでも FalconStor の小規模企業としてのプロフィールが重要になる。同社は長いエンタープライズストレージの歴史を持つが、ハイパースケールのクラウドプロバイダーでも巨大なバックアップスイートベンダーでもない。最近の財務リリースは、控えめな収益基盤からの経常収益成長と運営規律を強調するビジネスを示している。これは、集中した顧客にとって強みになりうる。専門的な注意、IBM Power の専門知識、MSP アライメント、特定の運用上の痛点のために設計された製品。また、リスクにもなりうる。顧客は、サポート能力、製品ロードマップの継続性、パートナーカバレッジ、バックアップエステートの寿命にわたる熟練した実装者の可用性に自信を持つ必要がある。
ベンダーの継続性は、回復において抽象的な調達問題ではない。重複排除リポジトリ、VTL フォーマット、管理システム、またはクラウド保持モデルがコンプライアンスと災害復旧の実践に埋め込まれると、プラットフォームからの退出は骨の折れる作業になりうる。バックアップターゲットからの移行は、それ自体がリカバリーに似たプロジェクトである。したがって顧客は、「FalconStor はストレージコストを削減できるか？」だけでなく、「FalconStor との関係が変わったり、MSP が変わったり、クラウド戦略が変わった場合に、保護されたデータを回復または移行できるか？」と問うべきである。答えは受け入れ可能かもしれないが、システムが古いバックアップメディアへの唯一の実用的な経路になる前に、文書化されるべきである。
ランサムウェアがバックアップの意味を変える
ランサムウェアは、バックアップを日常的な継続性の実践から敵対的な制御へと変えた。攻撃者は本番データの暗号化で止まらないかもしれない。攻撃者はバックアップコンソール、管理者資格情報、ストレージバケット、レプリケーションターゲット、保持ポリシーを探すかもしれない。したがって、最良のバックアップターゲットは単に効率的であるだけではない。改ざんが困難で、ストレス下で観測可能で、テストされたリストアプロセスに結びついていなければならない。
FalconStor のランサムウェア関連性は、いくつかの機能から来る。オフサイト保持、不変ストレージ統合、WORM スタイルの仮想テープ、暗号化、レプリケーション、そしてプライマリ環境の外に保護コピーを保持する能力。これらは意味のある機能である。攻撃者が本番ホストと到達可能なバックアップストレージを侵害した場合、保護されたオフサイトコピーは、交渉と再構築の違いになりうる。保持ロックが、特権ユーザーでさえ保持期間中にコピーを変更するのを防ぐなら、防御側はより強力なアンカーを得る。
しかし、ランサムウェアはストレージ中心の言葉の限界も露呈させる。保護されたコピーは不変でありながら、すでに暗号化されたデータのコピーであるかもしれない。バックアップはクリーンであるが、アクセスに必要なアイデンティティサーバーを見逃すかもしれない。データベースはリストアできるが、アプリケーションファイルやメッセージキューと不整合のままかもしれない。クラウドコピーは存在するが、帯域幅、エグレスコスト、またはターゲットのコンピュート容量が計画されていなかったために、取得に時間がかかりすぎるかもしれない。仮想テープは利用可能だが、カタログや互換性がずれていれば、期待されるバックアップソフトウェアバージョンで読み取れないかもしれない。
だからこそ、回復記録には技術的な証拠だけでなく、決定の証拠も含まれなければならない。どの時点がクリーンとして選択されたか？どのようなマルウェアの潜伏期間の仮定が使用されたか？アイデンティティ、DNS、証明書、ジョブスケジューラ、ファイル共有、監視は含まれていたか？リストアは再接続前に隔離された環境で実行されたか？アプリケーション所有者はデータを受け入れたか？法務、コンプライアンス、経営陣は予想されるデータ損失ウィンドウを理解していたか？FalconStor は、特にバックアップメディアの保存と移動に関して、その記録に貢献できるが、ビジネス上の決定を単独で下すことはできない。
Habanero とクラウドクリーンルームスタイルの言葉は、FalconStor がこのより広範な回復信頼問題に向かっていることを示している。IBM Power 向けのマネージドオフサイトサービスは、コアワークロードを完全にクラウドに移行しようとしているわけではないが、安全でコンプライアント、耐障害性のあるオフサイトコピーを必要とする顧客にとって、実際のギャップに対処する。この提供は商業的に理にかなっている。多くの IBM Power チームは限られたスタッフと高い継続性要件を持っているからだ。予測可能な価格と管理された運用は、オフサイト保護を適切に行うための障壁を下げることができる。
注意点は、マネージドオフサイト保護はリストアの証拠によって判断されなければならないということだ。顧客は、どのくらいの頻度でリカバリーテストが行われるか、テストリストアが含まれるか別料金か、回復ターゲットがどのようなものか、どのようなサービスレベルコミットメントが適用されるか、ソブリンストレージ要件がどのように処理されるか、キーと顧客資格情報がどのように管理されるか、インシデントエスカレーションがどのように機能するか、テスト後にどのような証明が提供されるかを尋ねるべきである。オフサイトコピーを保存するサービスは価値がある。再現可能な回復記録を生み出すサービスは、より価値がある。
ストレージの経済性は現実的だが条件付きである
FalconStor の経済的ケースはデータ削減から始まる。バックアップデータは冗長であり、冗長なデータを削減することで容量、帯域幅、クラウド保持コストを下げることができる。公式資料は、好条件下で最大95%を含む大きな削減可能性を繰り返し説明しており、同社はしばしばこれらの削減をより低いストレージおよび転送コストに結びつけている。IBM 関連の資料も、オブジェクトストレージを重複排除リポジトリまたはアーカイブ層として使用することを説明しており、これにより専用バックアップアプライアンスや物理テープ運用と比較してコストモデルが変わりうる。
経済性はもっともらしいが、条件付きである。重複排除は、ワークロードタイプ、バックアップ頻度、変更率、圧縮、取り込み前の暗号化、保持パターン、および同様のデータが同じリポジトリによって見られるかどうかに依存する。大幅に変更されるデータベース、バックアップ前に圧縮または暗号化するアプリケーション、またはデータを多くの小さなドメインに隔離する保持モデルでは、ベンダーの見出しよりも低い削減率になるかもしれない。顧客は平均的な主張を購入するのではなく、自らの実際のデータをモデル化すべきである。
クラウドの経済性には、ギガバイトあたりのストレージ以上のものが含まれる。ネットワーク接続性、オブジェクトストレージクラス、取得頻度、API 操作、エグレス、レプリケーション、リージョン間移動、リストア用コンピュート、サポート、セキュリティツール、そしてスタッフ時間がある。保存するのが安いバックアップコピーは、スケールで回復するには高価または遅いかもしれない。ランサムウェアインシデントでは、大量のデータを迅速に引き出し、複数のポイントをテストし、システムが再構築される間追加のコンピュートを稼働させておく必要があるかもしれない。したがって、回復記録にはストレージの請求書だけでなく、コストを考慮したリストアシナリオが含まれるべきである。
FalconStor の移行価値も同様に条件付きである。組織がサービス終了のハードウェア、テープライブラリの負担、データセンターの撤退、PowerVS への移行、または MSP への移行に直面している場合、StorSafe はレガシーバックアップメディアと既存のプロセスを新しいアーキテクチャで有用にすることができる。再水和の回避、大規模なランディングゾーンの回避、または馴染みのあるバックアップワークフローの維持は、実際の節約を生み出すことができる。しかし、顧客がすでに直接的なクラウド回復を備えた別の最新のバックアッププラットフォームに標準化している場合、または Power エステートが小さく安定している場合、増分価値はより狭いかもしれない。
ライセンスとベンダーの継続性も同じ計算に含まれる。FalconStor の経常収益と MSP チャネルへの移行は、サービススタイルの消費に対する顧客の需要と一致するかもしれない。それはまた、回復インフラを更新ガバナンスを必要とする経常運営費に変えるかもしれない。顧客は、価格が容量、保護されたテラバイト、サービス層、クラウドストレージ、MSP バンドル、サポートレベル、またはプロフェッショナルサービスに結びついているかを知るべきである。また、データをどのようにエクスポートできるか、古い仮想メディアがどのくらいの期間読み取り可能であり続けるか、インシデント中にライセンスが失効したら何が起こるかを知るべきである。
スタッフの計算が最も重要かもしれない。バックアップ近代化プロジェクトが失敗するのは、多くの場合、ストレージターゲットが悪いからではなく、組織が人的作業を過小評価するからだ。すなわち、インベントリ、クリーンアップ、サイジング、ネットワーク設計、アクセス制御、保持ポリシー、リストアテスト、アプリケーションマッピング、文書化、運用引き継ぎである。FalconStor はストレージとプロセス変更の負担を軽減できるが、それらのタスクを排除するわけではない。小規模なチームでは、リストア訓練や文書化に資金を提供せずにより効率的なターゲットを購入することは、単により高度な盲点を作り出すかもしれない。
代替品はすべて同じではない
FalconStor はいくつかの種類の代替品と競合し、それぞれが回復記録を異なる形で変える。第一の代替品は、ハードウェアバックアップアプライアンスまたは従来の重複排除ターゲットである。それは馴染み深く、ローカルで高速で、運用上成熟しているかもしれないが、リフレッシュに費用がかかり、クラウド環境での柔軟性が低く、オンプレミスと PowerVS コンテキストにわたるソフトウェア定義のデプロイメントにはあまり適していない。FalconStor のソフトウェアベースのアプローチは、ハードウェアロックインやアプライアンスの寿命末期が問題の一部である場合に最も強力である。
第二の代替品は、幅広いエンタープライズバックアップスイートである。そのカテゴリーのベンダーは、深いアプリケーション統合、オーケストレーション、不変リポジトリ、クラウド回復、大規模なサポートエコシステムを提供するかもしれない。すでにそのようなスイートに標準化している顧客にとって、FalconStor はターゲット、ブリッジ、または IBM Power スペシャリストとしての役割を正当化しなければならない。議論は、「すべてのエンタープライズが別の層を必要とする」ではない。一部のエステートは、一般的なスイートではエレガントに解決できないかもしれない VTL 形状の近代化経路と IBM Power カバレッジを必要とするということだ。
第三の代替品は、ネイティブクラウドバックアップとレプリケーションである。純粋にクラウドネイティブなエステートでは、プラットフォームはスナップショット、マネージドデータベースバックアップ、オブジェクトバージョニング、クロスリージョンレプリケーション、Infrastructure as Code のリカバリーを提供するかもしれない。それは VTL 層を挿入するよりもシンプルでありうる。しかし、FalconStor の顧客の多くは純粋にクラウドネイティブではない。彼らはハイブリッドで、レガシーに富み、Power 中心である。ネイティブクラウドサービスは、特に出発点が IBM i の保存/リストアの実践、履歴テープ、またはオンプレミスと PowerVS の混在した回復設計である場合、彼らの運用の現実を理解しないかもしれない。
第四の代替品は物理テープである。テープは長期保持、エアギャップ規律、特定のコンプライアンスやコストニーズに関連性を持ち続けている。適切に管理されれば堅牢でありうる。また、遅く、手動で、エラーが発生しやすく、迅速なクラウド回復と統合するのが難しいこともある。FalconStor の仮想テープアプローチは、テープのセマンティクスを維持しながら、一部のメディアおよび機械的負担を取り除くことができる。それでも、一部の顧客は、特に長期のオフライン保持が必要とされる場合、追加の層として物理テープを維持するだろう。
第五の代替品は、製品選択を抽象化する MSP または事業継続プロバイダーである。Habanero は FalconStor をこの方向に動かしているが、顧客は他のツールを使用するプロバイダーからもサービスとしての回復を購入するかもしれない。鍵となる比較は証拠である。どのプロバイダーがより良いリストア記録を生成するか？どのプロバイダーが顧客の運用環境でテストされた回復を示せるか？どのプロバイダーが IBM Power、監査ニーズ、保持、セキュリティ、コスト透明性を扱うか？製品名は回復の証明よりも重要ではない。
したがって、FalconStor の最適な適合は普遍的ではない。価値がある既存のバックアッププロセス、大幅に冗長なバックアップデータ、IBM Power または混在オペレーティングシステムのエステート、クラウドまたはオフサイト保持の必要性、移行の圧力、そしてリストアをテストするのに十分な運用規律を持つ組織にとって最も強力である。エステートがすでに最新のプラットフォームによってクリーンに保護されている場合、クラウドネイティブの回復がよりシンプルである場合、スタッフが記録を維持しない場合、または顧客がストレージソフトウェアが単独でアプリケーション継続性を解決することを期待する場合には、より弱い。
顧客がそれを信頼する前に要求すべきこと
真剣な FalconStor の評価は、機能リストではなく、リストアシナリオから始めるべきである。一つの重要なワークロードを選ぶ。必要な回復ポイントと回復時間を定義する。ソースバックアッププロセス、StorSafe ターゲット、重複排除リポジトリ、オフサイトまたはオブジェクトストレージコピー、管理コンソール、ネットワーク経路、人、資格情報、アプリケーション依存関係、および受け入れテストを特定する。その後、リストアを実行するか、少なくとも設計する。製品がその記録の作成を助けるか、あるいは助けないかである。
評価にはカタログ訓練も含めるべきである。チームは特定の日付に必要な正確な仮想メディアまたはバックアップセットを特定できるか？プライマリサイトが利用できない場合に回復できるか？スタブ化またはクラウド移行された仮想テープからリストアできるか？バックアップアプリケーションは依然としてそのメディアを理解できるか？新しい管理者が部族知識なしでその記録をたどることができるか？答えが不明確なら、重複排除の節約に関係なく、プロジェクトは本番依存の準備ができていない。
ネットワークとクラウドの前提もテストされるべきである。レプリケーショントラフィック、オブジェクトストレージ接続性、Direct Link や VPN の選択、VLAN 分離、ライセンスサービスへのアクセス、クラウド資格情報、リストア帯域幅のすべてが重要である。バックアップは優れていても、戻り経路が遅すぎたり、一人だけが知っている資格情報によってブロックされたりすれば、回復目標に失敗しうる。FalconStor のデプロイメントドキュメントは、これらの依存関係が現実であることを示すのに十分詳細である。顧客はその詳細を事務処理ではなく、計画チェックリストとして扱うべきである。
セキュリティの前提も明示されるべきである。誰が仮想メディアを削除、期限切れ、または改変できるか？どのコピーが不変か？どのくらいの期間か？鍵は FalconStor、顧客、クラウドプロバイダー、または MSP によって管理されるか？攻撃者の制御下にある管理者が将来の保護を無効にできるか？管理インターフェースは隔離され監視されているか？オフサイトコピーは侵害された本番アイデンティティから到達可能か？リストアテストは再接続前に隔離された環境で実行されるか？これらの質問は、ランサムウェア保護がマーケティングフレーズ以上であるかどうかを決定する。
サポートとサービスはシステムの一部として価格設定されるべきである。FalconStor のサポートハンドブックは、テクニカルサポートとデプロイメントまたは環境作業の間に通常だが重要な区別を設けている。回復プロジェクトが SAN ゾーニング、IP ネットワーキング、クラウドオブジェクトストレージ設定、Linux 作業、バックアップアプリケーションのチューニング、メジャーバージョンアップグレードの支援を必要とする場合、誰がその作業を担当するかを知るべきである。資金が確保されていないプロフェッショナルサービスを伴う安価なライセンスは、失敗したリストア中に高価になりうる。
ビジネスはまた、コストの証拠を要求すべきである。ベースラインのストレージ、FalconStor のライセンスまたはサービスコスト、オブジェクトストレージ、ネットワーク、クラウド検索、サポート、プロフェッショナルサービス、スタッフ時間、リストアテスト、移行労力をモデル化する。その後、そのモデルを現実的な代替案と比較する。一部の IBM Power およびハイブリッドエステートでは、FalconStor は変更を正当化するのに十分なストレージ、ハードウェア、移行の苦痛を削減するかもしれない。他のケースでは、経済性は最良ケースのデータ削減や過少に数えられた監督にあまりにも依存しているかもしれない。
最後に、評価は何が決定を変えるかも尋ねるべきである。リストアテストがカタログのずれを示したり、重複排除の節約が期待を大きく下回ったり、クラウド検索コストが完全なインシデント回復を非現実的にしたり、MSP レポートがあまりに不透明だったり、重要なオペレーティングシステムやバックアップアプリケーションのバージョンが認証されていなかったり、サポート境界が不明確だったり、ベンダー継続性の懸念が高まったりした場合、顧客は減速すべきである。代わりに、FalconStor がより低いストレージコスト、馴染みのある操作、テストされたオフサイト回復、許容可能なサポート条件でクリーンなリストア記録を可能にするならば、製品はその場所を獲得する。
判断
FalconStor Software が最も興味深いのは、すべての顧客に古い回復の世界を放棄するよう求めないからだ。その世界をより効率的に、よりクラウド対応に、より耐障害性のあるものにしようと試みる。これは、根本的な変更のコストが既存のプロセスの背後にあるターゲット層を改善するコストよりも高くなりうる IBM Power およびハイブリッドエンタープライズ環境において、信頼できる戦略である。
同社の技術ストーリーには実質がある。仮想テープ、重複排除、レプリケーション、オブジェクトストレージの使用、StorSight 管理、IBM Power 認証と IBM チャネルを通じた入手可能性、クラウド移行サポート、不変コピーの位置付け、Habanero という新しいマネージドオフサイトサービス。その商業ストーリーも首尾一貫している。経常収益、MSP 採用、IBM エコシステムフォーカス、すべてのコンポーネントを自分で構築することなく耐障害性を必要とする顧客向けのサービス主導の提供。
しかし、正しい基準は容赦ない。FalconStor は、完了したバックアップジョブ、大きな重複排除の主張、IBM カタログへの掲載、パートナーの見積もり、またはダッシュボードによって証明されるのではない。重要なワークロードについて、顧客が受け入れられた回復記録を生成できるかどうかによって証明される。その記録は、ソフトウェアバージョン、カタログ、インデックス、資格情報、ネットワーク経路、クラウドストレージ、保持、サポート境界、スタッフの変更、ランサムウェア疑惑、移行圧力といった、通常の運用の混乱をバックアップの真実が生き延びたことを示さなければならない。
その基準は、FalconStor を有用だが魔法ではないものにする。回復可能なデータを保存するコストと複雑さを下げることができる。チームがターゲットを近代化しながら使い慣れたバックアッププロセスを維持するのを助けることができる。オフサイトおよびクラウド保持をより実用的にすることができる。IBM Power 顧客にオンプレミスシステムと PowerVS の間の橋を提供できる。MSP が反復可能なサービスをパッケージ化するのを助けることができる。しかし、それらの利点のすべては、規律ある設定、繰り返しのテスト、そして正直な経済性に依存している。
実践的な結論は狭く、強い。FalconStor は、古くハイブリッドなインフラストラクチャにわたって、保護されたバックアップデータを受け入れられた回復可能な状態に変える必要がある企業およびサービスプロバイダーにとって、真剣な選択肢である。それは回復ガバナンスの代替品ではない。購入者は、必要なリストア記録から始め、その記録に対して FalconStor をテストし、その後で初めて、ストレージ節約、移行経路、ランサムウェア態勢、経常サービスモデルがコミットメントを正当化するかどうかを決定すべきである。