Introduction

For clarity of the article, we will define two terms: “backup type” and “backup sets”.

Backup type determines the way data is stored inside the archive. It can be “full”, “differential” and “incremental” . Full backups store all information present at the backup creation time; differential backups store only the difference between the last full backup and the current state of data; incremental backups store the difference between the current state of data and state of data from previous successful backup. For more information, see Difference between Full, Incremental and Differential Backup.

Backup sets determine the exact schedule and conditions under which the backup had been initiated. Backup type can be disregarded when working with backup sets because the backup set has no connection to the methods of storing backup contents.

For the purpose of retention calculation, only the backup sets are used. If you want to learn how retention affects different backup types and backed-up data, please refer to the description of archive12 format instead.

Retention rules

Relation to backup scheme and backup types

The schedule of the backup plan defines the backup scheme used to operate with a specific archive as well as various types of backup sets.

Glossary:

A backup set is a group of backups to which an individual retention rule can be applied. For the Custom backup scheme, the backup sets correspond to the backup methods (Full, Differential, and Incremental). In all other cases, the backup sets are Monthly, Daily, Weekly, and Hourly. 

A monthly backup is the first backup created after a month starts. 

A weekly backup is the first backup created on the day of the week selected in the Weekly backup option (click the gear icon, then Backup options > Weekly backup). If a weekly backup is the first backup created after a month starts, this backup is considered monthly. In this case, a weekly backup will be created on the selected day of the next week. 

A daily backup is the first backup created after a day starts unless this backup falls within the definition of a monthly or weekly backup. 

An hourly backup is the first backup created after an hour starts unless this backup falls within the definition of a monthly, weekly, or daily backup.

Under default settings, retention rules are applied based on the backup sets and are tied directly to them. Alternate retention rules allow changing this approach based on customer requirements.

Retention rules will only contain rules for the sets that are applicable to the current backup scheme and schedule. If you are missing sets that you otherwise expect to see in the retention settings make sure to check and verify the schedule settings first. Keep in mind that certain retention rules are not applicable to certain archive types or destinations – refer to User Guide for details

Retention rules types

• By backup age: define a separate rule for each backup set or use a single rule for all sets
• By number of backups: define the exact number of backups to keep
• By total size of backups: define the size of the archive to trigger retention
• Keep backups indefinitely: retention rules are disabled

The last three rules are generally simple, thus do not require detailed explanation. The focus of the remaining article will fall on the primary rule “By backup age”.

By number of backups: when the number of backups stored inside the archive exceeds the set threshold (maximum amount), the retention rules are applied. Users can choose to apply the retention before or after the backup and can also set the maximum amount of backups to the threshold of 1 (retention after backup) or 0 (retention before backup) to keep only one backup in the archive at all times.

By total size of backups: when the backup archive exceeds the set threshold (maximum size), the retention rules are applied. The software will attempt to remove the oldest backups from the archive until the archive no longer exceeds the threshold or until only one backup is remaining in the archive. If the size of a single backup exceeds the value provided, the archive will exceed the size as well, but will only contain that single backup until the values are modified.

By backup age: detailed

Single rule for all backup sets

A simplified method is to use a single rule for all backup sets. The user defines the exact duration by selecting the number and the measurement unit: weeks, days, months, hours, etc. This rule will be applied to all backup sets, removing ambiguity but also reducing flexibility.

Individual rule for each backup set

The most flexible and complex method is to set a separate rule for each backup set. With a custom backup scheme, the rules will be set per backup type: Full, Differential, and Incremental. With any other backup scheme, the rules will be set per backup set: Monthly, Weekly, Daily, Hourly. Only backups sets applicable for the current backup scheme will be available in the retention rules settings, e.g. for “Weekly Full, Daily Incremental” scheme the retention rules will not contain monthly settings because the monthly set is not present in that backup scheme, thus the retention can only be set for “Weekly” and “Daily” sets.

Whenever software creates a backup, it defines the current backup set of this particular backup for further retention purposes, this value cannot change over time. Refer to Glossary to find out how exactly the backup set of the current backup is defined.

Before software starts the “applying retention rules” procedure, whether it is before or after the backup, it goes through existing backups in the current archive and calculates which ones are expired based on defined retention rules. These backups get removed from the backup chain, consolidating or deleting any unreferenced data remaining in the archive.

You need to define the backup set of each backup that the archive currently stores for a better understanding of the process. The examples below aim to help with that.

General calculation rules

To calculate if the retention applies to certain backups follow this pattern:

1. Define the set of the target backup:
   
   1. For custom schemes, define if the backup is Full/Differential/Incremental based on schedule
   2. For other schemes define if the backup is Monthly/Weekly/Daily/Hourly based on the definition of the corresponding set – refer to Glossary
   3. If any backup is skipped or failed when it runs per schedule, the next successful one will take its place in this logic.
2. Check when the retention process starts. The exact time matters because the software checks backup age exactly when the retention process starts (and not when the associated backup process starts).
3. Define the age of the target backup in full years/months, weeks, days, and hours, based on the retention process starting time.
4. Compare the age of the backup to the retention rule for its set (if a single rule is used for all sets – compare the age to that rule):
   
   1. If the age value is larger than the set rule even by the smallest margin, the backup is subject to retention. Consider 1 month and 1 minute larger than 1 month.
   2. Otherwise, the backup is not subject to retention.

Important notes:

• Outside of retention logic, users can manually delete any backup in the chain regardless of their type or set. Since the sets are static, using manual deletion does not change anything for retention logic. Deleting a monthly backup that is not a subject for retention will not change the set of any subsequent daily or weekly backups to become a monthly one; thus retention may still remove the remaining backups of the same month, resulting in the complete absence of a backup in a period.
• In the current Acronis Cyber Cloud implementation, retention is always a part of a backup plan. If the backup plan is not running due to any circumstances, fails, or is interrupted before retention can start, the retention will not work. Disabled and revoked backup plans also do not apply retention. Separate retention plans are planned to be included in future versions of the product.
• Changing the retention of a backup that is already running will only apply to the next backup job run. To preserve backups that are already subject to retention (but had not yet been removed) cancel the running procedure completely, change and save retention settings and re-run the procedure.

Examples

Default (Always incremental, single-file; Monthly – 6 months, Weekly – 4 weeks, Daily – 7 days)

Assuming today is 16.Feb.2021 and the backups started on the 01.Jun.2020, ran on a daily basis without failures with weekly backup on Monday, we have:

• Monthly set:
  • 01.Jun.2020 (8 months and 14 days old – more than 6 months – deleted)
  • 01.Jul.2020 (7 months and 14 days old – more than 6 months – deleted)
  • 01.Aug.2020 (6 months and 14 days old – more than 6 months – deleted)
  • 01.Sep.2020 (5 months and 14 days old – less than 6 months – present)
  • 01.Oct.2020, 01.Nov.2020, 01.Dec.2020, 01.Jan.2021, 01.Feb.2021 (less than 6 months – present)
• Weekly set:
  • Mondays up to 18.Jan.2021 (4 weeks and 1 day old – more than 4 weeks – deleted)
  • 25.Jan.2021 (3 weeks and 1 day old – less than 4 weeks – present)
  • 01.Feb.2021 – defined as monthly, not related to weekly set (same applies to 01.Jun.2020), the rule is ignored
  • 08.Feb.2021, 15.Feb.2021 (less than 4 weeks – present)
• Daily set:
  • Any daily backup up to 08.Feb.2021 (more than 7 days – deleted)
  • 09.Feb.2021 (7 days – present, but will be deleted when retention starts)
  • 10-14.Feb.2021 (less than 7 days – present)
  • 15.Feb.2021 – defined as weekly, not related to daily set, the rule is ignored
  • 16.Feb.2021 (less than 7 days – present)

The number of days/weeks/months to keep a specific backup set will not always be equal to the number of such backups in the archive. Different scenarios will result in different numbers, e.g.:

• If you set to backup daily but only from Monday to Friday with 7 days retention, the highest amount daily backups you will ever have will be five (four – excluding the weekly backup, if any);
• A device that had skipped the full month of September will have monthly backups starting from October. Regardless of the number of backups, the calculations are the same: if the backup of the current set exceeds the rule of the set, the software deletes the backup. Hence skipping periods of time within retention rules will result in a smaller amount kept in the archive;

Always full, weekly on Fridays only (Monthly – 1 month, Weekly – 3 weeks, Daily – 10 days)

Since the weekly scheme allows creating multiple backups within one week it assumes that “Daily” set is available in the backup and will contain retention rules for all three sets. Under certain conditions, the daily backup may even be present, which we will also cover here. Assuming today is 16.Feb.2021 and the backups started on 12.Jan.2021 ran on a weekly basis without failures with weekly backup on Friday; additionally, manual backups launched on 20.Jan.2021 and 10.Feb.2021.

• Monthly set
  • 12.Jan.2021 – first backup in January, thus defined as Monthly (1 month and 4 days – more than 1 month – deleted)
  • 01.Feb.2021 (less than 1 month – present)
• Weekly set
  • 15.Jan.2021 (4 weeks and 4 days – more than 3 weeks – deleted)
  • 22.Jan.2021 (3 weeks and 4 days – more than 3 weeks – deleted)
  • 29.Jan.2021, 05.Feb.2021, 12.Feb.2021 (less than 3 weeks – present)
• Daily set (manual backups are defined as daily, unless they happen to be first successful backups of the week or the month launched before schedule, in which case the scheduled one will be defined as daily instead)
  • 20.Jan.2021 (more than 10 days – deleted)
  • 10.Feb.2021 (less than 10 days – present)

Custom, Full backup twice a year at 1 a.m., differential twice a month at 1 a.m. (except when Full is done), Incremental daily, including days of Full and Differential, at 6 a.m. (refer to picture)

 
This is an example of a relatively complex schedule set up using a custom scheme. In this case, you will have three backup sets: Full, Differential and Incremental. The sets are not tied to daily, weekly or monthly type and retention rules are defined for sets based on the backup type instead. For the purpose of this example, we will set the following retention rules: Full – 10 years, Differential – 2 years, Incremental – 10 weeks (refer to picture)

 
Assuming today is 16.Feb.2021 the backup had already run for more than 10 years you will see the following backups:

• Full set
  • Already deleted: 01.Jan.2011 (10 years, 1 month, and 15 days old) and earlier
  • Still present: 01.Jul.2011 (9 years, 7 months, and 15 days old) and later
• Differential set
  • Already deleted: 15.Feb.2019 (2 years and 1 day old) and earlier
  • Still present: 01.Mar.2019(1 year, 11 months and 15 days) and later
• Incremental set
  • Already deleted: 15.Dec.2019 (10 weeks and 1 day old) and earlier; keep in mind that the differential backup created on 15.Dec.2019 at 01:00 am is present because it does not belong to incremental set and has its own rule
  • Next for deletion after today’s backup: 16.Dec.2019 (10 weeks exactly)
  • Still present: 17.Dec.2019 (9 weeks and 6 days) and later

はじめに

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

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

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

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

保持ルール

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

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

用語集:

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

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

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

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

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

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

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

保持ルールの種類

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

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

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

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

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

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

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

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

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

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

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

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

一般的な確認手順　

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

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

注意事項:

• 保持の論理とは別に、ユーザーはバックアップのタイプまたはセットに拘わらずチェーン内の任意のバックアップを手動で削除できます。セットは変わらないので、手動で特定のバックアップを削除しても、保持の論理には影響はありません。たとえば、保持ルールの適用対象ではない月単位のバックアップを削除しても、その後の日単位バックアップや週単位バックアップは代わりに月単位バックアップになることはありません。一方、保持ルールに従ってこの月の残りのバックアップが削除されることがあり、その期間のバックアップは完全になくなる可能性があります　
• Acronis Cyber 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日間）およびそれ以降のバックアップ

はじめに

この記事では、ソフトウェアの設定や実行ファイルが古くなっている、破損されている、あるいは一部欠けていることが原因で発生する Acronis True Image ソフトウェアの問題を解決・回避できるトラブルシューティング テクニックを紹介しています。

たとえば、以下の症状の場合に有効です（他の症状の場合もあります）:

• プログラムのスタートアップ時に、「データベースを作成できません」というエラーが表示されます
• 特定のデバイス、パス、フォルダ、ファイル、バックアップ、ボリューム、バージョンが見つからない、あるいはそれにアクセスできないことを示す様々なエラーが表示されます
• Windows でこのプログラムを使用するときに、予期しない上記のアイテムのプロンプトが出てきます
• 他のタスクが実行されていないのに、バックアップ タスクは「キューに入れられています」として表示されます
• 何のエラーも表示されておらず、プログラムはただ単に開きません（プログラムの起動時にグラフィカル ユーザー インターフェイスが表示されません）

このページに記載されているトラブルシューティング方法は、バックアップタスクを再構成する必要のないデータベースのキャッシュの簡単なリフレッシュ → 修復もアンインストールも効果がなかった場合に使用できる専用のクリーンアップツールの実行、という順になっています。

また、この記事の手順は、Windows オペレーティングシステムで発生する問題の場合のみ適用できます。ブータブルメディア環境で発生する各問題には、この記事の手順を適用できません。

ソリューション

方法１。Database フォルダを作り直します

1. 現在実行されているすべてのタスク（バックアップ、復元、ディスクのクローン作成、アーカイブ、同期）を停止、あるいは一時停止します。何か問題がありできなかった場合は、このステップをスキップして、次のステップに進みます。
2. Acronis Active Protection の自己防御機能を一時的に無効にします。その手順は、こちらをご参照ください。
3. Acronis True Image のウィンドウを閉じます。
4. Ctrl+Shift+Escape を押して、Windows タスク マネージャーを開きます。
5. [サービス] タブに切り替えます。
6. サービスをサービス説明のアルファベット順（A → Z）に並べ替えるために、「説明」欄をクリックします。Acronis のサービスの説明は、A という文字で始まります。
7. 各 Acronis サービスを右クリックし、[停止] を選択します。
8. 実行中の Windows プロセスの一覧が表示されているタブに切り替えます:
   • Windows 7 を使用する場合、[プロセス] タブをクリックします。
   • Windows 8 または 10 を使用する場合、[詳細] タブをクリックします。何のタブも表示されていない場合は、タスク マネージャーのウィンドウの下にある [詳細] をクリックします。 
9. プロセスをプロセス説明のアルファベット順（A → Z）に並べ替えるために、「説明」欄をクリックします。Acronis のプロセスの説明は、A という文字で始まります。

   (!)「説明」欄が表示されていない場合は、いずれかの欄のヘッダーをクリックし、ドロップダウンメニューから [列の選択] を選択し、「説明」欄にチェックを入れます。

10. 各 Acronis プロセスを右クリックし、（Windows 7 の場合）[プロセスの終了] または（Windows 8、10 の場合）[タスクの終了] をクリックしてそれを停止します。要求されたら、[プロセスの終了] を押してこの操作を確定します。
11. ファイルエクスプローラー（Windows エクスプローラー）を開き、C:\ProgramData\Acronis\TrueImageHome というフォルダに移動します。C:\ProgramData は隠されたフォルダのため、場合によっては、それを表示させるために、ファイルエクスプローラーのオプションで隠された項目の表示を有効にする必要があります。また、C:\Program Files および C:\Program Files (x86) と間違えないでください。今回は、C:\ProgramData が必要です。
12. Database フォルダの名前を Database.bak に変更します。
    Database.bak というフォルダがすでに存在する場合は、その古いバージョンを削除します。
13. Acronis True Image を開始し、問題が解決されたかどうか確認します。

スケジュールされたバックアップ ジョブは維持されています。再構成する必要はありません。

この手順を実行しても問題が解決しなかった場合は、以下の二つ目の方法を使用してください。その方法を使用した後、バックアップの設定を再構成し、以前に作成されたバックアップをプログラムに指し示す必要があります。

方法２。すべての設定をリセットします

以下の手順によって、プログラムは新規インストールの過程を再現するように、その設定を最初から構築し直します。バックアップのファイルには影響がなく、以前に作成されたバックアップチェーンを継続できます。

(!)バックアップ タスクは、ゼロから再作成する必要が出てきます。

1. 方法１のステップ１～４に従って、Windows タスク マネージャーにたどり着きます。
2. [サービス] タブに切り替えます。
3. Acronis Scheduler2 Service を右クリックし、[開始] を選びます。
4. schedmgr.exe というファイルをダウンロードします。
5. ダウンロードしたファイルを右クリックし、[管理者として実行] を選びます。コマンドプロンプトの黒いウィンドウが開きます。
6. task zapというコマンドを入力し、Enter キーを押します。このコマンドの実行によって、Acronis スケジューラーでスケジュールされているジョブの一覧はクリアされます。
7. 方法１のすべてのステップをもう一度実行します。
8. C:\ProgramData\Acronis\TrueImageHome\Scripts というフォルダの名前を Scripts.bak に変更します。上記のステップと合わせて、これでユーザーインターフェイスで表示されるキャッシュ バックアップの一覧はクリアされます。このページで記載されている、あるいは、触れている手順では、バックアップ自体は削除されることや何らかの影響を受けることはありませんので、ご安心ください。
9. %userprofile%\AppData\Local\VirtualStore\ProgramData\Acronis というフォルダがあれば、そのフォルダを削除します。このパスを開くために、Windows ロゴキー + R を一緒に押すことで[ファイル名を指定して実行] を開き、そこに %userprofile%\AppData\Local\VirtualStore\ProgramData\Acronis を貼り付けて、Enter キーを押します。このフォルダの削除は、特に Windows エクスプローラーで .TIB ファイルをダブルクリックすることでバックアップを参照するときに発生する問題の場合に有効です。
10. Acronis True Image の問題が解決されたかどうか確認します。

以前に作成されたバックアップにアクセスし、それを継続させる方法については、こちらをご参照ください。

方法３。インストールの修復や再インストールを行います

上記のすべてのステップを実行しても効果がなかった場合は、Windowsでのインストールの修復、アップデート、およびクリーンインストールの説明に従ってインストールを修復してください。それでも問題が解決しなかった場合は、対象のソフトウェアのクリーンインストールを行ってください。これで、システムレジストリに保管されているものを含めてすべてのプログラムファイルおよび設定が再作成されます。

方法４。クリーンアップツールを使用します

インストールの修復やアンインストールを行うときに失敗、ハングアップあるいはクラッシュが起きた場合、最後の手段として、専用のクリーンアップ ツールを使用してソフトウェアを削除してください。その後、プログラムの最新バージョンをインストールし、問題が解決されたかどうか確認してください。

さらなるトラブルシューティング

問題が解決しなかった場合は、さらなるトラブルシューティングのためにAcronis カスタマーセンターへお問い合わせください。