Keeping Recovery Points

Product version: 10.5

Last modified: 09 December 2025

Question

How does the retention of recovery points work?

Answer

NAKIVO Backup & Replication supports two retention schemes: Grand-Father-Son (GFS) retention and Schedule retention.

GFS retention allows you to retain recovery points over long periods while optimizing storage space. The following options are available:

1. Retain the specified number of last recovery points: Once the number of recovery points exceeds the configured value, the oldest recovery point is deleted.

2. Retain one recovery point for the specified period of time: The last recovery point within each day, week, month, or year is preserved for the configured duration.

3. Make new recovery points immutable: Immutability prevents deletion or modification of new recovery points for a specified period.
   

Note

You can manually configure recovery point retention on the Settings > Repositories page. The following options are available:

• Use job retention: This option enables a job-specific retention policy for the recovery point.

• Keep forever: This option is automatically enabled if the job does not have a schedule. You can also select this option manually.

• Protect until: This option allows you to manually select a specific date until which the recovery point will be protected. Afterward, the rules of the job retention policy automatically apply to this recovery point.

• Recovery points with a custom Protect until date are excluded from job retention processing and are counted separately from other retained recovery points. They remain stored until the specified date and are removed only when retention rules allow it.

• Note that manually protected recovery points are separate from those protected by the job retention policy. Manually protected recovery points are not removed by GFS retention logic and remain stored until the Protect until date is reached, at which time normal expiration rules apply.

• Immutable recovery points cannot be removed or modified during the immutability period.

• If the incremental backup chain extends beyond the original immutability date of the Full Recovery Point, the immutability period for the Full RP and the entire chain will be automatically extended. This guarantees that the chain cannot be broken or deleted until the entire sequence of dependent RPs is eligible for removal under the standard retention policy.

• If a recovery point cannot be removed during a job run (for example, due to a service interruption), it is marked as Pending for removal. Pending recovery points are treated as deleted and are ignored by subsequent job runs until the system removes them successfully.

The Schedule retention scheme assigns an expiration date to each recovery point based on the Keep backups for setting or a manually configured Protect until date.

When the expiration date is reached, the recovery point is removed automatically, unless it is still required by another recovery point in the chain.

Expired recovery points that cannot be safely removed remain marked as Expired until their dependent chain becomes eligible for removal.

The product checks for expired recovery points periodically (every ~45 minutes).

Example

Let’s say you have scheduled a backup job to run every hour from Monday to Friday, and you have configured the following retention options:

• Retain the 10 last recovery points;

• Retain one recovery point per day for 3 days;

• Retain one recovery point per week for 2 weeks;

• Retain one recovery point per month for 6 months;

• Retain one recovery point per year for 2 years; and

• Make new recovery points immutable for 0 days.
  

Note that the immutable for option has been set to 0 for simplicity—in short, all recovery points are kept for the specified number of immutability days before other retention settings are taken into account. Here's how recovery point retention works with the above example for the two types of backup repositories:

Forever-incremental Repository

Starting the following Monday, the backup job will run every hour and a new recovery point will be created in the backup repository after each job run. The following will happen with the recovery points:

1. Once recovery point 11 is created, the first recovery point (the oldest) will be removed. So, the total number of last recovery points always remains 10. With each new job run, one new recovery point is created and the oldest one is deleted. 

2. The last recovery point created on that Monday (let's say at 11:00 PM) will be considered the “recovery point of the day”. This recovery point will be stored for 3 days and deleted when the fourth daily recovery point is created.

3. After the end of the first week since the first backup, the last recovery point of the week (let's say Friday 11:00 PM) is stored as the “recovery point of the week”. It will be stored for 2 weeks and deleted when the third weekly recovery point is created.

The same process applies to monthly and yearly recovery points. Thus, with the above ruleset, the maximum number of recovery points that may exist at one time is 23:

• 10 last "regular" recovery points,

• 3 daily recovery points,

• 2 weekly recovery points,

• 6 monthly recovery points,

• and 2 yearly recovery points.

Incremental-with-full-backups Repository

Let's say that, in addition to the sample retention settings in the Example above, you have set Create full backup in Job options to Job runs #: 4. This means that when the job runs once an hour, a full recovery point is created every 4 hours. The other 3 job runs in that time frame will create Incremental recovery points, which will only get removed according to the following scenarios:

• The whole chain of recovery points, including the Full one, is removed provided that:

  1. A new Full recovery point is created.

  2. The whole chain of recovery points no longer falls within your retention period.

  3. An older Full recovery point is not assigned to a recovery point of the week, month, or year.

     Note

     NAKIVO Backup & Replication always keeps at least one full chain (a full recovery point and all dependent increments). A full chain is removed only when a newer full exists and all recovery points in the older chain exceed the retention policy.

• The whole chain of recovery points, excluding the Full one, is removed provided that:

  1. A new Full recovery point is created.

  2. All the recovery points, except for the Full recovery point, in the chain up to the following full recovery point no longer fall within your retention period.

  3. The Full recovery point is assigned to a recovery point of the week, month, or year.

     Note

     Incremental recovery points may be deleted while keeping the Full recovery point when the Full is preserved as a daily, weekly, monthly, or yearly recovery point. In this case, only the increments outside the retention window are removed.

Starting the following Monday, the backup job will run every hour and a new Full recovery point will be created in the backup repository once every 4 runs. The following occurs:

1. As long as the oldest Full recovery point still falls under the retention period, the chain of Incremental recovery points (in this example, 3) leading up to the newest Full recovery point will be kept. Once the 11th recovery point is created (not counting designated daily/weekly/monthly/yearly recovery points), the first Full recovery point and its chain of Incremental recovery points are deleted.

2. The last recovery point created on any day (let's say 20:00 PM) will be considered the “Full recovery point of the day”. This Full recovery point will be stored for 3 days and deleted when the fourth daily recovery point is created.

3. After the end of the first week since the first backup, the last Full recovery point of the week (let's say Friday 20:00 PM) is stored as the “Full recovery point of the week”. It will be stored for 2 weeks and deleted when the third weekly Full recovery point is created.

The same process applies to monthly and yearly recovery points. Thus, with the above ruleset, the maximum number of recovery points that may exist at one time is 23:

• 10 last recovery points (mix of Incremental and Full),

• 3 daily Full recovery points,

• 2 weekly Full recovery points,

• 6 monthly Full recovery points,

• 2 yearly Full recovery points.

Note
Since chains of Incremental recovery points are only deleted if the respective Full recovery point is deleted, the number of recovery points in a repository may temporarily exceed retention policy limits.

Viewing Types of Recovery Points

You can view which type of recovery point (incremental or full) is stored in the repository in one of the following ways:

• On the Backup page of the Recovery Job Wizard.

• By viewing the backup details on the Settings > Repositories page.

Retention Behavior for Tape Backups

When recovery points are written to tape, retention is controlled by expiration dates:

• Each recovery point receives an expiration date according to the Backup Copy job retention policy.

• A full recovery point inherits the longest expiration date among all incremental recovery points in its chain and updates dynamically as those incrementals expire.

• The product always preserves at least one full chain (a full recovery point and all dependent incrementals), even if they span multiple cartridges.

If Auto erase expired tapes is enabled, a tape cartridge can be automatically erased only when:

• All recovery points on the cartridge have expired, and

• The cartridge does not contain any portion of a recovery point chain that still has non-expired segments on another cartridge.

This logic ensures that tapes required to restore an active (non-expired) recovery chain are never removed prematurely.

Example

The following examples illustrate how expired recovery points and dependent chains affect automatic tape reuse when the Auto erase expired tapes option is enabled.

Fully Expired Chain Across Two Tapes (Cartridge Can Be Reused)

• Tape A contains:

  • 1 Full recovery point

  • 1 Incremental recovery point

  • Both belong to Chain X and are expired

• Tape B contains:

  • The last part of the same Incremental recovery point from Chain X (also expired)

  • A new backup Chain Y:

    • 1 Full recovery point (not expired)

    • 1 Incremental recovery point (not expired)

• The Auto erase expired tapes option is enabled.

• A new Backup Copy job to tape is started. The job starts with an empty cartridge.

Result:

• Tape A is considered expired and overwritable. Tape A is used for the new job.

• If Tape A becomes full, a free or empty cartridge is used.

Entire Chain Expired, But Stored on Multiple Tapes (Cartridge Can Still Be Reused)

• Tape A contains:

  • 1 Full recovery point

  • 1 Incremental recovery point

  • Both belong to Chain X

• Tape B contains:

  • The last Incremental recovery point of Chain X

  • All recovery points of Chain X are expired

  • A new Chain Y with non-expired Full and Incremental points

• The Auto erase expired tapes option is enabled.

• A new Backup Copy job to tape is started.

Result:

• Tape A is considered expired and overwritable. Tape A is reused for a new job.

• If additional space is required, a free or empty cartridge is used.

Dependent Non-Expired Recovery Point Exists (Cartridge Cannot Be Reused)

• Tape A contains:

  • 1 Full recovery point (expired)

  • 1 Incremental recovery point (expired)

  • Both belong to Chain X

• Tape B contains:

  • The last Incremental recovery point of Chain X (not expired)

  • A new Chain Y with non-expired Full and Incremental points

• The Auto erase expired tapes option is enabled.

• A new Backup Copy job to tape is started.

Result:

• Tape A is NOT considered expired, because it contains a portion of Chain X that still has non-expired dependencies on Tape B. Tape A is NOT reused.

• NAKIVO Backup & Replication attempts to use:

  • Another expired (overwritable) tape, or

  • A free tape, or

  • An empty tape.