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

acebmxer

Just got a failure today but with a different pool.

    "message": "backup task failed with undefined error",
    "name": "Error",
    "stack": "Error: backup task failed with undefined error\n    at forwardResult (file:///usr/local/lib/node_modules/xo-server/src/_handleBackupLog.mjs:37:25)\n    at handleBackupLog (file:///usr/local/lib/node_modules/xo-server/src/_handleBackupLog.mjs:68:12)\n    at onTaskUpdate (file:///usr/local/lib/node_modules/xo-server/src/xo-mixins/metadata-backups.mjs:117:13)\n    at onTaskUpdate (file:///usr/local/lib/node_modules/xo-server/node_modules/@xen-orchestra/mixins/Tasks.mjs:205:23)\n    at onLogFct (/usr/local/lib/node_modules/xo-server/node_modules/@vates/task/combineEvents.js:61:5)\n    at metadataBackup._executor (file:///usr/local/lib/node_modules/xo-server/src/xo-mixins/metadata-backups.mjs:122:11)\n    at Jobs.runJob (file:///usr/local/lib/node_modules/xo-server/src/xo-mixins/jobs/index.mjs:297:7)\n    at file:///usr/local/lib/node_modules/xo-server/src/api/schedule.mjs:84:9\n    at Task.runInside (/usr/local/lib/node_modules/xo-server/node_modules/@vates/task/index.js:204:22)\n    at Task.run (/usr/local/lib/node_modules/xo-server/node_modules/@vates/task/index.js:188:20)\n    at Xo.runSequence (file:///usr/local/lib/node_modules/xo-server/src/api/schedule.mjs:73:3)\n    at Task.runInside (/usr/local/lib/node_modules/xo-server/node_modules/@vates/task/index.js:204:22)\n    at Task.run (/usr/local/lib/node_modules/xo-server/node_modules/@vates/task/index.js:188:20)\n    at Api.#callApiMethod (file:///usr/local/lib/node_modules/xo-server/src/xo-mixins/api.mjs:475:18)"
  }
}

JB

Every day I update XO-CE hoping this error gets fixed, but so far, no solution!

olivierlambert

Is there a way in private message to give access to the XCP-ng host and XO VM in question OR to get all logs from 2 machines somewhere? 5min is clearly a timeout error.

acebmxer

@olivierlambert

Mine has not done it since last post but i have opened a support ticket along with tunnel being opened - Ticket#7762089

JB

@olivierlambert Yes, I can grant it.

marcoi

looks like mine also just started working.

JB

Master, commit be960

olivierlambert

@JB I'd like to test a different way of investigating the problem. So I won't do it for many people, just send me a private message with a way to SSH to your host and XOA, promise it's not a scam

JB

@marcoi Try doing it three times, and the problem comes back.

marcoi

@JB seems okay after a few back to back runs.

JB

@marcoi Does your backup include METADATA and XO CONFIG?

marcoi

@JB both
Also Xen Orchestra, commit be960

JB

@marcoi The problem is with the METADATA backup. XO Config is working fine!

JB

@marcoi So the problem is with my infrastructure.

JB

@marcoi I see that you use NFS to store the backup. I use SMB.

JB

This post is deleted!

JB

marcoi

i switched one of the backups for my extra pool from nfs to smb and its been sitting so i expect it to fail. might be a smb issue. ill update this post with results once it either fails or works

i did test smb and it works.

back to nfs works

MajorP93

@olivierlambert said:

Hi! Can you try to replicate on the latest commit?

Hello!
Yes I was able to replicate this issue after updating my Xen Orchestra.

The thing is that the "XO-config-and-pool-metadata" does not always fail.
It fails from time to time then it looks exactly like shown in the screenshot.
Attached logs please find above in my earlier post.

This exact job has been working for a long time before.
After some Xen Orchestra commit this issue got introduced.

I use the same backup remotes for multiple backup jobs.
Only the "XO-config-and-pool-metadata" job is failing with this body timeout error.

Best regards

pierrebrunet

@MajorP93 Hi,
Thank you, thank you! I think you found it! It seems to be SMB, @acebmxer can you confirm that you also use smb please?
If this is the case, the bad news is I think we will need to update our docs to not advise SMB at all: it was already said for delta but maybe we will have to extend this to all kind of BR