#669 PR merged: Add new NBKDC backup method¶
Labels: enhancement, waiting for info
andyvb070 opened issue at 2015-10-16 11:35:¶
A new support for a 3rd party backup tool
ReaR will not trigger the actual backup, it gets triggered and done by
the backup program
Integrated the support for the backup program into the recovery image
schlomo commented at 2015-10-16 13:47:¶
Hello @andyvb070 and thanks a lot for your contribution!
schlomo commented at 2015-10-16 14:05:¶
I went over your code and in general it looks good and I don't see any reason not to accept it.
Can you please look at my line comments? Thanks a lot!
schlomo commented at 2015-10-21 05:26:¶
Do you plan to join the 1.18 release? I'll merge your request when you give me the go that you did all the changes you still want to make.
andyvb070 commented at 2015-11-02 10:14:¶
Yes, we would surely want to join the 1.18 release, if that is still
possible.
(sorry for the delayed response)
I will be working on some proposed changes and commit these, asap.
Will I need to create a new pull request?
schlomo commented at 2015-11-02 20:22:¶
No, just keep working but please update your fork to the latest HEAD from us so that your pull request is against latest HEAD and not some old commit.
gdha commented at 2015-11-13 09:25:¶
@andyvb070 It looks ok to me.
@schlomo Is this pull request acceptable for you?
andyvb070 commented at 2015-11-13 09:39:¶
Hi, and thanks.
One quick last question, do I need to "Close pull request" once schlomo
gives his ok?
Or will you take it from here.
gdha commented at 2015-11-13 10:07:¶
No, once we accept the pull request it will be closed automatically.
Gratien
On Fri, Nov 13, 2015 at 10:39 AM, Andreas von Bülow <
notifications@github.com> wrote:
Hi, and thanks.
One quick last question, do I need to "Close pull request" once schlomo
gives his ok?
Or will you take it from here.—
Reply to this email directly or view it on GitHub
https://github.com/rear/rear/pull/669#issuecomment-156378303.
andyvb070 commented at 2015-11-13 13:34:¶
About the documentation, yes, that generic doc URL is all but a placeholder for the upcoming documentation which will describe using NBKDC with ReaR - A guide on how to configure, backup and recover a system using NBKDC and ReaR. The doc is still work in progress and will be ready soon. We will place it on our web for users to access. As soon as I have a URL I will change it there
andyvb070 commented at 2015-11-13 13:57:¶
About the init scripts and rootfs. Could I then let it generate the boot script in the rear/skel/NBKDC section. The problem is, there is no generic init script for the agent to copy from. When our agent gets installed a necessary entry for the process is made for the relevant init process (systemV, systemd or upstart). Since I dont want to probe the running system for which init process it uses, I treat the rescue system as a new system and we let the agent create the service and start. So somehow I need to place a script on the rescue system. Does that make sense?
schlomo commented at 2015-11-13 14:15:¶
Generating code into skel is even worse than generating it into the rootfs. Contrary to your statement you actually generate a static start script which does not change at all. That same content could also be put into skel.
Another thought: Why not simply copy the currently used init.d, init or systemd script/config file to the rescue system if you don't know about it beforehand? Maybe you take a look at the other backup software sub direcories under skel to get some inspiration. For example SESAM has some code. Others like NSR and BACULA start the backup client as part of the ReaR scripts. Assuming that you know how to start your own client that should also be fairly easy.
andyvb070 commented at 2015-11-13 14:29:¶
Yes, I have given that a thought too, to copy the init or init.d conf
file to the skel.
That would work for the init and init.d, but for systemV we add a line
in the /etc/inittab. How would I add that to a /etc/initab for rescue
system without messing up the inittab during the normal rescue system
compilation. Unless of course the inittab of the original system is
copied-as-is. Then I dont need to worry about it, as its all there.
In fact, I have taken the SESAM approach and based most of my initial implementation on its code, since we use a very similar architecture.
andyvb070 commented at 2015-11-13 15:16:¶
I will now check if the /etc/init/
Just need to know if the /etc/initab is copied-as-is from the source
system or not. That will cover the SystemV init.d and all is done. I
will test it and supply the changes.
andyvb070 commented at 2015-11-16 11:51:¶
Completed cahnges.
Recoded, so that now,
skel/NBKDC/etc/scripts/system-setup.d/90-start-nbkdc.sh
checks and starts all NBKDC agent stuff
removed it from rescue/NBKDC/....
prep/NBKDC/... now checks and does all the things nbkdc-functions.sh
did.
rescue/NBKDC/... merely copies the agent init .conf file if it exists.
If it doesnt, agent service startup is handled by the startup script.
schlomo commented at 2015-11-16 12:07:¶
Did you update your pull request?
andyvb070 commented at 2015-11-16 12:31:¶
Yes, now I did ...
schlomo commented at 2015-11-16 14:04:¶
@andyvb070 great work! Almost there. I found only two blockers (use of
exit and please append >&2 to everything producing logging output)
and lots of advice.
As soon as you fix the blocker I will merge this pull request. Unfortunately I cannot test it so that will remain your responsability. As far as ReaR is concerned I am pretty confident that your code won't to any harm to people not using NBKDC.
andyvb070 commented at 2015-11-16 16:40:¶
@schlomo Thanks for the invaluable advice!
I will get the blockers resolved, no problem. I wasnt aware of all the
functions and what they do. Yes, "Error" is much better and that is what
I was looking for at doing there. Was there a doc I missed where I could
have read about them?
andyvb070 commented at 2015-11-16 17:04:¶
I did give the timing of the upstart and the 90-start-nbkdc.sh a thought. It doesnt matter really, the only risk I see is the script could start the agent first, then upstart will do the same. But then upstart or rather initctl will handle it appropriately with "Job already running" or whatever job start phase it is in.
schlomo commented at 2015-11-16 20:10:¶
Did you test this "Job already running" assumption? In my experience upstart will not recognize processes started elsewhere as belonging to an upstart job.
BTW, if you have a reliable way of starting the agent on your own, why bother copying the upstart job? Even without it should function. And with only one place to start the agent, there can't be any confusion.
In any case. As soon as you fix the blockers I'll be happy to merge and you can continue to develop ReaR. This is not your last shot but your first :-)
andyvb070 commented at 2015-11-17 08:14:¶
I "tested" it on a running system, where the agent was started and if I
am not mistaken, the upstart daemon issues an "initctl start
rcmd-executor" and it returned job already running. So no, I did not
test it in a rescue init phase as I need to issue the startscript before
the upstart to really test if it is the same.
But you know what, I was thinking about this over a good nights sleep
and yes, I dont see a need for it to start the backup agent service via
the upstart. If we can start it via the startscripts, we keep a single
source of failure and that makes troubleshooting so much easier.
I will get rid of the copy conf file and let the startscript initialize
and start the agent. Without the agent, obviously no restore takes
place. So I will have the restore script check for a running agent
first. Too bad if it is not running and does not start. What to do then.
Will the user be able or need to run "rear recover" again, after trying
to fix the issue. I mean it shouldnt really happen as we have taken care
of starting the agent when we create the boot media. But you never know.
schlomo commented at 2015-11-17 09:40:¶
Great - just let me know when you want me to merge.
gdha commented at 2015-11-25 12:11:¶
@andyvb070 How far are you with the pull request?
andyvb070 commented at 2015-11-26 14:00:¶
@gdha Currently I am still a little swamped with year-end business, but I will have it ready soon, sometime next week.
btw, do you have any idea why when running the
restore/NBKDC/default/40_restore_backup.sh (which just produces a
LogPrint ... , at the shell prompt it states
"Welcome to Relax and Recover. Run "rear recover" to restore your
system."
This is a little confusing to the user, as he has run 'rear recover' to
get here and has prepared the system for NBKDC restore.
After he enters 'exit' he is then confronted with the
rear_shell function and message.
Is there any way to suppress the "Welcome to Relax and Recover. Run
"rear recover" to restore your system." message?
Thanks!!
gdha commented at 2016-02-09 13:59:¶
@andyvb070 are the pull requests ok or any changes to happen beyond this
phase?
@schlomo Ok for you to checking in the code?
andyvb070 commented at 2016-02-10 09:39:¶
@gdha I don't have any changes to be committed, so the pull request is good to go from my side. Thanks to all for your help
[Export of Github issue for rear/rear.]