How Recovery Point Expiration Dates Are Calculated

Product version: 10.8

Last modified: 31 October 2022


How are recovery points assigned expiration dates after migrating a job to the schedule retention scheme?


With the legacy retention approach, recovery points for backup and backup copy jobs are created every run and removed according to retention settings. For example, if a job is set to keep one recovery point per day for 10 days, the following occurs:

  • The last recovery point created on a given day is kept as a daily recovery point.

  • This recovery point is kept for 10 days.

  • When the recovery point is older than 10 days, it is removed after the next successful job run.

The same logic applies for weekly, monthly, and yearly retention settings. For incremental with full repositories, only full recovery points are considered for weekly, monthly, or yearly settings; for daily settings, an incremental recovery point is chosen if no full recovery point is available within a given day. Within backup repository details, recovery point expiration information is displayed simply as Use job retention.

The schedule retention approach integrates retention settings with job schedules, and creates recovery points for backup and backup copy jobs using a similar principle. For example, if a job has a schedule with Keep backups for set to 10 days, the following occurs:

  • The scheduled job run creates a recovery point.

  • The recovery point is assigned an expiration date 10 days from the time of creation.

  • In 10 days (i.e. the set expiration date), the recovery point is marked as Expired.

  • Once every hour, NAKIVO Backup & Replication checks recovery point status and removes expired recovery points, except in the following cases:

    • If product services have been stopped, expired recovery points are removed at the nearest opportunity.

    • If an expired recovery point is part of a chain, that recovery point is kept as Expired until the whole chain can be removed.

The same applies for schedules with retention periods in weeks, months, and years. Within backup repository details, each recovery point created with this method has a specific expiration date. This also applies to recovery points created prior to migrating the respective job to the schedule retention method.

"Backup copy job"above refers to backup copy jobs to repository. Recovery points for backup copy jobs to tape already had expiration dates prior to the schedule retention feature.


Upon migrating from legacy retention to schedule retention, previously created recovery points are assigned an expiration date based on their respective original daily, weekly, monthly, or yearly retention settings. This applies to recovery points that have Use job retention listed in backup details; recovery points created using Keep forever or a manually set retention date are unaffected. Newly-migrated recovery points gain an expiration date N days, weeks, months, or years from their creation time, N being the retention period for a given legacy retention option.


  • If a job using legacy retention has only the Keep X last recovery points setting configured, then these settings cannot be mapped to the schedule retention scheme. As such, you will have to configure schedule retention settings for this job manually, and the existing recovery points will not be assigned an expiration date.

  • If a backup copy job with Maintain exact copy of the source backup enabled is migrated to the schedule retention approach while the source job still utilizes the legacy retention approach, the following occurs:

    • Recovery points created by the backup copy job (prior to the migration) using the source job’s legacy retention settings are converted to the schedule retention format.

    • Recovery points created by the backup copy job (prior to the migration) are assigned expiration dates based on respective source job retention settings.


Consider a job with the following legacy retention settings:

  1. Keep one recovery point per day for 7 days

  2. Keep one recovery point per week for 3 weeks

  3. Keep one recovery point per month for 2 months

  4. Keep one recovery point per year for 1 year

Recovery points created with one of the above settings will receive expiration dates upon migration based on the original creation time and the respective retention period. For example:

  1. Daily recovery point created at 12:00 on January 1st — expiration date set for 12:00 on January 8th

  2. Weekly recovery point created at 14:00 on January 2nd — expiration date set for 14:00 on January 23rd

  3. Monthly recovery point created at 17:00 on January 3rd — expiration date set for 17:00 on March 3rd

  4. Yearly recovery point created at 20:00 on January 4th — expiration date set for 20:00 on January 4th of the following year

In case a single recovery point applies to multiple retention settings, an expiration date is assigned according to the lowest-frequency retention setting—that is to say, the priority is Yearly > Monthly > Weekly > Daily.

Using the above example, let's say a legacy recovery point is created at 12:00 on January 31st, and that this happens to be both the Daily and Monthly recovery point. After migrating to the schedule retention method, this recovery point will receive an expiration date according to its Monthly retention settings. Therefore, its expiration date will be set for 12:00 on March 31st.