Backup fails with "Body Timeout Error", "all targets have failed, step: writer.run()"

acebmxer

Yes restarting the tool stack works for me. I currently do not have any host offline at least not intentionally. If there is a network glitch that i am not aware of that might cause the issue if that is the actual cause.

As @olivierlambert stated maybe we were having issues all along and they just changed something that is making the issue visible now. The support tunnel should still be open on my environment if you or the team want to look at logs.

GregBinSD

@jb
@olivierlambert
Oliver, you may be right, wondering whether they really worked. How can I prove that the metadata and xo-config backups were truly successful?

Below, I pasted in the GUI backup log from XO5.

JB

All my hosts are online, yet the error still occurs. However, if I restart, the backup works for two or three runs.

bogikornel

The problem is that my VM backups don't run either, because I still get a timeout. This morning out of 11 VM backups, 2 failed, on Tuesday 1 failed, 20 were good.

olivierlambert

5 minutes is clearly an HTTP timeout, the question is way we are reaching this timeout in the first place.

pierrebrunet

@bogikornel are you talking about another issue? We are on an issue specifically on "pool metadata backups". It seems you are talking about VM backups. If yes, can you send the backup log please?

bogikornel

@pierrebrunet This is the same error, but it occurs more often when saving metadata. I'm attaching the logfile. xo-backup-error-log.txt

CodeMercenary

This happens to me mostly with non-config backups but occasionally a config backup will fail. The VM that fails the backup with the body timeout changes around every day, then once a week or so, every VM will get backed up. It only happens on this XO instance and only with the full backups. It doesn't happen on another XO instance that performs delta backups of the same VMs a couple hours later.

christopher-petzel

@olivierlambert I feel like the cause of the timeout is what I posted here: https://xcp-ng.org/forum/post/107454

The incidents of the errors in syslog correspond by matching pool, date and time to the incidents of errors in XO backup. I've traced through several of these incidents in the syslog and matched them to the errors in the XO metadata backup and matched these to missing metadata backup files in the directory on the storage server (ex. 20260807T041000Z) which is created even if the backup fails.

I would look in older logs to see if maybe this has been happening for a long time, possibly before an XO update now shows the error, but my syslog data only goes back 30 days. The XO metadata backup errors started over 30 days.

olivierlambert

I have a theory that I'd like you to test on a specific branch. It might be an Undici bug, but I'm far from being sure.

You need Node >=22.19 to make it work. Switch to the branch named fix_undici_paused_parser_crash, build it and try again.

christopher-petzel

@olivierlambert Good news. This morning, I built on the fix_undici_paused_parser_crash branch and manually ran the metadata backup job 10 times and did NOT get an error. Previously, running the job manually could result in the body timeout error, so we have progress.

I will stay on this build during this week, let the scheduled metadata backups run, and report back by this Friday.

MajorP93

@christopher-petzel Thank you for testing this! I am also interested in this fix since I encounter this issue from time to time. Unfortunately my testing environment / lab is currently unavailable which is why I wasn't able to compile & deploy this branch myself.

GregBinSD

@christopher-petzel
Great news!
I will test and report after it is available in a global update.
Thank you Christopher.

christopher-petzel

@olivierlambert No metadata backup errors in the 4 scheduled backups since Monday, while on the fix_undici_paused_parser_crash branch. Previously, I would not have more that 1 day without an error. Between manual and scheduled backup jobs, I've not been able to recreate the error on this test branch.

This is good to see again...

olivierlambert

Excellent so it was an undici bug after all… Now I'm making sure @Team-XO-Backend won't miss it

JB

@christopher-petzel Unfortunately, for me, it still has an error.

commit c5fae

MajorP93

@JB Yes makes sense. You are not on the branch that already has the fix. Your commit is latest master branch.
Either switch to the branch that got mentioned or wait for the fix to land in master.

JB

@MajorP93 Ok. Thanks!

pierrebrunet

@JB @majorp93 We made a smaller PR to be merged just after the release (because it is linked to almost all XAPI calls), the new branch is this one if you want to test: fix_undici_timeout
Same fix, just a little smaller

christopher-petzel

@pierrebrunet I built on the fix_undici_timeout branch and manually ran the metadata backup job 10 times and did NOT get an error. I will stay on this build through the weekend, let the scheduled metadata backups run, and report back on Monday.