3-2-1 バックアップ ルールは引き続き戦略に関連していますか?

組織がトラック、衣類、エネルギー、またはアイデアを製造しているかどうかにかかわらず、ほぼ確実にデジタル組織です。 仕様を製造工場に送り、クライアントにアドバイスを送り、財務データを株主に送ります。 中小企業でさえ (おそらく特に中小企業です!)、作成して保存するデータに依存しています。 過去、現在、および計画に関する情報が突然利用できなくなった場合、どのような影響がありますか?

答えは、テクノロジをどのように使用して結果を出すかによって異なります。つまり、クラウドの時代にデータ バックアップの計画はどのように変化しましたか?

組織がデータへのアクセスなしではビジネスを行うことができない場合は、バックアップが必要です。 しかし、組織は独自のバックアップを実行する必要がありますか? サービスとしてのバックアップ (BaaS) の調達をいつ検討する必要がありますか? また、BaaS プロバイダーは何を提供していますか?

バックアップ計画はどのように作成する必要がありますか?

データ バックアップの 3-2-1 プラクティスは、ほとんどの種類の組織に適した一般的な方法です。 3-2-1は、コピーの数、メディアの数、およびすべてのデータを同じ場所に保存してはならないことを示す略号です。

このルールについて覚えておくべき内訳は次のとおりです。

• 3 : 現在のデータのコピーを 3 つ保持します。 元のデータは最初のコピーとしてカウントされ、常に 2 つのバックアップを作成する必要があります。 多くの場合、元のデータは本番データであり、現在はビジネスの運営と顧客へのサービス提供に使用されています。 ただし、膨大なテスト データ セットがある場合は、それらもバックアップする価値があると考えるかもしれません。

• 2 : 2 つのバックアップ コピーは、それぞれ異なるメディアに書き込む必要があります。 これは、DVD やテープ ドライブなどのさまざまな種類の物理バックアップを伝達するために使用されていましたが、安全にルールを拡張して仮想化を含めることができます。 たとえば、1 つのバックアップをハード ドライブに保存し、もう 1 つを仮想マシンに保存して、*2 つのメディア* の要件を満たすとします。 その仮想マシンがクラウド内にある場合、バックアップ オフサイトの要件を満たすことができます。 これにより、本番環境で破損した可能性のあるデータに加えて、1 つのタイプのメディアでのバックアップの失敗または破壊が可能になります。

• 1 : これらのバックアップ コピーの 1 つは、必ずオフサイトに配置する必要があります。 オフサイトとは、自社の施設の外だけを意味するものではありません。 これは、本番環境やその他のバックアップ コピーから離れることを意味します。 完全にクラウドにある企業は、このルールに同じように取り組む必要があります。主要なクラウド プロバイダーまたは SaaS でデータをホストしている場合、バックアップをそれらでホストするべきではありません。

なぜ練習として 3-2-1 を選ぶのですか?

3-2-1 は歴史的に実用的な選択です。 情報技術がビジネスに定着し始めたとき、バックアップはほとんど手作業で行われていました。 クラウド サービスが利用可能になる前は、技術サービスとバックアップはすべて同じ場所で行われていました。 バックアップ管理者は、各バックアップの複数のコピーを作成し、1 つのコピーを安全なオフサイトの場所に送信していました。

これは、物理的または技術的な脅威から身を守る賢明な方法でした。 ほとんどの IT 障害は、両方の場所で同時に発生する可能性はありませんでした。 したがって、重要なデータを復元する必要がある場合に備えて、少なくとも 1 つの使用可能なバックアップが安全でした。

バックアップがデジタルであっても、同じことが現代のビジネスにも当てはまります。 3-2-1 により、1 つのイベントだけですべてのデータが回復不能になることはありません。

なぜ3-2-1を選ばないのですか？

中小企業 (SMB) がサービスとしてのソフトウェア (SaaS) に依存する時代では、3-2-1 はある程度の有用性を失います。 情報技術はより民主的になり、技術機能をサポートするために社内の IT ホスティングと開発を必要としなくなりました。

組織は、テンプレートから美しい Web ストアを作成し、数回のキーストロークで製品を追加し、販売ブームの間に自動的に処理を拡張できます。 さらに良いことに、使用したリソースに対してのみ料金が発生します。 この柔軟な投資により、企業は限られたリソースを専門分野に専念することができます。

しかし、自社のバックアップを効果的に管理するための従業員や技術者を失う可能性もあります。

SaaS プロバイダーのバックアップはどうですか?

クラウド プロバイダー (SaaS プロバイダーを含む) は、サービスのいくつかの側面で責任共有モデルに依存しています。 共有責任において、SaaS プロバイダーは、サービス、セキュリティ、またはデータの可用性に対していくつかの保証を持っています。 顧客は、自分のビジネスが確実に機能するようにするためのその他の取り決めを処理します。

たとえば、プロバイダーは、独自のエラーによってデータが失われないことを保証する必要があります。 ただし、顧客の管理者が顧客の販売記録または製品データベースを誤って削除しないことを保証するものではありません。

プロバイダーは、プラットフォーム レベルのバックアップを実行します。 プラットフォーム レベルのバックアップには、複数の顧客からのデータがあります。 プラットフォーム バックアップを使用して 1 人の顧客を復元することは、その時点以降の他の顧客の変更を失うことを意味します。 これは、顧客データを維持するというクラウド プロバイダーの責任を果たしますが、1 人の顧客だけのデータを復元するにはバックアップが不適切になります。

共有責任モデルでは、顧客は自分のニーズに適したバックアップがあることを確認する必要があります。 どのようにしてデータを紛失または破損する可能性があるか、およびサービスを復元するにはどのような情報が必要かを理解する必要があります。 たとえば、誤ってアカウントを削除したり、製品のリスト全体を削除したりした場合はどうなりますか? 削除された情報が失われるだけでなく、失われた情報とまだ存在するデータとの間の関係が失われる可能性があります。 これらの関係も再作成または復元する必要があります。

SaaS プロバイダーは、さまざまなレベルの技術的スキルを必要とする顧客が独自のバックアップ ニーズを満たすことができるようにするためのオプションを提供します。 プロバイダーは、次のいずれかまたはすべてを提供する場合があります。

• アカウント全体の自動バックアップ。 これは、アカウント レベルの復旧に適した選択肢です。 たとえば、だれかが誤ってまたは悪意を持って SaaS サービス アカウント全体を削除した場合、これはその日を救うためのタイプのバックアップです。

• 顧客側からバックアップを開始するための手動 Web インターフェイスまたは API。 自動バックアップと同様に、これはアカウントのすべてまたは一部を一度に復元するのに役立ちます。

• 大規模な輸出入。 これは通常、新しい製品を作成したり、レポート用のデータをダウンロードしたりするのにより便利な方法です。

何が問題になる可能性がありますか？

上記のオプションのいずれも、顧客側のバックアップがないよりはましですが、それぞれ固有の制限があります。 これらのバックアップから復元するための自動化の欠如は、高度な技術を持つスタッフがいない場合の障壁です。 バックアップには費用がかかる場合があります。GitHub は、無料プランで 10 個のコード リポジトリのバックアップを提供していますが、追加のバックアップには費用がかかります。

そして、Shopify はデータをバックアップしますが、プラットフォーム レベルでのみです。 (システム バックアップはユーザー バックアップとは異なります)。 つまり、基本的に、Shopify は、ユーザーがデータを失う可能性があるような大規模な問題に耐えることができますが、自分でデータを失った場合は、アカウント レベルのバックアップを復元する別の方法を用意する必要があります.

データに確実にアクセスできるようにすることは、適切で必要なステップですが、それがすべての答えではありません。 単にバックアップを作成しただけでは、実行中の状態に効率的に戻れるとは限りません。 バックアップのアップロード、復元、SaaS アプリケーションでの使いやすさのテスト方法を知っていますか?

3-2-1 では、バックアップの作成と保護のみを扱います。 それ自体でデータ復旧計画を作成することはありません。

復旧計画が必要です

そのプロバイダーからのデータのバックアップに SaaS プロバイダーを使用する際の最大の問題は、バックアップの復元です。 リポジトリ、製品ファイル、チケットなどをダウンロードするだけでも十分ですが、緊急時にそのデータを SaaS プラットフォームに戻すにはどうすればよいでしょうか?

復旧計画は、データ損失から通常どおりの業務に戻るための最初から最後まで書かれた指示です。 データを見つけて、適切な形式と適切な権限で再インポートするための正確な手順が含まれている必要があります。

保存して適切にインポートできない関連データがある場合は、再作成する必要があります。 たとえば、Jira データを JSON ファイルに保存する場合、バックアップは技術的に実行されます。 ただし、結果の JSON ファイルは読みにくく、Jira に再インポートするのも困難です。 これにより、データ損失イベント後の回復時間が長くなり、その場で把握したいものではありません.

リカバリ プランが機能し、最小限のダウンタイムで実行できることを確認するために、リカバリ プランを定期的に実施する必要があります。

回収のための商用サービス

クラウドおよび SaaS アプリケーションの復旧計画がコア スキルに合わない場合は、評判の良いベンダーが外部委託の復旧を提供します。 ベンダーは、ブラックボックス ストレージからサーバーおよびデータベースのバックアップ、SaaS アプリケーションのアカウント レベルのリカバリまで、あらゆるものを提供しています。 プロバイダーのバックアップとは異なり、サービスとしてのバックアップは、個々のクライアント (あなた) に属するデータのみを収集します。

BaaS を使用することに決めた場合は、クラウドまたは SaaS アプリケーションの使用状況に一致するベンダーを探してください。 たとえば、ビジネス SaaS アプリとテクニカル SaaS アプリの組み合わせが必要な場合は、[Rewind](https://rewind.com/products/backups/github/) を使用できます。 彼らは幅広いクラウド サービス プロバイダー向けのバックアップ統合を事前に構築しており、1 つの BaaS 製品を習得するだけで、その広がりをカバーできます。

ダウンタイムに対する許容度が低い組織は、商用のバックアップ プロバイダーを検討する必要があります。 厳格な時間枠で高度な保証を備えた復旧を提供します。 独自のバックアップ ストレージとソフトウェアに投資するよりも資本支出が少なく、ビジネス モデルは、各顧客に代わってデータの復元を適切に管理できるかどうかにかかっています。

商用 BaaS は、主要なソリューションになるか、独自の 3-2-1 プラクティスの一部を置き換えることができます。 唯一の正しい答えは、予算、技術スキルの可用性、および回復時間のニーズを満たすものです。

結論

SaaS ベンダーにニーズに合ったバックアップが含まれていると思い込まないでください。 彼らのデータ回復オプションを理解していることを確認してから、彼らの製品とあなたのニーズとの間のギャップを評価してください. ほとんどの組織では、追加のバックアップと、バックアップされたデータを SaaS アプリケーションに復元するための計画が必要になります。 3-2-1 のような複数のコピー、複数の場所の計画を使用すると、必要なときにデータを利用できるというより確実な保証が得られます。

ただし、リカバリ プランを作成することは、複数のバックアップを作成するだけではないことを忘れないでください。 組織内の責任者が、コピーおよび保存されていないデータの再作成を含め、バックアップにアクセスして復元する方法を知っていることを確認してください。

企業に専門知識がない場合、または資本支出に対する欲求がない場合は、BaaS プロバイダーが答えになる可能性があります。 BaaS を選択する場合は、できるだけ多くの SaaS プロバイダーと重要なアプリケーションをカバーするソリューションを探してください。