What were you trying to do that didn't work?
This is a continuation of https://issues.redhat.com/browse/RHEL-17390.
When fixing the issue above, the restore happens fine, until it fails at the end, as seen in the log file /var/tmp/rear.XXX/tmp/bplog.restore:
Restore Job Id=7417541 Restore started 11/24/2023 16:19:26 16:19:27 (7417541.xxx) Found (1,941,929) files in (33) images for Restore Job ID 7417541.xxx 16:19:30 (7417541.xxx) Estimated time to assemble file list: (0) days, (0) hours, (0) min, (38) sec 16:19:39 (7417541.xxx) !/mnt/local -s 11/23/2023 15:47:20 -e 11/24/2023 16:19:27 - no files matched in the given date range 16:19:40 (7417541.xxx) Searched ( 167,252) files of (1,941,929) files for Restore Job ID 7417541.xxx 16:19:40 (7417541.001) Restoring from copy 1 of image created Thu Nov 23 15:47:20 2023 from policy VMware-OE-ClientBased-Linux [...]
We see NetBackup complains about path !/mnt/local (timestamp 16:19:39), which is ReaR generated, and used to exclude the target directory, as seen in /usr/share/rear/restore/NBU/default/300_create_nbu_restore_fs_list.sh on line 24 or 31:
[...] 21 # Part 4: Add excluded filesystems to the listfile used in the -f option of the bprecover command 22 if grep -q "^/$" $TMP_DIR/restore_fs_list 23 then 24 echo "!$TARGET_FS_ROOT" >> $TMP_DIR/restore_fs_list 25 fi 26 if [ ${#EXCLUDE_MOUNTPOINTS[@]} -gt 0 ] 27 then 28 for FS in ${EXCLUDE_MOUNTPOINTS[@]} 29 do 30 echo "${FS}/" >> $TMP_DIR/restore_fs_list 31 echo "!${FS}/*" >> $TMP_DIR/restore_fs_list 32 done 33 fi
Apparently NetBackup 10.2.0.1 doesn't like this, since it searches for !/mnt/local as a real path, not something excluded.
Please provide the package NVR for which bug is seen:
rear-2.6-19.el9.x86_64
How reproducible:
Always on customer system, cannot test myself since no access to NetBackup