Backups to SMB remote failing
-
Update 2
Backups failed again from XO. I ran backups from XOA and they succeeded. The VM and XO setup was very vanilla, Debian 9, so it doesn't make much sense. I'm going to start from scratch with a new XO VM.
-
It makes sense: XOA is carefully tested with QA for all backup situation before a release. There's many things that can go wrong if you don't provide the right environment (guess why we have a QA phase before a release
)Please report the detailed error (is it the one you gave on your first post?).
Could be your Node version, yarn version, etc.
-
@olivierlambert said in Backups to SMB remote failing:
It makes sense: XOA is carefully tested with QA for all backup situation before a release. There's many things that can go wrong if you don't provide the right environment (guess why we have a QA phase before a release
)Please report the detailed error (is it the one you gave on your first post?).
Could be your Node version, yarn version, etc.
I'll update with the log if the error still occurs after rebuild. I checked all dependency versions from the XOA before building. I'll report back soon.
-
Backups failed again after rebuilding. Error log is attached. Is there anything sticking out to you from the log?
-
interruptedmeans either toolstack was restarted (or XO) during the transfer. -
Taxi cab confession. I was using an install script to build XO from source due to laziness. I started troubleshooting and found there was a memory leak, no matter how many resources I gave to XO it would max out memory and eventually cause the interrupted error.
I decided to build XO from source following the guide. Everything is working perfectly now. SMB write is about 50% faster, read is almost 300% faster.
-
We should pin this post somewhere
edit: thanks a lot for your feedback @dwita !
-
It "convenient" to blame the install script when something goes awry. It's also possible that the issue has been caused by a recent change made by the developers. See this recent thread for example.
Maybe it would help to diagnose some of these ongoing problems if the web GUI showed the last commit for non-XOA installs. This could help distinguish between
xo-server 5.51.1built on Oct 25th and the same version number built on Nov 2nd. -
@Danp That may not be directly to script but to the external environment: SMB works much better if
cifs-utilsis installed on the system, something that is present on our doc but might be missing in some install scripts.We have no animosity whatsoever regarding these scripts but we prefer our appliances (or even manual installs from our documentation) because we understand much better what's going on and it's easier to replicate and fix the issues
Regarding your idea of including the commit identifier for the source version, that's not a bad idea, a (as simple as possible) implementation in a PR would be welcome
-
I've checked the install script and I do see that cifs-utils is not included in that installer. I double and triple checked packages required before I abandoned the installer just to make sure nothing we missed, but missed that cifs-utils wasn't included. The install script in question is the one linked below.
https://github.com/ronivay/xenorchestrainstallerupdater
I may test this later by using the install script and adding cifs-utils, plus whatever else may be missing. If I do I will report back.
-
-
@Danp done.
-
And that's exactly our point. 3rd party script won't be able to "follow" any change in the install procedure (which is a markdown text we update in the same repo), and people could hit walls and have a bad opinion on the software based on unmaintained/not up to date script.
In the end, following the procedure in our doc is not that complicated, and you are sure to use the latest/up to date instructions.
-
@julien-f said in Backups to SMB remote failing:
We have no animosity whatsoever regarding these scripts
@olivierlambert said in Backups to SMB remote failing:
And that's exactly our point. 3rd party script won't be able to "follow" any change in the install procedure (which is a markdown text we update in the same repo), and people could hit walls and have a bad opinion on the software based on unmaintained/not up to date script.
Can we just agree to disagree?
-
I don't see any animosity here, I'm not sure to understand what you meant?
-
@julien-f said in Backups to SMB remote failing:
Regarding your idea of including the commit identifier for the source version, that's not a bad idea, a (as simple as possible) implementation in a PR would be welcome
Maybe you could expand your recently created issue to include this.
https://github.com/vatesfr/xen-orchestra/issues/4693
closed Display XOA build number in UI #4693
-
@Danp The implementation would be very different
