Veeam backup with XCP NG

[Pilow]

finally understood the network problem...

If you have a match of MAC ADDRESS in netplan

Veeam restores the VM with a NEW MAC ADDRESS

so either you delete the match, or get the good mac on the VIF...

[florent]

nice
I think they compute speed as "disk size / time" , whereas we compute it as " used data / time"

That's great to have more choice on this space

[Pilow]

@florent yep, bandwidth computation on Veeam has always been big numbers because of that method.

another thing is MERGING at each remote transfer ending that make feel the backup is longer with XCP BACKUPS
would be cool to have some insights (other than looking for the lock file in the remote) to see the progress of merge.

[flakpyro]

@Pilow You can watch it via the cli using Journal using this command. Not as nice as having it in the UI but useful if you are waiting for a merge for finish before running maintenance on your remotes.

sudo journalctl -u xo-server -f -n 50

[acebmxer]

@Pilow didnt realize veeam support for xcp-ng entered public beta. Downloading now and going to start testing.

[Pilow]

@flakpyro thank you

@florent , would be nice to add this to XCP backup ? merge progress

[acebmxer]

@Pilow

How did you add your xcp-ng pool/host to veeam? I sure its stupid simple but i cant figure it out...

Yes i am running the Beta version.

Edit - after full uninstall and reinstall i see the option now. Now i can begin testing.

[acebmxer]

I decided to go all in and do 5 at once... 4 vms at once.

3 linux and 2 windows 11 vms.

[acebmxer]

and when not accidentally routing the backups... save 6 min..

host

[florent]

@Pilow said in Veeam backup with XCP NG:

@flakpyro thank you

@florent , would be nice to add this to XCP backup ? merge progress

You can check the toggle "merge sychronously" in the advanced block of the backup job, to at least know when the merge is done

(we intend to make this the default choice in the near future)

[Pilow]

@florent i always check it, to avoid a merging process to be disrupted by another job.

so when the backup tranfer is done (we have a progress bar), the job just sits there.. .merging in background, without progress bar or percentage.
5 minutes later, the backup job finishes.

so your stats are flawed (used data over time) if time of merging is taken in account

see what I mean ?

[olivierlambert]

Merging is another process than transfer. Transfer is between XCP-ng to XO (then to BR), while merging is only between XO and BR. The impact is very different (eg on the XCP-ng side, nothing happening during the merge)

[Pilow]

@olivierlambert I get you.

Same in veeam and synthetic fulls, it's only between the server/proxy and the repository.
but we get a progressing percentage while the job sits while doing the synthetic full.

would be cool to "see" the progress of merging.
why ? bad habits from previous technologies used I guess.

[florent]

@Pilow said in Veeam backup with XCP NG:

@olivierlambert I get you.

Same in veeam and synthetic fulls, it's only between the server/proxy and the repository.
but we get a progressing percentage while the job sits while doing the synthetic full.

would be cool to "see" the progress of merging.
why ? bad habits from previous technologies used I guess.

Giving better observability is something we are working actively on , this is tightly coupled with being able to stop a task, and I hope we will be able to show the progress soon