I definitely brought up the wrong terminology, sorry about that! I don't
need to get into man in the middle attacks or DNS changes between servers.
Hours is something I am after. I just need to have the station back up
before the end of the day.
Your 1a suggestion is excellent, very good idea! I'll look into that down
the road when it is more mission critical, thanks! Your second suggestion,
while absolutely ingenious, is going to be more of a hassle to keep updated
then it will be a convenience (at least for my needs).
Over the last four hours the size of the directory went from 1023MB to
951MB. What is going on here?! I'm so confused =( Is it absolutely safe
to delete the core files? I would like to see if they continue showing up
when I'm sure that Hobbit has not been restarting.
Josh
On 10/18/07, Haertig, David F (Dave) <user-68874b735d77@xymon.invalid> wrote:
If you want recovery within minutes you probably won't get by with a
backup/restore scenerio. Hours possibly, but not minutes. You of course
still need to backup things even if you choose one of the suggestions below.
(1)
If you have a second server, clone your current Hobbit server to it
and keep it up to date regularly with rsync. Simplest, but not necessarily
the best, would be a manual failover where you start up all processes
manually. You would need to handle the move of the webserver. You could
twiddle with DNS for that, but I've never seen that work well. You have DNS
propogation delays and you have Windows clients that try to "help" you by
caching previous DNS lookups. I would instead recommend an IP takeover
using ARP poisoning ("poisoning" sounds bad, so maybe that's not the best
word to use for this, but it's the same technique used by those on The Dark
Side). A decent short description of this is:
http://www.onlamp.com/pub/a/onlamp/2003/04/03/linuxhacks.html
(1a)
It would be fairly simple just leave Hobbit running 100%, and also the
webserver, on both machines. The secondary machine could have a blank
hobbit-alerts.cfg file that gets overwritten with the real file upon
failover (so you won't get duplicate notifications). All Hobbit clients
should be configured to send all data to both servers all the time.
(2)
If you don't have two machines to work with and you still want speedy
recoveries, I'd look into making a portable Hobbit bootable CD. Start with
Knoppix, Slax, or one of the other Linux LiveCDs and modify it to include
your Hobbit installation on the CD. At least in theory, you could then
hijack some poor coworker's PC, boot it with your Hobbit/Linux LiveCD, and
have a functional Hobbit. You wouldn't have your history available but
that's probably acceptable during a quick recovery scenerio. You would also
need to update that LiveCD whenever you make significant changes to Hobbit.
You could do the same IP takeover as above with ARP poisoning to make it
semi-tranparent. Running off the LiveCD would be the short term quick fix
... after getting that up and running you'd quickly move your efforts to
recovering your real Hobbit server from the backups that you had.
I have not implemented the above myself. I am just starting to look into
that. The above are some ideas that I'm considering implementing myself.
*From:* Josh Luthman [mailto:user-4c45a83f15cb@xymon.invalid]
*Sent:* Thursday, October 18, 2007 2:55 PM
*To:* user-ae9b8668bcde@xymon.invalid
*Subject:* [hobbit] Backing up hobbit
I am trying to create a backup of hobbit so in case the box is stolen,
blown up, disappear, vanishes into thin air or even the boogey monster
steals it, I can recover with a secondary box in a matter of minutes - hours
at most.
What I had done with BB was simply backup the entire user's home
directory. I had this done every single morning. Each gzipped tar was a
mere 15 megs.
When I do a du -shc /home/user it reaches 1021M and in
/home/user/server/bin/ du -shc core* I see 860M. What are these core*
files?
Does anyone have any suggestions on what to backup? I don't have the
luxury of using tapes or another machine on the same LAN, so I am
transporting this data over the Internet. While bandwidth is not a concern,
I'd much rather not have to transport a gigabyte every morning =)
Thanks in advance,
Josh
--
Josh Luthman
Office: XXX-XXX-XXXX
Direct: XXX-XXX-XXXX
XXXX Wayne St
Suite XXXX
Troy, OH XXXXX
Those who don't understand UNIX are condemned to reinvent it, poorly.
--- Henry Spencer
--
Josh Luthman
Office: XXX-XXX-XXXX
Direct: XXX-XXX-XXXX
XXXX Wayne St
Suite XXXX
Troy, OH XXXXX
Those who don't understand UNIX are condemned to reinvent it, poorly.
--- Henry Spencer