#1 Global Leader in Data Resilience

Backup Job has Too Many Restore Points - Considerations and Causes

KB ID: 1990
Product: Veeam Backup & Replication | 10 | 11 | 12 | 12.1 | 12.2 | 12.3
Published: 2015-01-19
Last Modified: 2022-06-07
mailbox
Get weekly article updates
By subscribing, you are agreeing to have your personal information managed in accordance with the terms of Veeam's Privacy Notice.
This site is protected by hCaptcha and its Privacy Policy and Terms of Service apply except as noted in our Privacy Policy.

Cheers for trusting us with the spot in your mailbox!

Now you’re less likely to miss what’s been brewing in our knowledge base with this weekly digest

error icon

Oops! Something went wrong.

Please, try again later.

Purpose

This article provides information about the two most common configurations whose behavior can appear to cause "Too many restore points."

Solution

Forward Incremental Retention

The  Forward Incremental* Backup mode's method of retention enforcement often leads to misunderstandings about "Too many restore points." Forward Incremental Backup mode is enabled when a job when Incremental is selected and Synthetic Full or Active Full, or both, are enabled. Please review the information below to understand more about Forward Incremental retention and how its behavior may be misinterpreted.

*When the Incremental backup mode is selected, and neither synthetic full backups nor active full backups are enabled, the job will operate in Forever Forward Incremental mode.

Incremental with Synthetic Fulls
Forward Incremental with Synthetic Fulls enabled
Forward Incremental with Active Fulls enabled
Forward Incremental with Active Fulls enabled

Retention Behavior

When a backup job uses Forward Incremental mode, the job will maintain more restore points on disk than specified to meet retention. The retention setting specifies a minimum number of restore points or days that should be available to be restored, not the maximum number of restore points.

This is explained further in the user guide: Forward Incremental Backup Retention Policy.

retention demo
Within the above animation, the lettered squares represent blocks on a disk.
Each Full (VBK) that is created starts a new Backup Chain, and until all restore points of the oldest backup chain are outside of retention, no portion of that chain can be deleted by retention.

Calculating the Number of Expected Restore Points

Use the Restore Point Simulator to preview how many restore points of each type to expect on disk.

Below are examples of calculating the number of expected restore points by hand.

Simple Example (Click to expand and read more)

Simple Example

  • Scheduled to run daily.
  • Retention is set to 14 restore points.
  • Synthetic Fulls are set to be created every Saturday.

In this configuration, each Full will have six Incremental restore points associated with it. Therefore the chain length is seven (1 Full + 6 Increments).
 

Calculate Max Restore Points

Use the following formula to calculate the maximum number of restore points on the disk:

  • (Chain Length - 1) + Retention = Max Restore Points

    (7 - 1) + 14 = 20
     
Calculate # of Fulls

Taking this a step further, we can then calculate the maximum number of Full restore points with:

  • Max Restore Points / Chain Length = Max Number of Fulls (Round-Up)

    20 / 7 = ~3
     
Results

The job in the example provided will have at most on disk:

  • 3 Full Restore Points
  • 17 Incremental Restore Points
     

Restore Point Simulator Example

Complex Example (Click to expand and read more)

Complex Example

  • Scheduled to run every two hours.
  • Retention is set to 30 days.
  • Synthetic Fulls every Saturday.

This job will generate 12 Incremental restore points a day, except on Saturday when it will create a Synthetic Full. Assuming the Synthetic Full completes in less than 2 hours, Saturday will have 1 Full and 11 Increments. For a total Chain Length of 84 restore points (1 Full and 83 Increments).
 

Convert Days to Restore Points

Because the retention is set to a specific number of days, not restore points, first convert the retention from days to restore points.

  • Days to Retain * Restore Points Per Day = Total Restore Points

    30 * 12 = 360
     
Calculate Max Restore Points

With the number of restore points calculated, use the following formula to calculate Max Restore Points:

  • (Chain Length - 1) + Retention = Max Restore Points

    (84 - 1) + 360 = 443
     
Calculate # of Fulls

With Max Restore Points calculated, next, the maximum number of Full restore points can be calculated with:

  • Max Restore Points / Chain Length = Max Number of Fulls (Round-Up)

    443 / 84 = ~6
     
Results

The job in this example will have at most on disk:

  • 6 Full Restore Points
  • 437 Incremental Restore Points
     

Restore Point Simulator Example

Actual Too many restore points

When using Forward Incremental Retention, creating a Full restore point is what starts a new backup chain. Retention is enforced when the entirety of the oldest backup chain is outside retention. Therefore, if a new Full fails to be created, the backup chain will become longer as more increments are created, and retention cannot be enforced as expected. For this reason, the most common situation where there are legitimately too many restore points occurs when the scheduled Synthetic or Active full fails to be created.

Remember, until all restore points of the oldest chain have fallen outside of retention, no portion of that chain can be deleted. Furthermore, if there is only one backup chain on disk because a second full could not be created, retention will never be enforced.

If, due to repository space restrictions, it will never be possible to create enough full restore points on disk to allow retention to function correctly, either (a) reduce retention or (b) switch to Forever Forward Incremental.

Scenarios that lead to Full restore point creation failure:
  • Scenario 1: Ignored failure

    This often occurs when a backup job is configured to create a Synthetic Full on Saturdays, and each Saturday, the Full fails to be created. The job reports a failure for the Saturday run, but on the next day, the job completes successfully. The Saturday's job failure may be overlooked because it is followed by a successful run, creating the impression that whatever went wrong fixed itself the next day.

    Recommended Action:
    Investigate why the Full failed to be created.

  • Scenario 2: Disabled Job

    The backup job was disabled on the day that the Full restore point was scheduled.

    Recommended Action:
    Ensure that the job is not disabled for the next day that a Full is scheduled to be created.

  • Scenario 3: Job Overrun

    An Incremental session ran for more than 24 hours, causing the next job run to not occur on the day a Full is scheduled to be created.

    For example, the job is scheduled to run every day at 10 PM. The incremental job started at 10 PM on Friday but did not complete until 2 AM on Sunday. Because the Incremental run of the job was still running at 10 PM on Saturday, the job run that should have created the Full on Saturday was not able to trigger. The next run of the job, at 10 PM on Sunday, does not create a Full because that is not the day a Full restore point is scheduled.

    Recommended action:
    Investigate why the incremental job run took so long. If the incremental job runs often take longer than 24 hours, consider ways to improve job performance to ensure that the job completes within 24 hours or consider reducing the number of objects in the job.

  • Scenario 4: Job Chaining Issue

    There are multiple backup jobs, and they are scheduled to run sequentially using the After this job scheduling option. The first few jobs in the sequence run and create their Full restore point, but in doing so, they take so long that they push the later jobs in the series to start on the next day of the week. Since those later jobs began on a different day of the week than was scheduled to create a new Full restore point, they do not create a Full restore point.

    For example, ten jobs are configured to run in sequence, the first job starts the sequence by running daily at 9 PM, and all the jobs are set to create a Full restore point on Saturday. On Saturday, as each job in the sequence starts and creates its respective full, the later jobs are pushed to start running past midnight, meaning they technically start on Sunday and therefore did not create a new Full.

    Recommended action:
    Generally speaking, it is not advisable to use Job Chaining when jobs are set to create Fulls on specific days of the week. Instead, the better option is to fine-tune a combination of task limitations, job priorities, and staggering job start times. In most environments, multiple jobs may be set to start simultaneously, and the task limitations on proxy and repository will control how many tasks occur simultaneously to ensure that the environment is not overwhelmed.

    If, however, there remains a desire to use Job Chaining, set the first job that starts the chain of jobs to start at Midnight. Doing so will ensure that the first and all jobs after it run on the same day, assuming the last job in the chain begins before the next day.

Per-Machine Backup Files

When per-machine backup files is enabled, the backup job will use a separate write stream for each machine it processes and store data for each machine within its own backup file. For example, a backup job protecting 10 VMs with a retention of 14 restore points could have over 140 or more individual files on disk. Veeam Backup & Replication regards all backup files created during one backup job session as one restore point for retention purposes. When Veeam Backup & Replication needs to remove earlier restore points by retention policy, it removes backup files for all machiness created during one job run.

Reference: Retention Policy for Per-Machine Backup Files

Notes:

  • For simple Repositories, Per-Machine Backup Files is disabled by default.
  • For Scale-Out Backup Repositories, Per-Machine Backup Files is enabled by default.
  • If Per-Machine backup files is enabled on the repository, or the existing repository is added to a Scale-Out Backup Repository, the existing jobs will not adopt the new setting until after the next (forced or scheduled) active full backup. A Synthetic full backup cannot trigger the change over to Per-Machine backup files for an existing job.

 

To submit feedback regarding this article, please click this link: Send Article Feedback
To report a typo on this page, highlight the typo with your mouse and press CTRL + Enter.

Spelling error in text

This site is protected by hCaptcha and its Privacy Policy and Terms of Service apply except as noted in our Privacy Policy.
Thank you!

Thank you!

Your feedback has been received and will be reviewed.

Oops! Something went wrong.

Please, try again later.

You have selected too large block!

Please try select less.

KB Feedback/Suggestion

This form is only for KB Feedback/Suggestions, if you need help with the software open a support case

By submitting, you are agreeing to have your personal information managed in accordance with the terms of Veeam's Privacy Notice.
This site is protected by hCaptcha and its Privacy Policy and Terms of Service apply except as noted in our Privacy Policy.
Verify your email to continue your product download
We've sent a verification code to:
  • Incorrect verification code. Please try again.
An email with a verification code was just sent to
Didn't receive the code? Click to resend in sec
Didn't receive the code? Click to resend
Thank you!

Thank you!

Your feedback has been received and will be reviewed.

error icon

Oops! Something went wrong.

Please, try again later.