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.
Forward Incremental with Synthetic Fulls enabled
Forward Incremental with Active Fulls enabled
When a backup job uses Forward Incremental mode, the job will maintain more restore pointson 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 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
The job in this example will have at most on disk:
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.
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.
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.
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.
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 VM it processes and store data for each VM 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 VMs created during one job run.
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.
Click here to send feedback regarding this KB, or suggest content for a new KB. To report a typo on this page, highlight the typo with your mouse and press CTRL + Enter.
Spelling error in text
Your feedback has been received and will be reviewed.