Backups to SMB remote failing
-
I am using the latest XO compiled from sources, on the latest XCP-NG 8.0. Backups are failing to SMB remote for both Delta backups and the metadata backups. The first metadata backup did complete, however the following backups will not. The logs are attached below. The remote shows as enabled, and it is able to perform a read/write test however the speed is slower than I would expect. Both the server and backup target are connected at 1gb. There is plenty of space on the target, and I have verified both share and NTFS permissions are correct (full permissions on both) for the account.
2019-11-01T16_00_00.003Z - backup NG.txt
2019-11-01T04_00_00.007Z - backup NG.txt
-
Update 1
I am testing with the free XOA appliance. When connecting the SMB remote I was given error 121 from mount.cifs, when searching a resolution I found to place the SMB version in the options, for me this is vers=2.1 and then the remote SMB connected successfully.
I've added that to my original XO setup to test backups. I will report if they are successful.
-
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
