cannot recover on clean install system

[Hardcore-fs]

Relax-and-Recover (ReaR) Issue Template

Rear 2.7
rocky linux 8.5
VMware fusion.

BACKUP=NETFS
BACKUP_PROG=tar
BACKUP_TYPE=Incremental
FULLBACKUPDAY="SAT"

Went straight into an "incremental" backup

rear -v mkbackup

the first file shows as 2022-08-19-2021-F.tar.gz

But REAR complains it cannot find backup.tar.gz

I have no
NETFS_KEEP_OLD_BACKUP_COPY=y

[gdha]

@Hardcore-fs Could you please explain what you did step-by-step as it is not 100% clear to us?

[Hardcore-fs]

Used the above. (obviously with an NTFS mount point ..not shown)

then
sudo rear -v mkbackup.

which scanned system built the ISO and then built a tar file with an extension of *-f.tar
which WILL NOT WORK for recovery, without a base tar file "backup.tar.gz"

if you go straight into incremental on a CLEAN system, there does not appear to be a "backup.tar.gz"

also for sanity....... really... when the system runs the "full backup" it should also at minimum find the "backup.tar.gz"
to ensure it at-least exists....
becasue otherwise , should it go astray, any backup is totally useless, even though your system shows it has "full" backups.

If you comment out the "BACKUP_TYPE=Incremental", then the system DOES create "backup.tar.gz"
and when you put "BACKUP_TYPE=Incremental" back, the system functions as expected.

[jsmeix]

For me a test today "just works" with

OUTPUT=ISO
BACKUP=NETFS
BACKUP_OPTIONS="nfsvers=3,nolock"
BACKUP_URL=nfs://192.168.122.1/nfs
BACKUP_TYPE=incremental
FULLBACKUPDAY=( Tue )

where 192.168.122.1 is the host
of a QEMU/KVM virtual machine
(the "original system")
where I run "rear mkbackup"

# usr/sbin/rear -D mkbackup
...
Today's weekday ('Tue') is a full backup day that triggers a new full backup in any case
No full backup found (YYYY-MM-DD-HHMM-F.tar.gz) triggers full backup
Performing full backup using backup archive '2022-09-06-1444-F.tar.gz'
.
.
.
Making backup (using backup method NETFS)
Creating tar archive '/var/tmp/rear.5PCLWy1ONV0cRZR/outputfs/localhost/2022-09-06-1444-F.tar.gz'
Preparing archive operation
Archived 25 MiB [avg 4408 KiB/sec] 
...
Archived 1894 MiB [avg 5895 KiB/sec] 
OK
...
Exiting rear mkbackup (PID 2828) and its descendant processes ...

which results on the 192.168.122.1 host

# ls -lhtr /nfs/localhost
total 2.0G
-rw-rw-rw- 1 qemu   qemu    71M Sep  6 14:45 rear-localhost.iso
-rw-rw-rw- 1 root   root    266 Sep  6 14:45 VERSION
-rw-rw-rw- 1 root   root    202 Sep  6 14:45 README
-rw-rw-rw- 1 root   root   1.8M Sep  6 14:45 rear-localhost.log
-rw-rw-rw- 1 nobody nobody 1.9G Sep  6 14:50 2022-09-06-1444-F.tar.gz
-rw-rw-rw- 1 root   root   6.9M Sep  6 14:50 backup.log

Then on another new created QEMU/KVM virtual machine
(the "replacement hardware")
with same disk size on the same 192.168.122.1 host

RESCUE localhost:~ # rear -D recover
...
For backup restore using  2022-09-06-1444-F.tar.gz
...
Calculating backup archive size
Backup archive size is 1.9G     /var/tmp/rear.Yxdw9yOemQrjj4B/outputfs/localhost/2022-09-06-1444-F.tar.gz (compressed)
.
.
.
Restoring from '/var/tmp/rear.Yxdw9yOemQrjj4B/outputfs/localhost/2022-09-06-1444-F.tar.gz' (restore log in /var/lib/rear/restore/recover.2022-09-06-1444-F.tar.gz.721.restore.log) ...
Backup restore program 'tar' started in subshell (PID=4496)
Restored 241 MiB [avg. 49419 KiB/sec] 
...
OK
Restored 3907 MiB in 105 seconds [avg. 38109 KiB/sec]
...
Finished 'recover'. The target system is mounted at '/mnt/local'.

[jsmeix]

Tomorrow I will test how an actual incremental backup
and restore works on the above QEMU/KVM virtual machines.

[jsmeix]

@Hardcore-fs
perhaps in your initial comment BACKUP_TYPE=Incremental
with capital I at the beginning is a typo only in your comment
but for actual ReaR only BACKUP_TYPE=incremental
(all lowercase incremental) will work because the code in
usr/share/rear/prep/NETFS/default/070_set_backup_archive.sh

if ! test "incremental" = "$BACKUP_TYPE" -o "differential" = "$BACKUP_TYPE" ; then
.
.
.
        case "$BACKUP_TYPE" in
            (incremental)

only tests for incremental.
See usr/share/rear/conf/default.conf how BACKUP_TYPE
is described therein.

Also FULLBACKUPDAY="SAT" with all uppercase SAT
probably will not work.
See usr/share/rear/conf/default.conf how FULLBACKUPDAY
is described therein (excerpt):

# The weekday values must match the output of "date +%a" run in the POSIX/C locale

and on my system (openSUSE Leap 15.3) I get today

# ( export LC_ALL=C LANG=C ; date +%a )
Tue

i.e. for me only the first letter is uppercase.
Furthermore FULLBACKUPDAY has to be normally an array.
For a single word FULLBACKUPDAY="Sat" should also work
by luck how bash handles arrays versus strings.

[Hardcore-fs]

Hi,
Your run is exactly what I get. INCLUDING your directory list.
the problem is the restore, it demands a file that is NOT "xxx.f.tar.gz"
it insists it is given "backup.tar.gz"

Which i can fix by making 2 runs, as outlined above.

Could it be that during the restore, the BACKUP_TYPE=Incremental (capital I)
is confusing the system, and THAT is why it is asking for "backup.tar.gz" ?

I will check if simply changing the "I" will make it function on restore.
I think maybe the "upper case" is some damned interaction with "notes" on the osx (where i keep base configs)
I have seen it changing text pasted to the clip board, specifically --`' &"-- to some weird unicode values and also capitalization.
same with MS outlook., which we use sometimes to pass copy & paste configs to distribute to branch offices.

That said... SW should not be fooled by case changes, user /system input should be sanitized with forced case before compares. (also what happens if these are running on non English systems...? )
where "( export LC_ALL=C LANG=C ; date +%a )" will not produce this output

[jsmeix]

An actual incremental backup (cf. above)
and restore "just works" for me.

On my "original system" (cf. above):

# date >/root/incremental1.date

# ls -lh /root/incremental1.date
-rw-r--r-- 1 root root 33 Sep  7 12:04 /root/incremental1.date

# cat /root/incremental1.date
Wed 07 Sep 2022 12:04:36 PM CEST

# usr/sbin/rear -D mkbackuponly
...
Latest full backup found (2022-09-06-1444-F.tar.gz) triggers incremental backup
Performing incremental backup for files newer than 2022-09-06 using backup archive '2022-09-07-1207-I.tar.gz'
...
Creating tar archive '/var/tmp/rear.t4DYeqyKCkFhOLF/outputfs/localhost/2022-09-07-1207-I.tar.gz'
Preparing archive operation
Archived 11 MiB [avg 1906 KiB/sec] 
...
Archived 190 MiB [avg 6110 KiB/sec]
OK
...
Exiting rear mkbackuponly (PID 2580) and its descendant processes ...

On my "192.168.122.1 host" (cf. above):

# ls -lhtr /nfs/localhost
total 2.2G
-rw-rw-rw- 1 qemu   qemu    71M Sep  6 14:45 rear-localhost.iso
-rw-rw-rw- 1 root   root    266 Sep  6 14:45 VERSION
-rw-rw-rw- 1 root   root    202 Sep  6 14:45 README
-rw-rw-rw- 1 root   root   1.8M Sep  6 14:45 rear-localhost.log
-rw-rw-rw- 1 nobody nobody 1.9G Sep  6 14:50 2022-09-06-1444-F.tar.gz
-rw-rw-rw- 1 nobody nobody 192M Sep  7 12:07 2022-09-07-1207-I.tar.gz
-rw-rw-rw- 1 root   root   9.5M Sep  7 12:07 backup.log

On my "replacement hardware" (cf. above):

RESCUE localhost:~ # rear -D recover
...
For backup restore using  2022-09-06-1444-F.tar.gz 2022-09-07-1207-I.tar.gz
...
Start system layout restoration.
...
Disk layout created.
Restoring from '/var/tmp/rear.KAnt0PndE75EBlo/outputfs/localhost/2022-09-06-1444-F.tar.gz' (restore log in /var/lib/rear/restore/recover.2022-09-06-1444-F.tar.gz.717.restore.log) ...
Backup restore program 'tar' started in subshell (PID=4494)
Restored 169 MiB [avg. 34667 KiB/sec] 
...
OK
Restored 3907 MiB in 110 seconds [avg. 36376 KiB/sec]
Restoring from '/var/tmp/rear.KAnt0PndE75EBlo/outputfs/localhost/2022-09-07-1207-I.tar.gz' (restore log in /var/lib/rear/restore/recover.2022-09-07-1207-I.tar.gz.717.restore.log) ...
Backup restore program 'tar' started in subshell (PID=4655)
Restored 181 MiB [avg. 37160 KiB/sec] 
OK
Restored 332 MiB in 10 seconds [avg. 33997 KiB/sec]
...
Recreated initrd (/sbin/mkinitrd).
Installing GRUB2 boot loader...
...
Finished 'recover'. The target system is mounted at '/mnt/local'.
...
RESCUE localhost:~ #

RESCUE localhost:~ # ls -l /mnt/local/root/incremental1.date 
-rw-r--r-- 1 root root 33 Sep  7 12:04 /mnt/local/root/incremental1.date

RESCUE localhost:~ # cat /mnt/local/root/incremental1.date 
Wed 07 Sep 2022 12:04:36 PM CEST

[jsmeix]

One more actual incremental backup
with "rear mkbackup" also works for me:

On my "original system" (cf. above):

# date >/root/incremental2.date

# cat /root/incremental*.date
Wed 07 Sep 2022 12:04:36 PM CEST
Wed 07 Sep 2022 01:20:07 PM CEST

# ls -l /root/incremental*.date
-rw-r--r-- 1 root root 33 Sep  7 12:04 /root/incremental1.date
-rw-r--r-- 1 root root 33 Sep  7 13:20 /root/incremental2.date

# usr/sbin/rear -D mkbackup
...
Latest full backup found (2022-09-06-1444-F.tar.gz) triggers incremental backup
Latest incremental backup found (2022-09-07-1207-I.tar.gz) that is newer than the latest full backup
Performing incremental backup for files newer than 2022-09-07 using backup archive '2022-09-07-1320-I.tar.gz'
...
Creating disk layout
...
Copying files and directories
Copying binaries and libraries
...
Creating recovery/rescue system initramfs/initrd initrd.cgz with gzip default compression
...
Making ISO image
...
Making backup (using backup method NETFS)
Creating tar archive '/var/tmp/rear.V3T5DR2BwnS4Wvd/outputfs/localhost/2022-09-07-1320-I.tar.gz'
Preparing archive operation
Archived 1 MiB [avg 269 KiB/sec] 
OK
...
Exiting rear mkbackup (PID 1930) and its descendant processes ...

On my "192.168.122.1 host" (cf. above):

# ls -lhtr /nfs/localhost
total 2.2G
-rw-rw-rw- 1 nobody nobody 1.9G Sep  6 14:50 2022-09-06-1444-F.tar.gz
-rw-rw-rw- 1 nobody nobody 192M Sep  7 12:07 2022-09-07-1207-I.tar.gz
-rw-rw-rw- 1 qemu   qemu    71M Sep  7 13:21 rear-localhost.iso
-rw-rw-rw- 1 root   root    266 Sep  7 13:21 VERSION
-rw-rw-rw- 1 root   root    202 Sep  7 13:21 README
-rw-rw-rw- 1 root   root   1.8M Sep  7 13:21 rear-localhost.log
-rw-rw-rw- 1 nobody nobody 1.9M Sep  7 13:21 2022-09-07-1320-I.tar.gz
-rw-rw-rw- 1 root   root   9.7M Sep  7 13:21 backup.log

On my "replacement hardware" (cf. above):

RESCUE localhost:~ # rear -D recover
...
For backup restore using  2022-09-06-1444-F.tar.gz 2022-09-07-1207-I.tar.gz 2022-09-07-1320-I.tar.gz
...
Start system layout restoration.
...
Disk layout created.
Restoring from '/var/tmp/rear.fUWCbLaNo28hZn2/outputfs/localhost/2022-09-06-1444-F.tar.gz' (restore log in /var/lib/rear/restore/recover.2022-09-06-1444-F.tar.gz.725.restore.log) ...
Backup restore program 'tar' started in subshell (PID=4518)
Restored 169 MiB [avg. 34667 KiB/sec] 
...
OK
Restored 3907 MiB in 101 seconds [avg. 39618 KiB/sec]
Restoring from '/var/tmp/rear.fUWCbLaNo28hZn2/outputfs/localhost/2022-09-07-1207-I.tar.gz' (restore log in /var/lib/rear/restore/recover.2022-09-07-1207-I.tar.gz.725.restore.log) ...
Backup restore program 'tar' started in subshell (PID=4668)
Restored 134 MiB [avg. 27553 KiB/sec] 
Restored 253 MiB [avg. 25956 KiB/sec] 
OK
Restored 332 MiB in 15 seconds [avg. 22665 KiB/sec]
Restoring from '/var/tmp/rear.fUWCbLaNo28hZn2/outputfs/localhost/2022-09-07-1320-I.tar.gz' (restore log in /var/lib/rear/restore/recover.2022-09-07-1320-I.tar.gz.725.restore.log) ...
Backup restore program 'tar' started in subshell (PID=4710)
OK
Restored 34 MiB in 5 seconds [avg. 7022 KiB/sec]
...
Recreated initrd (/sbin/mkinitrd).
Installing GRUB2 boot loader...
...
Finished 'recover'. The target system is mounted at '/mnt/local'.
...
RESCUE localhost:~ #

RESCUE localhost:~ # ls -l /mnt/local/root/incremental*.date
-rw-r--r-- 1 root root 33 Sep  7 12:04 /mnt/local/root/incremental1.date
-rw-r--r-- 1 root root 33 Sep  7 13:20 /mnt/local/root/incremental2.date

RESCUE localhost:~ # cat /mnt/local/root/incremental*.date
Wed 07 Sep 2022 12:04:36 PM CEST
Wed 07 Sep 2022 01:20:07 PM CEST

[github-actions]

Stale issue message