Johannes Meixner

I postponed https://github.com/rear/rear/issues/2666 to ReaR 2.8 Via https://github.com/rear/rear/pull/2815 I describe in default.conf the currently implemented user config variable names USB_BOOT_PART_SIZE and USB_DEVICE_BOOT_LABEL I think the current user config variable names...

I won't find noticeable time for this pull request until ReaR 2.7 was released, cf. https://github.com/rear/rear/issues/2751 so I set this pull request's milestone to ReaR v2.8 i.e. after ReaR 2.7...

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...

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

@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...

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...

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...

This needs to be done before ReaR 2.7 can be released.

I postpone this to ReaR 2.8

@bwelterl thank you for your enlightning issue report! I have to think a bit deeper about it - it looks complicated.