Jump to content
rcfa

Retrospect server lists drives as empty which the clients mount according to an /etc/fstab entry

Recommended Posts

Here's what happens:

 

Our clients mount, to seamlessly extend certain critical sections of the file system hierarchie with RAID-6 support, volumes at custom mount points, such as not to interfere with OS X default paths. The resulting /etc/fstab entry looks as follows:

 

cat /etc/fstab
# fs_spec								    fs_file  fs_vfstype  fs_mntops
#
# UUID=01234567-89AB-CDEF-0123-456789ABCDEF /export ufs ro
# UUID=01234567-89AB-CDEF-0123-456789ABCDEF none hfs rw,noauto
# LABEL=This\040Is\040The\040Volume\040Name none msdos ro
# UUID=01234567-89AB-CDEF-0123-456789ABCDEF /Applications/Folder\040with\040spaces\040in\040name hfs rw,auto,suid,nobrowse
UUID=01234567-89AB-CDEF-0123-456789ABCDEF /Users    hfs rw,auto,suid
UUID=01234567-89AB-CDEF-0123-456789ABCDEF /Users/Shared/Pictures  hfs rw,auto,suid

 

(Of course the UUIDs are the real volume UUIDs, which I replaced here with placeholders)

 

When connecting to the client with the server, I can look at the list of backup sources, and I can see the clients root volume, and also the volume named Users and the volume named Pictures, as well as automounted volumes from a variety of external drives.

I can list the files/folders in both the root drive and in all the automounted volumes, but when I want to list the contents of the Users volume or the Pictures volume, they show as empty, which of course, they are not.

 

This effectively prevents us from backing up the most important part of the entire client: the /Users file system hierarchy!

 

Needless to say, I sent in a support request, but all I got back was this somewhat laconic answer:

 

Agent Response:

 

Retrospect is only going to be able to view volumes that show up under /volumes and inside /dev. When we scan the internal HD Mac HD, we are only going to be able to see items that physically exist on that disk.

 

Thank you for using Retrospect.

The Retrospect Support Team

 

The response is for one trying to restate a massive bug as a feature, and also makes no sense, because file systems mounted to user specified mount points with the /etc/fstab mechanism are visible perfectly fine in /dev/ and using /etc/fstab is perfectly supported by the OS X (it works even in iOS!!!) and is if anything the original standard way of mounting any file system. If anything is non-standard in a Unix system, then it's some proprietary automount demon.

 

I'm posting this here in the hope that someone who actually does coding for Retrospect and understands what I'm talking about is reading this and ends up fixing the bug, because this certainly *IS* a bug, not a feature or even a limitation. A backup software that wants to be taken seriously simply has to support something as standard as this.

  • Like 1

Share this post


Link to post
Share on other sites

By the sounds of it, Retrospect doesn't actually read the fstab file at all. It's looking for the contents of /Volumes. You'll probably need to mount the drives to /Volumes/Users, and /Volumes/Pictures and then symlink to them within the parent filesystems.

 

As a side-note, Retrospect Linux doesn't read the fstab at all. It tends to look at the mtab, and last I checked, it would choke if if you had more than one whitespace between fields.

Share this post


Link to post
Share on other sites

By the sounds of it, Retrospect doesn't actually read the fstab file at all. It's looking for the contents of /Volumes. You'll probably need to mount the drives to /Volumes/Users, and /Volumes/Pictures and then symlink to them within the parent filesystems.

Sure, that's what I conclude. But I consider that a bug, because just because /Volumes is the default location for automounted volumes, it's by no means the only place to mount volumes. If Retrospect were some cheap desktop backup solution for $20 from the AppStore, then I might tolerate that sort of behavior, but with something that's supposed to be enterprise-class backup solution, it's clear that even in the age of 5TB disk drives, a logical Unix-like file system hierarchy may need to be pieced together from multiple drives in a large server installation, e.g. boot drive, and then mounting a 30TB RAID-6 on /Users/

 

Auto-mounting these things in /Volumes and making a symlink won't work, because OS X (which I also consider a bug), expands all symlinks it encounters. Thus various parts of the OS throw hissy-fits because they do not recognize ~someUser when /Users/someUser ends up being expanded to some other location. That and similar matters make it impractical or impossible to use the /Volumes/ as mount points.

 

What I do is the inverse: make symlinks from /Volumes to the real mount points. The problem with that is, that after each reboot these symlinks are cleared, so I have to employ startup scripts to recreate these symlinks after each boot.

 

All in all, a rather obnoxious sort of workaround...

 

As a side-note, Retrospect Linux doesn't read the fstab at all. It tends to look at the mtab, and last I checked, it would choke if if you had more than one whitespace between fields.

 

Yikes....

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

×