Surviving the Apocalypse: A Pragmatic Disaster Recovery Strategy for Norwegian Systems

There are two types of sysadmins: those who have verified their backups, and those who are about to lose their job. Last winter, I watched a seasoned engineer weep because a RAID controller in a "budget" datacenter silently corrupted three months of data. The backups? stored on the same array. The redundancy? Non-existent.

If you are hosting critical services targeting the Norwegian market, relying on a single dedicated server or a flimsy OpenVZ container is negligence. We need to talk about real Disaster Recovery (DR). Not the paper-pushing kind you show auditors, but the kind that saves your skin at 3:00 AM on a Sunday.

The Latency vs. Redundancy Trade-off

When serving customers in Oslo, Stavanger, or Trondheim, latency is king. You want your heavy iron close to the Norwegian Internet Exchange (NIX). However, physical proximity often creates a single point of failure. If the power grid in the Eastern region fluctuates or a fiber line gets cut, your local redundancy means nothing.

The solution isn't to move everything to a massive US cloud and suffer 150ms latency. The solution is smart replication. You keep your primary logic on high-performance VPS Norway nodes for that sweet <5ms response time, but you replicate data asynchronously to a secondary location.

Database Replication: MySQL 5.6 Basics

In 2014, if you aren't running Master-Slave replication, you aren't running production. With the release of MySQL 5.6, Global Transaction Identifiers (GTIDs) have made failover less of a nightmare, but let's look at a rock-solid, traditional binary log configuration that works on virtually any *nix system (CentOS 6, Ubuntu 14.04).

On your Master (Primary CoolVDS Instance):

# /etc/mysql/my.cnf
[mysqld]
bind-address            = 0.0.0.0
server-id               = 1
log_bin                 = /var/log/mysql/mysql-bin.log
binlog_do_db            = critical_production_db
innodb_flush_log_at_trx_commit = 1
sync_binlog             = 1

The sync_binlog = 1 flag is controversial because it hits I/O hard. On standard spinning rust, this kills performance. This is why we deploy on SSD-backed storage. On CoolVDS's storage arrays, the I/O penalty is negligible compared to the data safety guarantees.

On your Slave (Backup/DR Instance):

# /etc/mysql/my.cnf
[mysqld]
bind-address            = 0.0.0.0
server-id               = 2
relay_log               = /var/log/mysql/mysql-relay-bin.log
read_only               = 1

Pro Tip: Never rely on `mysqldump` for live databases larger than 5GB. The lock time will cause timeouts for your users. Use Percona XtraBackup for hot backups if you need a snapshot, or rely on the slave for the heavy lifting.

File Synchronization: Rsync is Still King

Forget complex distributed filesystems like GlusterFS unless you have a dedicated storage team. They introduce complexity that breaks when you least expect it. For 99% of web applications (Magento, WordPress, Drupal), a robust rsync script running every minute is sufficient for DR.

Here is a battle-tested wrapper script. It handles the lock files and timeouts so you don't end up with fifty zombie rsync processes eating your CPU.

#!/bin/bash
# /root/scripts/sync_dr.sh

SOURCE_DIR="/var/www/vhosts/"
DEST_IP="192.168.10.55" # Your Secondary CoolVDS IP
DEST_DIR="/var/www/vhosts/"
USER="root"
LOCKfile="/tmp/rsync_dr.lock"

if [ -f $LOCKfile ]; then
    echo "Lock file exists, exiting..."
    exit 1
fi

touch $LOCKfile

rsync -avz -e "ssh -p 22" --delete --bwlimit=5000 \
    --exclude 'cache/' \
    --exclude 'logs/' \
    $SOURCE_DIR $USER@$DEST_IP:$DEST_DIR

rm $LOCKfile

Note the --bwlimit. Even with our gigabit uplinks, you don't want a massive sync to choke your web traffic during peak hours. Be a good neighbor, even to yourself.

Virtualization Matters: KVM vs. OpenVZ

This is where many providers cheat you. They sell "VPS" but give you a container (OpenVZ) on a strictly oversold kernel. For DR, this is fatal. If the host kernel panics, you vanish. If a neighbor gets DDoS'd, your I/O crawls.

At CoolVDS, we prioritize KVM (Kernel-based Virtual Machine). You get your own kernel. You can tune your TCP stack variables in /etc/sysctl.conf without permission denied errors. This isolation is mandatory for security compliance, especially with Datatilsynet watching how we handle personal data.

The Compliance Landscape: Datatilsynet & Sovereignty

We are seeing a shift in Europe. The discussions around the proposed General Data Protection Regulation (GDPR) in the EU Parliament suggest that data sovereignty is about to become a legal minefield. While we still operate under the Personal Data Act (Personopplysningsloven), the "safe harbor" of sending data to US servers is looking increasingly shaky.

Hosting in Norway isn't just about low latency; it's about legal safety. By keeping your primary and DR nodes within Norwegian borders (or strictly within the EEA), you mitigate the risk of cross-border data transfer violations. Your CTO will thank you when the auditors come knocking.

Network Resilience and DDoS

You can have the best backups in the world, but if your public IP is null-routed due to a volumetric attack, you are offline. Standard ddos protection is often just an upstream ACL that drops everything. You need intelligent mitigation that scrubs traffic before it hits your eth0.

Check your firewall rules. In 2014, we still see admins leaving port 3306 open to the world. Don't be that person.

# Basic iptables hygiene for your DR node
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
# Allow SSH only from your office IP
iptables -A INPUT -p tcp --dport 22 -s 84.23.xx.xx -j ACCEPT
# Allow MySQL replication only from Master
iptables -A INPUT -p tcp --dport 3306 -s 10.0.0.5 -j ACCEPT
iptables -P INPUT DROP

Final Thoughts

Hardware fails. Fiber gets cut. Junior devs run DROP TABLE. It is not a matter of if, but when. Building a resilient architecture in 2014 doesn't require expensive SANs or proprietary enterprise software. It requires smart configuration, verified backups, and a host that gives you raw, unadulterated access to hardware resources.

Don't wait for the catastrophe to test your strategy. Spin up a KVM instance on CoolVDS today, configure your replication, and sleep better tonight knowing your data stays in Norway and stays online.