Merge Manually with Backup first

[jm_HH]

Dear Support Team,

is there any way to merge a Backup even without doing a backup first? I am right at the Limit if the repository.

Thank you

[PetrM]

Hi Jens,

There is no way to trigger merge manually but you may want to contact our support team and probably our support engineers would be able to do it by running the specific Data Mover commands.

From my point of view it would be the best to move backup files to another repository having enough free space and to point the backup job to this repository.

Thanks!

[jm_HH]

Hi Petr,

thank you for your answer. Maybe this could be put on the wish-list for later Veeam Versions. Anyhow i started to export the Backup on external Drives and will start with a fresh repository.
I love to have so many restore points and i would like to prevent the NAS-Drives from excessive Merge Actions. My Plan is to write about 30 Restore points in the repository. Than make a full move monthly on an external USB Drive and start again from fresh. With this Method i only need 12 Drives for all Days of one year.

Greetings from Hamburg, Germany

[PetrM]

Hi Jens,

Let's consider your case as +1 request to get manual merge in one of our future releases but we need to collect enough similar requests anyway prior we can add it to our road map.

I'd recommend to take a look at at this simulator and that tool to have better estimations of required free space in future.

Thanks!

[IT_Timo]

Please count this as another +1 for an option or tool to manually merge backups.

[foggy]

My Plan is to write about 30 Restore points in the repository. Than make a full move monthly on an external USB Drive and start again from fresh. With this Method i only need 12 Drives for all Days of one year.

If I'm getting you right, you can do this monthly 'full move' with the help of a backup copy job that will create a full backup corresponding to the latest VM state available in the source repository from the entire backup chain residing there.

[lepphce1]

Another +1 for manual merge tool.

My scenario: rebuilding/replacing a machine backed up with Veeam Agent for Windows. I want to keep the last backup for historical archive, not the entire chain. Thank you.

[Mildur]

My scenario: rebuilding/replacing a machine backed up with Veeam Agent for Windows. I want to keep the last backup for historical archive, not the entire chain. Thank you.

If you have VBR (this subforum is for vbr), you can export the backup from the chain and remove the other restore points after the export.

https://helpcenter.veeam.com/docs/backu ... ml?ver=110

[DanielJ]

+1 for the ability to do manual merge. And/or being able to postpone the merging phase until no more backups were being written to that repository. That should be a more efficient use of resources, and probably cut down on the backup window considerably.

[Gostev]

Merge is only a thing if you don't use ReFS/XFS based backup repositories. On the other hand, why would you use anything else with Veeam, Daniel? At least in the longer term, as it will take some time to implement your asks.

[DanielJ]

I do use ReFS everywhere I can, with the recommended settings. My experience is that fastclone merging can still take hours of I/O which I at that time would rather see spent on writing backups.

[Gostev]

Hmm... are you saying you see hours of heavy I/O load on your storage during fastclone merges? Because merging is a metadata-only operation on ReFS, so it should not be resulting in any significant storage I/O.

[DanielJ]

Yes, I know how it works (at least the basics of it), but I do see that jobs merging while others are still running adds significantly to the load on the repository, both by checking things like disk queues in the resource monitor and just noticing how long time the backup jobs take. This is not on a particular server, I have seen it on wildly varying hardware, Server 2016 and 2019, various patch levels, ever since we did the switch over from NTFS. Which isn't that long ago, a couple of years or something. Maybe we are just running too many tasks? But we have not generally increased the number of tasks assigned to repositories since we used NTFS. Usually I see that a merging operation which is taking place when nothing else is running on the same server is significantly faster than it would have been with NTFS, but I have also seen such a case run on for 10-12 hours after the other jobs finish, with no apparent difference from a usual day (about the same amount of changed data), with the process shuffling a few MB/s into the VBK - which is, as you say, only metadata being updated. Maybe there is some possible case when it seems to Veeam that fastclone is used, but Windows somehow does not use it? Anyhow, I never saw this "reduced" fastclone performance as any great problem, I just wanted to suggest that postponing the merging operations (fastclone or not) to after the backups were finished would be sensible.