はじめに

記事の内容を明確にするために、まずは2つの用語について説明いたします。

バックアップ タイプは、アーカイブの中でデータを保管する際の方式を示します。バックアップ タイプは、「完全」、「増分」および「差分」があります。完全バックアップには、バックアップの作成時にバックアップ対象のロケーションに存在するすべての情報が保存されます。差分バックアップには、最後の完全バックアップの作成後に行われた変更のみ保存されます。また、増分バックアップには、前回の成功したバックアップの作成後に行われた変更が保存されます。詳細については、完全バックアップ、増分バックアップ、差分バックアップの違いをご参照ください。

バックアップ セットは、バックアップが開始された具体的なスケジュールおよび条件を示します。バックアップ セットはバックアップの内容の保管方法とは関係ないため、バックアップ セットを扱う場合は、バックアップ タイプを考慮する必要はありません。　

バックアップの保持をめぐる計算では、バックアップ セットのみ使われます。保持がそれぞれのバックアップ タイプおよびバックアップされたデータに与える影響について知りたい場合は、アーカイブ12 フォーマットに関する説明をご参照ください。　

保持ルール

バックアップ スキームおよびバックアップ タイプとの関係

バックアップ計画のスケジュールによって、特定のアーカイブに使われるバックアップ スキームおよびバックアップ セットの種類が指定されます。

用語集:

バックアップ セットとは、個別の保持ルールを適用できるバックアップ グループのことです。「カスタム」というバックアップスキームでは、バックアップ セットはバックアップ方法（「完全」、「差分」、「増分」）を意味します。それ以外の場合、バックアップ セットは「月単位」、「日単位」、「週単位」、「1時間ごと」のことです。

月単位のバックアップとは、月が始まってから最初に作られたバックアップのことです。

週単位のバックアップとは、週単位のバックアップというオプション（歯車アイコン -> [バックアップ オプション] -> [週単位のバックアップ]）で指定した曜日に最初に作られたバックアップのことです。週単位のバックアップはそれと同時に月が始まってから最初に作られたバックアップでもある場合は、そのバックアップは月単位のバックアップとして見なされます。その場合、週単位のバックアップは次の週の指定された曜日に作成されます。

日単位のバックアップとは、日が始まってから最初に作られたバックアップのことです（月単位または週単位のバックアップの定義に当てはまるバックアップは除く）。

1時間ごとのバックアップとは、1時間が始まってから最初に作られたバックアップのことです（月単位、週単位または日単位のバックアップの定義に当てはまるバックアップは除く）。

デフォルトの設定では、保持ルールはバックアップ セットに対して適用され、直接そのバックアップ セットと結び付けられています。任意の保持ルールを作ることで、お客様のニーズに合わせてこのアルゴリズムを調整できます。

保持ルールには、現在のバックアップスキームおよびスケジュールに適用できるセットのルールのみ含まれます。予想していたセットが保持ルールの設定で見つからなかった場合は、まずはスケジュールの設定をチェックしてください。また、特定の保持ルールが特定のアーカイブ タイプやバックアップ先に適用されないことがありますので、その制限を考慮してください（詳細については、ユーザーガイドをご参照ください）。

保持ルールの種類

• バックアップ期間: 各バックアップ セットに個別のルールを使用するか、すべてのセットに単一ルールを使用できます。
• バックアップの数: 保存するバックアップの正確な数を指定します。
• バックアップの合計サイズ別: アーカイブが指定のサイズになったとき、保持ルールが適用されます。
• バックアップを無期限に保存する: 保持ルールは無効です。

最後の３つのルールは単純であり、詳細な説明を必要としません。そのため、この記事の残りでは、主に「バックアップ期間」という最初のルールに焦点を当てていきます。

バックアップの数: アーカイブの中に保存されているバックアップの数がセットのしきい値（最大数）を超えたとき、保持ルールが適用されます。ユーザーは、保持ルールの適用タイミング（バックアップ前かバックアップ後）を選択できます。また、すべての時点において対象のアーカイブの中に１つのバックアップだけ残るように、バックアップの最大数を１（バックアップ後）または０（バックアップ前）にすることもできます。

バックアップの合計サイズ別: アーカイブの中に保存されているバックアップの数がセットのしきい値（最大のサイズ）を超えたとき、保持ルールが適用されます。ソフトウェアは、アーカイブがしきい値を超えないサイズになるまで、あるいは、アーカイブの中に１つのバックアップだけ残るまで、最も古いバックアップから順に削除しようとします。唯一のバックアップのサイズが指定の値を超える場合は、アーカイブのサイズも指定の値を超えますが、しきい値などの設定が調整されるまでそのバックアップを保持します。

バックアップ期間（詳細）

すべてのバックアップ セットに単一ルールを使用する場合

最も簡単な方法は、すべてのバックアップ セットに１つのルールを使用することです。数および測定単位（週、日、月、時間など）を選択することで、ユーザーは正確なバックアップ期間を指定します。このルールはすべてのバックアップ セットに適用されるため、曖昧さはなくなりますが、その分、柔軟性も低下します。

各バックアップ セットに個別のルールを使用する場合

最も柔軟で複雑な方法は、各バックアップセットに個別のルールを指定することです。「カスタム」というバックアップスキームを使用すると、ルールはバックアップ タイプ（「完全」、「差分」、「増分」）ごとに指定されます。保持ルールの設定では、現在のバックアップスキームに適用できるバックアップ セットのみ使用可能として表示されます。たとえば、「週単位完全、日単位増分」というスキームには「月単位」というセットは含まれていないため、そのスキームの場合、保持ルールには月単位の設定は含まれず、「週単位」と「日単位」というセットにのみ保持ルールを設定できます。

バックアップが作成されるたびに、ソフトウェアは保持目的でこの具体的なバックアップの現在のバックアップ セットを定義します。時間が経ってもこの値は変わりません。現在のバックアップのバックアップ セットが定義されるアルゴリズムについては、用語集をご参照ください。

バックアップ前またはバックアップ後に「保持ルールの適用」という過程が始まる前に、ソフトウェアは現在のアーカイブに含まれるアーカイブをチェックし、指定の保持ルールに基づいて削除対象のバックアップを特定します。これらのバックアップはバックアップチェーンから外され、アーカイブに残った参照されないデータはまとめられるか、削除されます。

より正確にこの過程を理解するために、現在アーカイブに保存されている各バックアップのバックアップ セットを特定する必要があります。その際、以下の例を参考にできます。

一般的な確認手順　

特定のバックアップに保持ルールが適用されるかどうか確認するために、以下のパターンに従ってください:

1. 必要なバックアップのセットを特定します:
   
   1. カスタム スキームの場合は、スケジュールを確認して、そのバックアップは「完全」、「差分」、「増分」のどちらなのか確認します。
   2. 他のスキームの場合は、セットの定義（用語集をご参照ください）に基づいて、そのバックアップが「月単位」、「週単位」、「日単位」、「1時間ごと」なのか、それともそのどちらでもないのか確認します。
   3. スケジュールに従って実行されている際、スキップされたバックアップまたは失敗したバックアップがあった場合、その次に行われ成功したバックアップはこの論理においてその代わりになります。　
2. 保持ルールが適用される時間をチェックします。バックアップ期間（バックアップが作成されてから経った時間）がチェックされるのは、バックアップ操作が始まったときではなく、保持ルールが適用されるときなので、保持ルールが適用される正確な時間を調べる必要があります。
3. 保持の過程が開始されたタイミングに基づいて、必要なバックアップのバックアップ期間を特定します（満〇〇年、月、週、日、時間）。
4. このバックアップのバックアップ期間を、そのセット用に指定されている保持ルールの内容と対照します（すべてのセットに単一ルールが使用されている場合は、バックアップ期間をそのルールと対照します）:
   
   1. バックアップ期間の値は対象のセットのルールより少しでも大きい場合は、このバックアップは保持ルールの適用対象になります。たとえば、1カ月1分は、1カ月より大きいと見なされます。
   2. そうでない場合は、このバックアップは保持ルールの適用対象ではありません。

注意事項:

• 保持の論理とは別に、ユーザーはバックアップのタイプまたはセットに拘わらずチェーン内の任意のバックアップを手動で削除できます。セットは変わらないので、手動で特定のバックアップを削除しても、保持の論理には影響はありません。たとえば、保持ルールの適用対象ではない月単位のバックアップを削除しても、その後の日単位バックアップや週単位バックアップは代わりに月単位バックアップになることはありません。一方、保持ルールに従ってこの月の残りのバックアップが削除されることがあり、その期間のバックアップは完全になくなる可能性があります　
• Acronis Cyber Protect Cloud の現在の実装では、保持はいつもバックアップ計画の一部となります。何らかの理由でバックアップ計画が実行されないか、失敗したか、保持が始まる前に中断された場合は、保持ルールも適用されません。また、無効になったバックアップ計画や取り消されたバックアップ計画にも保持ルールは適用されません。この製品の今後のバージョンには、個別の保持計画を導入する予定です。
• すでに実行されているバックアップの保持ルールを変更すると、その変更はバックアップ ジョブが次に開始されるときに適用されます。すでに保持ルールの適用対象になっているがまだ削除されていないバックアップの削除を避けるためには、バックアップ操作を完全に取り消してください。それから、保持ルールの設定を変更して、その変更を保存してから、再度バックアップを開始してください。

例

デフォルト（常に完全、シングルファイル；月単位 6カ月、週単位 4週間、日単位 7日間）

今日は2021年2月16日で、バックアップは2020年6月1日に開始されたとしましょう。バックアップは失敗なしで毎日行われており、月単位バックアップは月曜日の設定です。そうすると、以下の仕組みになります:

• 「月単位」セット:
  • 2020年6月1日（バックアップ期間は8ヵ月+14日間、6カ月より大きい、削除済み）
  • 2020年7月1日（バックアップ期間は7ヵ月+14日間、6カ月より大きい、削除済み）
  • 2020年8月1日（バックアップ期間は6ヵ月+14日間、6カ月より大きい、削除済み）
  • 2020年9月1日（バックアップ期間は5ヵ月+14日間、6カ月より少ない、現存）
  • 2020年10月1日、2020年11月1日、2020年12月1日、2021年1月1日、2021年2月1日（6カ月より少ない、現存）
• 「週単位」セット:
  • 2021年1月18日までの月曜日（1月18日でバックアップ期間は4週間+1日になるので、4週間より大きい → 削除済み）
  • 2021年1月25日（バックアップ期間は3週間+1日、4週間より少ない、現存）
  • 2021年2月1日（2020年6月1日と同様に月単位として定義されたため、週単位のセットとして見なされない → 週単位のセットの保持ルールは無視）
  • 2021年2月8日、2021年2月15日（4週間より少ない、現存）
• 「日単位」セット:
  • 2021年2月8日までの日単位バックアップ（バックアップ期間は7日間より大きい、削除済み）
  • 2021年2月9日（7日間、今は現存だが保持ルールが適用されたときに削除されます）
  • 2021年2月10日～14日（7日間より少ない、現存）
  • 2021年2月15日（週単位として定義されたため、日単位のセットとして見なされない → 日単位のセットの保持ルールは無視）
  • 2021年2月16日（7日間より少ない、現存）

特定のバックアップ セットを保持する日数（週数、月数）は必ずしもそのようなバックアップの数と一致するとは限りません。それは、具体的なシナリオによって異なります。たとえば:

• 日単位だが月曜日から金曜日までバックアップを実行して、7日間の保持を指定した場合は、どの時点においても最大5つのバックアップが保管されます（週単位バックアップが含まれる場合は、4つになります）。
• 9月にすべてのバックアップがスキップされたデバイスでは、月単位のバックアップは10月から始まります。バックアップの数に拘わらず、通常と同じ計算になります。現在のセットのバックアップがそのセットのルールを超えている場合は、このバックアップは削除されます。従って、保持ルール内のある期間をスキップすると、アーカイブ内のバックアップが少なくなります。

常に完全、週単位（金曜日のみ）；月単位 1カ月、週単位 3週間、日単位 10日間

週単位のスキームでは、1週間以内に複数のバックアップを作成ることもできるため、「日単位」セットは使用可能になっており、すべてのセット（３つ）の保持ルールを指定できます。特定の条件下では、日単位バックアップが実際に存在する場合もあります（この場合もこの例でカバーします）。今日は2021年2月16日で、バックアップは2021年1月12日から失敗なしで毎週金曜日に実行されているとしましょう。また、2021年1月20日と2021年2月10日に手動で追加のバックアップが作成されました。　

• 「月単位」セット:
  • 2021年1月12日（1月の最初のバックアップのため、月単位として定義されます；1カ月+4日間、1カ月より大きい、削除済み）　
  • 2021年2月1日（1カ月より少ない、現存）
• 「週単位」セット:
  • 2021年1月15日（4週間+4日間、3週間より多い、削除済み）
  • 2021年1月22日（3週間+4日間、3週間より多い、削除済み）
  • 2021年1月29日、2021年2月5日、2021年2月12日（3週間より少ない、現存）
• 「日単位」セット（手動で行われたバックアップは日単位バックアップとして定義されます。ただし、それはスケジュールされた週単位や月単位のバックアップの前に行われ、その週またはその月の最初の成功したバックアップになった場合は、元々最初のバックアップとしてスケジュールされていたバックアップは代わりに日単位として定義されます）
  • 2021年1月20日（10日間より多い、削除済み）
  • 2021年2月10日（10日間より少ない、現存）

カスタム、1年間2回の完全バックアップ（夜1時）、1カ月2回の差分バックアップ（夜1時、完全バックアップが行われた日を除く）、毎日の増分バックアップ（朝6時、完全バックアップおよび差分バックアップの日も含む）

以下のスクリーンショットをご参照ください。

 
これは、カスタム スキームを使った比較的複雑なスケジュールの一例です。この場合、3つのバックアップ セットが存在します（「完全」、「差分」、「増分」）。セットは日単位、週単位、月単位というタイプとは関係なく、その代わりにセットごとの保持ルールはバックアップ タイプに応じて指定することになります。この例では、以下のスクリーンショットのように、「完全 10年間、差分 2年間、増分 10週間」という保持ルールを設定しました。

 
今日は2021年2月16日で、バックアップはすでに10年間以上実行されているとすると、以下のバックアップが表示されます:

• 「完全」セット
  • 削除済み: 2011年1月1日（バックアップ期間は10年間+1カ月+15日間）およびそれ以前のバックアップ
  • 現存: 2011年7月1日（バックアップ期間は9年間+7カ月+15日間）およびそれ以降のバックアップ
• 「差分」セット
  • 削除済み: 2019年2月15日（バックアップ期間は2年間+1日）およびそれ以前のバックアップ
  • 現存: 2019年3月1日（バックアップ期間は1年間+11カ月+15日間）およびそれ以降のバックアップ
• 「増分」セット
  • 削除済み: 2019年12月15日（バックアップ期間は10週間+1日）およびそれ以前のバックアップ；2019年12月15日の夜1時に作成された差分バックアップは増分セットに属せず、専用のルールを持っているため、現存します。
  • 今日のバックアップの後で削除されるのは、2019年12月16日のバックアップです（バックアップ期間はちょうど10週間）
  • 現存: 2019年12月17日（9週間+6日間）およびそれ以降のバックアップ