Issue with incremental backup on rotated drives

Hi everyone,

This is my situation: i configured a backup job on Veeam 12 on rdx drives; i ve got 3 drives (4TB each) and the total size of vms backup is around 1,6 TB; drives are changed daily.

My goal is to make an incremental backup, veeam perform each day a full backup tough. So the third day the drives is put in the rdx reader  veeam gives me error because the storage is full.

In repository settings i marked the rotated drives options. If i set the retention policy to 2 days nothing changes (because veeam policy always keep at least 3 restore points i guess).

I tried also reversed incremental with no result.

 Is there any chance to manage an incremental backup on rotated drives in my situation?

The best option would be to have in each drives a full backup + x incremental file, at worst i may configure a pre-job script to manually prune one of the two full backup on the drive.




Best answer by David_b 24 June 2024, 18:25

View original


Userlevel 7
Badge +9

First of all: Which version of VBR are you using? Make sure to use the most recent version (V12+), as it brought some new options in the rotated drive area.


It should well be possible to achieve your goal. 


Depending on your incremental sub type you get a different outcome. I’d suggest to use a forever forward incremental, as it keeps the length of the chain precisely and does not produce additional fulls that eat up disk space. Therefore, you must not select neither synthetic nor active fulls for your chain.

(also see:


In addition you might wanna decide if every RDX should initiate a new chain/backup when inserted with the option to either 

  • Delete backups belonging to this job or
  • Delete all backups on the drive

I’d rather suggest to use the third option

  • Continue an existing backup chain if present

(also see:


This would always follow up with the chain and keep the length at the point you’ve chosen (you said you selected 2 - there is no policy to always keep three, only backup-COPY jobs have 2 as their minimum here, while regular backup jobs can have 1).

On top please keep in mind the limitations for rotated drives:


Don’t use reverse incremental. It will be deprecated soon.


Hope it helps!



@Michael Melter i am very grateful for your response; 

The version is

i tried either incremental or reverse, the outcome is the same tough. But as u suggested i ll put back incremental.

As behavior for rotated disk my selection has always been:

  • Continue an existing backup chain if present

With this config i still get a new full backup each day, following this schema:


day1: drive1 → full backup

day2: drive2 → full backup

day3: drive3 → full backup

day4: drive1 → full backup(day1) + full backup(day4)

day5: drive2 → full backup (day2) + full backup(day5)

day6: drive3 → full backup (day3) + full backup (day6)

day7: drive1 → error (drive has not enough space)

and so on…


This happen also with retention policy set to 2 days, in this way in day7 veeam should delete full backup (day1) and make a new full backup (day7), isn’t it?


Anyway the best solution would be a full backup per drive + some incremental just has it happen with others not rotated repository.


thanks again for your time :)






Userlevel 7
Badge +9

How did you set your synthetic and active full options?

Make sure to disable both in advanced settings:

Also disable ALL GFS options as GFS is not supported for rotated drive repos:

If this is already the case, I could only think of something unsupported. Do you drive NAS backups towards this repo as well? This would disable the rotation schema according to:

Also maybe set the retention policy to restore points, not days. At least during testing:

Otherwise you can get more than 2 points if produced on the same day.

If all that fails → file a support case with Veeam and let us know the reason.




@Michael Melter the setting of full backup, synthetic backup and gfs are correct (as u shared in your pic); i just changed from 2 day to 2 restore points; i’ll let you know if it work properly.


My concern is about the minimun retention policy that i found in this article:


Thanks again,



Userlevel 7
Badge +9

This minimum is only relevant for backup copy. Are we talking primary backup or backup copy?

@Michael Melter 

My bad, i misunderstood the article; i confirm that we are talking about primary backup.

Tomorrow i’ll let you know if the change from  from 2 day to 2 restore points is effective.

best regards

@Michael Melter 


unluckyly even with the retention policy set to 2 restore points veeam do not perform the pruning correctly :(

I proceed with pruning via pre-job script.

Thanks anyway for your help.

Have a nice day

Userlevel 7
Badge +9

If you correctly disabled all methods for full backups and are in a what we call “Forever-Forward” chain, you will find the following in the log of each and every run of the job once the maximum retention (2 in your case) is reached:


This keeps the chain at the fixed length.

Can you see an entry like this? Or maybe an error related to this process? Maybe you won’t see [fast clone] as you might not be using ReFS on the RDX volumes. But a merge should definitely happen.

Another possibility could be: If you have very few room left on the disk, the merge might fail as it uses some temporary space. Maybe try to set compression to high or extreme if this is the case to end up with more room left.

Please consider flagging one of the answers as best answer in case you’re happy with the help we provided here. This also helps to keep track about open cases.

@Michael Melter 

this is the last log:

before the job was performed on the rdx drive there was backup of two days (about 1,5 TB each) so there was about 600GB free.


first piece of log

Userlevel 7
Badge +9

Here you seem to be running with 0 bytes free. No merge will occur then. You have to have >5% free to shorten your chain.

@Michael Melter 

before backup i had:

-restore point 1 (1,5TB)

-restore point 2 (1,5TB)

-600GB free

with this retention policy 

veeam should prune restore point 1 and the perform restore point 3, isn’t it?

Userlevel 7
Badge +9

Veeam will in this case (forever forward) never delete anything. It will merely merge the large VBK with the oldest increment (VIB) and therefore shorten the chain by one. This always happens after the next VIB was created. So at the end of the job - as could be seen in my screenshot above.

So you’re saying you only have VBKs on the drive? Please check your settings again:

If you also “continue existing backup chain” it should work as I described. 

If it doesn’t work as expected, maybe try “Delete all backups on the drive”

At least than you should end up with a single backup on each drive after changing on a daily basis.

@Michael Melter 

Yes, i only have .vbk on my drives; and yes i use the settings that you shared in last pic.

So my only options with this drive size is  to set “Delete all backups on the drive”  in repository settings?  and keep 2 TB of storage in each drive unused? 

Userlevel 7
Badge +9

Try it, but also file a support case as VBR should continue the chain and not start a new one.

Please be so kind to report the outcome here if possible.

Userlevel 7
Badge +21

Hi @David_b - I wanted to follow up on your post to see if you were able to contact Support and get the issue resolved? If so can you please post the solution here for others to see and then mark your post as best answer if support helped you.  Otherwise please select one of the posts above as the answer that best helped you for your issue.


i opened a ticket but unluckyly using veeam community they didn’t answer to me.

So i proceeded with the prune of the oldest full backup with a PS script in this way i m able to keep 2 full backups on each drive.


Thanks for ur help

best regards



Userlevel 7
Badge +21

Hi @Madi.Cristil @safiya -- can you please change the best answer to David’s reply above as that is the answer to the thread and not the one marked.