#1948 Issue closed: TSM set point-in-time recovery date via configuration¶
Labels: enhancement, fixed / solved / done,
Dedicated Priority Support
schlomo opened issue at 2018-11-02 13:32:¶
For a special use case it would help if we can set the
TSM_RESTORE_PIT_DATE and TSM_RESTORE_PIT_TIME variables in
configuration (or set something else instead) so that I don't have to
enter this information on each recovery.
Context is doing a mass recovery from a specific point in time backup.
Currently those variables are actually ignored by https://github.com/rear/rear/blob/aa7b1979c347a3800959d757f7ce485fc10bd788/usr/share/rear/verify/TSM/default/390_request_point_in_time_restore_parameters.sh
Solution idea
Remove those variables from default.conf as they are actually internal
to this script. Instead, switch the user input in the TSM scripts to use
the new UserInput function written by @jsmeix so that then the user
can pre-fill that with the desired answer.
gdha commented at 2018-11-03 08:26:¶
@schlomo Perhaps not a bad idea to write a note in the default.conf
file that these 2 variables are not removed as such, but taken in
account by the 390_request_point_in_time_restore_parameters.sh script?
So that user know about it?
schlomo commented at 2018-11-03 19:07:¶
Yes, I would do that if those variables would have worked. Since they never worked I think removing them is fine as it won't break anybody's stuff.
I converted them to lower case in the code and unset them at the end
to make it clear that these variables are, in fact, internal.
So, unless it is specifically important to you, I'd prefer to leave them
out. I think as we convert more and more read calls to UserInput
people will learn to use this new mechanism.
gdha commented at 2018-11-04 07:56:¶
@schlomo I'm not a TSM user, so for me it is OK. Trimming the
default.conf file is not a bad idea. For a novice user it can be
overwhelming IMHO.
schlomo commented at 2018-11-04 09:29:¶
IMHO we should only have variables in the default.conf that are meant
for the user to change. By that logic those variables don't belong
there.
Once upon a time we said that default.conf should initialize every
variable, but this example shows that it is better if it contains only
variables meant for users but not internal variables.
jsmeix commented at 2018-11-08 10:12:¶
In current ReaR master code
https://raw.githubusercontent.com/rear/rear/master/usr/share/rear/conf/default.conf
reads
# Here we define and describe all configuration variables and set them to a default.
so that 'default.conf' is meant to initialize only all those variables
that are meant for users to be changed (if needed).
Accordingly it is right to remove variables from default.conf
that are not meant as configuration variables for users, cf.
all those non-config variables that are set in usr/sbin/rear
@schlomo
your
https://github.com/rear/rear/commit/f5558efbf5407437bc3c6e671146faefa9992ee4
looks good to me from plain looking at the code
(I cannot test proprietary backup tools).
The only tiny inconsistency is the date format that the code does
tsm_restore_pit_date=$( date -d "$answer" +%Y.%m.%d 2>/dev/null ) ...
versus what date format is told the user in the LogPrint message
LogPrint " ... ${tsm_restore_pit_date} ${tsm_restore_pit_time} (MM/DD/YYYY HH:mm:ss)"
because (as far as I understand the copd from plain looking at it)
${tsm_restore_pit_date} is e.g. '2018.11.08' and not '11/08/2018',
cf.
https://github.com/rear/rear/pull/1951#issuecomment-435874716
FYI
some explanations about my ideas behind my
https://github.com/rear/rear/pull/1951
I thought TSM_RESTORE_PIT_DATE and TSM_RESTORE_PIT_TIME
are meant as user config variables (because they are in default.conf)
but implementing the code for that had been somehow forgotten.
Because 390_request_point_in_time_restore_parameters.sh
runs during "rear recover" I found it a bit too hard to error out
only because the user may have by accident a typo in his input
so that I tried to implement an endless loop until input was valid.
But because 390_request_point_in_time_restore_parameters.sh
runs early during "rear recover" (the verify stage runs at the
beginning
in particular before the disklayout gets recreated) I think it does
not hurt in practice to error out at that early stage of "rear recover".
schlomo commented at 2018-11-08 11:33:¶
@skrueger8 FYI
[Export of Github issue for rear/rear.]