Backing up from Replica triggers full backup
-
Testing the Symmetrical backup feature in the upcoming version of XOA using the latest commit from today. (8e580) and running into a potential issue where after backing up a replicated VM a full CR run will be triggered and a new replicated VM will be created instead of simply a snapshot on an existing replica.
Here is an example of the issue:
Create a new CR job with a VM replicating from Pool A to Pool B and set the retention to whatever you choose. I am using a retention of 3 in this example. Run the job and the initial sync will take place.

After running the job 3 times i will have 3 snapshots on the replica side as expected.

Now create a delta backup job that backs up this replica . To simulate backing up from production pool to DR pool and backing up those replicas to long term, immutable or cheaper storage. Then run the job, as expected the initial backup run will be a full.

Here is how the VM looks at this point:

Everything should now be in place. What used to happen on earlier commits this month is the next time the CR job ran only a delta would be transferred again, allowing very efficient offsite replication and Backup.
However if i run the CR job again, instead a full replica takes place and a new VM/UUID is generated.


I have attached the log of in hopes it may also shed some light on why this happens.
With a commit from March 12th this behaviour did not occur, a delta replica would be transferred as expected and show as a snapshot on the existing VM/UUID.
-
Here is the log2026-03-25T14_26_49.978Z - backup NG.txt
-
I am on it , thanks for all the informations
-
@flakpyro could you test this branch ?
https://github.com/vatesfr/xen-orchestra/pull/9635/commits -
@florent Just gave this branch a shot, trying to run replication job after running a backup job no longer results in a full replication but just fails with:

-
Retrying the job after the above failure results in a full replication and a new VM being created just as before.
-
@flakpyro you probaby had multiple job/schedule on the same schedule
I reworked the code and pushed an update and added a doc with the edge cases : https://github.com/vatesfr/xen-orchestra/pull/9635/changes#diff-ef545af2ad06f2759c1a3787f266108b3b2cbc203bc8071bbd847278f3e6a5f0 (will be on doc xo when merged )
-
@florent Since both jobs were test jobs that i have been running manually, i do have an unnamed and disabled schedule on both that does look identical, so i unintentionally did have multiple jobs on the same schedule. I have since named the schedule within my test job so to each is unique.
Updating to "f445b" shows improvement:
I was able to replicate from pool A to Pool B, then run a backup job which was incremental.
I then ran the replication job again which was incremental and did not create a new VM!
Unfortunately though after this i ran the backup job again which resulted in a full backup from the replica rather than a delta, not sure why. The snapshot from the first backup job run was also not removed, leaving 2 snapshots behind, one from each backup run.

I then tried the process again. Ran the CR job, which was a delta (this part seemed fixed!) then ran the backup job after, same behavior, a full ran instead of a delta and the previous backup snapshot was left behind leaving the VM looking like:

So it seems one problem solved but another remains.
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login