Retain log file at a safe place during recovery

[gdha]

Was on Sourceforge as SF#3448325

Currently when "rear recover" runs successfully its log file /tmp/rear-.log in the ReaR recovery system is copied into /root/ on the recovered system.

But when "rear recover" fails, its log file is not saved to a save plave so that it is lost when the ReaR recovery system is finished.

For "BACKUP=NETFS" the "rear recover" log file should be saved in any case to the NETFS_URL to have it automatically at the same save place where the backup.tar.gz and the "rear mkbackup" log file and the ISO image already are.

To make sure a "rear recover" log file exists at the save place in any case even if "rear recover" breaks at a random stage,
it is perhaps best to write the "rear recover" log directly into a file at the save place as soon as this is possible (instead of copying it just before "rear recover" finishes).

[dagwieers]

+1

Maybe we should think about renaming the log files as well. I find it very confusing that both the original log file and the recovery log file have similar names. Maybe we should think about have a rear-(hostname).log and a rear-recover-(hostname).log ? We could have workflows set the prefered log file name (if the default is not ok).

Also the location of the logfile could maybe be harmonized as well, I am still not very fond of using /tmp for this purpose. But having both logfiles in the same location seems useful.

[schlomo]

I see also the following options/aspects:

• send failed (and optionally successful) recovery logs via Email
• if storing the recovery log off-system fails then Relax-and-Recover should not abort

[dagwieers]

Ok, let's summarize what we would like to do:

• Indicate the workflow (or at least the mode) in the logfile name (rear-backup-hostname.log and rear-recover-hostname.log
• Move the logfile to the default directory (/var/log/rear) on the original host, on the rescue system and on the recover host
  • original system: rear-backup-hostname.log
  • rescue system:
    • initrd: rear-backup-partial-hostname-date.log and rear-recover-hostname-date.log
    • medium: rear-backup-hostname-date.log and rear-recover-hostname-date.log
  • recovered system: rear-backup-hostname-date.log and rear-recover-hostname-date.log
• Take into account partial logfiles in the rescue image, and "less" partial logfiles on the rescue medium (if available)

[gdha]

will implement this in v1.17

[gdha]

post-pone this to rear-1.18

[jsmeix]

I will implement it.

I think /mnt/local/root/ is o.k. but probably not really
the best directory for that.

See also #706

I think only the plain log file is not fully sufficient.
I prefer to also keep other recovery-related data.

In the end what I like to keep is all what is needed
so that the admin or rear upstream can do later
a full detailled analysis of a recovery.

In particular for professional support
(e.g. from Relax-and-Recover upstream or
from our SUSE Linux Enterprise support department)
the ability to do a full detailled analysis after a recovery
is mandatory.

This is another reason why I would like to keep
the 'rear recover' log et alii by default so that this
information is by default available after a recovery.

[jsmeix]

As a first step I implemented #706

But for this issue here I need a bit more time to think about how to do it.

Because currently it is copied as an exit task I wonder if this is not yet sufficiently fail-safe - at least for normal error exits.

I assume the exit tasks are called for any exit (i.e. also when there is
a normal error exit) as far as I understand _input-output-functions.sh

builtin trap "DoExitTasks" 0

and "help trap"

trap: trap [-lp] [arg signal_spec ...]
  ... If a SIGNAL_SPEC is EXIT (0)
  the command ARG is executed on exit from the shell.
  ...