#3011 Issue `closed`: Suggested tweaks to the initial `rear recover` menu¶

Labels: discuss / RFC, no-issue-activity

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.

pcahyna commented at 2023-06-19 14:35:¶

Given that migration mode is often a source of problems, to me it also seems preferable to offer the option that leads to switching it off, i.e. Confirm identical disk mapping and proceed without manual configuration, as the default. The question is, when this is not present (because the disk mapping is not identical), the default must be something else - is that ok?

danboid commented at 2023-06-19 15:56:¶

Yes, that makes perfect sense to me.

jsmeix commented at 2023-06-20 10:30:¶

@pcahyna
I disagree with your reasoning.
Perhaps I misunderstand what you meant?

My arguments:

(1)
Regarding "migration mode is often a source of problems":

As far as I implemented it (or at least I tried to implement it)
migration mode is never the actual source of a problem.
Actually it is the opposite:
Because of a "source of a problem" ReaR enters migration mode
and ReaR enters migration mode to give the user the chance
to avoid bad consequences because of the actual problem.

(2)
Switching migration mode off by some automatism would be
a contradiction in itself because when ReaR enters migration mode
there is a "source of a problem" so switching migration mode off
means to ignore that "source of a problem" by some automatism.

(3)
Switching migration mode off by some automatism would be
in itself a source of possibly severe and fatal problems.

Did you understand that an identical disk mapping
does not mean "all disks are same as on the original system"?

The standard example where
"Confirm identical disk mapping and 'just proceed'"
leads to a final disaster is:

Original virtual machine with 20GiB virtual disk /dev/sda
for the system plus additionally attached 20GiB
virtual disk /dev/sdb for ReaR with OUTPUT=USB.
Replacement virtual machine with 20GiB virtual disk
for the system plus the above 20GiB ReaR disk.

When on the replacement virtual machine
the virtual disk for the system is /dev/sda
and the ReaR disk is /dev/sdb
all is well.

BUT:

When on the replacement virtual machine
the virtual disk for the system is /dev/sdb
and the ReaR disk is /dev/sda
then
"Confirm identical disk mapping and 'just proceed'"
will recreate (the storage layout) on the ReaR disk
which leads to a final disaster
by destroying the backup on the ReaR disk
unless WRITE_PROTECTED_IDS (fortunately) avoids it.

In migration mode I would prefer to not rely blindly
on even more automatisms like WRITE_PROTECTED_IDS.

Instead in migration mode I prefer explicit user confirmation
on which disk "rear recover" will recreate, in particular
for cases like

Ambiguous disk layout needs manual configuration
(more than one disk with same size used in '.../disklayout.conf')

Ambiguous possible target disks need manual configuration
(more than one with same size found)

cf. layout/prepare/default/250_compare_disks.sh

(4)
A generic note:

Recently I see more often that the wish appears here
to make ReaR again "bindly proceed automatically"
which was how ReaR had behaved about 10 years ago
when I became acquainted with ReaR.
At that time my personal user experience was horrible.

Since that time I worked primarily to make ReaR behave better
(primarily more fail-safe) for SUSE's ReaR users who are
experienced system admins at SUSE customers
who in the end pay my salary.

I assume also Red Hat customers prefer when ReaR
behaves by default fail-safe (as far as possible
with reasonable effort).

jsmeix commented at 2023-06-23 11:51:¶

As far as I see things work OK for me
with automated user input via

USER_INPUT_LAYOUT_MIGRATION_CONFIRM_MAPPINGS="2"

I had a 20 GiB sda system disk
and an empty (unused) 1GiB sdb disk on the original machine.

The original machine and the replacement machine are VMs.

I did one test with a 20 GiB sda and 1 GiB sdb
plus an additional 20 GiB sdc on a replacement machine
so there is an identical disk mapping
/dev/sda 20 GiB => /dev/sda 20 GiB

RESCUE localhost:~ # export USER_INPUT_LAYOUT_MIGRATION_CONFIRM_MAPPINGS="2"

RESCUE localhost:~ # rear -D recover
Relax-and-Recover 2.7 / Git
...
Comparing disks
Cannot check write protection by ID for /dev/sdb (no ID found)
Cannot check write protection by ID for /dev/sdc (no ID found)
Ambiguous possible target disks need manual configuration (more than one with same size found)
Switching to manual disk layout configuration (GiB sizes rounded down to integer)
/dev/sda has same size 21474836480 (20 GiB)
/dev/sdb has same size 1073741824 (1 GiB)
/dev/sdc was not used on the original system and has now 21474836480 (20 GiB)
Using /dev/sda (same name and same size 21474836480) for recreating /dev/sda
Current disk mapping table (source => target):
  /dev/sda => /dev/sda

UserInput -I LAYOUT_MIGRATION_CONFIRM_MAPPINGS needed in /usr/share/rear/layout/prepare/default/300_map_disks.sh line 334
Confirm or edit the disk mapping
1) Confirm disk mapping and continue 'rear recover'
2) Confirm identical disk mapping and proceed without manual configuration
3) Edit disk mapping (/var/lib/rear/layout/disk_mappings)
4) Use Relax-and-Recover shell and return back to here
5) Abort 'rear recover'
(default '1' timeout 300 seconds)
UserInput: Will use predefined input in USER_INPUT_LAYOUT_MIGRATION_CONFIRM_MAPPINGS='2'
Hit any key to interrupt the automated input (timeout 10 seconds)
UserInput: Valid choice number result 'Confirm identical disk mapping and proceed without manual configuration'
User confirmed identical disk mapping and proceeding without manual configuration
...

I did another test with a 21 GiB sda and 1 GiB sdb
plus an additional 20 GiB sdc on a replacement machine
so there is not an identical disk mapping
/dev/sda 20 GiB => /dev/sdc 20 GiB

RESCUE localhost:~ # export USER_INPUT_LAYOUT_MIGRATION_CONFIRM_MAPPINGS="2"

RESCUE localhost:~ # rear -D recover
Relax-and-Recover 2.7 / Git
...
Comparing disks
Cannot check write protection by ID for /dev/sda (no ID found)
Cannot check write protection by ID for /dev/sdb (no ID found)
Cannot check write protection by ID for /dev/sdc (no ID found)
Device sda has size 22548578304 bytes but 21474836480 bytes is expected (needs manual configuration)
Switching to manual disk layout configuration (GiB sizes rounded down to integer)
/dev/sda had size 21474836480 (20 GiB) but is now 22548578304 (21 GiB)
/dev/sdb has same size 1073741824 (1 GiB)
/dev/sdc was not used on the original system and has now 21474836480 (20 GiB)
Cannot check write protection by ID for /dev/sdc (no ID found)
Using /dev/sdc (same size 21474836480) for recreating /dev/sda
Current disk mapping table (source => target):
  /dev/sda => /dev/sdc

UserInput -I LAYOUT_MIGRATION_CONFIRM_MAPPINGS needed in /usr/share/rear/layout/prepare/default/300_map_disks.sh line 334
Confirm or edit the disk mapping
1) Confirm disk mapping and continue 'rear recover'
2) n/a
3) Edit disk mapping (/var/lib/rear/layout/disk_mappings)
4) Use Relax-and-Recover shell and return back to here
5) Abort 'rear recover'
(default '1' timeout 300 seconds)
UserInput: Will use predefined input in USER_INPUT_LAYOUT_MIGRATION_CONFIRM_MAPPINGS='2'
Hit any key to interrupt the automated input (timeout 10 seconds)
UserInput: Valid choice number result 'n/a'
Not applicable (no identical disk mapping)
Current disk mapping table (source => target):
  /dev/sda => /dev/sdc

UserInput -I LAYOUT_MIGRATION_CONFIRM_MAPPINGS needed in /usr/share/rear/layout/prepare/default/300_map_disks.sh line 334
Confirm or edit the disk mapping
1) Confirm disk mapping and continue 'rear recover'
2) n/a
3) Edit disk mapping (/var/lib/rear/layout/disk_mappings)
4) Use Relax-and-Recover shell and return back to here
5) Abort 'rear recover'
(default '1' timeout 300 seconds)
UserInput: Will use predefined input in USER_INPUT_LAYOUT_MIGRATION_CONFIRM_MAPPINGS='2'
Hit any key to interrupt the automated input (timeout 10 seconds)
Confirm or edit the disk mapping
(default '1' timeout 300 seconds)

UserInput: No real user input (empty or only spaces) - using default input
UserInput: Valid choice number result 'Confirm disk mapping and continue 'rear recover''
User confirmed disk mapping
...

github-actions commented at 2023-08-23 01:59:¶

Stale issue message

[Export of Github issue for rear/rear.]

#3011 Issue closed: Suggested tweaks to the initial rear recover menu¶

danboid opened issue at 2023-06-09 09:54:¶

jsmeix commented at 2023-06-13 10:51:¶

jsmeix commented at 2023-06-13 11:49:¶

danboid commented at 2023-06-13 12:35:¶

pcahyna commented at 2023-06-19 14:35:¶

danboid commented at 2023-06-19 15:56:¶

jsmeix commented at 2023-06-20 10:30:¶

jsmeix commented at 2023-06-23 11:51:¶

github-actions commented at 2023-08-23 01:59:¶

#3011 Issue `closed`: Suggested tweaks to the initial `rear recover` menu¶