ReaR and NFS version 4

[exfarmer]

Can rear run with NFS V4?

• ReaR version ("/usr/sbin/rear -V"):
  Relax-and-Recover 2.6 / 2020-06-17

• If your ReaR version is not the current version, explain why you can't upgrade:
  No reason

• OS version ("cat /etc/os-release" or "lsb_release -a" or "cat /etc/rear/os.conf"):
  LSB Version: :core-4.1-amd64:core-4.1-noarch
  Distributor ID: RedHatEnterprise
  Description: Red Hat Enterprise Linux release 8.8 (Ootpa)
  Release: 8.8
  Codename: Ootpa

• ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat /etc/rear/local.conf"):
  OUTPUT=ISO
  BACKUP_OPTIONS="nfsvers=3,nolock"
  BACKUP=NETFS
  BACKUP_URL=nfs://edlusxo001.oneabbott.com/data/col1/usxo_linux_bu_image
  BACKUP_PROG_EXCLUDE=("${BACKUP_PROG_EXCLUDE[@]}" '/media' '/var/tmp' '/var/crash' '/var/log' '/usr/openv' '/srv' '/tmp/*')
  ONLY_INCLUDE_VG=( "vgos" )
  NETFS_KEEP_OLD_BACKUP_COPY=
  SYSLINUX_MODULES_DIR="/usr/share/syslinux"
  NETFS_PREFIX="$HOSTNAME-date +%Y%m%d%H%M%S 2>/dev/null"
  OUTPUT_PREFIX="$HOSTNAME.ReaRbkup.$( date +%Y%m%d%H%M%S 2>/dev/null )"
  NETFS_PREFIX="$HOSTNAME.ReaRbkup.$( date +%Y%m%d%H%M%S 2>/dev/null )"
  PROGRESS_WAIT_SECONDS="10"

• Hardware vendor/product (PC or PowerNV BareMetal or ARM) or VM (KVM guest or PowerVM LPAR):
  Dell PowerEdge R650

• System architecture (x86 compatible or PPC64/PPC64LE or what exact ARM device):
  X86

• Firmware (BIOS or UEFI or Open Firmware) and bootloader (GRUB or ELILO or Petitboot):

• Storage (local disk or SSD) and/or SAN (FC or iSCSI or FCoE) and/or multipath (DM or NVMe):
  SAN

• Storage layout ("lsblk -ipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,LABEL,SIZE,MOUNTPOINT"):

• Description of the issue (ideally so that others can reproduce it):
  It's not an issue, more of a question, Can rear backup use NFS V4?

• Workaround, if any:

• Attachments, as applicable ("rear -D mkrescue/mkbackup/recover" debug log files):

You can drag-drop log files into this editor to create an attachment
or paste verbatim text like command output or file content
by including it between a leading and a closing line of
three backticks like this:

verbatim content

[jsmeix]

@exfarmer
I am not at all an NFS expert so I cannot provide
authoritative information in this area.

I think in general ReaR should also work with NFS V4
because otherwise I would expect many issues from users
who use BACKUP=NETFS without BACKUP_OPTIONS="nfsvers=3,nolock"

From my (limited) experience with NFS issues in ReaR
I think when ReaR had issues with NFS the root cause
was in most cases something outside of ReaR
like improper NFS setup on the NFS server or
improper NFS things on the client where ReaR runs.

In conf/default.conf I found

# BACKUP=RBME
##
# This mode allows restoring a RBME backup from NFS shares.
# As NFSv4 is not fully supported with ReaR (yet) it is safer to
# use BACKUP_OPTIONS="nfsvers=3,nolock" in the local.conf file.
# Note: You may have to open appropriate TCP/UDP ports on the NFS server (iptables).

According to git log --follow -p usr/share/rear/conf/default.conf
this is from @gdha more than 10 years ago in 2012
7033653

I don't know if this comment is still relevant nowadays.

By searching for 'nfs' in doc/rear-release-notes.txt
https://github.com/rear/rear/blob/master/doc/rear-release-notes.txt#L3492
I found
#754
which leads to
fdcaf7a

So NFS version 4 specific things are (mostly) implemented in
prep/NETFS/default/100_check_nfs_version.sh
https://github.com/rear/rear/blob/master/usr/share/rear/prep/NETFS/default/100_check_nfs_version.sh
which is run during "rear mkrescue/mkbackup"
and in
verify/NETFS/default/050_start_required_nfs_daemons.sh
https://github.com/rear/rear/blob/master/usr/share/rear/verify/NETFS/default/050_start_required_nfs_daemons.sh
which is run during "rear recover".

[gdha]

@exfarmer Yes, we use ReaR in combination with NFS version 4.0 all the time.
If the NFS server has to pass many hops make sure that the MTU values are the same everywhere, as otherwise, too many packet drops may be possible.
We are also switching from gzip to zstd as compression algorithm as it much faster and it provides lossless compression that is splittable (gzip is not splittable).

[jsmeix]

Via #3053
I propose to update the RBME description in default.conf

[github-actions]

Stale issue message