Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a typically configured dedicated LAMP server running CentOS 5.

I am creating a plan for worst case scenarios - "server dies" any which way.

As of now I have a good back up system going for all users that includes their files databases etc.

My question now is what system information should I capture about the server configuration in order to bring a new server into a matching configuration of the dead one quickly. Things like IP config / DNS setting etc.

I realize there are services that will be unique to my config, but any general static config points to capture would be helpful - as well as where to capture them.

share|improve this question

This is one of the areas where Puppet is helpful. Since Puppet is self-documenting, you can easily expand your network and recover from outages. Puppet collects certain information about the hosts it manages, the processors, RAM, disks, SSH keys, etc.

The basic premise is to kickstart enough to get EPEL installed and onto the local PuppetCA, then your puppetmaster can take care of the rest of the configuration.

Rolling endless crap into kickstart is not a solution.

A software that you can use to identify changes in an environment is Blueprint, which can also play into Puppet configs.

The end result is that your servers should be recipes. Predictable, reproducible recipes that you can test and deploy at will.

The question here for you is the size of your environment. How many physical hosts are you managing? How many virtual? If it's not a lot, Puppet might not be worth the effort.

share|improve this answer
The environment is very small at this server, under 50 domains on it doing the normal web server functions (serving pages, email, db). So I think Puppet will be a little over kill. I was hoping for an answer more along the lines of: make a copy of your httpd.conf in /etc/apache2, etc. – bMon Jul 11 '11 at 19:29
With Blueprint you can identify what has changed from a default install. This can give you information about what to back up. In my environment I have docroots that are simply deployed from subversion. I don't back those up as they are straight from subversion and I have Capistrano scripts to deploy them. I can literally roll that out again in 30 seconds. – Jodie C Jul 11 '11 at 22:56

For a single machine, just taking a whole-of-system backup is usually the best way. I'm an automation lover, but using an automation tool for a one-off system just isn't worth it.

share|improve this answer

You should try to build a test server with a matching config and write down each step along the way then build a kickstart autoinstaller and configuration script to build your server in a fully automated way. That can serve as your documentation so you can rebuild your system quickly if you have a catastrophic failure.

The best way to find out what information you need (network info, filesystem layout, package install, configuration) is to build a test instance and then test it to make sure it works.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.