Disaster Recovery for Norwegian Enterprises: Beyond "sudo rm -rf"

It is May 2017. We are exactly one year away from the enforcement of the General Data Protection Regulation (GDPR). If you are a CTO or Lead Systems Architect in Oslo, the clock is ticking louder than the fans in your server room. The days of simply dumping a tarball to an FTP server and calling it a "Disaster Recovery Plan" are legally over. If you lose customer data, the Datatilsynet (Norwegian Data Protection Authority) will not be impressed by your cron jobs.

True resilience is about RTO (Recovery Time Objective) and RPO (Recovery Point Objective). In a recent audit for a FinTech client in Bergen, we found their "backup" strategy had an RTO of 48 hours. In the current market, that is not downtime; that is bankruptcy.

Let's strip away the marketing buzzwords and look at how to architect a failover solution using tools available today—CentOS 7, MySQL 5.7, and the stability of KVM-based virtualization provided by CoolVDS.

The Data Sovereignty Paradox

Before we touch the config files, we must address the infrastructure. Since the invalidation of Safe Harbor and the shaky ground of the Privacy Shield framework, storing data outside the EEA is a liability. Latency is another. If your primary audience is in Scandinavia, hosting your DR site in Virginia adds 100ms+ of latency that makes active-active replication painful.

We recommend keeping your primary and DR sites geographically separated but jurisdictionally unified. A CoolVDS instance in Oslo peering directly via NIX (Norwegian Internet Exchange) ensures that your data stays under Norwegian law while benefiting from millisecond-level latency.

Database Replication: The Heart of DR

Files are easy; databases are hard. In 2017, MySQL 5.7 with GTID (Global Transaction Identifier) based replication is the robust standard. It prevents the "drift" that plagued older binary log position methods. If your master melts, you need to know exactly where the slave left off.

Here is the critical configuration for your Master server (/etc/my.cnf). Note the innodb_flush_log_at_trx_commit setting—we set it to 1 for ACID compliance, even though it costs I/O performance. This is why CoolVDS NVMe storage is non-negotiable here; spinning rust cannot handle the write penalties of sync replication.

[mysqld]
server-id = 1
log_bin = /var/log/mysql/mysql-bin.log
binlog_format = ROW
expire_logs_days = 7
max_binlog_size = 100M

# GTID Replication (The modern standard)
gtid_mode = ON
enforce_gtid_consistency = ON

# Durability settings
sync_binlog = 1
innodb_flush_log_at_trx_commit = 1
innodb_buffer_pool_size = 4G  # Adjust to 70% of your CoolVDS RAM

On the Slave (DR) server, the configuration differs slightly to ensure it stays read-only until promoted:

[mysqld]
server-id = 2
relay_log = /var/log/mysql/mysql-relay-bin.log
log_bin = /var/log/mysql/mysql-bin.log
gtid_mode = ON
enforce_gtid_consistency = ON
read_only = 1  # Crucial safety net

Pro Tip: Do not rely on mysqldump for datasets larger than 10GB. The lock time is unacceptable. Use Percona XtraBackup. It performs non-blocking backups for InnoDB, allowing you to seed your slave without stopping the master.

File Synchronization without the Bandwidth Tax

For static assets, rsync remains king. However, a naive cron job running rsync every minute can saturate your uplink, causing packet loss for legitimate web traffic. You must throttle it.

We use a wrapper script that checks for the existence of a lock file (to prevent overlapping executions) and limits bandwidth.

#!/bin/bash

LOCKFILE="/var/run/dr_sync.lock"
SRC="/var/www/html/"
DEST="user@dr-node.coolvds.no:/var/www/html/"

if [ -f "$LOCKFILE" ]; then
    echo "Sync already running."
    exit 1
fi

touch $LOCKFILE

# --bwlimit=5000 limits to approx 5MB/s, saving room for HTTP traffic
rsync -avz --delete --bwlimit=5000 -e "ssh -p 2202" $SRC $DEST

rm $LOCKFILE

Network Layer: The Failover Switch

Having the data ready is only half the battle. You need to switch traffic. In a high-availability setup, we often use Keepalived with VRRP (Virtual Router Redundancy Protocol). However, if your DR site is in a different subnet (which it should be for true redundancy), VRRP won't span the routing gap.

In 2017, the pragmatic approach for a mid-sized setup involves DNS Failover with a low TTL (Time To Live). Set your A records to a TTL of 60 seconds. Yes, it increases DNS query load, but it allows you to swing traffic in under 5 minutes without BGP complexity.

Securing the Tunnel

Data moving between your primary site and your CoolVDS backup node must be encrypted. While SSH tunnels work for rsync, database replication requires a persistent link. We recommend OpenVPN for this. It is battle-tested and stable.

# /etc/openvpn/server.conf snippet
port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh2048.pem
server 10.8.0.0 255.255.255.0
cipher AES-256-CBC
auth SHA256

Ensure your iptables firewall rules explicitly allow traffic only on the tun0 interface for MySQL (port 3306), denying it on the public interface.

Why KVM Matters for Recovery

Why do we insist on KVM (Kernel-based Virtual Machine) at CoolVDS? Container-based virtualization (like OpenVZ) often shares the kernel with the host. In a "noisy neighbor" scenario, another tenant under DDoS attack could starve your database of kernel resources right when you are trying to recover.

KVM provides strict hardware isolation. When you provision an NVMe VPS with us, the RAM and CPU cycles are reserved. During a recovery scenario, you need predictable performance, not "burstable" promises.

The