#514 Issue closed: Always need to start manually rpcbind and rpc.statd before able to use rear to restore under RHEL

Labels: support / question

bobbysch opened issue at 2014-12-05 17:40:

Please could you fix that so NFS can be used to restore automatically without having to start manually rpcbind and rpc.statd processes (like on the live system running RHEL).

gdha commented at 2014-12-08 14:18:

@bobbysch could you a bit be more precise with which RHEL version do you have issues? Could you paste the exact error message you saw in the rear.log?

bobbysch commented at 2014-12-08 16:30:

Actually the problem occurs on Oracle Linux 5, 6 and 7. It's a clone from RHEL so i'm sure RHEL will have the same.
Here is the logs from

Backup:

2014-12-04 17:43:19 Including prep/NETFS/default/06_mount_NETFS_path.sh
mkdir: created directory '/tmp/rear.kUYQHo8imnYuaJw/outputfs'
2014-12-04 17:43:19 Mounting with 'mount -v -t nfs -o rw,noatime hounetapp2:/vol/vol_B_linux_backups/rear /tmp/rear.kUYQHo8imnYuaJw/outputfs'
mount.nfs: mount(2): Protocol not supported
mount.nfs: trying 10.2.203.122 prog 100003 vers 3 prot TCP port 2049
mount.nfs: trying 10.2.203.122 prog 100005 vers 3 prot UDP port 4046
mount.nfs: timeout set for Thu Dec  4 17:45:19 2014
mount.nfs: trying text-based options 'vers=4,addr=10.2.203.122,clientaddr=10.2.241.114'
mount.nfs: trying text-based options 'addr=10.2.203.122'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: prog 100005, trying vers=3, prot=17
2014-12-04 17:43:19 Including prep/NETFS/default/07_set_backup_archive.sh
/usr/share/rear/prep/NETFS/default/07_set_backup_archive.sh: line 13: [: ==: unary operator expected

Beside that, can you fix also the error /usr/share/rear/prep/NETFS/default/07_set_backup_archive.sh: line 13: [: ==: unary operator expected

Restore:

2014-12-08 16:12:55 Including verify/NETFS/default/06_mount_NETFS_path.sh
mkdir: created directory '/tmp/rear.ASlm0FgXHyt48ra/outputfs'
2014-12-08 16:12:55 Mounting with 'mount -v -t nfs -o rw,noatime hounetapp2:/vol/vol_B_linux_backups/rear /tmp/rear.ASlm0FgXHyt48ra/outputfs'
mount.nfs: Failed to resolve server hounetapp2: Name or service not known
2014-12-08 16:13:21 ERROR: Mount command 'mount -v -t nfs -o rw,noatime hounetapp2:/vol/vol_B_linux_backups/rear /tmp/rear.ASlm0FgXHyt48ra/outputfs' failed.
=== Stack trace ===
Trace 0: /usr/sbin/rear:249 main
Trace 1: /usr/share/rear/lib/recover-workflow.sh:27 WORKFLOW_recover
Trace 2: /usr/share/rear/lib/framework-functions.sh:81 SourceStage
Trace 3: /usr/share/rear/lib/framework-functions.sh:42 Source
Trace 4: /usr/share/rear/verify/NETFS/default/06_mount_NETFS_path.sh:11 source
Trace 5: /usr/share/rear/lib/global-functions.sh:153 mount_url
Trace 6: /usr/share/rear/lib/_input-output-functions.sh:132 StopIfError
Message: Mount command 'mount -v -t nfs -o rw,noatime hounetapp2:/vol/vol_B_linux_backups/rear /tmp/rear.ASlm0FgXHyt48ra/outputfs' failed.
===================
2014-12-08 16:13:22 Running exit tasks.
rmdir: removing directory, '/tmp/rear.ASlm0FgXHyt48ra/outputfs'
2014-12-08 16:13:22 Finished in 27 seconds
2014-12-08 16:13:22 Removing build area /tmp/rear.ASlm0FgXHyt48ra
rmdir: removing directory, '/tmp/rear.ASlm0FgXHyt48ra'
2014-12-08 16:13:22 End of program reached

Note that right after it failed, I could do nslookup and ping my NFS server hounetapp2 and of course rpcbind and rpc.statd processes are not running as expected.
Need to add sleep somewhere in the scripts?

bobbysch commented at 2014-12-08 16:44:

Additionally here is the logs when I launched manually "rear -v recover" after the automatic recovery failed.
It's slightly different but claims that rpc need to be there:

2014-12-08 16:35:19 Relax-and-Recover 1.16.1 / Git
2014-12-08 16:35:19 Command line options: /bin/rear -v recover
2014-12-08 16:35:19 Using log file: /var/log/rear/rear-houoraesx99.log
2014-12-08 16:35:19 Including /etc/rear/os.conf
2014-12-08 16:35:19 Including conf/Linux-i386.conf
2014-12-08 16:35:19 Including conf/GNU/Linux.conf
2014-12-08 16:35:19 Including /etc/rear/local.conf
2014-12-08 16:35:19 Including /etc/rear/rescue.conf
2014-12-08 16:35:19 Using build area '/tmp/rear.7i1QcUEUpg9Ewxq'
mkdir: created directory '/tmp/rear.7i1QcUEUpg9Ewxq/rootfs'
mkdir: created directory '/tmp/rear.7i1QcUEUpg9Ewxq/tmp'
2014-12-08 16:35:19 Running recover workflow
2014-12-08 16:35:19 Running 'setup' stage
2014-12-08 16:35:19 Including setup/default/01_pre_recovery_script.sh
2014-12-08 16:35:19 Finished running 'setup' stage in 0 seconds
2014-12-08 16:35:19 Running 'verify' stage
2014-12-08 16:35:19 Including verify/default/02_cciss_scsi_engage.sh
2014-12-08 16:35:19 Including verify/default/02_translate_url.sh
2014-12-08 16:35:19 Including verify/default/03_translate_tape.sh
2014-12-08 16:35:19 Including verify/default/04_validate_variables.sh
2014-12-08 16:35:19 Including verify/NETFS/default/05_check_NETFS_requirements.sh
2014-12-08 16:35:19 Skipping ping test
2014-12-08 16:35:19 Including verify/GNU/Linux/05_sane_recovery_check.sh
2014-12-08 16:35:19 Including verify/NETFS/default/06_mount_NETFS_path.sh
mkdir: created directory '/tmp/rear.7i1QcUEUpg9Ewxq/outputfs'
2014-12-08 16:35:19 Mounting with 'mount -v -t nfs -o rw,noatime hounetapp2:/vol/vol_B_linux_backups/rear /tmp/rear.7i1QcUEUpg9Ewxq/outputfs'
mount.nfs: mount(2): Protocol not supported
mount.nfs: rpc.statd is not running but is required for remote locking.
mount.nfs: Either use '-o nolock' to keep locks local, or start statd.
mount.nfs: mounting hounetapp2:/vol/vol_B_linux_backups/rear failed, reason given by server: No such file or directory
mount.nfs: timeout set for Mon Dec  8 16:37:19 2014
mount.nfs: trying text-based options 'vers=4,addr=10.2.203.122,clientaddr=10.2.241.114'
2014-12-08 16:35:20 ERROR: Mount command 'mount -v -t nfs -o rw,noatime hounetapp2:/vol/vol_B_linux_backups/rear /tmp/rear.7i1QcUEUpg9Ewxq/outputfs' failed.
=== Stack trace ===
Trace 0: /bin/rear:249 main
Trace 1: /usr/share/rear/lib/recover-workflow.sh:27 WORKFLOW_recover
Trace 2: /usr/share/rear/lib/framework-functions.sh:81 SourceStage
Trace 3: /usr/share/rear/lib/framework-functions.sh:42 Source
Trace 4: /usr/share/rear/verify/NETFS/default/06_mount_NETFS_path.sh:11 source
Trace 5: /usr/share/rear/lib/global-functions.sh:153 mount_url
Trace 6: /usr/share/rear/lib/_input-output-functions.sh:132 StopIfError
Message: Mount command 'mount -v -t nfs -o rw,noatime hounetapp2:/vol/vol_B_linux_backups/rear /tmp/rear.7i1QcUEUpg9Ewxq/outputfs' failed.
===================
2014-12-08 16:35:20 Running exit tasks.
rmdir: removing directory, '/tmp/rear.7i1QcUEUpg9Ewxq/outputfs'
2014-12-08 16:35:20 Finished in 1 seconds
2014-12-08 16:35:20 Removing build area /tmp/rear.7i1QcUEUpg9Ewxq
rmdir: removing directory, '/tmp/rear.7i1QcUEUpg9Ewxq'
2014-12-08 16:35:20 End of program reached

gdha commented at 2014-12-09 07:43:

@bobbysch see issue #158 for a work-around. NFSv4 support will be added in the future (when time permits), or faster (with sponsoring)

bobbysch commented at 2014-12-10 18:21:

This issue made me wonder how to tell rear to recover from a non original source use for backup.
In my case I used NFS to backup, but since I have this issue, how can i transfer the backup files to a different place and tell rear to use the new place and not the original one?

This is definitively very useful and flexible if rear can do it.

gdha commented at 2014-12-12 11:52:

rear can talk to a remote NFSv4 server, but in NFSv3 mode. Therefore, use BACKUP_OPTIONS="nfsvers=3,nolock" in the local.conf file

gdha commented at 2016-02-09 13:46:

@bobbysch This issue made me wonder how to tell rear to recover from a non original source use for backup just change the BACKUP_URL variable before doing the recover.
Can this issue be closed?

bobbysch commented at 2016-02-09 14:04:

Yes you can close it!
Thanks for this wonderful product!

On Tuesday, February 9, 2016, gdha notifications@github.com wrote:

@bobbysch https://github.com/bobbysch This issue made me wonder how to
tell rear to recover from a non original source use for backup
just
change the BACKUP_URL variable before doing the recover.
Can this issue be closed?


Reply to this email directly or view it on GitHub
https://github.com/rear/rear/issues/514#issuecomment-181870061.

Antoine Nguyen


[Export of Github issue for rear/rear.]