Veeam Japanブログ

Veeam Backup for Microsoft Office 365の保持タイプの詳細について

　私は日々お客様をサポートするなかで、保持に関するあらゆる種類の質問を受けます。「保持の仕組み」や「…が発生した場合、どうなるのか？」などの基本的な質問から、「保持設定を変更しただけなのに、なぜバックアップが消えてしまったのだろう？」といった悪夢のような質問まで、その内容は多岐に渡ります。こうした経験を踏まえ、確信を持って言えることがあります。それは、保持ポリシーは最も重要なものである「バックアップデータ」に直接影響を与えるため、絶対に間違えてはならないということです。既にご推察のことと思いますが、保持ポリシーの設定ミスにより、データが予定よりも早く削除されてしまったり、そもそもバックアップされていなかったりなどの事態を招くことがあります。

　この記事では、Veeam Backup for Microsoft Office 365で使用可能な保持タイプの違いと、各保持タイプがバックアップ・ジョブ・サイクルの様々なポイントでそれぞれどのように機能するかについて説明します。

　Veeam Backup for Microsoft Office 365の保持タイプ

　選択できる保持タイプは2種類です。

スナップショットベースの保持

　この保持タイプは、Veeam Backup & ReplicationおよびVeeam Agentの製品と同様の保持機能を提供するように設計されています。Veeam Backup & Replicationでは、バックアップされたデータのファイルレベルの構造によって多少の違いはあるものの、考え方は同じです。以下で選択される日数（または年数）が、リストアポイント全体がリポジトリに保存される期間に影響します。

　全てのリストアポイントには、バックアップジョブに追加されたあらゆるオブジェクトの完全なコピーが含まれます。また、時間が経過しても、保持によってこのコピーが変更されることはありません。

　このタイプの保持は、Office 365に保存されている全てのデータの正確なコピーを作成し、バックアップと保持の両方において、単一の変更されないエンティティとしてそのコピーを管理することを計画している場合に選択する必要があります。

アイテムレベルの保持

　この保持タイプは、Exchange Onlineの保持ポリシーと同じように機能します。

　Office 365のメールボックス内の全てのデータは、Exchange管理センターで設定された特定の日数の間、保存されます。その日数の間、データが変更されていなければ、設定に応じて削除されるか、メールボックスのアーカイブ部分に配置されます。

　例えば、アイテムレベルの保持でリポジトリに7日間の保持が設定されている場合、過去7日間で1回以上変更が行われたデータのみがバックアップされます。

　[Date modified（変更日）]フィールドに古い情報が含まれているデータは全てスキップされます。またこのメカニズムは、ジョブが新しいリストアポイントを作成する際に適用されるのはもちろん、既存のリストアポイントの内容を確認し、変更日から7日を超えたファイルも削除します。

　この保持タイプは、例えば、Office 365データだけでなく、その保持ルールも含めてレプリケートする場合に適しています。通常、特定のライフサイクルより古くなったデータを全て削除しなければならないといった法的要件を満たすために使用されます。また、単純にフルバックアップに必要なディスク容量を減らすためにも役立ちます。

　この選択肢は、Office 365のExchangeメールボックス、およびオプションでそのアーカイブに対してのみ機能しますが、Veeam Backup for Microsoft Office 365では、OneDrive、SharePoint、Teamsにも適用できます。

ワークフローの例

　これらの画像は、数日間のスパンで、両方の保持タイプが一般的なイベントや問題に遭遇した際の動きについて示しています。

　ここではわかりやすく、あるユーザーが、3件のメッセージが入ったメールボックスと、3件のファイルが保存されたOneDrive for Businessを使用しているとします。

　その他の条件は次のとおりです。

1. このユーザーのOneDriveとExchangeのデータは、別々のバックアップジョブを使用している
　　・OneDriveのジョブは毎日午前1時（01時00分）に実行
　　・Exchangeのジョブは毎日午前2時（02時00分）に実行
2. アイテムレベルのリポジトリの保持ポリシーは3日間に設定されている
3. スナップショットベースのリポジトリの保持ポリシーは2日間に設定されている
4. 両リポジトリに対し、毎日午前0時1分（00時01分）に保持ポリシーが適用されるように設定されている

フルバックアップ

　新しく作成されたジョブの初回のセッションで、フルバックアップが行なわれます。

　2019年8月22日 00時01分：保持ポリシーが適用されますが、リポジトリが空であるため、何も実行されません。

スナップショットベースの保持

　このジョブは、本番環境に存在する全てのアイテムを、実行のたびにバックアップします。

　2019年8月22日 01時00分：OneDriveのジョブが開始され、全てのファイルがバックアップされます。

　2019年8月22日 02時00分：Exchangeのジョブが開始され、全てのファイルがバックアップされます。

アイテムレベルの保持

　これは、変更日から3日以内のアイテムのみをバックアップします。

　2019年8月22日 01時00分：OneDriveのジョブが開始され、アイテム「4.log」のみがバックアップされます。これは、他の2つのアイテムの変更日が3日以上前であるためです。

　2019年8月22日 02時00分：Exchangeのジョブが開始され、アイテム「2.msg」と「3.msg」がバックアップされます。これは、この2つのメッセージが3日以内に受信されているためです。

変更されていないファイルの増分バックアップ

　では、Office 365に変更が行なわれていないと考えて、次の実行時に何が起こるかを見てみましょう。

スナップショットベースの保持

　2019年8月23日 01時00分：OneDriveのジョブが開始。Veeamの変更の追跡機能を使用し、全てのアイテムが前回の実行時に既にバックアップされていること、および前回と今回のジョブの実行の間に変更が行われていないことを確認して、Office 365から同じデータを再ダウンロードする代わりに、元のアイテムへの参照を新しいリストアポイントに作成します。

　2019年8月23日 02時00分：Exchangeのジョブが開始。Exchange Web Servicesの変更の追跡機能を使用し、全てのアイテムが前回の実行時に既にバックアップされていること、および前回と今回のジョブの実行の間に変更が行なわれていないことを確認して、Office 365から同じデータを再ダウンロードする代わりに、元のアイテムへの参照を新しいリストアポイントに作成します。

アイテムレベルの保持

　2019年8月23日 01時00分：OneDriveのジョブが開始。Veeamの変更の追跡機能を使用し、「4.log」が前回の実行時に既にバックアップされていること、および前回と今回のジョブの実行の間に変更が行われていないことを確認して、Office 365から同じデータを再ダウンロードする代わりに、元のアイテムへの参照を新しいリストアポイントに作成します。

2019年8月23日 02時00分：Exchangeのジョブが開始。Exchange Web Servicesの変更の追跡機能を使用し、「2.msg」と「3.msg」が前回の実行時に既にバックアップされていること、および前回と今回のジョブの実行の間に変更が行われていないことを確認して、Office 365から同じデータを再ダウンロードする代わりに、元のアイテムへの参照を新しいリストアポイントに作成します。

新しいファイルまたは変更されたファイルの増分バックアップ

　既存のファイルが変更された場合や、新しいファイルが作成された場合、ジョブはそれに対応して既存のレコードをアップデートしたり、新しいファイルを作成したりします。

　例えば、メールボックスに誰かから新しいメッセージが届くと、次のジョブ実行時にそのメッセージの新しいレコードがリポジトリに作成されます。

スナップショットベースの保持

　2019年8月23日 14時20分：このユーザーに新しいメールが届き、それが他のアイテムと一緒に保存される

　2019年8月24日 02時00分：Exchangeのジョブが開始。Exchange Web Servicesの変更の追跡機能を使用し、全てのアイテムが前回の実行時に既にバックアップされていること、および前回と今回のジョブの実行の間に変更が行なわれていないことを確認して、Office 365から同じデータを再ダウンロードする代わりに、元のアイテムへの参照を新しいリストアポイントに作成します。

アイテムレベルの保持

　2019年8月23日 14時20分：このユーザーに新しいメールが届き、それが他のアイテムと一緒に保存される

　2019年8月24日 01時00分：OneDriveのジョブが開始。Veeamの変更の追跡機能を使用し、「4.log」が前回の実行時に既にバックアップされていること、および前回と今回のジョブの実行の間に変更が行われていないことを確認して、Office 365から同じデータを再ダウンロードする代わりに、元のファイルへの参照を新しいリストアポイントに作成します。また、「1.docx」アイテムの変更日が3日以内となっているため、このアイテムもバックアップします。

　2019年8月24日 02時00分：Exchangeのジョブが開始。Exchange Web Servicesの変更の追跡機能を使用し、「2.msg」と「3.msg」が前回の実行時に既にバックアップされていること、および前回と今回のジョブの実行の間に変更が行なわれていないことを確認して、Office 365から同じデータを再ダウンロードする代わりに、元のファイルへの参照を新しいリストアポイントに作成します。

保持の適用時の削除について

　それでは、両方のポリシーの動作を確認してみましょう。この時点までに、既にいくつかの日次の保持チェックが行われていますが、これまでの実行ではファイルが削除されなかったため、今回は意図的にこの特定の保持チェックをお見せします。

スナップショットベースの保持

　2019年8月25日 00時01分：保持ポリシーが適用。2019年8月23日 00時01分より前に作成されたバックアップが全て削除されます。これは、バックアップの日時が48時間以上経過しているためです。　

アイテムレベルの保持

　2019年8月25日 00時01分：保持ポリシーが適用。既存の全てのリストアポイントから、「4.log」、「2.msg」、「3.msg」が削除されます。これらの変更日フィールドの日付が3日以上経過しているためです。

バックアップジョブがオブジェクトの新しいリストアポイントの作成に失敗した場合

　このような場合、ジョブは新しいリストアポイントの作成を続行せずに、保持の適用を延期します。

　どちらの保持タイプでも同じように動作しますが、スナップショットベースのシナリオを確認してみましょう。

　2019年8月25日 01時00分：OneDriveのジョブが開始したが、技術的な問題（サーバーがインターネットから切断されるなど）により全てのオブジェクトで即座に失敗。

　2019年8月25日 02時00分：Exchangeのジョブでも同様の現象が発生。

　2019年8月26日 00時01分：保持ポリシーが適用。2019年8月24日 00時01分より前に作成されたバックアップが全て削除されます。これは、バックアップの日時が48時間以上経過しているためです。

　2019年8月26日 01時00分：OneDriveのジョブが開始したが、同じ理由により再び失敗。

　2019年8月26日 02時00分：Exchangeのジョブでも同様の現象が発生。

　2019年8月26日 11時00分：バックアップの失敗の原因となっていた問題が確認され、修正。

　2019年8月27日 00時01分：保持ポリシーが適用。ファイルのバックアップの日時が48時間の保持期間を過ぎても、ファイルはリポジトリから削除されません。これは保持ポリシーにより、バックアップの実行が失敗した場合は、新しいバックアップが作成されるまで最後に成功したバックアップが保持されるために発生します。

　2019年8月27日 01時00分：OneDriveのジョブが開始し、新しいリストアポイントの作成に成功。その後、8月24日に作成されたリストアポイントは保持ポリシーに適合しなくなったために削除され、同時に新しいリストアポイントが正常に作成されたことを確認できました。

　2019年8月27日 02時00分：Exchangeのジョブでも同様の現象を確認。

　このルールは、問題が発生しているジョブにのみ適用されることを理解することが重要です。UIでジョブが無効になっているだけでは、保持は一時停止されません。

ストレージについて

　ローカルのVeeamリポジトリのフォルダを開いたことがあれば、実際にバックアップされたメールやOneDriveのドキュメントが個別のファイルとして含まれていないことに気付かれたのではないでしょうか。代わりに、このような構造になっています。

　これらの各フォルダには、repository.adbというデータベースコンテナがあり、そこにバックアップされたデータが全て格納されます。特定のファイルのコンテナは、Office 365の変更日フィールドに基づいて選択されます。

　このような手法では、保持によりバックアップされたデータがリポジトリから削除されても、ほとんどの場合において、ディスク上の実際のスペースが削除されるのではなく、該当のrepository.adbコンテナのデータブロックが空としてマークされるだけです。そして、保持によってコンテナ内の全てのデータが削除された場合にのみ、コンテナ自体が削除されます。なお、削除されて空になった部分は、新しいバックアップに再利用されます。

　上述のストレージの特性は、まったく異なるアーキテクチャであるために、オブジェクトストレージのリポジトリには影響しません。これについては、別の記事で取り上げるべき内容であると考えています。

重要なポイントのまとめ

・保持タイプは両方ともそれぞれの目的に適しているため、どちらかを選択する前に、バックアップ要件を定めることをおすすめします。

・ [Keep Forever（恒久的に保持）]が設定されていない場合、どちらの保持タイプもバックアップされたデータをある時点で削除します。また、アイテムレベルの保持ではバックアップするデータを定義することもできます。

・ローカルリポジトリの場合、保持がデータを削除した直後は、実際のディスク容量が解放されないことがあります。

　Veeam Backup for Microsoft Office 365を実際に体験してみませんか？是非、30日間の無償評価版をダウンロードしてお試しください。

■関連サイト

• Veeamブログ
• Veeam Software