oleksiak Posted January 9, 2020 Report Share Posted January 9, 2020 We recently moved our storage (xfs formatted volume) from one server (Linux CentOS 6) to another (Linux CentOS 7). Now, when backing up the same volume using Retrospect, everything is transferred to tape properly, but at the end the activity ends with an error: While scanning volume , root folder name doesn't match volume name: root "", volume "" Does anyone have a clue what that means and how to make Retrospect happy? Retrospect Engine version is 16.1.2.102, because the latest one does not work, it crashes our Linux client on connect. Linux client is on its latest, 16.0.0.7. Quote Link to comment Share on other sites More sharing options...
Nigel Smith Posted January 9, 2020 Report Share Posted January 9, 2020 It looks like you've got an un-named volume on the Linux client, and RS isn't happy about volumes without a name. Try setting things so that only the (named) storage volume(s) is/are backed up. Quote Link to comment Share on other sites More sharing options...
oleksiak Posted January 9, 2020 Author Report Share Posted January 9, 2020 Well, if by "name" you mean that the volume should have a label - then it has. [root@host ~]$ lsblk --fs /dev/sdn1 NAME FSTYPE LABEL UUID MOUNTPOINT sdn1 xfs inS<redacted> 8117289f-4d52-40b0-a018-1b64dc836d06 /mnt/inS<redacted> Quote Link to comment Share on other sites More sharing options...
DavidHertzberg Posted January 9, 2020 Report Share Posted January 9, 2020 oleksiak, Read the second post in this Windows Linux, Unix and Netware Clients thread. If the CentOS 7—but with FreeBSD kernel (... 11.2 and 12.0 kernels)—is applicable to you, it looks like there was—at least experimentally—some kind of fix for the Retrospect Windows Engine that may not have made it into the Retrospect Mac Engine. OTOH maybe that fix never made it into a later production release of the Retrospect Windows Engine. I'd suggest PM'ing Xenomorph to find out if it did, and then contacting Retrospect Tech Support on that basis. You may also (or instead—in case your OP-described bug was fixed in Engine 16.5 or 16.6) have to get your "it crashes our Linux client on connect" bug fixed for the Retrospect Mac Engine 16.6, though, unless you can get your OP-described bug fixed in an experimental version of 16.1.2.102 instead for 16.6. Quote Link to comment Share on other sites More sharing options...
oleksiak Posted January 9, 2020 Author Report Share Posted January 9, 2020 Thank you for the feedback. I reported the crashing bug to Tech Support, although our ASM expired, so I wonder how such issue will be treated. Quote Link to comment Share on other sites More sharing options...
DavidHertzberg Posted January 9, 2020 Report Share Posted January 9, 2020 As to how the crashing bug report will be treated, read the fifth paragraph in this 2017 post. I have never had ASM, but Tech Support responds to my bug reports; for one bug I was given a test release with enhanced logging—although I didn't get personalized help. 1 Quote Link to comment Share on other sites More sharing options...
Nigel Smith Posted January 9, 2020 Report Share Posted January 9, 2020 5 hours ago, oleksiak said: Well, if by "name" you mean that the volume should have a label - then it has. No -- I'm suggesting that it is successfully scanning, backing up, and verifying the storage volume, and is *then* failing to scan a nameless volume. What's the output from "lsblk --fs", without the device selector? I'm assuming that, as with a Mac client, you can set things to back up the complete Linux box, only selected volumes, etc. Perhaps a previous "only the storage volume" tick-box was forgotten in the transfer to the new server. Quote Link to comment Share on other sites More sharing options...
oleksiak Posted January 10, 2020 Author Report Share Posted January 10, 2020 There are many nameless devices listed on lsblk output (these are StorNext LUNs), but they were present on previous system too. I am not sure what tick-box you are referring to... In my backup I have only one specific volume selected as a source. Most probably containerd (Docker) running on this Linux server is the culprit (Retrospect client is not installed inside container). I got a reply from Tech Support regarding 16.6.0.114 version crashing, they informed me there is no support for "docker configurations". If that's true, that would be a severe limitation. Quote Link to comment Share on other sites More sharing options...
Nigel Smith Posted January 10, 2020 Report Share Posted January 10, 2020 1 hour ago, oleksiak said: I am not sure what tick-box you are referring to... In my backup I have only one specific volume selected as a source. That's the information I was looking for... So *if* you are only backing up one volume *and* that volume is backing up/verifying successfully *and* you can restore from the backup *and* you get the un-named volume error *and* Retrospect carries on regardless -- I'd just ignore it. If the error is causing other problems, eg killing the script while there are still other machines to process, re-arrange things so the erring machine is the last to be done. If the error is truly killing the system, eg popping a dialog that must be dismissed before continuing, I'd look into script triggers and a GUI-targetted AppleScript to automatically dismiss the dialog so RS can continue. Some things are easier to work round than to fix 😉 1 Quote Link to comment Share on other sites More sharing options...
oleksiak Posted January 10, 2020 Author Report Share Posted January 10, 2020 For now I can and will ignore this error. It just marks the (scheduled) backup as failed at the end and sends an email report stating what the problem is, no interaction is needed. Quote Link to comment Share on other sites More sharing options...
DavidHertzberg Posted January 10, 2020 Report Share Posted January 10, 2020 (edited) oleksiak, This sounds like a problem I had in July 2017 (note to self: see Support Case #56419) when I experimentally upgraded my MacBook Pro from the Mac 14.0 Client to the Mac 14.1 Client. When I re-Added the MBP as a "client" on Retrospect Mac 14, it began doing scripted Backup activities having the MBP as a Source so as to automatically include what I will call 3 Apple-created "hidden duplicate volumes" on the MBP—for which it got -1101 errors because the Engine couldn't see the "hidden duplicate volumes" on Backup script runs. I discovered that there is now a Volumes dropdown in Sources->Options that specifies which volumes on a "client" should be backed up. The dropdown defaults to All Volumes; I found I had to change the dropdown to Startup Volume to eliminate the "hidden duplicate volumes" (which are not shown with a disclosure triangle). The Volumes dropdown is documented on page 40 of the Retrospect Mac 16 User's Guide,. Try changing the Options->Volumes dropdown in your Sources definition of your Linux "client" machine to Startup Volume—you may need to do a Sources Remove and re-Add and then re-checkmark in scripts. I have a hunch that doing so may eliminate Retrospect Mac's trying to back up the Docker container. Edited January 11, 2020 by DavidHertzberg Revise first paragraph because the "hidden duplicate volumes" problem occurred in 2017 instead of 2019, and the Volumes dropdown _is_ documented in the UG Quote Link to comment Share on other sites More sharing options...
oleksiak Posted January 13, 2020 Author Report Share Posted January 13, 2020 Thanks for the suggestion, I indeed overlooked that option. Unfortunately removing unnecessary volumes, both from sources list and by unchecking them in "Selected Volumes" list, did not help. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.