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

@manilx

the PR is here : https://github.com/vatesfr/xen-orchestra/pull/8754

fbeauchamp opened this pull request in vatesfr/xen-orchestra

open fix(xo-web): clarify when CBT is enabled automatically #8754

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

@robyt said in mirror backup to S3:

1 backup job with two disables schedules, one full and one delta, to a nas

Hi robyt

i the mirror settings : full mirror if when mirroring full backup ( called backup ) , as one file per VM
The incremental mirror will take care on all the files created by a delta backup

Can you show me what retention you have on both side ? you have more explanation on the syncrohnization algorithm here https://docs.xen-orchestra.com/mirror_backup , to be short a delta mirror can only be done if part of the disks chains are common to both remotes

@peo said in Error: invalid HTTP header in response body:

@olivierlambert Also the same in XOA, switched "latest" in the "release channel" before updating:

this is probably a CBT issue
you will have more infomation in the log ( journalctl as root )
can you try running the backup without NBD/CBT enabled ?

@katapaltes said in XO Community edition backups dont work as of build 6b263:

Error: invalid HTTP header in response body

Error: invalid HTTP header in response body should come with a trace in the logs ( journalctl under the same acount that runs xo )
could you extract it ?

second fix is merged
Can you retest master, latest commit ?

@uwood the fix regarding the "catch" error is still in review, will probably be merged in a few hours

the second fix regarding the stuck stream ( so pool metadata, full backup and disaster recovery) is merged . This one was effectively added in friday's PR

@uwood a metadata backup shouldn't trigger any timeout
I am retesting it

It may be related to the other topic, but I see a few things :

• invalid HTTP header in response body. There is an issue while trying to download the disk. The XO logs ( journalctl ) should contains lines ith the xo:xapi:vdi key regarding this.
  It may be worth to tests without purge snapshot , if this error reoccur

• SIGTERM is probably more an out of memory issue on the backup worker. How muck memory does your XO have ?

Hi Lulina
you need to disable the schedul on the backup job (but don't remove them)
Then you schedule the sequence ,and backup A, B and C should run

Note that if theses job uses the sam VM ( like a delta backup followed by a mirror to S3 ) , you should enabled " merge backup synchronously" option on the advanced tab of the first job