#21 Issue `closed`: Retain log file at a safe place during recovery¶

Labels: enhancement

gdha opened issue at 2012-03-28 06:37:¶

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 commented at 2012-03-28 07:32:¶

+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 commented at 2012-03-28 16:53:¶

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 commented at 2012-06-24 10:42:¶

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 commented at 2014-04-16 11:54:¶

will implement this in v1.17

gdha commented at 2015-01-04 18:29:¶

post-pone this to rear-1.18

jsmeix commented at 2015-11-20 10:33:¶

I will implement it.

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

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 commented at 2015-11-23 11:29:¶

As a first step I implemented https://github.com/rear/rear/issues/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.
  ...

[Export of Github issue for rear/rear.]

#21 Issue closed: Retain log file at a safe place during recovery¶