#2973 PR `merged`: nfs_server as new restore method¶

Labels: enhancement, fixed / solved / done, sponsored

codefritzel opened issue at 2023-04-25 11:00:¶

Relax-and-Recover (ReaR) Pull Request Template¶

Please fill in the following items before submitting a new pull request:

Pull Request Details:¶

Type: New Feature
Impact: Low
Reference to related issue (URL):
How was this pull request tested?
Manually on Ubu22.04 and OL8.7
Brief description of the changes in this pull request:
This pull request adds NFS_SERVER as a new restore method. In the rescue stage rear starts an NFS server and exports all mount points. With NFS version 4 the rootfs to be restored can be mounted with the following command:
mount -t nfs -o nfsvers=4 <ip>:/ /mnt
Another server with working backup software can mount this share and restore all data to it.
Rear waits until the file 'rear_finished.txt' is created and all connections to the nfs server are disconnected. After that Rear continues with the restore process

jsmeix commented at 2023-04-25 11:33:¶

@codefritzel
thank you for your contribution to enhance ReaR!

jsmeix commented at 2023-04-25 11:44:¶

All new added files are shown in
https://github.com/rear/rear/pull/2973/files
with a "No newline at end of file" mark
which means the last line does not end with a newline character.
As far as I know a newline character at the end of every line
(including the last line) is required at least by some programs
that read input line by line where only the newline character
marks the end of a line so that a line without terminating
newline character will not be read by such programs.

gdha commented at 2023-04-26 10:33:¶

@codefritzel Could you please add some clear clarification why you need a NFS_SERVER workflow? Is NFS client not enough?

schlomo commented at 2023-04-26 10:47:¶

I can add some more context for this, I see three main scenarios for restore via NFS server:

In some cases there is a problem running the backup client in our rescue system, and then it might be "cheaper" to use an indirect restore scheme instead of spending more hours on enabling our rescue system to support that piece of commercial software
From a security perspective, it is always better to connect from a high-security ("bastion") system to the periphery. For backups this means that one could implement an NFS-based backup solution with pulling the date onto a central server. For restore we then need to start an NFS server in ReaR to push the data back. This could be part of a self-written solution or even use a commercial backup tool that is installed only on the central backup server for licensing or other reasons.
Implement asymmetric solutions, using one tool for backup and another tool for restore, in this case via NFS

In all those cases adding NFS server capabilities to the ReaR rescue system is IMHO a useful addition. I'd also consider modifying it to be an optional add-on feature instead of a stand-alone backup method. I also envision introducing a general split of BACKUP and RESTORE, if somebody needs this.

gdha commented at 2023-04-26 11:58:¶

@schlomo Thanks for the heads up as it makes it clear to me why it might be useful.
@codefritzel That being said please add some more comments from your side of the need of this new workflow, not just that it could be useful. And, above all, without proper documentation it will be a workflow only used by a happy few (amongst yourself I'm afraid).

schlomo commented at 2023-05-02 20:16:¶

Thanks a lot @codefritzel for the rework, I added you a bunch of minor fixes/changes and then I think we are good to go.

pcahyna commented at 2023-05-03 10:26:¶

Hi, looks useful, but I have a question: will the various extended attributes/ACLs get restored properly? SELinux contexts are probably handled in usr/share/rear/restore/default/500_selinux_autorelabel.sh, but there are other extended attributes that matter. See:

$ getfattr -m- -nsecurity.capability - /usr/sbin/* /usr/bin/* 2>/dev/null
# file: usr/sbin/arping
security.capability=0sAAAAAgAgAAAAAAAAAAAAAAAAAAA=

# file: usr/sbin/clockdiff
security.capability=0sAAAAAgAgAAAAAAAAAAAAAAAAAAA=

# file: usr/bin/newgidmap
security.capability=0sAQAAAkAAAAAAAAAAAAAAAAAAAAA=

# file: usr/bin/newuidmap
security.capability=0sAQAAAoAAAAAAAAAAAAAAAAAAAAA=

AFAIK if one uses NFSv4.2, then one is able to use such attributes over the NFS mount, but I have not tried it. -V 4.2 needs to be passed to rpc.nfsd and mount option v4.2 (or nfsvers=4.2?) should be specified.

pcahyna commented at 2023-05-03 14:38:¶

Another question about NFS. Is NFSv4 required because of its ability to automatically export and access filesystems mounted under the exported filesystem, i.e. to cross mountpoints? Seems pretty crucial for use in ReaR.

codefritzel commented at 2023-05-03 15:43:¶