#562 Issue closed: What to do if server has failed and NFS is not working

Labels: waiting for info, support / question

cocampbe opened issue at 2015-03-09 14:29:

This post is for brain storming ideas. Currently I have rear setup to take a new backup weekly. Occasionally I test a restore to make sure things are still working. After awhile of patching and updating the OS, I notice that NFS connectivity breaks in rear. I wil try different nfs options to no avail. One idea I was thinking about was booting from a recovery cd, mounting the rear iso, and then running rear recover. I am not sure how well this would work. I am also curious if anyone has run into this issue and has a good workaround.

bbeaver commented at 2015-03-09 19:19:

You mention running a test restore - when you do this, are you able to boot off the stored kernel image, but then your recover fails due to some type of NFS error? If so, from the ReaR prompt after booting up the kernel image, you could try "showmount -e NFSSERVER" to confirm the NFS mounts are properly exported and available. And if they are, then try to manually perform an NFS mount and see what happens.

cocampbe commented at 2015-03-09 19:24:

You are correct. Rear boots. the rpc services are running. Showmount did work in this. But kept getting the error "protocol not supported". I have seen threads that talk about NFSv4, but that was not the case here. I tried mounting different shares from other servers. And I still got the "protocol not supported error". I also changed the mount options to nfsvers=3,nolock an nfsvers=2,nolock. But no go. Once I updated rear to a newer version, it worked fine.

Another option I have is to update rear more frequently and test more frequently.

schlomo commented at 2015-03-09 21:52:

It for sure is good to use a recent ReaR version if you update the OS.

What OS and ReaR version are we talking here about?

jsmeix commented at 2015-03-10 08:18:

Only FYI a generic side note regarding
"patching and updating the OS":

See "Version upgrades" at
https://en.opensuse.org/SDB:Disaster_Recovery
that reads (excerpt):

For each rear version upgrade you must carefully re-validate that
your particular disaster recovery procedure still works for you.
...
When you have a working disaster recovery procedure running
and you upgrade software that is related to the basic system or
you do other changes in your basic system, you must also
carefully re-validate that your particular disaster recovery
procedure still works for you.

In other words:
There are often somewhat hidden/unexpected interdependencies between the Linux distribution and its version and the rear version.

gdha commented at 2015-03-10 09:28:

Perhaps, read issue #547 - was the portmap daemon running?

bbeaver commented at 2015-03-10 14:20:

Just an fyi - testing with the showmount command will confirm whether or not portmap is running. @cocambe mentioned showmount returned properly. Should be able to isolate NFS issues outside of ReaR, using showmount and manually attempting to mount, (mkdir /mnt/a;mount NFSSERVERIP:/sharename_from_showmount /mnt/a;umount if it mounted;then rmdir /mnt/a), after booting up the ReaR kernel image.

cocampbe commented at 2015-03-10 14:29:

@schlomo The happened recently. I am running OEL6. Most are at 6.6. I have a few at 6.5. The last rear push I had was rear-1.13.0-56.git201209050817. I know it's old. I need to do a better job of keeping up to date. I just updated all my dev/test hosts to 1.16.1-git201503061713.

@jsmeix Very good point.

@gdha Unfortunately, I did not check portmap. I felt pressured to get things working, so I only went so far in the troubleshooting process. I assumed a newer rear version would resolve the issue.

gdha commented at 2015-03-10 14:51:

@cocampbe yes rear -1.16.1-git201503061713 should contain the fix for your problem. Please give feedback if it doesn't

gdha commented at 2015-06-30 10:25:

I'll close this issue - if it comes back a new case will be made (I'm sure of it)

[Export of Github issue for rear/rear.]