第10回 Commvaultがバックアップしたデータの保持期限はどのように決まるの?

第10回となる今回は、「Commvaultがバックアップしたデータの保持期限はどのように決まるの?」と題して、Commvaultを使用してバックアップされたデータがいつまで保存されるのかについてご説明します。

Commvaultでは、ストレージ ポリシーの設定によりバックアップされたデータの保持期限が決まります。今回は、まずストレージ ポリシーについて概要を説明し、その後、ストレージ ポリシー内で指定する設定 (「日」と「サイクル」の値) の意味について説明し、その後、簡単な例を通してデータの保持期限の仕組みについてご説明していきます。

(1) ストレージ ポリシーの概要

最初に、ストレージ ポリシーについて簡単にご紹介しておきます。ストレージ ポリシーは、Commvaultでバックアップされたデータがどのように管理されるかを定義するルールの集合体です。これらのルールには、以下のものが含まれます。

  • どのデータを保護するか (どのサブクライアントとストレージ ポリシーを関連付けるか) 。
  • どこにデータを保存するか。
  • どのくらいの期間、データを保存するか。
  • その他のメディア管理のオプション (例: 重複排除や暗号化の使用の有無等)

「どのくらいの期間、データを保存するか。」が、バックアップされたデータの保持期限を定義するルールとなります。Commvaultを運用したり構築したりされている方であれば、ストレージ ポリシーの作成時に以下の設定項目があるのを覚えておられるのではないでしょうか。 

この「日」と「サイクル」の数値の設定により、バックアップされたデータの保持期限が決まります。これだけでは具体的にどうなるかをイメージできないと思いますので、次にこの「日」と「サイクル」の意味するところは何かをご説明していきます。 

(2) ストレージ ポリシーで定義した「日」と「サイクル」

「日」の設定ですが、バックアップが保持される最小の日数を意味します。文字通りの意味でこれ以上ご説明することもないため、「サイクル」の説明に移ります。

「サイクル」の設定ですが、このサイクルは、フルバックアップ (または合成フルバックアップ) とそれ以降のフルバックアップに依存するバックアップの1セットを意味します。

簡単な例で「サイクル」をご説明します。週に1回、日曜日にフルバックアップ (初回以降の日曜日には合成フルバックアップ) を実行し、月曜日から土曜日の間は日に1回の増分バックアップを行う運用をイメージしてみてください。この運用で、ある日曜日からバックアップを開始し、翌週の火曜日まで10日間運用を継続したとします。そうすると、この10日間のバックアップの状況は以下の図のようになります。 

この例の場合、バックアップ運用を開始した最初の日曜日 (フルバックアップ) から土曜日までが1サイクル、次の日曜日 (合成フルバックアップ) から火曜日までが1サイクルとなります。 

取得したバックアップがいつまで保持されるかの考え方ですが、基本的には、「日」の値と「サイクル」の値の両方を超えたバックアップが削除対象となり得る、ということになります。また、1サイクルの長さはフルバックアップ (または合成フルバックアップ) の実施間隔となりますので、どのバックアップが削除対象となるかを考える場合は、「日」の値、「サイクル」の値、及び、フルバックアップ (または合成バックアップ) の実施間隔が重要なポイントとなります。 

(3) 例題で考える保持期限

ここからは簡単な例題で保持期限を考えていきます。この例では、以下の設定でのバックアップ運用を例に考えます。

  • 「日」の値:15
  • 「サイクル」の値:2
  • フルバックアップ (または合成バックアップ) の実施間隔: 7日。初回はフルバックアップを取得し、以降は7日ごとに合成フルバックアップを取得するものとする。
  • フルバックアップ (または合成バックアップ) を取得する以外の日は1日1回増分バックアップを取得 

この設定で25日間、運用を継続したとします。1日目に初回のフルバックアップが実行されたとすると、それぞれの日に実行されるバックアップは以下の表のようになります。

「日」の値は15なので、11日目から25日目までのバックアップが「日」の設定による保持の対象となります。「サイクル」の値は2なので、15日目から25日目までのバックアップが「サイクル」の設定による保持の対象となります。

分かりやすくするため、「日」と「サイクル」の各設定による保持の対象となるものをYes (緑色) 、保持の対象とならないものをNo (赤色) で表にすると以下のようになります。

既にご説明した通り、ストレージ ポリシーの「日」の値と「サイクル」の値の両方を超えたバックアップが削除対象となり得ます。そうすると、1日目から10日目のバックアップが削除対象とされる、ということになりですが、実はそうではなく、8日目から10日目までのバックアップも保持されます。この例で、いつまでのバックアップが削除対象となるかを考えると以下の表のようになります。  

「日」の値と「サイクル」の値の両方を超えたバックアップである8日目から10日目のバックアップがなぜ保持されるのかを簡単に説明しておきます。

増分バックアップは、前回のバックアップ以降に新規に作成されたファイルや変更されたファイルのみをバックアップしています。言い換えると、増分バックアップはそれ以前に実行されたフルバックアップ (合成フルバックアップ) や増分バックアップに依存しているということができます。

具体例で考えてみます。例えば、11日目の時点での全データをリストアしたいとします。もし、仮に8日目から10日目までのバックアップが存在していないとすると、11日目の時点の全データをリストアできるでしょうか。これはできないということになります。このような状況がおきないように、Commvaultは「日」や「サイクル」の設定に加え、リストアに必要なデータを保持する、という考え方でデータを保持しています。 

今回はバックアップしたデータの保持期限をテーマとしたブログにしましたが、いかがでしたでしょうか。難しく感じた方もいらっしゃるでしょうし、保持期限の考え方をご存知の方でも頭の中だけで考えていると訳が分からなくなるように感じたかたもいらっしゃるでしょう。

実は、Commvaultのオンライン マニュアル上に「日」や「サイクル」の値、フルバックアップの実施間隔日数などを入力すると、どのバックアップが削除対象となるのかを比較的わかりやすく表示してくれるスプレッドシートを入手可能です。ご興味のある方は、こちらの「Spreadsheet for Calculating Retention」の項をご参照ください。 

このブログはベーシックな保持期限の考え方の説明とさせていただいたので、「重複排除実施時にはどうなるのか?」というような細かい話はあえて割愛して説明しました。手短に説明すると、重複排除を使用している場合は、バックアップされたデータはブロックに分割され、一意なブロックのみが保存されています。このような状態で保存されているブロックは、どのバックアップからも参照されなくなった時点で削除の対象となります。重複排除時にどうなるかについてご興味のある方は、こちらの「Data Aging for Deduplication」の項をご参照ください。

また、ベーシックな保持期限の考え方は共通しているものの、使用するCommvaultのエージェントに応じたルールも多少存在しています。こちらから確認いただけますので、ご興味のある方は適宜ご参照ください。細かい話をし始めるときりがなくなりますので、このブログではここまでにしておきます。
  

※このブログでご紹介している画面ショットは、Commvault v11 Service Pack 13の環境で確認したものです。

【参考資料】

前回の記事へ | 次の記事へ>

Posted on 2019.01