@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:

• V2V handles flat, cowd, sesparse, stream optimized vmdk in the format "metadata.vmdk and a data file ) and ova ( for VSAN)
• disk import support monolithic vmdk ( cowd, sesparse, streamoptimized )
• ova improt support only stream ova with streamoptimzed vmdk inside

@andrewreid Yes, I can't wait to share it with everybody.

@olivierlambert @Gheppy that is a nice catch and it gives us a interesting clue

I am currently working on it

@manilx this is merged

@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

@olivierlambert yes, I started to work on friday, and hopefully will have a fix today

@flakpyro today the backup code use binary stream in a the vhd format. This format is limited, by design , to 2TB disks
xcp-ng team introduce the qcow2 format to handle bigger disk
By using a independant format, we'll be able to handle both vhd and qcow2 on the backup side without multiplying complexity. We'll also be able to build the adapter to handle the various vmdk sub format (rax, cowd, sesparse and stream optimized) used by v2v and import bigger disks directly

@b-dietrich said in Externalised backup LTO:

Hi everyone,

I would like to know if it's possible to externalised backup on library tape with XOA ?

Is it in the roadmap for 2024 ?

I will let @olivierlambert on the backlog point. It is still planned, but there is a lot of ground work before :

• since tape can't be easily seek , so you'll have to write the backup at once no turning back to update a previously written block/metadata
• you'll have to build a catalog of tape<->backup to know which tape you'll have to use to restore, or rewrite. This is a huge change since XO don't use any database , the backup repositories are self contained : you can mount a backup repository to a new XO, and the backup will be listed . With tapes, you'll have to keep (and backup) the backup catalog. Yep , we'll need to backup the backups and ensure it's recoverable

That being said, the mirror backup feature as been built to pave the way to tape backup

For now the easiest way to do tape backup is to use full backup to a backup repository only used for this, and to mirror it to tapes. At our scale, priorities can also change if there is a big enough sponsor, that is ready to take a part of the financial load of this feature and gives us access to real world hardware and processes.

@CJ yes we have to fix the preview panel

@olivierlambert @Gheppy that is a nice catch and it gives us a interesting clue

I am currently working on it

@flakpyro the stable branch, is the stable xoa. The latest release is " it is tested, but on limited hardware". The "pull from master and use it" is on best effort, I wouldn't advise to use it on any critical use.

the april's release is stable and will be promoted to stable today.
the may's release probably won't be promoted to stable in june, given the massive changes. my guess is that the june's release maybe , if we deem it stable enough

@manilx said in Our future backup code: test it!:

@florent waiting for final master

this will reach master today, and probably be released in the may version of XO

@manilx said in Our future backup code: test it!:

@florent Simple NFS, no encryption.

I have a potential fix here on the branch fix_backup
( https://github.com/vatesfr/xen-orchestra/pull/8635/files)

fbeauchamp opened this pull request in vatesfr/xen-orchestra

closed fix(disk-transform): backup omnibus fix #8635

At least I reproduce it locally , when going from a non block remote to an encrypted remote

Is your target remote encrypted ?

this error is known : this when a mirror backup start before the end of the asynchronoux cleaning of previous backup is not done

you can check the "merge backup synchronously" on the advanced setting of the first backup

I am checking it
Can you confirm that this a delta backup job and you are not using block.

@Tristis-Oris I still don't have the solution I am working on it .

@manilx this is merged

@manilx the PR is in review, it should be merged in a few hours

thank you for helping us improve the quality