#3011 Issue open: Suggested tweaks to the initial rear recover menu¶
Labels: discuss / RFC
danboid opened issue at 2023-06-09 09:54:¶
I'm pretty confident in saying that the philosophy of the rear devs is
that rear should be as easy to use as possible and operate in the most
obvious and straightforward way, which is why I decided to file this
rather nitpicky suggestion regarding the first menu the user is
presented with when they run rear recover.
I would expect that the most common use case for rear is when a user is
restoring a backup onto the same machine with the same (disk) config
versus restoring the backup onto the same machine with a slightly
different disk config or another machine entirely. I would imagine this
is how it gets used the majority of the time and so in that case, when
the user is restoring a rear backup onto the same machine with the same
disk config, the option they most likely want to pick from the first
rear recover menu is awkwardly option #2, "Confirm identical disk
mapping and proceed without manual configuration" so my first suggestion
is that this should be moved to option #1 because its the most likely
option the user wants and so should logically be the first suggestion
and menu item, ie the "default" option.
Another reason I'm suggesting this tweak is that I presumed option 1 was
what I should be using on my first few goes with rear and not only does
option 1 make rear recover more complicated than it needs to be in
most cases, it doesn't currently doesn't work for me and so I'll be
opening a separate ticket for that.
My other suggested tweak for this menu is changing the wording of what
is currently the first option (which I think should be the second
option)- "Confirm disk mapping and continue rear recover". What does
"continue rear recover" mean to the new user? Not very much. How does
this option differ from ""Confirm identical disk mapping and proceed
without manual configuration" - it is not made clear from the options
current label. I think this option should be called something more like
"Confirm disk mapping and configure recovery options."
jsmeix commented at 2023-06-13 10:51:¶
I think you are talking about the user dialog
which looks like
Confirm disk mapping and continue 'rear recover'
n/a
Edit disk mapping (/var/lib/rear/layout/disk_mappings)
Use Relax-and-Recover shell and return back to here
Abort 'rear recover'
or
Confirm disk mapping and continue 'rear recover'
Confirm identical disk mapping and proceed without manual configuration
Edit disk mapping (/var/lib/rear/layout/disk_mappings)
Use Relax-and-Recover shell and return back to here
Abort 'rear recover'
This dialog is implemented in
layout/prepare/default/300_map_disks.sh
which is in our current GitHub master code
https://github.com/rear/rear/blob/master/usr/share/rear/layout/prepare/default/300_map_disks.sh
This dialog only appears in so called "migration mode"
because the whole layout/prepare/default/300_map_disks.sh
script is skipped if not in migration mode
# Skip if not in migration mode:
is_true "$MIGRATION_MODE" || return 0
The second choice of this dialog
Confirm identical disk mapping and proceed without manual configuration
only appears when in migration mode ReaR autodetects
that the proposed disk mapping is an identical mapping
for example like
Current disk mapping table (source => target):
/dev/sda => /dev/sda
/dev/sdb => /dev/sdb
/dev/sdc => /dev/sdc
in layout/prepare/default/300_map_disks.sh via
is_completely_identical_layout_mapping && choices[1]="Confirm identical disk mapping and proceed without manual configuration" || choices[1]="n/a"
where the is_completely_identical_layout_mapping function
in lib/layout-functions.sh only checks that
in /var/lib/rear/layout/disk_mappings
all syntactically valid lines have
same "source" and "target" disks.
This means the is_completely_identical_layout_mapping function
returns 'true' when no disks get interchanged by the mapping.
For example in
Current disk mapping table (source => target):
/dev/sda => /dev/sda
/dev/sdb => /dev/sdc
/dev/sdc => /dev/sdb
/dev/sdb and /dev/sdc get interchanged by the mapping.
BUT:
When no disks get interchanged by the mapping
it does not mean that
all target disks on the replacement hardware
(i.e. on the hardware where "rear recover" is running)
are identical compared to each source disk
on the original system (where "rear mkbackup" was run).
In other words:
When no disks get interchanged by the mapping
it does not mean that nothing is migrated
(i.e. it does not mean "all is the same")
which matches that this dialog only appears
in "migration mode" (i.e. the mode when
something has changed regarding the disks).
The usual cases when in "migration mode"
no disks get interchanged by the mapping
is that some disk size(s) changed like
/dev/sda 110 GiB => /dev/sda 110 GiB
/dev/sdb 120 GiB => /dev/sdb 120 GiB
/dev/sdc 130 GiB => /dev/sdc 131 GiB
or when there are several target disks with same size like
/dev/sda 110 GiB => /dev/sda 110 GiB
/dev/sdb 120 GiB => /dev/sdb 120 GiB
/dev/sdc 120 GiB => /dev/sdc 120 GiB
The difference between
Confirm disk mapping and continue 'rear recover'
and
Confirm identical disk mapping and proceed without manual configuration
is that after
Confirm disk mapping and continue 'rear recover'
several subsequent "migration mode" user dialogs appear
while after
Confirm identical disk mapping and proceed without manual configuration
those subsequent "migration mode" user dialogs do not appear
in layout/prepare/default/300_map_disks.sh via
case "$choice" in
...
(${choices[1]})
if is_completely_identical_layout_mapping ; then
# Confirm identical disk mapping and proceed without manual configuration:
MIGRATION_MODE='false'
i.e.
after
Confirm identical disk mapping and proceed without manual configuration
the "migration mode" is switched off.
jsmeix commented at 2023-06-13 11:49:¶
@danboid
personally (I cannot speak for other ReaR developers)
I would like to ask you to avoid "well intentioned advice" like
rear should be as easy to use as possible and
operate in the most obvious and straightforward way
My personal reasoning:
Personally I feel a bit treated as if I was an idiot
when someone tells me such things because of course
I do not intend to make ReaR so that it is hard to use or
that it operates in obscure ways in a roundabout fashion.
BUT:
Often (basically always from my personal experience)
what is the obvious and straightforward way
from an end-user point of view
becomes a maze of traps and snakepits
when one implements it because at code level
"obvious intents" are no longer obvious to implement.
From my personal experience the general root cause is
that there are too many cases "out there in the wild"
so there is no such thing as "the use case" and
accordingly there is no such thing as "the implementation".
danboid commented at 2023-06-13 12:35:¶
Surely the use case / purpose for rear is backing up and restoring Linux based systems? That's what it is supposed to do right? If I'm mistaken then please correct me.
[Export of Github issue for rear/rear.]