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

At present I operate a (reasonably low volume) web-hosting service with a Centos 5.3 server running cPanel/WHM.

I would like to implement a level of redundancy such that in the event of server failure, I can restore service with a minimum of effort in less than 60 minutes.

I also want to setup a secondary DNS that cPanel will replicate with. My current idea is to kill two birds with one stone by:

My current server is called "www1"

  1. Purchase an identical server (HP DL360 G4) with mirrored disks. Call this server "www2"
  2. Install Centos 5.4 (or perhaps I should install 5.3 to be identical with www1)
  3. Install cPanel/WHM on this server and fully license it
  4. Setup www1 and www2 cPanel to replicate DNS with each other
  5. Setup a nightly replication script that does the following: a) rsync's the /home directory from www1 to www2 b) dumps all MySQL databases on www1 and copies them to a temp folder (with root access only) on www2 c) triggers a script to run on www2 that restores the MySQL dumps

Thus each night a fully working copy of all the websites and MySQL databases is copied to www2.

I do not have enough knowledge of MySQL replication to understand if it works safely and transparently with cPanel. Thus I propose the mysql dump/copy/restore due to not knowing any better!

In the event that www1 dies a horrible death, I envisage that I could login to www2, change the IP addresses to those that www1 had, and presto, the websites are available again.

The advantage of this idea is that it is fairly simple and "low tech" and thus does not require an expert sysadmin to setup and monitor (I am NOT an expert sysadmin)

The disadvantage of this idea is that up to a full days worth of data changes would be lost. I think this would be acceptable to the sorts of customers I host at the moment. The other disadvantage would be having to pay for a full cPanel license, but I am comfortable with that cost, so for now all I want to discuss are technical considerations.

Is this a sound scheme?

share|improve this question

closed as off-topic by HopelessN00b Feb 22 '15 at 0:23

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions should demonstrate reasonable business information technology management practices. Questions that relate to unsupported hardware or software platforms or unmaintained environments may not be suitable for Server Fault - see the help center." – HopelessN00b
If this question can be reworded to fit the rules in the help center, please edit the question.

This type of setup will work for you - I've used the same setup on cPanel hosts before. MySql backups specifically are a larger topic, but what you're talking about will probably work fine. You're missing a lot of important small pieces you probably just wouldn't think of unless you've done this a few times, most of this can be copied into place directly when you need to failover:

Information in /etc/:

  • Password info: You're going to want key configuration files like /etc/passwd, /etc/shadow, etc - unless you want to change all your user's passwords. Bonus for you is that running a cpanel server you'll ned /etc/proftp/, where all the ftp passwords are stored. (Yes, cpanel uses pure-ftpd now - it just stores all the passwords in /etc/proftpd/ for reasons you'd probably better not explode you're head thinking about now).
  • Your customer's email forwarders - /etc/valiases/
  • /etc/ssl <-ssl certificates - customers don't like when these disappear.
  • Other miscelleneous files in /etc/domains and /etc/.ips off the top of my head.

Critical cPanel config files/templates

  • cpanel configuration and service configuration template data from /var/cpanel/. At the least you'll want to backup /var/cpanel/, move it into place during a failover situation, and run /scripts/upcp --force. (this will fix many ills)
  • cPanel uses a templating system to build config files. For example, all your apache template data is stored in /var/cpanel/userdata/ - that's what's used by /scripts/rebuildhttpdconf to actually create your httpd.conf file.
  • /var/cpanel/easy/apache/profile/ - these are the profiles used by easy apache to build your apache configuration, I'd have this ready to go on the new server rather than trying to rebuild on the fly.


  • You'll want to backup /var/named/ if you're running DNS on the same machine
  • I'm assuming you're going to setup www2 to also host ns2.yourdomain? If you want real redundancy on the cheap, you may want to snipe two small VPS accounts somewhere and just use cPanel's DNS clustering if want to move that off the same machine: (
share|improve this answer

While this scheme of yours will work when you have both of the servers in the same datacenter and you have your IPs routed to the vLAN, having both servers inside the same DC pretty much defeats the purpose of redundancy, as all this will do is protect against massive hardware failure on your main server, but will do nothing against a DC catastrophe.

You will likely have the same effect by using dual redundant power supplies connected to different PDUs as well as a RAID-10 setup on your server, and you'll have less hassle of setting up a second one, but this will still leave you vulnerable in case your datacenter has serious problems.

share|improve this answer

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