[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bare Metal Backups & Restorations




On Mon, 2009-01-12 at 11:42 -0700, Richard H. Fifarek wrote:
> Robert G. (Doc) Savage wrote:
> > In this document I've borrowed many of the techniques I learned in a
> > SANS Security 508 course, "Computer Forensics, Investigation, and
> > Response" that I took about three years ago. For those of you who can
> > finagle your employer to send you to such a course at an upcomig event
> > like SANS 2009 at Orlando, I highly recommend it. 
> 
> 	Disclaimer: I work for SANS.
> 
> 	Here, here, 508 is a great course.  I'm currently staffed for Orlando
> (could change, granted), let me know if any of you go and we'll meet up.
> 
> 	Back on topic: bare-metal backup and restoration, a slightly different
> take on it, which is particularly useful in a server maintenance role,
> but can be easily tweaked for desktop/laptop.
> 
> 	NOTE: This does not replace backups of user generated data, that still
> needs to be done.
> 
> 	Basically, the idea being that 90% of your "OS" files (primarily
> applies to UNIX/Linux) is available in some form that doesn't need to be
> backed up (repos, install cds, etc.), and the config file changes are
> stored in some config management solution (puppet, cfengine, etc.).  The
>  remaining 5-10% of software that needs "special" setup and install
> (i.e. isn't available in .rpm, .deb, .pkg, etc) can often be stored in
> the config management tool directly.  This also makes OS upgrades
> (nearly) seamless.  I say nearly because some package updates (most
> recently, bind caught us with this) will change permissions, expected
> ownership, config options, etc. that will require tweaking of puppet to
> handle the new package.
> 
> 	We use puppet, and we've tuned it to the point where we can rebuild a
> system from bare metal in ~15mins with PXE, kickstart (we use CentOS)
> and puppet.  PXE+kickstart gets a minimal system on the box, with a good
> starting point for disk partitioning, and then we let puppet handle the
> rest.  Puppet will pull additional packages from the rpm repos we've
> defined, and then update the config files for the system to match our
> settings, create user accounts, configure sudo perms, etc.  We haven't
> gotten to the point where we've plugged our backups into the mix, but
> with some work, I don't see this being a huge undertaking.  What I
> envision would be a secondary script running on a new system, once
> puppet was finished, would connect to the backup server, pull all the
> data (probably via rsync+ssh) for the system, and then "uninstall" or
> disable itself once finished.  For CentOS systems, this might be
> pluggable into the firstboot foo provided.
> 
> 	The advantage of a system like puppet over the old school "scp script
> that copies the new file to every system" is that puppet can generate
> different files for each system using templates and variable
> definitions.  Best of both worlds, you get a system that can create
> identical files as well as custom files for each system.	

Richard,

I wish I could join you in Orlando. I had a great time in the SANS 503
Intrusion Detection In-Depth course a few years ago. I don't recall ever
seeing so many folks (virtually everyone in attendance) who so very
obviously didn't subscribe to GQ magazine!

Puppet, CDP, and to a lesser degree, clonezilla would all appeal to the
numbers found in larger organizations. The method I described absolutely
WOULD NOT be appropriate in those levels of scale. You'd have to be
suffering from advanced OCBD to use it more than 2-3 times a year.

When used by an individual, however, the process I describe IS a free
and absolutely reliable way to archive, manipulate, and restore
important "gold images". Running it just once will instill a teriffic
sense of accomplishment and self-sufficiency in any end user.

--Doc

--Doc



-
To unsubscribe, send email to majordomo@silug.org with
"unsubscribe silug-discuss" in the body.