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

archw

@bogikornel
Same here.....was getting the errors a while back and then they stopped. Over the last week it now happens a lot. I found that it rarely happens on incremental backups.

JB

It's happening to me every day.

JB

I try to back it up manually, and after 3 or 4 attempts, the backup succeeds.

pierrebrunet

@bogikornel Can you tell us on which versions you are please?
the ones where it works and the ones where it does not work.
Thanks for your help!

bogikornel

@pierrebrunet said:

@bogikornel Can you tell us on which versions you are please?
the ones where it works and the ones where it does not work.
Thanks for your help!

Not working: commit bb4da build date: 2026.07.01
Not working: commit 3bc70 build date: 2026.07.02
Working:: commit 71fa8 build date: ~ 2025.11.29
Working: commit 96b76 build date: ~ 2024.07.22

pierrebrunet

@bogikornel @jb @gregbinsd @majorp93
We tested metadata backups every 5 min and it works in XO. It seems it might be coming from XCP-NG, can you provide us a xensource.log from the problematic timeline?

bogikornel

@pierrebrunet I'll try to collect the logs.
However, I can't even backup VMs. What's interesting is that the error always occurs with only 1 VM or 1 Metadata backup. This morning's backup report:
Job ID: 3c17f0c1-85f5-4b98-b43a-0d117c812a9a
Run ID: 1783461900005
Mode: full
Start time: Wednesday, July 8th 2026, 12:05:00 am
End time: Wednesday, July 8th 2026, 1:22:44 am
Duration: an hour
Successes: 14 / 15
Transfer size: 276.37 GiB

Or with another host and another XO:
Job ID: 53c582e5-ba01-4a82-8a45-948a991add99
Job name: metadata
Run ID: 1783483200004
Start time: Wednesday, July 8th 2026, 6:00:00 am
End time: Wednesday, July 8th 2026, 6:05:00 am
Duration: 5 minutes
Successes: 5 / 6
Error: backup task failed with undefined error

poddingue

Thanks @bogikornel, that version comparison really helps.
Narrowing it to something that changed between the late-November 2025 build and the July 2026 ones gives everyone a better place to start than "it just times out".

On the log Pierre asked for: the useful one is /var/log/xensource.log from the pool master, covering one failed run's window.
You already have the Job and Run IDs and the 00:05 to 01:22 timestamps from this morning's run, so that exact span is perfect.
If you can pull it from the master and attach it here (or just the slice around the timeout), that's what lets them line the failure up against what xapi was doing.
It's looking like it may be coming from the XCP-ng side rather than XO, so a mention to @Team-Storage might help too. I could be wrong about where it actually lands, but the log is the thing that'll tell us.

bogikornel

@poddingue said:

Narrowing it to something that changed between the late-November 2025 build and the July 2026 ones gives everyone a better place to start than "it just times out".

The backup function was definitely still good in the 2026-05-28 build. So I think you should look at the last 1 month.

poddingue

The 2026-05-28 build still being good narrows the window a lot more than "sometime since November".
What I keep coming back to is the shape of the failure: 14 out of 15, then 5 out of 6, so it is always exactly one that falls over and never the whole run. I don't know whether that points at a per-VM timeout or at something the last task in a run does differently, and someone on the XO team will read that better than me.
@pierrebrunet still needs /var/log/xensource.log from the pool master covering one failed run's window, so even a slice from a job where only one VM failed should be enough.