#818 Issue closed: missing nfs mountpoint after the recovery

Labels: bug, support / question, fixed / solved / done

pavoldomin opened issue at 2016-04-11 19:01:

Relax-and-Recover (rear) Issue Template

After the recovery mountpoints for NFS mounts are missing. This will make nfs shares not mounted after the recovery (if they are referenced from fstab). Related to #619.

Particularly, in prep/default/40_save_mountpoint_details.sh, the collection of nfs mountpoints is explicitly excluded.
I assume there is reason for it, but cannot figure out which.

Work-around is trivial: mkdir manually.

gdha commented at 2016-04-14 14:43:

Hi Pavol - good question: what was the reason? I cannot remember - is there any?
@rear/owners What are your thoughts?

jsmeix commented at 2016-04-15 09:05:

Because in prep/default/40_save_mountpoint_details.sh
there are no comments that explain why certain
things are excluded from the "mount" output,
nobody (except the one who made that code ;-)
can know about the reasoning behind.

Regardless of the reasoning behind I think the command

... mount | grep -vE '(cgroup|fuse|nfs|/sys/|REAR-000)' ...

is wrong because it excludes any "mount" output line
that contains anywhere e.g. "nfs" (i.e. much more
than to exclude only "mount" output lines where
the mounted filesystem type is "nfs".

In general I wonder if a hardcoded list of what should
be excluded is the right thing.

If something cannot be implemented in a hardcoded way,
I think the right way is to make it configurable by the user.

In this case e.g. via a array variable in default.conf that is
predefined with a list of what would be excluded by default.

jsmeix commented at 2016-04-15 09:44:

FYI how one could exclude mounted filesystem types
by using the newer "findmnt" command and output only
the mountpoint directories, e.g.:

findmnt -nrv -o TARGET -i -t 'nfs,cgroup'

But "findmnt" is not available on older systems
so that rear may use mount as fallback as I did in
usr/share/rear/layout/save/GNU/Linux/23_filesystem_layout.sh

didacog commented at 2016-04-15 10:15:

Hello!

Maybe with something like this should help:

mount -l -t "$(echo $(cat /proc/filesystems | grep -v nodev) | tr ' ' ',')"

And also works for older systems

gdha commented at 2016-04-19 11:56:

@didacog nice trick.

However, it wouldn't fix the NFS mounted file-systems. Perhaps, to catch all mounted file-systems (including the NFS ones) a simple ls -ld $(mount | grep -vE '(cgroup|fuse|nfsd|/sys/|REAR-000)' | awk '{print $3}') could do the trick?
Only change nfs to nfsd and it is fixed IMHO

jsmeix commented at 2016-04-19 13:57:

@pavoldomin
first and foremost I like to understand the actual issue here.

In your initial comment you wrote:

After the recovery mountpoints for NFS mounts are missing.
...
Work-around is trivial: mkdir manually.

Only a blind guess what I think the issue could be:

Usually directories should be restored from the backup.
In general what is not in the backup does not get restored.
Now I wonder why directories that are used as
mountpoints are not in the backup.
I guess that is because rear excludes for example
all what is mounted via NFS (because by default
files on remote systems should not be in the backup).
I assume when rear excludes sub-trees of the whole
tree of filesystems it also excludes their base directories
which is for NFS mounted stuff the mountpoint directory.

If my assumptions are true I wonder if it is really the
best way to deal with missing directories in the backup
by special scripts in rear for special cases when such
directories are used as mountpoints.

What about missing directories in the backup that are
not used as mountpoints?
For example how to exclude all content in /var/tmp
from the backup but keep the bare /var/tmp directory
in the backup?

Perhaps it would be better to improve how rear excludes
sub-trees of the whole tree of filesystems from the backup?

FYI:

I had the same issue for my https://github.com/rear/rear/issues/779
see https://github.com/rear/rear/issues/779#issuecomment-186171981
and https://github.com/rear/rear/pull/784/files

When moving away restored files that should not have been restored
the base directory of that files is kept (e.g. useful to remove all content in /var/tmp but keep the /var/tmp directory).

didacog commented at 2016-04-19 17:35:

@gdha thanks! ;)

If the problem is the exclude of basedir, maybe you can try using '/some_path/some_mount_point/*' in the exclude array definition, at least you can try using it as temporary workarround. :-P

pavoldomin commented at 2016-04-26 17:16:

Sorry, again the problem where this thread was found in trash :)

What is really happening here is, that /hana/shared contains nfs mountpoint referred from /etc/fstab, but as we exclude /hana/shared from the backup, mountpoint /hana/shared/SID is not created (and as a consequence application cannot start, because it environment links to that nfs mountpoint).

I think the solution above outlined by @gdha: ls -ld $(mount | grep -vE '(cgroup|fuse|nfsd|/sys/|REAR-000)' | awk '{print $3}') should work. Got a suspicion that it was actually meant like this in the first place :).

[Export of Github issue for rear/rear.]