#1702 Issue closed: When ReaR with Borg as back end returns error during rear recover recovery will abort.

Labels: enhancement, fixed / solved / done

gozora opened issue at 2018-01-23 12:00:

As @jsmeix correctly pointed out in https://github.com/rear/rear/pull/1698#issuecomment-359745613

When looking at the code in
restore/BORG/default/400_restore_backup.sh
I noticed that it errors out when the Borg backup restore
finished with a non-zero exit code.
I think this might be too hard here.

Reasoning:

I think during "rear mkrescue/mkbackup" it is good
to be strict and error out in case of failures because
when "rear mkrescue/mkbackup" errors out the user
can fix the reason in his original system until
"rear mkrescue/mkbackup" runs cleanly.

In contrast during "rear recover" I think it could be often better
to continue even if something finished with a non-zero exit code
because when "rear recover" errors out it is basically a dead end
for the user.

For example when "rear recover" errors out when Borg backup restore
finished with a non-zero exit code there might be nothing what the
user could do to fix the reason in the recovery system (except
changing the code in restore/BORG/default/400_restore_backup.sh
to no longer error out). Perhaps there was only a minor issue why
Borg backup restore finished with a non-zero exit code
that could be also fixed later in the recreated system?

Accordingly I think it could be often better when during "rear recover"
something finished with a non-zero exit code to show a user dialog
via the UserInput function where the user can decide whether or not
he wants to continue regardless of that particular failure so that
the user has a better chance to get at least a somewhat usable
recreated system (in contrast to get no recreated system at all).

gozora commented at 2018-03-30 06:58:

Since #1730 was merged, this issue can be closed.


[Export of Github issue for rear/rear.]