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

Re: Bare Metal Backups & Restorations



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 H. Fifarek
rfifarek@fifarek.net

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