Currently stdout and stderr are redirected to the log file in any case.

The reason behind is that all what could be useful for later debugging
in case of issues must appear in ReaR's log file, cf.
"What to do with stdin, stdout, and stderr" in
https://github.com/rear/rear/wiki/Coding-Style

But this means that also error messages from commands
that fail when a possible failure is expected and handled in ReaR
appear in the log file.

I.e. for code of the general form like

TRY_COMMAND || FALLBACK_COMMAND || Error "..."

a failing TRY_COMMAND error message appears in the log file
which may confuse the user regardless that all works well
because it is only a "false alarm" message.

On the other hand the TRY_COMMAND error message must appear
in the log file because for later debugging in case of issues it is needed
to see how TRY_COMMAND had failed i.e. what its exact error message was
because it makes a difference to understand the root cause of an issue
if the TRY_COMMAND error message shows that its failure is OK
(and FALLBACK_COMMAND does "the right thing")
or if the TRY_COMMAND error message points to the root cause of an issue
(e.g. because TRY_COMMAND should have worked in a particular case
and FALLBACK_COMMAND should not have been run in that case).

So there is a dilemma between suppressing error messages
to not confuse the user with "false alarm" error messages
versus having all what could be useful for later debugging in the log file.

Perhaps a possible way out of that dilemma could be
to only redirect stdout and stderr to the log file
when rear is run in verbose mode (-v) or in debug modes (-d -D)
to avoid that such messages appear in the log and confuse the user
when the user has called rear in a "normal operation" mode and
in "normal operation" mode stdout and stderr are redirected to /dev/null.

Perhaps the best way might be:

In "normal operation" mode stdout and stderr are redirected to /dev/null.
In verbose mode stderr is still /dev/null but stdout is redirected to the log.
In debug modes stdout and stderr are redirected to the log.

It seems this would be in compliance with our $v $verbose usage

# touch foo

# cp -v foo foo.cp 2>/dev/null
'foo' -> 'foo.cp'

# mv -v foo.cp foo.mv 2>/dev/null
renamed 'foo.cp' -> 'foo.mv'

because it seems command verbose output happens usually on stdout.

I do no longer think that my above described "best way" works OK in practice, see
#2416 (comment)