This script assumes you’re using user deployer and that SSH keys are set up.
#!/bin/bash
PRODDB="your db name"
PASSWORD="your db password"
DBUSER="your db user"
REMOTESERVER="remote server name"
cd /home/deployer
echo "Starting MySQL transfer of production to remote DR server"
echo -e "\t - Cleaning up previous export files";rm -f proddump.tgz proddump.sql
echo -e "\t - Exporting prod";mysqldump -u $DBUSER -p$PASSWORD --opt --skip-add-drop-table --skip-disable-keys --skip-comments -C $PRODDB >proddump.sql
echo -e "\t - Taring export";tar czvf proddump.tgz proddump.sql
echo -e "\t - Removing previous tar'd export at the DR server";ssh deployer@$REMOTESERVER "rm -f /home/deployer/proddump.tgz"
echo -e "\t - Copying over tar'd export";scp proddump.tgz deployer@$REMOTESERVER:/home/deployer/proddump.tgz
echo -e "\t - Untaring the scp'd export";ssh deployer@$REMOTESERVER "cd /home/deployer; rm -f proddump.sql;tar xzvf proddump.tgz"
echo -e "\t - Dropping remote DR server db";ssh deployer@$REMOTESERVER "mysql -u $DBUSER -pPASSWORD -e \"drop database $PRODDB\""
echo -e "\t - Creating db at the planet";ssh deployer@$REMOTESERVER "mysql -u $DBUSER -pPASSWORD -e \"create database $PRODDB\""
echo -e "\t - Importing database at the planet";ssh deployer@$REMOTESERVER "mysql -u $DBUSER -pPASSWORD $PRODDB < /home/deployer/proddump.sql"
echo "Finished MySQL transfer of production to remote DR server"
user@server:~$ cat diffapache.sh
#!/bin/bash
if [ "$1" == '' ]; then
echo -n "Which Server? (server1, server2, server3,...) : "
read -e SERVER
else
SERVER=$1
fi
cd /etc/apache2/sites-enabled
for f in `ls`
do
echo "Comparing $SERVER's $f file "
ssh $SERVER cat /etc/apache2/sites-enabled/$f |diff /etc/apache2/sites-enabled/$f -
done
1- Which web sites need DR? (per SLA requirements)
2- Method to maintain DR server(s) current – code & data: config, user
a. Hourly rsync (all or database DDL and config tables only?)
b. Daily rsync code rsync? Deploy to production and DR?
3- DR infrastructure
a. Capacity
b. Speed
c. Complete functionality?
d. Server(s)? interconnections? database(s)?
4- Failover plan
a. What could go wrong?
i. Database: corruption, server off line, fail
ii. Web server(s) fail (services down, hardware, software, exploit, etc)
iii. Switches, cabling, routing, load balancers, firewall issue, power
iv. DNS/Registrar issue
1. Secondary DNS servers with sync’d host records
v. When to fail over (metric: minutes of downtime?)
5- How to fail over
a. Communication with decision makers and implementers: text, email, phone, emergency conference line
b. Who makes the determination? after how many minutes of downtime?
c. DNS host changes (set TTL to LOW value, 30 minute browser cache)
6- Recovery plan (switching back to primary)
a. Migrating data
7- Testing (firedrills)
a. How frequently is DR plan exercised? Monthly?
b. Capacity/load tested
8- Modified code deployment/release process
a. New databases, databse DDL changes
b. Apache changes: new sites (virtualhosts), SSL certs
9- Other considerations
a. Using DR infrastructure for handling capactity not just for DR
b. Administrative reporting
c. Handling mid-stream transactions
d. Monitoring/patching/logging DR architecture
i. Third Party: Alertsite, Keynote, Gomez
ii. In house:
1. External monitoring: nagios, selenium, nessus/openvas
2. Internal monitoring: nagios, cacti, tripwire
3. Splunk
e. Cloud? (Amazon EC2 not PCI compliant unless you use their payment processor)
