@kratos no, it's not that rare. I even saw in the wild replication on the same storage (wouldn't recommend it , though )

the cross pool replication is a little harder since the objects are each split on their own xen api, so the calls must be routed to the right one
We tested the harder part, not the mono xapi case

@kratos you probably heard the sound of my head hitting my desk when I found the cause
the fix is in review, you will be able to use it in a few hours

@kratos @pilow is it possible that your replications are in the same pool ?

@Pilow

we had as many "VMs with a timestamp in the name" as number of REPLICAs, and multiple snapshot on source VM
now we have "one Replica VM with multiple snapshots" ? Veeam-replica-style...

we didn't look at veeam , but it's reassuring to see that we converge toward the solutions used elsewhere

it shouldn't change anything on the source
I am currently doing more test to see if we missed something

edit: as an additional beenfits it should use less space on target it you have a retention > 1 since we will only have one active disk

@Dezerd and you can either add the replication to the same backup job if you have a good connection between host, or create separate replication jobs

a replication is quite neat, especially for a fast restart, since the replicated VM is ready to start

@Pilow the timestamp is on the snapshot, but you're right, we can add a note on the VM with the last replications informations

note that the older VMs replicated will be purged when we are sure they don't have any usefull data , so you will have only one VM replicated , wuth multiple snapshots

@ph7 yes this is expected even if we did not have time to communicate on this yet : https://github.com/vatesfr/xen-orchestra/pull/9524

the goal is to have more symmetry between the source ( on VM with snapshots ) and the replica ( on VM with snapshots) . The end goal is to use this to be able to reverse a PRD , and to allow advanced scenarii like VM on edge site => replica on center site => backup on central servers

but it should not do full backups, it should respect the delta / full chain

fbeauchamp opened this pull request in vatesfr/xen-orchestra

closed feat(backups): symetrical backups #9524

@MajorP93 we merged a lot of changes yesterday , so it's on master

it clean more aggressively the task log, and more cleanup after backup; We are still looking for other possibilities , but for now it's our best bets

patch done by @bastien-nollet

@ElFritto can you do a yarn && yarn build at the root of xen-orchestra ?

edit : found it, we will do a patch

@deligatedgeek we will try to push this branch to master before the end of the month
(we will have a lot of documentation to write on what is solves and what it don't solves)

@flakpyro thanks for the test
we are preparing a branch with some performance improvement , hopefully this time we found the right cause

@wralb it is in master, we are preparing a patch release for XOA on monday morning with this fix

@wralb this will impact each merges with different sizes, so if you revert to master you may still have the issue

this commit will probably be in master by monday

@simonp can you check if it's related to the xo5/xo6 proxying ?

ping @bastien-nollet

did you resize the VM disks in the near past ?

I insist on the fact that this will only have impact on the FULL backups jobs , and not on the incremental ones

@olivierlambert I am summoning @simonp that worked on the merge last month ( in fact he is already working on it)

@deligatedgeek would it be ok to do a quick iteration where you need to use the command line to add some magics to your backup repository settings ?

first you will need to change your branch to feat_s3_part_settings ( if you are using xo from source)
Then use xo-cli to update the settings of your remote :

xo-cli remote.getAll

find the right one, then xo-cli remote.set id=<the uuid you get at the previous step> url='<the previous url >&maxPartNumber=1000

you can also add maxPartSize and minPartSize if needed