理論上しか存在しなかったバックアップ：シンガポールのエドテック企業とクラウドバックアップ

結論から： シンガポールのエドテック企業でコンテンツサーバーが故障し、復旧を試みたところ、毎晩のバックアップジョブが三週間にわたって静かに失敗し続けていたことが判明した。バックアップはスケジュール上は存在していた。それが本当に走ったかを見ていた人がいなかっただけだ。バックアップのスケジュールを「頼れるもの」に変えるのは、ジョブ監視と、日付の残る復旧演習である。

本記事の企業は複合シナリオであり、特定の顧客ではない。時系列は説明のためのものである。実在するのは、ここで説明するサービスだ。バックアップジョブの監視、復旧演習、そして主環境から独立したオフサイトのクラウド保管先は、Brocent のクラウドマネージドバックアップが実際にそう作られている。

デジタルコンテンツ企業にとって、バックアップの失敗は別種の事故である

シンガポールには、エドテック、eラーニング、メディア制作、デジタル出版の企業が濃く集まっている。五十〜八十人規模、製品は完全にデジタル、そしてコンテンツライブラリは何年もの時間と相応の費用をかけて積み上げたものだ。講座動画、評価問題バンク、インタラクティブモジュール、四つ五つの市場向けのローカライズ版、そしてそれらの背後にあるプロジェクトファイル。

こうした企業にとって、データは事業の記録ではない。データそのものが事業である。ファイルサーバーの三週間分を失った製造業は、面倒な再構築作業に直面する。講座マスターを失ったエドテック企業が失うのは、再調達できない在庫だ。講師はすでに次の仕事に移り、スタジオを押さえたのは一年前で、ローカライズ業者の作業ファイルは、まさにあのサーバー上にあったものだからである。

こうした企業を、その技術的洗練が示唆するより脆くしている構造的な要因が二つある。第一に、技術的成熟度が均一ではない。エンジニアリングチームは実際に有能であり、そのため社内システムも同様にきちんと扱われているだろうという合理的な思い込みが生まれる。しかし社内システムは通常、誰の製品でもなく、したがって誰の優先事項でもない。第二に、環境が中途半端にハイブリッドである。顧客向けプラットフォームはクラウド基盤上で適切に運用されている一方、コンテンツ制作パイプラインはオフィスのオンプレミスサーバーか NAS に載っている。VPN 越しのレンダリングや編集は現実的ではなかったからだ。

結果として、現代的でよく運用された制作プラットフォームと、物置レベルのコンテンツアーカイブを同時に抱える企業ができあがる。そして後者を守っているのは、二年前に誰かが的確に設定し、その後誰も見ていないバックアップジョブである。

シナリオ：ドライブの故障と、三週間の空白

複合シナリオの企業はシンガポールに約六十五人を擁し、域内の法人顧客向けに講座コンテンツの制作とローカライズを行っている。コンテンツパイプラインは、直結ストレージを備えた一台のオンプレミスサーバー上で動く。ソース動画、プロジェクトファイル、レンダリング済みマスター、そして制作チームが日々使う素材ライブラリ。

バックアップはサーバー構築時にきちんと設定された。毎晩のジョブ、ローカルの保管先、保持期間の設定、完了時のメール通知。それを設定した人物は、約一年後に退職した。メール通知は配信リストに送られ、そのリストは次第に読まれなくなり、やがて受信トレイのルールで自動振り分けされ、最終的には誰が受け取っているのか自信を持って言える者がいなくなった。

火曜日の朝、アレイが劣化し、そのまま完全に故障する。エンジニアリングリードは正しいことを正しい順序で行った。故障を確認し、交換ハードウェアを手配し、バックアップからの復旧に取りかかった。

直近の成功したバックアップは、二十三日前のものだった。

定例のアップデートがサービスアカウントの権限を変更して以来、ジョブは失敗し続けていた。毎晩まったく同じかたちで失敗し、毎晩その失敗を誰も読まないログに書き込み、誰も受け取らない通知を送っていた。外から見て環境には何の異常もなかった。バックアップソフトは動いていた。スケジュールも無傷だった。保管先には空き容量があった。ジョブが完了しなかっただけである。静かに、二十三回。

三週間分のコンテンツ作業は、「やり直せる」という意味では復旧可能だ。この会社が支払った代償は、顧客への納品遅延、二週末分の制作工数、そして再発注せざるを得なかったローカライズ一件である。業者は納品後、自分たちの作業コピーをすでに削除していた。

実際に何が壊れていたのか——それはソフトウェアではない

これをツールの失敗として読みたくなる。しかし違う。バックアップソフトは設定されたとおりに動作し、毎晩正直に報告していた。

この結果を生んだのは四つのギャップであり、それは我々がほぼ毎回見つけるのと同じ四つである。

ジョブの状態を誰も所有していなかった。 バックアップは「設定するもの」として扱われ、「走り続けるがゆえに見張りを要する運用」としては扱われていなかった。失敗を虚空に報告するジョブの実用的価値は、ジョブがないのと同じである。

主環境から独立したオフサイトのコピーが存在しなかった。 保管先は同じオフィス、同じネットワーク上にあり、同じ認証情報で到達できた。これは単一サイトのコピーであり、シンガポールの中小企業を実際に痛めつける可能性が最も高い二つのシナリオ——到達できるすべてを暗号化するランサムウェアと、建物内の物理的事故——に対して無力である。

復元が一度もテストされていなかった。 これはジョブの失敗とは別の話である。仮に二年間毎晩ジョブが成功していたとしても、有用な時間内にデータを稼働状態へ戻せることを誰も証明していなかった。復元したことのないバックアップは、仮説にすぎない。

RTO と RPO が事業側と合意されていなかった。 制作ディレクターに対して、どれだけのコンテンツ作業を失って許容できるのか、パイプラインは何日止まってよいのかを尋ねた者はいなかった。この二つの数字がなければ、毎晩のローカルのみのバックアップで十分かどうかを誰も評価できない。実際には十分ではなかったのだが、それに気づくための基準そのものが存在しなかった。

最後の点は、飛ばされがちなだけに掘り下げる価値がある。RPO は失って許容できるデータ量を時間で表したもの。RTO は止まって許容できる時間である。いずれも技術判断ではなく事業判断だ。IT はある RPO にいくらかかるかを示せるが、それにいくらの価値があるかを言えるのは事業側だけである。複合シナリオの企業では、ようやく誰かが問うたときの正直な答えは「一日分の制作作業なら許容できるが、三週間は許容できない」であり、その一言で既存の体制は擁護不能になった。

Brocent の見解：復元したことのないバックアップは仮説である

Brocent は 2007 年からアジア各地で IT 運用を担い、2016 年に香港オフィスを開設、2021 年からシンガポールに本社を置いている。バックアップと災害復旧はマネージド IT プランの全ティアに含まれており、選択制ではなく標準としているのは、まさに上記のパターンのためである。痛い目に遭う企業は、バックアップをまったく取っていない企業ではほとんどない。バックアップはあったが、誰も見ていなかった企業である。

クラウドマネージドバックアップは、設定して放置されたジョブが持たない三つの要素を軸に構成している。

24 × 7 のバックアップジョブ監視。 当社の SCC および NOC チームは、バックアップジョブを通知メールとしてではなく、人が監督する運用として監視する。火曜に失敗したジョブは同じ週に表面化する。インシデントの最中に、二十三日後に発覚するのではない。

定期的な復旧演習。 バックアップの完全性と復旧可能性を検証するため、お客様とともに定期的なデータ復旧演習を実施する。成果物は日付の入った結果である。この日、このデータを復元し、これだけの時間を要した、という記録だ。これが仮説を事実に変える証跡であり、保険会社や大企業顧客のデューデリジェンス調査票が実際に求めているものでもある。

RTO と RPO を書面で合意した BCP。 我々は、RTO と RPO に対応したデータバックアップと災害復旧の戦略・方法論を含む事業継続計画の策定を支援している。複合シナリオの企業が一度も持たなかった会話であり、下流のすべての技術判断を決める会話でもある。

その下の設計は、市場で 3-2-1 と略される規律に従う。データのコピーを少なくとも三つ、少なくとも二種類の異なる媒体またはプラットフォーム上に、そのうち少なくとも一つをオフサイトに置く。実務的には、オフィスにあるサーバーやシステムのオンプレミスバックアップ、クラウド IaaS 環境のデータをオンプレミスストレージへ、あるいはクラウド間冗長のために別のクラウドプラットフォームへ集約すること、そしてリスクプロファイル上必要であれば、物理バックアップ媒体を第三者施設にオフサイト保管することを意味する。ツールは Veeam、Microsoft、Acronis、MSP360 を扱い、保管先は Azure、AWS、Alibaba Cloud に対応する。ツールは環境に合わせて選ぶのであって、その逆ではない。

一点、意図的にしていることがある。これは単体で売って顧客に世話をさせる商品ではない。バックアップと災害復旧はすべてのマネージド IT サポートプランに含まれている。ジョブ監視は運用上の規律であり、パッチ適用、エンドポイント保護、NOC 監視と並ぶ場所に属するものであって、誰も開かないダッシュボードとして孤立させるものではないからだ。

この規模の企業にとって、良い状態とは

制作パイプラインが事業の核心である六十五人のエドテック企業にとって、現実的な形は特別なものではない。

ジョブの状態を、それを職務とする人が見ている。 通知メールでもなく、エンジニアリングリードが「見るつもり」のダッシュボードでもない。失敗時にエスカレーション経路のある、監視された運用である。

少なくとも一つのコピーがオフサイトにあり、別の認証情報で守られている。 オフサイトのコピーは、ランサムウェア事案で侵害される同じ認証情報では到達できないようにすべきだ。シンガポールの中小企業の実際の生存率を最も改善する単一の変更がこれであり、たいていは一覧の中で最も安価でもある。

復旧演習がスケジュールされ、日付入りの結果を残す。 四半期ごとが妥当な基準である。演習では、バックアップファイルが開けることを確認するのではなく、実際のデータを使える状態へ戻すべきだ。

RTO と RPO が文書化され、事業側が承認している。 二つの数字を、結果を引き受ける人物と合意する。支出の適正水準も含め、その他すべてはそこから導かれる。

保持期間が業務の実態に合っている。 コンテンツ企業では、納品から数週間後にマスターファイルの問題が発覚することが珍しくない。保持期間七日と九十日は別の製品であり、その差は必要になった瞬間にしか意味を持たない。

クラウドプラットフォーム自身のデータも範囲に入っている。 Microsoft 365、Google Workspace、各種 SaaS のデータは、提供元がバックアップしていると思い込まれがちだ。提供元のレプリケーションが守るのは提供元のインフラ障害であって、自社での誤削除、退職者によるメールボックスの消去、あるいは自社テナント内で動くランサムウェアではない。これはスコープ策定時に最もよく見つかるギャップの一つである。

クラウドマネージドバックアップは、基本の予防保守プランが 298 米ドルから。加えて、デバイス単位のクラウドバックアップアドオンが月額のデバイス単価として価格ページにマネージドプランの他の項目と並んで公開されている。サービスの下で何が動いているかを見たい場合は、バックアップと復旧のページに関連するツールの選択肢を掲載している。

同じ話のランサムウェア版

反実仮想をはっきり述べておく価値がある。上のシナリオの読み方が変わるからだ。

複合シナリオの企業では、障害はアレイの劣化だった。それは穏当な版である。自ら音を立て、影響は一システムに留まり、保管先は——いかに古かったとはいえ——探しに行ったときにまだ無傷で読める状態だった。

同じ環境をランサムウェア事案に通すと、計算はまったく変わる。有効な認証情報でファイルサーバーに到達した暗号化プログラムは、その認証情報で書き込める他のすべてにも到達する。同じネットワーク上で同じサービスアカウントによりマウントされた保管先は、まさにその「他のすべて」である。この会社が見つけたのは二十三日前のバックアップではなく、暗号化されたバックアップだっただろう。

オフサイトのコピーがバックアップ戦略の改良点ではなく耐荷重部分である理由、そしてイミュータブル性が重要である理由がここにある。保持期間内は変更も削除もできないコピー——管理者であっても、正しい認証情報を持っていても——こそが、環境を掌握した攻撃者の後に生き残るものだ。イミュータブルバックアップをマネージドプランのバックアップ／DR 基準線に含めているのは、まさにこの理由による。

見落としやすい二次的な論点もある。ランサムウェア事案で問われるのは「復元できるか」だけではなく、「どれだけ速く、どこから復元するか」である。唯一の健全なコピーがクラウドリージョンにあり、まだ購入していないハードウェアに数テラバイトを戻す必要があるなら、バックアップがどれほど正しくても復元は日単位になる。それは RTO の会話であり、事案の最中ではなく事前に済ませておくべきものだ。

シンガポール企業がバックアップに取る三つの道

監視されていないスケジュールジョブ

• 得られるもの： 正しく設定され、稼働しているバックアップ。継続コストはなし。
• どこで壊れるか： 静かに壊れる。ジョブの失敗はログか、誰も読まないメールボックスに報告され、空白は実際のインシデント中に発見される。それがどれだけ続いていたかを知るには最悪のタイミングである。
• 見分け方： 昨夜のバックアップジョブの結果を誰が読んだか言えないなら、誰も読んでいない。
• 向いている相手： 誰にも向かない。ただし正直に評価すれば、多くの中小企業の実態を言い当てている。

自社運用のクラウドバックアップツール

• 得られるもの： 十分な能力のソフトウェア、オフサイトの保管先、保持ポリシーの制御、そして完全な柔軟性。
• どこで壊れるか： それでもジョブ状態を見る人と、復旧演習を回す人が必要である。IT が一人か二人で、しかも自分たちの製品ロードマップを抱えている会社では、真っ先に外れるのが演習であり、ジョブ監視は静かに「何かあれば気づくだろう」に置き換わる。
• 向いている相手： 専任のインフラ担当がいて、その時間を守る権限を持っている企業。

監視と復旧演習を伴うマネージドクラウドバックアップ

• 得られるもの： SCC/NOC チームによる 24 × 7 のバックアップジョブ監視、日付入り結果を残す定期復旧演習、主環境から独立したオフサイトのクラウド保管先、そして RTO と RPO を書面で合意した BCP。ツールは Veeam、Microsoft、Acronis、MSP360、保管先は Azure、AWS、Alibaba Cloud。
• コスト： 基本の予防保守プランが 298 米ドルから、加えてクラウドバックアップアドオンのデバイス単価。バックアップと災害復旧はマネージド IT プランの全ティアに含まれる。
• どこで壊れるか： 事業側が RTO と RPO を決める必要をなくすものではない。助言はできるが、御社のダウンタイムの価値を我々が決めることはできない。
• 向いている相手： データが製品そのものである企業、そして社内チームの時間をジョブログの監視より製品に充てたほうがよい企業。

よくある質問

クラウドバックアップの料金はどうなっていますか？

範囲によって二通りある。クラウドマネージドバックアップは、設計・構築・監督付き運用を含む基本の予防保守プランが 298 米ドルから。エンドポイントやデバイス単位のカバレッジについては、月額のデバイス単価として公開しているクラウドバックアップアドオンがあり、含まれるストレージ枠を超える分は環境ごとの見積もりとなる。いずれもマネージド IT プランと並行し、そのプランでは全ティアでバックアップと災害復旧が含まれる。最新の金額は価格ページを参照いただきたい。

3-2-1 バックアップ戦略とは何ですか？

データのコピーを少なくとも三つ、少なくとも二種類の異なる媒体またはプラットフォーム上に持ち、そのうち少なくとも一つをオフサイトに置く考え方である。三つ目のコピーの意義は冗長性それ自体ではない。他の二つを破壊する事象——実務的にはネットワーク上のすべてに到達するランサムウェアか、建物での物理的事故——をオフサイトのコピーが生き延びるべきだ、という点にある。守る対象のサーバーと同じネットワーク上にあるローカルバックアップは、この三条件をどれも満たさない。

復元は実際どのくらいの頻度でテストすべきですか？

多くの中小企業にとっては四半期ごとが妥当な基準で、RTO が厳しいシステムではより頻繁に。重要なのは演習が何を残すかである。特定のデータが稼働状態へ復元されたこと、そしてそれに要した時間を示す日付入りの記録だ。その時間こそが計画書上のものではない実際の RTO であり、初めて測ったときに両者が大きく食い違うのはよくあることである。

バックアップと災害復旧の違いは何ですか？

バックアップはデータのコピーである。災害復旧は、合意した時間内に業務を再開できる能力である。完全で有効なバックアップを持ちながら一週間止まることは十分にあり得る。数テラバイトをオフィスの回線経由で、まだ調達していないハードウェアに戻すには、かかるだけの時間がかかるからだ。DR 計画が扱うのは RTO、すなわち時間であり、それは「何をコピーするか」だけでなく「何を構築するか」を変える。

どのクラウドプラットフォームにバックアップできますか？

Azure、AWS、Alibaba Cloud を保管先として扱い、ツールは環境に応じて Veeam、Microsoft、Acronis、MSP360 を使い分ける。クラウド IaaS 環境のデータをオンプレミスストレージへ、あるいはクラウド間冗長のために 第二のクラウドプラットフォームへ集約する構成にも対応し、リスクプロファイル上必要であれば物理バックアップ媒体の第三者施設でのオフサイト保管も行う。

バックアップジョブが静かに失敗したらどうなりますか？

監視されたサービスでは、静かなままにはならない。SCC および NOC チームがバックアップジョブをエスカレーション経路のある運用として 24 × 7 で監督するため、失敗は復元を試みる場面ではなく同じ週のうちに表面化する。それが「設定されたバックアップ」と「マネージドなバックアップ」の具体的な違いであり、本記事のシナリオが回っている軸でもある。

五十〜八十人規模の企業に適していますか？

適している。そしてこの規模こそ、ギャップが最も大きいことが多い。この規模の企業は、重要と言えるだけのデータ量を持ち、「そこは誰かが見ているはずだ」と思える程度の技術的自信も持っているが、バックアップログを読むことを職務に含む専任のインフラ担当を置いていることは稀である。基本の予防保守プランは、まさにこうした環境を想定した範囲になっている。

サーバーだけでなく、Microsoft 365 のデータもカバーされますか？

カバーできるし、通常はカバーすべきである。Microsoft のレプリケーションが守るのは同社のインフラ障害であって、削除、退職者によるメールボックスの消去、有効な認証情報でテナント内部を動くランサムウェアではない。SaaS データはスコープ策定時に最も頻繁に見つかるギャップの一つだ。まさに「他社の問題」のように感じられるからである。

ここからどう進めるか

本記事の複合シナリオの企業は、コンテンツライブラリを失ってはいない。失ったのは三週間、顧客への納品期日、そしてローカライズ一件である。高くついたが生き延びられる結末であり、しかもそれは、障害がランサムウェアではなくハードウェア故障によって発覚したからにすぎない。ランサムウェアであれば、同じネットワーク上の保管先にも到達していただろう。

有用な問いは「バックアップを取っているか」ではない。ほぼ全員が取っている。問うべきは、昨夜のジョブ結果を誰かが読んだか、主たる認証情報が届かない場所にコピーが存在するか、そして最近誰かが実際に何かを復元し、所要時間を書き留めたか、である。

この三つに自信を持って答えられないなら、そのギャップを埋めるのは難しくないし、それを露呈させるインシデントよりはるかに安い。クラウドマネージドバックアップは監視・演習・オフサイト保管先をカバーし、バックアップと災害復旧はマネージド IT サポートの全ティアに含まれる。現状で何をお持ちで、それがどこで破綻するかから始めるので、ご連絡いただきたい。