Hi Aaron,
In general, Red Hat typically recommends using kickstart for all of your deployment and disaster recovery needs.  Kickstart is a method for automating an installation by specifying the settings and configuration for anaconda to use, such as the network settings, partitioning layout, package selections, etc.  You can also utilize scripts in a kickstart that will run before, during, and after the installation process to setup just about any aspect of a deployment.  A properly written kickstart will be able to deploy your desired configuration on any system, resulting in an an identical setup in the areas that matter, while differing in the areas that it needs to (such as network and hardware configuration).  

Although you mention that you have identical hardware available for your recovery system now, somewhere down the line you may decide that you want to deploy this same configuration on a newer hardware platform, in which case a bit-for-bit backup of your current server's hard drive would not be ideal.   However, you could just run the installation again on the new server using your kickstart, migrate any data over to that new system, and you are done.  

The best way to get started with kickstart is to look at the one that was generated for you by your installation, stored in /root/anaconda-ks.cfg.  You can also consult the Installation Guide for more details, such as the available options and examples:

  http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html-single/Installation_Guide/index.html

To take that one step further, you might want to take a look at Red Hat Network Satellite.  With a Satellite, you can, among other things, create installation profiles, system groups, and kickstarts; create and clone software channels so that you have customized repositories for each of your deployment types; manage and deploy configuration files, directories, and symlinks; provision, manage, and update systems; and even automate all of this through API calls and scripting.  You can also use satellite to grab all of the package versions from one system, and install those same versions on another.

For further information on Red Hat Network Satellite, visit:

  http://docs.redhat.com/docs/en-US/Red_Hat_Network_Satellite/index.html

If you are more interested in just taking a copy of one system and restoring it to another, there are a few tools that you can take advantage of:

* rsync: With rsync, you can copy the files and directories you need, compress them, and transfer them to the destination system over the network with a single command.  You can either schedule an rsync backup with cron or run it manually on-demand.  You can also take advantage of rsync's ability to run incremental backups, where it will only have to copy and transfer the bits that have changed since the last time you have run it.  

* dd: This tool will create a bit-for-bit copy of any file, partition, or disk that you specify and write it out to a file or disk of your choosing.  You can then transfer this to your recovery system and again use dd to write that out to disk.  For disaster recovery purposes, dd backups are difficult to manage due to the size of the files, as well as the fact that any hardware differences between the two systems will need to be accounted for and corrected in the backup image.

* LVM snapshots: If the data you are backing up is on an LVM2 logical volume and you have free space available in that volume group, then you can take a snapshot of the LV for backup purposes.  This is useful because in order to get a consistent backup, you need to ensure that nothing is changing the source files while you are copying them.  Snapshotting allows you to basically take a backup of a point-in-time version of your LV, while not actually preventing anything from continuing to write to it.  Without a method for snapshotting or quiescing the system while taking the backup, best practice would be to completely shut down the system and create a backup from rescue mode.  

There are numerous tools out there to help you manage backups and disaster recovery, and these are just a select few, so I'm sure others will have some ideas to offer as well.  I'd be happy to go into more detail about any of this, or answer any questions you have, so don't hesitate to ask.

Regards,
John Ruemker, RHCA
Red Hat Technical Account Manager