Scott, <br><br>I got a question: When are you going to present on said subject(s) for ALE?<br>MG,<br>GC<br><br><div class="gmail_quote">On Wed, Jun 30, 2010 at 5:07 PM, scott <span dir="ltr"><<a href="mailto:scott@sboss.net">scott@sboss.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">This is something I could write a (short) book on.  But here goes the<br>
shorter and more centralized on Brandon's particular server needs.<br>
<br>
option 1) hack through the issues with Mondo and use it to create .ISOs<br>
of system.  You can give it a nas share (like NFS) and mondo will create<br>
the .ISOs there then you can burn them to DVDs, CDs, etc later.<br>
pros: will have CDs (or DVDs) to boot off of and restore the system to<br>
that point in time configuration. these can be sent to your DR (disaster<br>
recovery) site for someone else to use in case Atlanta gets hit by a<br>
hurricane, tornado, earthquake (we are on a fault line, didnt you<br>
know?), terrorist attack, etc...<br>
cons: time to set it up.  it is going to do the whole system and you<br>
dont care about the data.  newer version might let you skip certain<br>
filesystems (to reduce the time & number of CDs).<br>
<br>
option 2) hook up an external usb disk and copy the files that you want<br>
over to it.  Then if the server goes belly up (and they never do that<br>
</sarcasm>) you can plug the usb drive into another server and recover<br>
the files.<br>
pros: cheap to setup and easy to automate.<br>
cons: what happens if the server is struck by lightning or electrical<br>
surge and takes the server and the external drive out?  what happens<br>
when the disk is failing? etc.  what happens if the building is leveled<br>
(or flooded with water)?<br>
<br>
option 3) use rsync (over ssh) and an "include these files" file.  Rsync<br>
can be automated.  the target where you are copying it to can be in the<br>
same building/data center, across the country, or wherever.  you just<br>
need network connectivity.  You could do 2 rsyncs every time.  one to a<br>
local server (same building/data center) and one remote (for when stuff<br>
goes really bad).  rsync doesnt care.<br>
pros: can be automated.  can do mulitple destinations.  can be near or<br>
far replciations.  restores are easy to do.<br>
cons: have to maintain the "files to include" list.  although if you<br>
wanted to, you could automate that too.  rsync is not the fastest tool<br>
on the planet to do replications. see my note about how rsync works below.<br>
<br>
<br>
rsync and how it works notes (this is high level not the nuts-n-bolts):<br>
rsync goes through these phases:<br>
* both sides compiles a list of files (and directories since they are<br>
actually files).<br>
* rsync compares the two lists to determine what needs to be replicated,<br>
what needs to be deleted, etc.<br>
*(only if using the delete-before option) deletes the "to be deleted"<br>
files on the target<br>
* copies the files from source to target<br>
* (only if NOT using the delete-before option - this is the default<br>
option for delete) deletes the "to be deleted" files on the target.<br>
<br>
as you get more and more files (quantity of files/directories not sizes<br>
here), the longer the first two steps take (compiling lists/comparing<br>
lists).  And sometimes it takes longer to do that then the actual<br>
copying of data.<br>
<br>
to do a restore of the data, you reverse the order of the source and<br>
target inte rsync line and now you are restoring.<br>
<br>
backups:<br>
rsync <whole bunch of option> <source> <target><br>
<br>
restores:<br>
rsync <whole bunch of options> <target> <source>  (using the stuff from<br>
above).<br>
technically that is not correct.  it is always the <source> then<br>
<target> but for a restore the <target> is now your <source> and vice versa.<br>
<br>
my suggestion to you Brandon for this box (since you dont care about<br>
data, just the config files) I would do option 3.  Unless you want to<br>
setup and play with Mondo.  If this is a learning experience so you can<br>
deploy Mondo onto other systems then that is a different story.  If you<br>
do option 3, I would automate/cronjob once a week to dump "rpm -qa" to a<br>
text file that you rsync.  that way you know that a current list of all<br>
rpms.<br>
<br>
I hopefully answered some questions without going on and on and on too<br>
much. I can do a hour long preso on the various options including the<br>
differences in DR, HA, CA, and DA... (Disaster Recovery, High<br>
Availability, Continuous Availability, and Disaster Avoidance respectfully)<br>
<br>
let me know if you have other questions..<br>
scott<br>
<div class="im"><br>
Brandon Wood wrote:<br>
> This stems from having to reinstall the system after a drive crashed<br>
> (non-raid, no backup of the OS). At this point there are a couple of<br>
> 500gb drives in a RAID 1 setup but I want to make sure I don't have to<br>
> start from scratch should the worst happen.<br>
><br>
> I'm running CentOS 5.5 on a Proliant ML350 G6. The two 500gb drives are<br>
> setup with software raid in linux currently while the large data drives<br>
> are using the SmartArray raid hardware. I only mention this as mondo had<br>
> some complaints about the raid setup.<br>
><br>
> I doubt the OS will be messed with much more beyond this point and the<br>
> scripts that do the data processing are backed up on their own. The data<br>
> produced is sent off to another server so there isn't much that changes<br>
> as time goes on so the snapshot may cover me. But I am interested in<br>
> hearing your suggestions for backups / disaster recovery.<br>
><br>
><br>
> On Wed, Jun 30, 2010 at 6:47 PM, scott <<a href="mailto:scott@sboss.net">scott@sboss.net</a><br>
</div><div><div></div><div class="h5">> <mailto:<a href="mailto:scott@sboss.net">scott@sboss.net</a>>> wrote:<br>
><br>
>     are you looking for "backups"? "disaster recovery"? or "system image"?<br>
><br>
>     mondo works well for recovering a system from a point in time snapshot<br>
>     of the system (when you did the mondo image create - cant remember the<br>
>     terminology right now).<br>
><br>
>     mondo is not a backup and recovery tool.<br>
><br>
>     mondo is not for disaster recovery (unless you just want to recovery<br>
>     from that one time point in time snapshot).<br>
><br>
>     it has been a little while since I used mondo but it has worked well for<br>
>     me in the past.  target HD doesnt have to be the same size.  It can be<br>
>     larger or just larger than what you have backed up.<br>
><br>
>     for instance:<br>
>     current HD = 1Tb drive. But only using 300gig<br>
><br>
>     recovery system doesnt have to have a 1TB drive.  a 320gig drive from<br>
>     newegg would be fine.  If you are recovering to a non-same-sized drive,<br>
>     you have to go into the system at recovery time (the one you boot off<br>
>     of) and change the drive specs before the actual recovery.<br>
><br>
>     scott<br>
><br>
><br>
>     Brandon Wood wrote:<br>
>      > All,<br>
>      >    I am looking to create an image of a live system and want to know<br>
>      > what software is suggested for this purpose. I've done some searching<br>
>      > and came across 'mondo' and am trying it out now.<br>
>      ><br>
>      > Does anyone have any better suggestions or success stories they<br>
>     want to<br>
>      > share?<br>
>      ><br>
>      > -Woody<br>
>      ><br>
>      ><br>
>      ><br>
>     ------------------------------------------------------------------------<br>
>      ><br>
>      > _______________________________________________<br>
>      > Ale mailing list<br>
</div></div>>      > <a href="mailto:Ale@ale.org">Ale@ale.org</a> <mailto:<a href="mailto:Ale@ale.org">Ale@ale.org</a>><br>
<div class="im">>      > <a href="http://mail.ale.org/mailman/listinfo/ale" target="_blank">http://mail.ale.org/mailman/listinfo/ale</a><br>
>      > See JOBS, ANNOUNCE and SCHOOLS lists at<br>
>      > <a href="http://mail.ale.org/mailman/listinfo" target="_blank">http://mail.ale.org/mailman/listinfo</a><br>
>     _______________________________________________<br>
>     Ale mailing list<br>
</div>>     <a href="mailto:Ale@ale.org">Ale@ale.org</a> <mailto:<a href="mailto:Ale@ale.org">Ale@ale.org</a>><br>
<div><div></div><div class="h5">>     <a href="http://mail.ale.org/mailman/listinfo/ale" target="_blank">http://mail.ale.org/mailman/listinfo/ale</a><br>
>     See JOBS, ANNOUNCE and SCHOOLS lists at<br>
>     <a href="http://mail.ale.org/mailman/listinfo" target="_blank">http://mail.ale.org/mailman/listinfo</a><br>
><br>
><br>
><br>
> ------------------------------------------------------------------------<br>
><br>
> _______________________________________________<br>
> Ale mailing list<br>
> <a href="mailto:Ale@ale.org">Ale@ale.org</a><br>
> <a href="http://mail.ale.org/mailman/listinfo/ale" target="_blank">http://mail.ale.org/mailman/listinfo/ale</a><br>
> See JOBS, ANNOUNCE and SCHOOLS lists at<br>
> <a href="http://mail.ale.org/mailman/listinfo" target="_blank">http://mail.ale.org/mailman/listinfo</a><br>
_______________________________________________<br>
Ale mailing list<br>
<a href="mailto:Ale@ale.org">Ale@ale.org</a><br>
<a href="http://mail.ale.org/mailman/listinfo/ale" target="_blank">http://mail.ale.org/mailman/listinfo/ale</a><br>
See JOBS, ANNOUNCE and SCHOOLS lists at<br>
<a href="http://mail.ale.org/mailman/listinfo" target="_blank">http://mail.ale.org/mailman/listinfo</a><br>
</div></div></blockquote></div><br>