Jump to content
oleksiak

"root folder name doesn't match volume name" error

Recommended Posts

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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>

 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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 😉

  • Like 1

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×