Feature Request - Full backup file merge schedule

[klippit]

We are using Forever Forward Backup for most of ours jobs except big virtual machines and every time after backup the last increment is merged into full backup, so the full backup file is changed.

The chnaged full backp causes trouble in our air gap backup, because on friday our office is closed at 1pm therefore is not enogh time to copy the large full backup files.

It would be usefull to us to define on which days of week merge is performed, so the full backup files are not changed for air gap backup on friday.

[david.domask]

Hi Christian, welcome to the forums.

Forever Forward Incremental retention scheme works a little differently than I believe you're understanding -- it's not a one-time merge, but instead once there are more restore points than the scheduled retention (redundant restore points), the redundant points will be merged into the full backup.

This is relevant as once the backup chain has reached a certain state, you should expect merges of redundant backups on each run.

Can you tell a bit more about your configuration and the relationship between the Forever Forward Incremental backups and the air-gapped repositories? If I'm understanding correctly, you're backing up using Forever Forward Incremental to a primary repository, then making a copy to your air-gapped repositories, and I have some confusion on how that copy is being done.

Veeam's built in Backup Copy job will intelligently move only necessary changed data to the target repository, so the source job having the Forever Forward Incremental merge will NOT require copying the entire full backup. Since you have this trouble, is it correct you're using some other option to copy the primary backups to your air-gapped repositories?

[klippit]

Hi David

Thank yor the fast repley.

We are creating backups everyday on a fast inhouse repo and there are to copy tasks, on task copies data to veeam data vault and other backup tasks copies data to slow archiv backup repo.
These task are working.

The air gap backup is a file level based copy of the fast inhouse repo on two alternating external disks and when using Forever Forward Incremental .vbk needs to be copied every day, becuase .vbk file is changed by merge.

If there is any possibility to copy fast repo to alternating external disks via Veeam Software our problem would be solved.

Thank you

[david.domask]

Thanks for clarifying the workflow.

Backup Copy jobs are intended for creating secondary copies of data on secondary locations, including rotated drives. You would need to configure a Backup Repository backed by Rotated Drives, and then use that as the target of your Backup Copy.

Please review the link for Repositories backed by rotated drives as there is a decision to make on how to handle the backups on a drive when you perform rotation, and some consideration depending on if you attach the rotated drives to a Windows managed server or a Linux managed server / network share.

[klippit]

Thank you for the link.
I think the solution should fit our requirements. Last time i was looking for a feature like this a few years ago i was not able to find something like this.

I created the special repo and added one job to copy for testing.

[klippit]

The feature is not working as expected.

We are using: Shared Folder Backup Repository.
Feature "This repository is backed by rotated drivers -> Contine existing backpu chains (if present)" is enabled for the repo.

First backup is running an created full backup with vbk and vbm File. -> everything OK
After rotating drive and starting the task again only .vbm Files are created and vbk files are missing. -> no restoreable backup available

[david.domask]

Hi klippit,

At this point since it sounds like a technical issue has appeared, please open a Support Case and let Veeam Support review logs for the test job. A review of the debug logs will help to explain what is happening, as will be difficult to troubleshoot over the forums.

Backup Copy + Repository backed by rotated drives will allow for what you're trying to accomplish, but sounds like Veeam Support needs to review the configuration through the debug logs to help get this sealed.