クラウドデータのバックアップの必要性を身をもって知った4人の顧客
クラウドへ!
リソースは無限、SLAは厳格、そしてバックアップはすべてプロバイダーが処理してくれるので、バックアップの必要もない、そんな魔法のような場所。そうでしょう?
それを当てにしないでください。
主要クラウドはすべてバックアップサービスを提供しており、ほとんどの主要SaaSプロバイダーはバックアップを約束していますが、クラウドのバックアップは各自で責任を持つべきです。確かに面倒で、追加費用もかかりますが、プロバイダーが全てを担ってくれるので自分は何も心配する必要がないと単純に思い込むのは愚かなことです。
例をいくつか挙げてみましょう。以下を試してみてください。
Code Spaces:この企業は顧客向けにGitおよびSubversionリポジトリをホスティングしていました。2014年にハッキングを受け、完全に消滅しました。まずDDoS攻撃を受け、身代金要求を受けました。身代金要求はCode SpacesのEC2コンソールに残されていました。つまり、攻撃者は攻撃を開始する前から既に深く侵入していたということです。SVNおよびGitリポジトリは壊滅的な被害を受け、同社の発表によると、「当社のデータ、バックアップ、マシン構成、オフサイトバックアップのほとんどが、部分的または完全に削除されました」とのことです。
Rackspace: 1年も経たないうちに、Rackspaceのホスト型Exchange環境が侵害され、ランサムウェア攻撃を受けました。障害は数日間続き、同社は顧客のデータを復旧する手段がなかったようです。最終的に、Rackspaceは全顧客に対し、Microsoftのホスト型Exchange事業であるMicrosoft 365への移行を推奨しました。この攻撃により、Rackspaceのこの事業は停止し、多くの顧客データも失われました。
KPMG:多くの企業と同様に、KPMGもMicrosoft Teamsを使用しています。Microsoft Teams自体には問題は発生していませんでしたが、問題はKPMGの管理者がミスで14万5000人のユーザーのチャット履歴を削除してしまったことです。管理者が極度の偏見を持って削除したため、このデータは復元できなかったようです。
Musey, Inc.:このインテリアデザインツール会社は、Googleドライブのフォルダを誤って削除してしまい、Googleが復元不可能だと告げると、ついに絶望のあまりGoogleを提訴しました。これは個人的な責任感の欠如のように聞こえますが、原告は召喚状が出ればGoogleはデータの復元にもっと力を入れなければならないだろうという理論に基づいて行動していました。これは決して健全なバックアップ戦略とは言えません。
OVHの火災、HostSolutionsなど、他にも例を挙げればきりがありませんが、肝心なのは明白です。確かにクラウドは素晴らしいものであり、自分にとって意味があるのであれば、ぜひ活用すべきです。しかし、すべてのデータを一つのカゴに詰め込み、プロバイダーがそれを放棄しないと決めつけるのは、まさに破滅への近道です。