#1164 Issue closed: BACKUP=NETFS behaves inconsistent for BACKUP_URL=usb versus BACKUP_URL=nfs¶
Labels: enhancement, cleanup, fixed / solved / done
jsmeix opened issue at 2017-01-12 15:45:¶
When one uses
BACKUP=NETFS BACKUP_URL=nfs://nfs_server_IP/directory
one gets the backups in one same fixed directory
so that an existing backup.tar.gz file gets overwritten
by a new backup.tar.gz file.
In contrast when one uses
BACKUP=NETFS BACKUP_URL=usb:///dev/disk/by-label/REAR-000
one gets separated full backups in separated timestamp
directories via the default settings for BACKUP_URL=usb.
This inconsistent behaviour results inconsistent user experience
for multiple backups and incremental/differential backups, cf.
https://github.com/rear/rear/issues/1160#issuecomment-272194526
In particular with BACKUP_URL=nfs multiple backups
and incremental/differential backups "just work" while
with BACKUP_URL=usb defaults neither multiple backups
nor incremental/differential backups work.
To make multiple backups or incremental/differential backups
work with BACKUP_URL=usb special setup is needed, cf.
https://github.com/rear/rear/issues/1160
and
https://github.com/rear/rear/issues/1145
I wonder what the right default behaviour of BACKUP_URL=usb
should be:
Shouldn't by default BACKUP_URL=usb
behave same as BACKUP_URL=nfs
to get consistent user experience in ReaR?
gozora commented at 2017-01-12 21:47:¶
Hello @jsmeix
I just have tried BLOCKCLONE backup on USB, (I know that I should be writing documentation but it is not fun :-( ) so I had a chance to have a quick look on USB workflows. In general the logic there seems to be a bit different.
Differences I've noticed:
-
When booting from ISO it is quite straightforward as all files for ReaR rescue/recovery system are in one same location (that particular ISO). USB on the other hand can have multiple ReaR rescue/recovery systems. Basically every time
rear mkrescue/mkbackupis run new environment is created. At syslinux boot screen you can decide which environment will be booted. -
As you already mentioned:
one gets separated full backups in separated timestamp
directories via the default settings for BACKUP_URL=usb.
Archive to restore is being chose not only by BACKUP_PROG_ARCHIVE defined in local.conf but also by user query for particular timestamp.
On one hand I agree with you that user experience should be same, but somehow I have a feeling that USB is implemented as it should be.
What do you think should be changed?
jsmeix commented at 2017-01-13 08:40:¶
I slept over it, cf.
https://github.com/rear/rear/issues/1145#issuecomment-272217150
and now I have an idea how all this can be solved:
This issue here is the actual root cause.
When I solve this issue,
https://github.com/rear/rear/issues/1160
and
https://github.com/rear/rear/issues/1145
get automatically solved.
I know that for BACKUP_URL=usb the syslinux bootloader stuff
is recreated anew but currently this is o.k. for me.
Basically it matches that for each ISO image its bootloader
is also created.
The main issue for now for me is to implement a fixed
backup directory also for BACKUP_URL=usb.
When a fixed backup directory is used for BACKUP_URL=usb
then one can later think about whether or not in this case
it is needed to receate the syslinux bootloader stuff anew
each time. But that is a minor issue because it also works
when the syslinux bootloader stuff is always recreated.
My current idea how to implement a fixed backup directory
also for BACKUP_URL=usb in a backward compatible way:
I need to be able to distinguish between the current default case
(i.e. multiple timestamp backup directories) and the new
fixed backup directory case.
I cannot distinguish when USB_PREFIX is set in local.conf
because when that variable is set I cannot know later at
arbitrary places in the code if it was set as a default
or if it was set deliberately by the user.
Therefore I need another new config variable to specify
the backup directory for BACKUP_URL=usb.
Because the USB_PREFIX value must currently
start with rear/$HOSTNAME cf.
https://github.com/rear/rear/issues/1160#issuecomment-272119383
the new config variable can only specify the trailing part
of the backup directory for BACKUP_URL=usb.
I think I will name that new config variable
USB_SUFFIX
When USB_SUFFIX is unset or empty, BACKUP_URL=usb
will work in its current default mode which means
USB_PREFIX="rear/$HOSTNAME/$( date +%Y%m%d.%H%M )"
and multiple timestamp backup directories plus
automated backups cleanup via USB_RETAIN_BACKUP_NR.
When USB_SUFFIX is set,
USB_PREFIX="rear/$HOSTNAME/$USB_SUFFIX"
and then BACKUP_URL=usb will work in compliance
with how BACKUP_URL=nfs works which means
a fixed backup directory and no automated backups cleanup.
This way the user gets back direct easy control, cf.
https://www.gnu.org/philosophy/free-software-even-more-important.html
Of course ReaR is free software where the user can change the code
but I prefer when full user control is already built-in and
ready-to-use.
In particular when the user specifies in local.conf
USB_SUFFIX="$( date +%Y%m%d.%H%M )"
he will get same multiple timestamp backup directories
but without automated backups cleanup.
For now I will implement alignment of
BACKUP_URL=usb with BACKUP_URL=nfs
only as far as currently needed.
A long-term general goal for ReaR could be to align
all those various grown differences in ReaR carefully
and step by step - but that is something for the future
and only if really needed, cf. "Dirty hacks welcome" in
https://github.com/rear/rear/wiki/Coding-Style
... it is more important that the Relax-and-Recover code works than having nice looking clean code ...
jsmeix commented at 2017-01-13 14:22:¶
With
https://github.com/rear/rear/pull/1165
merged this issue is fixed.
dwerner1 commented at 2017-01-20 14:05:¶
I have just tested that with the current git version and can confirm that everything works as expected and flawless. @jsmeix many thanks for your valuable work!
jsmeix commented at 2017-01-23 09:36:¶
@dwerner1
your testing and feedback is much appreciated!
[Export of Github issue for rear/rear.]