Backup fails with "Body Timeout Error", "all targets have failed, step: writer.run()"
-
@marcoi Does your backup include METADATA and XO CONFIG?
-
@JB both
Also Xen Orchestra, commit be960
-
@marcoi The problem is with the METADATA backup. XO Config is working fine!
-
@marcoi So the problem is with my infrastructure.
-
@marcoi I see that you use NFS to store the backup. I use SMB.
-
This post is deleted! -
-
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
-
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
-
@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
-
@pierrebrunet Hello, thank you for working on this issue.
Are you completely sure that this isn't something that got introduced within Xen Orchestra code?
Since I started using XCP-ng / Xen Orchestra I have been using these backup repositories via SMB.
All backup jobs (including this one) have been working fine for almost a year.This repeated body timeout error is a rather new issue which is why I was wondering if this could have been introduced by XO code changes?
I did not switch to a different linux kernel major version or similar. So the SMB client kernel module is at the same version number.
Best regards
-
I use nfs for my remotes and still get the error occasionally.
Edit - Note i am only seeing this error in my work production environment. I am not seeing this issue in my home lab. Both use NFS for remote storage and vm storage.
-
@pierrebrunet Oh one more thing that I just remembered.
If I recall correctly the first time I saw this issue was right after I patched my XCP-ng hosts without updating Xen Orchestra.
So maybe this is caused by XAPI code changes?
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login