Microsoft 365 Exchange データの削除
Exchange 内には、論理的な削除とハード削除の 2 種類の削除があります。 これは、メールボックスとメールボックス内のアイテムの両方に適用されます。
論理的に削除されたメールボックスとハード削除されたメールボックス
論理的に削除されたユーザー メールボックスは、Microsoft 365 管理センターまたは Remove-Mailbox コマンドレットを使用して削除されたもので、Microsoft Entra ID のごみ箱に残っており、30 日未満の間存在しています。 メールボックスは、次のいずれかの方法で論理的に削除できます。
- ユーザー メールボックスに関連付けられている Microsoft Entra ユーザー アカウントは論理的に削除されます (ユーザー オブジェクトがスコープ外であるか、ごみ箱コンテナー内にあります)。
- ユーザー メールボックスに関連付けられている Microsoft Entra ユーザー アカウントはハード削除されていますが、Exchange メールボックスは訴訟ホールドまたは電子情報開示ホールドの下にあります。
- ユーザー メールボックスに関連付けられている Microsoft Entra ユーザー アカウントは、過去 30 日以内に消去されました。これは、Exchange が完全に消去されて回復不能になる前に、メールボックスを論理的に削除された状態に保つ最大保持期間です。
ハード削除されたユーザー メールボックスは、次のいずれかの方法で削除されたメールボックスです。
- ユーザー メールボックスは 30 日以上論理的に削除されており、関連付けられている Microsoft Entra ユーザーはハード削除されています。 メール、連絡先、ファイルなどのすべてのメールボックス コンテンツは完全に削除されます。
- ユーザー メールボックスに関連付けられているユーザー アカウントが、Microsoft Entra ID からハード削除されました。 ユーザー メールボックスは Exchange Online で論理的に削除され、論理的に削除された状態のまま 30 日間保持されます。 30 日間に、新しい Microsoft Entra ユーザーが同じ ExchangeGuid または ArchiveGuid を持つ元の受信者アカウントから同期され、その新しいアカウントが Exchange 用にライセンスされている場合、元のユーザー メールボックスがハード削除されます。 メール、連絡先、ファイルなどのすべてのメールボックス コンテンツは完全に削除されます。
- 論理的に削除されたメールボックスは、 Remove-Mailbox -PermanentlyDelete を使用して削除されます。
上記の削除シナリオでは、ユーザー メールボックスが訴訟や電子情報開示ホールドなどの保留状態にないことを前提としています。 メールボックスに何らかの種類の保留がある場合、メールボックスを削除することはできません。 すべてのメール ユーザー受信者の種類では、 保留 設定は無視され、ハード削除や論理的な削除には影響しません。
論理的に削除されたアイテムとハード削除されたアイテム
ユーザーがメールボックス アイテム (メール メッセージ、連絡先、予定表の予定、タスクなど) を削除すると、アイテムは [回復可能なアイテム] フォルダーに移動され、"削除" という名前のサブフォルダーに移動されます。 これは論理的な削除と呼ばれます。 削除したアイテムが [削除] フォルダーに保持される期間は、メールボックスに設定された 削除済アイテムの保持期間によって決まります。 Exchange メールボックスは既定で 14 日間削除済みアイテムを保持しますが、Exchange 管理者はこの設定を変更して、期間を最大 30 日間まで増やすことができます。 (Exchange メールボックスの削除済みアイテムの保持期間を長くする詳細な手順については、「 Exchange メールボックスに対して完全に削除されたアイテムを保持する期間を変更する」を参照してください)。ユーザーは、削除されたアイテムのリテンション期間が切れる前に、削除済みアイテムを回復または消去できます。 これを行うには、Microsoft Outlook または Outlook on the web の削除済みアイテムの回復機能を使用します。
ユーザーが Outlook または Outlook on the web の削除済みアイテムの回復機能を使用して削除済みアイテムを消去した場合、これはハード削除と呼ばれます。 Exchange では、新しいメールボックスの作成時に 1 つのアイテムの回復が既定で有効になるため、管理者は削除済みアイテムの保持期間が切れる前に、ハード削除されたアイテムを 回復 できます。 また、単一アイテムの回復が有効になっていれば、ユーザーまたはプロセスによってメッセージが変更されたときに、元のアイテムのコピーの保存も行われます。
ページゼロ
ゼロ化 は、削除されたデータの回復がより困難になるように、削除されたデータに対してゼロまたはバイナリ パターンを書き込むセキュリティ メカニズムです。 Exchange では、メールボックス データベースは ページ をストレージの単位として使用し、 ページ ゼロと呼ばれる上書きプロセスを実装します。 ページ ゼロは既定で有効になっており、顧客や Microsoft では無効にできません。 特定のデータベースのすべてのコピーが同様の方法でページ ゼロになるように、ページゼロ操作はトランザクション ログ ファイルに記録されます。 アクティブなデータベース コピーでページをゼロにすると、データベースのパッシブ コピーでページがゼロになります。
ページゼロは、ハード削除されたレコードにバイナリ パターンを書き込みます。 ページ ゼロパターンは、拡張記憶域エンジン (ESE) 操作 (Exchange のサーバーで使用される内部データベース エンジンの名前) に固有であり、実行時操作とバックグラウンド データベースメンテナンス操作では異なります。 (バックグラウンド データベースメンテナンスは、各データベースのチェックサムとスキャンを継続的に行うプロセスです。その主な機能は、データベース ページのチェックサムですが、ストアのクラッシュのためにゼロ化されなかったレコードやページの領域のクリーンアップとゼロ化も処理します)。
次の表に、特定の実行時操作に対応したパターンを一覧表示します。
ESE 実行時操作 | パターン |
---|---|
置換 | R |
レコード/長い値の削除 | D |
解放されたページ領域 | H |
次の表は、ESE バックグラウンド データベース保守で実行される特定の操作に対応したパターンの一覧です。
ESE バックグラウンド データベース保守操作 | パターン |
---|---|
レコードの削除 | D |
長い値の削除 | L |
部分的に使用されたページの解放されたページ領域 | Z |
未使用ページの解放されたページ領域 | U |
ページゼロ処理
ページゼロのプロセスは、削除シナリオによって異なります。 次の表に、データベースの削除のシナリオ、およびページ解放機能が実行される時点について説明します。
データベースの削除のシナリオ | データベース データを解放するための ESE プロセスと期間 |
---|---|
削除されたアイテムの保持期間に基づいて、アイテムの有効期限が切れます。 | 非同期のスレッドは、バイナリ パターンを削除されたデータに上書きします。 この操作はレコード削除の数ミリ秒以内に実行されます。 非同期ゼロ処理がまだ未処理である間にストア プロセスがクラッシュした場合 (またはバージョン ストアの増加によりバージョン ストアのクリーンアップが取り消された場合)、データベースのそのセクションをバックグラウンド データベースメンテナンスで処理すると、ゼロ化が完了します。 |
表示シナリオ: Outlook/Outlook on the Web フォルダー ビューのアイテムの有効期限 (会話ビューなど) | バックグラウンド データベース保守でデータベースのこのセクションが処理されたときに、データ解放が実行されます。 |
メールボックスの移動/メールボックスの削除シナリオ: ソース メールボックスが削除されました (削除されたメールボックスの有効期限) | バックグラウンド データベース保守でデータベースのこのセクションが処理されたときに、データ解放が実行されます。 |
ページゼロを使用しないメールボックス データ型
次のメールボックス データ型には、ページ ゼロのプロビジョニングはありません。
- メールボックス データベース トランザクション ログ - トランザクション ログが通常の操作の一部として削除されると、削除されたログ ファイルを格納したファイル システム内のブロックをゼロにするプロセスはありません。 ファイル システムは、新しく作成されたログの空き領域をすばやく再利用する可能性がありますが、これが発生する保証はありません。
- コンテンツ インデックス カタログ ファイル - Exchange では、検索インデックス作成機能に Search Foundation (FAST とも呼ばれます) が使用されます。 検索インデックス カタログは、メールボックス データベース ファイルと同じボリュームに格納されている数十個のファイルで構成されます。 メッセージがメールボックス データベースから物理的に削除されても、検索カタログ内の関連付けられているコンテンツはすぐには削除されません。 コンテンツの削除は、Search Foundation が 1 つの大きなファイルに多数の小さなカタログ ファイルのシャドウ (またはマスター マージ) を行う場合に発生します。 マスター結合が完了すると、小さいカタログ ファイルが削除されます。 削除されたカタログ ファイルを格納したブロックをゼロにするプロセスはありません。
継続的レプリケーション
継続的レプリケーション (ログ配布と再生とも呼ばれます) は、高可用性、サイトの回復性、ディザスター リカバリーを提供するために、すべてのメールボックス データベースのコピーを作成および管理する Exchange のテクノロジです。 継続的レプリケーションでは、Exchange Server データベースクラッシュ回復サポートを使用して、メールボックス データベースの 1 つ以上のコピーの非同期更新を実行するテクノロジを提供します。 各メールボックス サーバーは、アクティブなデータベース (ユーザー電子メール アクティビティなど) で行われたデータベース更新を、1 MB のトランザクション ログ ファイルのシーケンシャル セットのログ レコードとして記録します。 この一連のファイルは、ログ ストリームと呼ばれます。 継続的レプリケーションでは、ログ ストリームを使用して、データベースの 1 つ以上のコピーを非同期的に更新することもできます。 これは、アクティブ データベースのパッシブ コピーを含む場所にログを送信し、パッシブ データベース コピーに再生することで実現されます。 アクティブ データベースのすべてのログがデータベースのパッシブ コピーに対して再生される場合、2 つのデータベースは同等であり、このプロセスを通じて、アクティブ なデータベースに対して行われた物理変更が、そのデータベースのすべてのパッシブ コピーにレプリケートされます。
メールボックス データベースからの削除 (メールボックスアイテムまたはメールボックス全体、論理的な削除またはハード削除のいずれであっても) は、アクティブなデータベースに対する物理的な変更を表します。 ページ ゼロ化では、アクティブなデータベースに物理的な変更を加える必要もあります。 これらの変更は、連続レプリケーションと呼ばれるプロセスを通じてログ ファイルに書き込まれ、それらのログ ファイルがデータベースのパッシブ コピーに対して再生されると、それらのパッシブ データベースに対して同じ物理的な変更が行われます。