Questions about swapping in hardware (disaster recovery) solution..

[Paul Schulz]

Greetings all!

I have an interesting server problem..

We (at work) are installing a new server and at the same time
preparing backup hardware should something go wrong.. The plan is to
do nightly backups to a disk in such a way that should something go
wrong we can then swap in replacement hardware and/or disk, and take
off from where the backup was done.

So.. I trying to create a Ubuntu-server system which is portable
across identical hardware, but where serial-numbers/MAC addresses will
have changed.

It is almost there, with just a couple of snags..
- grub and fstab need to refer to device names rather than UUID's (easy to fix).
- 'udev' wants to keep network device names around (looks easy to fix)
- sysklogd does not start up properly, which causes logins to stop
working (interesting to debug).
  Restarting sysklogd allows logins to occur.. but I get the following error:

    syslogd: unknown priority name "exec"

It's the last one I need to get to the bottom of (hence my question),
but other than this.. the idea, as a concept works quite well for us
(details below).

Does anyone have any suggestions?
[Hardware is DELL 1950 1U servers with 2x 72GB SAS drives (non-RAID)]

Cheers,
Paul

-- Disaster recovery methodology --

  Two servers (S1,S2, geographically separated),
  with two disks in each (diskA, diskB and diskC, diskD) + a couple of
spare identical drives.

  Main server:
  - S1-diskA, S2-diskC are Ubuntu-server installs
  - S1-diskA is the main server disk (sda)
  - On S1, diskB is a copy of diskA - 'dd' is used initially, then
regular rsync to maintain the copy.
      (Initial dd is also done to diskD to setup partitioning.)

  Backup server:
  - S2-diskC is a basic install, but is used to regularly copy
S1-diskB to S2-diskD
      across the network.
  - S2-diskD can be swapped for a spare drive to keep rolling system backups.

  Scenarios
  - Should the disk (diskA) fail in S1, then diskB can be swapped in
and system rebooted.
  - Should hardware in S1 fail, S2 can be moved in with diskA and
system rebooted.

  - These operations can be tested independently on S2 hardware.