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.

[klippit]

I will create a new Feature Request, because "This repository is backed by rotated drivers -> Contine existing backpu chains (if present)" is the correct feature, but currently not fully developed.

[klippit]

We are running a virtual Backup Server with a NAS System a Storage.

Currently Data is copied file based from NAS to external drive via rsync on two alternatingly used external drives.
This way of copying data is pretty slow because of forever incremental Backup jobs, all Full Backups and new Snapshosts have to be copied every day.

According to documentation and Support Ticket #08051441 swtich to a backup copy job with option "This repository is backed by rotated drivers -> Contine existing backpu chains (if present)" should be the best pratice for doing this.

Becaue of virtual Backup Server we are unable to connect the drive directly so we habe to you an SMB oder NFS Share for accessing external drive.

Now the missing Feature:
Because of chaning the external drives every day no incremental Backups are created.
Every day there is a new full backup on external drive.
Log shows Missing storage file 'db02.vm-13667D2026-04-09T072300_F0B7.vbk' but the file is existing on external drive and backup description file db02_D189C.vbm also exits.
In my opinion this is a bug, but support told me to create a R&D Request, because problem seems to be unsupported contine of backup chains on SMB shares.

I expect this case to be working like a standard backup copy job with forever incremental, the only difference is to search on copy start for the latest restorepoint to contine with.

Additional Info:
If i dont swap drives incremental bacups are created.

[david.domask]

Hi klippit,

We merged your other topic with the original, as there's no need for a 2nd topic for the same issue.

Thank you for sharing the support case number, as noted on the case, this is due to the use of a network share backed by rotated drives, which follow a cropped mechanism for retention. Regrettably with this configuration it is by design currently, but we can note your request for having the same retention behavior for rotated drives regardless of the target repository type.