@manilx yes, that's it
we should change the "full backup interval" to "base/complete backup interval", to clarify what is a full . And we will do it.
@manilx yes, that's it
we should change the "full backup interval" to "base/complete backup interval", to clarify what is a full . And we will do it.
we are reworking the import code , along the new backup code ( https://xcp-ng.org/forum/topic/10664/our-future-backup-code-test-it ) to unify the differetn disk transformation path
For now:
@andrewreid Yes, I can't wait to share it with everybody.
found it , there was not one, but 2 bugs
albeit small they were putting the xo backup in a incorrect state
the fix is here, and will be merged as soon as possible and then released as a patch for xoa users
https://github.com/vatesfr/xen-orchestra/pull/8780
really thank you everyone for the information
@RobWhalley saved the day
We are still working on it to better understand why it fixes and improve the situation
@RobWhalley nice work, I am testing it right now
@olivierlambert Nice catch
CBT will only be enabled when using purge data , I will fix the first one
(this is because CBT does not improve things without purge snaphot data , but has some edge case , so at least we won't enable it for nothing )
@olivierlambert @Gheppy that is a nice catch and it gives us a interesting clue
I am currently working on it
@manilx said in Our future backup code: test it!:
@florent Yes, just fine.
ok, so that's an issue with the mirror. I reproduced this night on my lab
I am working on a fix
@robyt your doiing incremental backup with 2 step : complete backup ( full/key disks) and delta (differencing/incremental) Both of theses are transfered through an incremental mirror
on the other hand if you do Backup , it build one xva file per VM containing all the VM data at each backup. These are transfered through a Full backup mirror
we are working on clarifying the vocabulary
@afk said in What is the status/roadmap of V2V (Migrating from VMware to XCPng/XO) ?:
Great news ! Thanks @olivierlambert and @florent and let me know if you need some information on the vmware side.
yes we are prototyping with vddk , it should open some interesting possibilities. stay tuned, hopefully by the end of the summer (I am saying it again : for a prototype)
as a shameless plug, we are looking for users with VSAN to ensure we don't break thing for it
@CodeMercenary Looking for in detail would need a support tunnel
it's probably a vdi that has been deeemed incorrect by the cleanup script. The easiest way to fix it in mirror backup is to delete the most recent backups of this VM on the target , they will be re transferred from the source.
If your retention is the same, you can even ourge all the backups of this VM on the target and restart the mirror backup
the mix shouldn't be an issue in itself
@robyt are you using full backus ( called "backup" ) on the source ?
because incremental mirror will transfer all the backups generated by a "delta backup" whereas it's the first transfer or the following delta
(our terminology can be confusing for now)
@DevFlint the https://XOA_URL/rest/v0/tasks endpoint exists, but it's not yet documented through swagger
you should be able to add ?sync=true to the url to get the immediate result, but it can fail with a timeout if the creation takes too much time ( for example : migrating a big template )
found it , there was not one, but 2 bugs
albeit small they were putting the xo backup in a incorrect state
the fix is here, and will be merged as soon as possible and then released as a patch for xoa users
https://github.com/vatesfr/xen-orchestra/pull/8780
really thank you everyone for the information
@RobWhalley saved the day
We are still working on it to better understand why it fixes and improve the situation
@frank-s yes please
the more detailed the bug report is, the easier it is to fix
@Gheppy and nothing in the journalctl log ?