Platformハイブリッド、マルチクラウド環境のセキュアなバックアップと高速で信頼性の高い復元というソリューションを通じて、データの回復性を提供します。製品Veeamプラットフォームハイブリッド、マルチクラウド環境のセキュアなバックアップと高速で信頼性の高い復元というソリューションを通じて、データの回復性を提供します。365の保持タイプスナップショットベースの保持アイテムレベルの保持ワークフローの例フルバックアップ変更されていないファイルの増分バックアップ新しいファイルまたは変更されたファイルの増分バックアップ保持の適用時の削除についてバックアップジョブがオブジェクトの新しいリストアポイントの作成に失敗した場合ストレージについて重要なポイントのまとめ私は日々お客様をサポートするなかで、保持に関するあらゆる種類の質問を受けます。「保持の仕組み」や「...が発生した場合、どうなるのか?」などの基本的な質問から、「保持設定を変更しただけなのに、なぜバックアップが消えてしまったのだろう?」といった悪夢のような質問まで、その内容は多岐に渡ります。した経験を踏まえ、確信を持って言えることがあります。それは、保持ポリシーは最も重要なものである「バックアップデータ」に直接影響を与えるため、絶対に間違えてはならないということです。ご推察のことと思いますが、保持ポリシーの設定ミスにより、データが予定よりも早く削除されてしまったり、そもそもバックアップされていなかったりなどの事態を招くことがあります。365で使用可能な保持タイプの違いと、各保持タイプがバックアップ・ジョブ・サイクルの様々なポイントでそれぞれどのように機能するかについて説明します。365の保持タイプ選択できる保持タイプは2種類です。Agentの製品と同様の保持機能を提供するように設計されています。Replicationでは、バックアップされたデータのファイルレベルの構造によって多少の違いはあるものの、考え方は同じです。以下で選択される日数(または年数)が、リストアポイント全体がリポジトリに保存される期間に影響します。全てのリストアポイントには、バックアップジョブに追加されたあらゆるオブジェクトの完全なコピーが含まれます。時間が経過しても、保持によってこのコピーが変更されることはありません。365に保存されている全てのデータの正確なコピーを作成し、バックアップと保持の両方において、単一の変更されないエンティティとしてそのコピーを管理することを計画している場合に選択する必要があります。Onlineの保持ポリシーと同じように機能します。365のメールボックス内の全てのデータは、Exchange管理センターで設定された特定の日数の間、保存されます。その日数の間、データが変更されていなければ、設定に応じて削除されるか、メールボックスのアーカイブ部分に配置されます。アイテムレベルの保持でリポジトリに7日間の保持が設定されている場合、過去7日間で1回以上変更が行われたデータのみがバックアップされます。modified(変更日)]フィールドに古い情報が含まれているデータは全てスキップされます。このメカニズムは、ジョブが新しいリストアポイントを作成する際に適用されるのはもちろん、既存のリストアポイントの内容を確認し、変更日から7日を超えたファイルも削除します。365データだけでなく、その保持ルールも含めてレプリケートする場合に適しています。通常、特定のライフサイクルより古くなったデータを全て削除しなければならないといった法的要件を満たすために使用されます。単純にフルバックアップに必要なディスク容量を減らすためにも役立ちます。365では、OneDrive、SharePoint、Teamsにも適用できます。ワークフローの例これらの画像は、数日間のスパンで、両方の保持タイプが一般的なイベントや問題に遭遇した際の動きについて示しています。Businessを使用しているとします。その他の条件は次のとおりです。このユーザーのOneDriveとExchangeのデータは、別々のバックアップジョブを使用しているOneDriveのジョブは毎日午前1時(01時00分)に実行Exchangeのジョブは毎日午前2時(02時00分)に実行アイテムレベルのリポジトリの保持ポリシーは3日間に設定されているスナップショットベースのリポジトリの保持ポリシーは2日間に設定されている両リポジトリに対し、毎日午前0時1分(00時01分)に保持ポリシーが適用されるように設定されているフルバックアップ新しく作成されたジョブの初回のセッションで、フルバックアップが行われます。00時01分:保持ポリシーが適用されますが、リポジトリが空であるため、何も実行されません。スナップショットベースの保持このジョブは、本番環境に存在する全てのアイテムを、実行のたびにバックアップします。01時00分:OneDriveのジョブが開始され、全てのファイルがバックアップされます。02時00分:Exchangeのジョブが開始され、全てのファイルがバックアップされます。アイテムレベルの保持これは、変更日から3日以内のアイテムのみをバックアップします。01時00分:OneDriveのジョブが開始され、アイテム「4.log」のみがバックアップされます。これは、他の2つのアイテムの変更日が3日以上前であるためです。02時00分:Exchangeのジョブが開始され、アイテム「2.msg」と「3.msg」がバックアップされます。これは、この2つのメッセージが3日以内に受信されているためです。365に変更が行われていないと考えて、次の実行時に何が起こるかを見てみましょう。01時00分:OneDriveのジョブが開始。365から同じデータを再ダウンロードする代わりに、元のアイテムへの参照を新しいリストアポイントに作成します。02時00分:Exchangeのジョブが開始。365から同じデータを再ダウンロードする代わりに、元のアイテムへの参照を新しいリストアポイントに作成します。01時00分:OneDriveのジョブが開始。365から同じデータを再ダウンロードする代わりに、元のアイテムへの参照を新しいリストアポイントに作成します。02時00分:Exchangeのジョブが開始。365から同じデータを再ダウンロードする代わりに、元のアイテムへの参照を新しいリストアポイントに作成します。新しいファイルまたは変更されたファイルの増分バックアップ既存のファイルが変更された場合や、新しいファイルが作成された場合、ジョブはそれに対応して既存のレコードをアップデートしたり、新しいファイルを作成したりします。メールボックスに誰かから新しいメッセージが届くと、次のジョブ実行時にそのメッセージの新しいレコードがリポジトリに作成されます。02時00分:Exchangeのジョブが開始。365から同じデータを再ダウンロードする代わりに、元のアイテムへの参照を新しいリストアポイントに作成します。01時00分:OneDriveのジョブが開始。365から同じデータを再ダウンロードする代わりに、元のファイルへの参照を新しいリストアポイントに作成します。「1.docx」アイテムの変更日が3日以内となっているため、このアイテムもバックアップします。02時00分:Exchangeのジョブが開始。365から同じデータを再ダウンロードする代わりに、元のファイルへの参照を新しいリストアポイントに作成します。保持の適用時の削除についてそれでは、両方のポリシーの動作を確認してみましょう。この時点までに、既にいくつかの日次の保持チェックが行われていますが、これまでの実行ではファイルが削除されなかったため、今回は意図的にこの特定の保持チェックをお見せします。00時01分:保持ポリシーが適用。00時01分より前に作成されたバックアップが全て削除されます。これは、バックアップの日時が48時間以上経過しているためです。00時01分:保持ポリシーが適用。既存の全てのリストアポイントから、「4.log」、「2.msg」、「3.msg」が削除されます。これらの変更日フィールドの日付が3日以上経過しているためです。バックアップジョブがオブジェクトの新しいリストアポイントの作成に失敗した場合このような場合、ジョブは新しいリストアポイントの作成を続行せずに、保持の適用を延期します。どちらの保持タイプでも同じように動作しますが、スナップショットベースのシナリオを確認してみましょう。01時00分:OneDriveのジョブが開始したが、技術的な問題(サーバーがインターネットから切断されるなど)により全てのオブジェクトで即座に失敗。02時00分:Exchangeのジョブでも同様の現象が発生。00時01分:保持ポリシーが適用。00時01分より前に作成されたバックアップが全て削除されます。これは、バックアップの日時が48時間以上経過しているためです。01時00分:OneDriveのジョブが開始したが、同じ理由により再び失敗。02時00分:Exchangeのジョブでも同様の現象が発生。11時00分:バックアップの失敗の原因となっていた問題が確認され、修正。00時01分:保持ポリシーが適用。ファイルのバックアップの日時が48時間の保持期間を過ぎても、ファイルはリポジトリから削除されません。これは保持ポリシーにより、バックアップの実行が失敗した場合は、新しいバックアップが作成されるまで最後に成功したバックアップが保持されるために発生します。01時00分:OneDriveのジョブが開始し、新しいリストアポイントの作成に成功。その後、8月24日に作成されたリストアポイントは保持ポリシーに適合しなくなったために削除され、同時に新しいリストアポイントが正常に作成されたことを確認できました。02時00分:Exchangeのジョブでも同様の現象を確認。このルールは、問題が発生しているジョブにのみ適用されることを理解することが重要です。UIでジョブが無効になっているだけでは、保持は一時停止されません。ストレージについてローカルのVeeamリポジトリのフォルダを開いたことがあれば、実際にバックアップされたメールやOneDriveのドキュメントが個別のファイルとして含まれていないことに気付かれたのではないでしょうか。代わりに、このような構造になっています。これらの各フォルダには、repository.adbというデータベースコンテナがあり、そこにバックアップされたデータが全て格納されます。365の変更日フィールドに基づいて選択されます。このような手法では、保持によりバックアップされたデータがリポジトリから削除されても、ほとんどの場合において、ディスク上の実際のスペースが削除されるのではなく、該当のrepository.adbコンテナのデータブロックが空としてマークされるだけです。保持によってコンテナ内の全てのデータが削除された場合にのみ、コンテナ自体が削除されます。削除されて空になった部分は、新しいバックアップに再利用されます。上述のストレージの特性は、まったく異なるアーキテクチャであるために、オブジェクトストレージのリポジトリには影響しません。これについては、別の記事で取り上げるべき内容であると考えています。重要なポイントのまとめ保持タイプは両方ともそれぞれの目的に適しているため、どちらかを選択する前に、バックアップ要件を定めることをおすすめします。Forever(恒久的に保持)]が設定されていない場合、どちらの保持タイプもバックアップされたデータをある時点で削除します。アイテムレベルの保持ではバックアップするデータを定義することもできます。ローカルリポジトリの場合、保持がデータを削除した直後は、実際のディスク容量が解放されないことがあります。365を実際に体験してみませんか?是非、30日間の無償評価版をダウンロードしてお試しください。365については、録画版オンラインセミナーや製品デモも併せてご覧ください。365関連ソリューションの企画・開発を経験。プログラムのエンジニアとして、主にサービスプロバイダ様に向けにVeeam製品活用のご支援を行う。日本語Englishブログの更新情報を週1回受け取る登録することで、Veeamのプライバシーポリシーに従って当社が個人情報を管理することに同意するものとします。Veeamブログ最新情報の配信登録をしていただき、ありがとうございます。最新情報がつまったVeeamブログのまとめを毎週配信します。登録することで、Veeamの製品やイベントに関するお知らせを受け取ること、また、プライバシー通知に従ってVeeamが個人情報を管理することに同意したものと見なれます。登録の解除はいつでも可能です。