Microsoft 365 での SharePoint と OneDrive のデータの復元性

  • [アーティクル]

Microsoft 365 内では、OneDrive は SharePoint ファイル プラットフォームの上に構築されます。 この記事では、両方の製品を参照するために SharePoint のみを使用します。 この記事は、クラウド添付ファイル、Teams で共有されているファイル、Teams 会議の記録とトランスクリプト、ループ コンポーネント、ホワイトボードなど、SharePoint にデータを格納するその他の製品にも適用されます。

SharePoint のコア コンテンツ ストレージを構成する主な資産は 2 つあります。

  • BLOB ストレージ: SharePoint にアップロードされたユーザー コンテンツは、Azure Storage に格納されます。 SharePoint では、ユーザー コンテンツと真にアクティブ/アクティブなシステムのほぼリアルタイムの重複を確保するために、Azure Storage の上にカスタム回復性プランを構築しました。
  • メタデータ: 各ファイルに関するメタデータは、Azure SQL Database に格納されます。 Azure SQL では、SharePoint で使用される完全なビジネス継続性のストーリーと詳細については、この記事の後半で説明します。

データの回復性を確保するためのコントロールの完全なセットについては、以降のセクションで説明します。

BLOB ストレージの回復性

SharePoint には、Azure Storage で顧客データを格納するためのカスタム構築ソリューションがあります。 すべてのファイルは、プライマリとセカンダリの両方のデータセンター リージョンに同時に書き込まれます。 いずれかの Azure リージョンへの書き込みが失敗した場合、ファイルの保存は失敗します。 内容が Azure Storage に書き込まれた後、チェックサムはメタデータと共に個別に格納され、コミットされた書き込みが将来のすべての読み取りの間に元のファイルと同じになるようにするために使用されます。 この同じ手法は、発生する必要がある破損の伝達を防ぐために、すべてのワークフローで使用されます。 各リージョン内で、 Azure Locally 冗長ストレージ (LRS) は高レベルの信頼性を提供します。

SharePoint では Append-Only ストレージを使用します。つまり、Microsoft は新しい BLOB のみを追加でき、完全に削除されるまで古い BLOB を変更することはできません。 このプロセスにより、最初の保存後にファイルを変更または破損できないようにし、古いバージョンを破損しようとする攻撃者から保護します。 バージョン整合性保護は SharePoint のアーキテクチャに組み込まれているため、個々の管理者設定に応じて、以前のバージョンのファイル コンテンツを取得できます。

BLOB ストレージの回復性。

どちらのデータセンターの SharePoint 環境でも、両方の Azure リージョンのストレージ コンテナーにアクセスできます。 パフォーマンス上の理由から、同じローカル データセンター内のストレージ コンテナーは常に優先されますが、目的のしきい値内に結果が表示されない読み取り要求には、データが常に使用可能になるようにリモート データセンターから要求されたコンテンツが同じです。

メタデータの回復性

SharePoint メタデータは、Azure Storage に格納されているコンテンツの場所とアクセス キーを格納するため、ユーザー コンテンツへのアクセスにも重要です。 これらのデータベースは、広範な ビジネス継続性計画がある Azure SQL に格納されます。

SharePoint では、Azure SQL によって提供されるレプリケーション モデルを使用し、フェールオーバーが必要かどうかを判断し、必要に応じて操作を開始するための独自の自動化テクノロジを構築しました。 そのため、Azure SQL の観点からは "手動データベース フェールオーバー" カテゴリに分類されます。 Azure SQL データベースの復旧可能性に関する最新のメトリックについては、 こちらを参照してください。

メタデータの回復性。

SharePoint では、Azure SQL のバックアップ システムを使用して 、ポイントインタイム リストア (PITR) を最大 14 日間有効にします。

自動フェールオーバー

SharePoint では、カスタムビルドの自動フェールオーバーを使用して、場所固有のイベントが発生した場合のカスタマー エクスペリエンスへの影響を最小限に抑えます。 特定のしきい値を超える単一または複数コンポーネントの障害を検出する監視駆動型の自動化により、問題のある環境からウォーム セカンダリへのすべてのユーザーのアクティビティの自動リダイレクトが行われます。 フェールオーバーすると、メタデータとコンピューティング ストレージが新しいデータセンターから完全に処理されます。 BLOB ストレージは常に完全にアクティブまたはアクティブに実行されるため、フェールオーバーに変更は必要ありません。 コンピューティング レベルでは、最も近い BLOB コンテナーを使用しますが、可用性を確保するために、ローカルとリモートの両方の BLOB ストレージの場所をいつでも使用します。

SharePoint では、Azure Front Door サービスを使用して、Microsoft ネットワークの内部ルーティングを提供します。 この構成により、DNS に依存しないフェールオーバー リダイレクトが可能になり、ローカル マシン キャッシュの影響が軽減されます。 ほとんどのフェールオーバー操作は、エンド ユーザーに対して透過的です。 フェールオーバーがある場合、顧客はサービスへのアクセスを維持するために変更を加える必要はありません。

バージョン管理とファイルの復元

新しく作成されたドキュメント ライブラリの場合、SharePoint は既定ですべてのファイルで 500 バージョンに設定され、必要に応じて、より多くのバージョンを保持するように構成できます。 UI では、100 バージョン未満の値の設定は許可されませんが、パブリック API を使用して格納するバージョンを減らすためにシステムを設定できます。 信頼性を確保するために、100 未満の値は推奨されないため、ユーザー アクティビティによって不注意によるデータ損失が発生する可能性があります。

バージョン管理の詳細については、「 SharePoint でのバージョン管理」を参照してください。

ファイルの復元は、SharePoint の任意のドキュメント ライブラリで過去 30 日間の任意の秒に "過去に戻る" 機能です。 このプロセスは、ランサムウェア、大量削除、破損、またはその他のイベントから回復するために使用できます。 この機能ではファイル バージョンが使用されるため、既定のバージョンを減らすことで、この復元の有効性が低下します。

ファイルの復元機能は、 OneDrive と SharePoint の両方について文書化されています。

削除、バックアップ、およびポイントインタイム リストア

SharePoint から削除されたユーザー コンテンツは、次の削除フローを経ます。

削除されたアイテムは、一定期間ごみ箱に保持されます。 SharePoint の場合、保持時間は 93 日です。 アイテムを元の場所から削除すると開始されます。 サイトのごみ箱からアイテムを削除すると、 サイト コレクションのごみ箱に移動します。 残りの 93 日間はそこにとどまり、完全に削除されます。 ごみ箱の使用方法の詳細については、次のリンクを参照してください。

このプロセスは既定の削除フローであり、保持ポリシーやラベルは考慮されません。 詳細については、「 SharePoint と OneDrive のリテンション期間について」を参照してください。

93 日間のリサイクル パイプラインが完了すると、メタデータと Blob Storage に対して個別に削除が行われます。 メタデータはデータベースからすぐに削除されるため、メタデータがバックアップから復元されない限り、コンテンツは読み取りできなくなります。 SharePoint では、メタデータの 14 日間分のバックアップが保持されます。 これらのバックアップは、ほぼリアルタイムでローカルに作成され、冗長な Azure Storage コンテナーのストレージにプッシュされます。このパブリケーションの時点の ドキュメントに従って 、5 分から 10 分のスケジュールです。

さらに、お客様はデータ復旧のために Microsoft 365 Backup を利用することもできます。 Microsoft 365 Backup は、より長い保護時間を提供し、ランサムウェアや偶発的/悪意のある従業員コンテンツの上書き/削除などの一般的なビジネス継続性とディザスター リカバリー (BCDR) シナリオからの一意の高速復旧を提供します。 追加の BCDR シナリオ保護もサービスに直接組み込まれており、強化されたレベルのデータ保護を提供します。

Blob Storage コンテンツが削除されると、SharePoint は Azure Blob Storage の論理的な削除機能を利用して、偶発的または悪意のある削除から保護します。 この機能を使用すると、コンテンツが完全に削除される前に、合計 14 日間のコンテンツを復元できます。 また、BLOB は不変であるため、Microsoft は常に 14 日間ファイルの状態を復元できます。

注:

Microsoft アプリケーションは標準プロセスのごみ箱にコンテンツを送信しますが、SharePoint には、ごみ箱をスキップして即時削除を強制できる API が用意されています。 アプリケーションを確認して、コンプライアンス上の理由から必要な場合にのみこれを行う必要があることを確認します。

整合性チェック

SharePoint では、さまざまな方法を使用して、データ ライフサイクルのすべての段階で BLOB とメタデータの整合性を確保します。

  • メタデータに格納されているファイル ハッシュ: ファイル全体のハッシュがファイル メタデータと共に格納され、すべての操作中にドキュメント レベルのデータ整合性が維持されるようにします
  • メタデータに格納されている BLOB ハッシュ: 各 BLOB アイテムには、基になる Azure ストレージの破損から保護するために、暗号化されたコンテンツのハッシュが格納されます。
  • データ整合性ジョブ: 14 日ごとに、各サイトは、データベース内の項目を一覧表示し、それらを Azure Storage の一覧表示された BLOB と照合することで、整合性をスキャンします。 ジョブは、不足しているストレージ BLOB の BLOB 参照を報告し、必要に応じて Azure Storage の論理的な削除 機能を使用してそれらの BLOB を取得できます。