Disaster Recovery in the Post-GDPR Era: Why Your Backup Script Isn't Enough

May 25th, 2018 has come and gone. The GDPR panic emails have finally stopped cluttering our inboxes, but for those of us managing infrastructure, the real work has just begun. If you are still relying on a nightly tar.gz dumped to an AWS S3 bucket in Frankfurt, you aren't doing disaster recovery (DR). You're just archiving your failure.

In the Norwegian market, we face a dual challenge: stringent data sovereignty requirements enforced by Datatilsynet and the physical reality of keeping services online when connectivity drops or hardware fails. A true DR plan isn't about backups; it's about Business Continuity.

Let's look at how to build a replication and recovery strategy that satisfies both the auditors and your users, leveraging the low latency of the Norwegian infrastructure.

The Legal & Technical Convergence

Under GDPR, a data breach isn't just a hack; it's also the loss of availability of personal data. If your server melts and you can't restore access to customer data within a reasonable timeframe, you are technically in violation. This shifts the conversation from "we need backups" to "we need strict RTO (Recovery Time Objective) and RPO (Recovery Point Objective)."

Pro Tip: Don't host your DR site in the same data center availability zone as your primary. For Norwegian businesses, if your primary is in Oslo, your failover should ideally be physically separated but network-adjacent—like a secondary facility in the greater Oslo region or a verified independent provider like CoolVDS to ensure data never crosses national borders unnecessarily.

Step 1: Database Replication (Not Just Dumps)

A nightly mysqldump means you are willing to lose up to 24 hours of data. In 2018, that is unacceptable. We need Master-Slave replication. With MySQL 5.7 (the current stable workhorse), GTID (Global Transaction ID) makes this significantly more robust than the old binary log position method.

Here is a production-ready my.cnf configuration for a Primary node. We optimize for data integrity (ACID) over raw write speed because a corrupted primary is useless.

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

# GTID for safer failover
gtid_mode = ON
enforce_gtid_consistency = ON

# Crash safety
sync_binlog = 1
innodb_flush_log_at_trx_commit = 1

# Performance tuning for 16GB RAM instance on CoolVDS
innodb_buffer_pool_size = 12G
innodb_log_file_size = 1G
innodb_io_capacity = 2000 # Only set this high if you have NVMe!

Note the innodb_io_capacity. On standard spinning rust VPS providers, setting this to 2000 will cause I/O wait times to spike, killing your CPU. On CoolVDS, where we utilize pure NVMe storage, you can push this even higher. The disk is rarely the bottleneck here.

Step 2: Real-Time Filesystem Synchronization

Databases are half the battle. What about user uploads, configuration files, and static assets? rsync is great, but it requires a schedule. lsyncd (Live Syncing Daemon) monitors your file system for changes via `inotify` and triggers rsync instantly.

Install it on your primary server (CentOS 7 example):

yum install epel-release
yum install lsyncd

Configure /etc/lsyncd.conf to push changes to your CoolVDS failover node immediately. This creates a hot-standby file system.

settings {
    logfile = "/var/log/lsyncd/lsyncd.log",
    statusFile = "/var/log/lsyncd/lsyncd.status",
    nodaemon = false,
}

sync {
    default.rsyncssh,
    source = "/var/www/html/",
    host = "dr-user@192.0.2.15", -- Your CoolVDS DR IP
    targetdir = "/var/www/html/",
    rsync = {
        archive = true,
        compress = true,
        _extra = { "--omit-dir-times" }
    },
    ssh = {
        port = 22
    }
}

This setup ensures that if a user uploads a PDF to your site in Oslo, it exists on your DR node milliseconds later. Latency within the Norwegian network infrastructure (NIX) is typically negligible, making this synchronization seamless.

Step 3: The "Warm" Failover Strategy

Cold storage is cheap but slow. A "Warm" standby is a running VPS that has the services installed (Nginx, PHP-FPM, MySQL) but stopped or idling. This minimizes costs while keeping RTO low.

Why CoolVDS works specifically well for this role: KVM Virtualization.

Many budget providers use OpenVZ (container-based virtualization). In an OpenVZ environment, you share the kernel with neighbors. If you are trying to restore a massive MySQL dump during a disaster, you might hit resource limits imposed by the host node's load. KVM (Kernel-based Virtual Machine) provides dedicated resources. When you hit the "On" switch during a crisis, the RAM and CPU cycles are actually there.

Automating the Failover Check

You need a script outside your infrastructure to monitor health. A simple bash script on a remote monitor node can check availability and alert you. Do not automate the DNS switch unless you have millions to spend on complexity; false positives cause downtime.

#!/bin/bash
PRIMARY_IP="198.51.100.10"
FAILOVER_IP="192.0.2.15"

# Check Primary HTTP Status
HTTP_STATUS=$(curl -s -o /dev/null -w "%{http_code}" http://$PRIMARY_IP)

if [ "$HTTP_STATUS" -ne 200 ]; then
    echo "CRITICAL: Primary site unreachable. Status: $HTTP_STATUS"
    # Send alert via SMS gateway or Email
    mail -s "ALERT: Primary Down" admin@example.no
    
    echo "To switch to Failover, update DNS A record to $FAILOVER_IP"
else
    echo "System Normal."
fi

The Storage Bottleneck: Why NVMe Matters for Recovery

Recovery is essentially a write-heavy operation. If you need to restore data from a compressed archive, you are reading, decompressing, and writing simultaneously. On a SATA SSD, restoring a 50GB database might take 45 minutes. On NVMe (Non-Volatile Memory Express), which bypasses the legacy SATA interface, this can drop to 8-10 minutes.

When your boss asks why the site is still down, the difference between 10 minutes and 45 minutes is the difference between an incident report and a resume update.

Conclusion

GDPR has raised the stakes. Data must remain secure, private, and available. By utilizing MySQL GTID replication and real-time lsyncd mirroring to a KVM-based instance in Norway, you satisfy the legal requirement for data sovereignty and the technical requirement for uptime.

Don't wait for the hardware failure to test your theory. Deploy a secondary KVM instance on CoolVDS today, configure your replication, and pull the plug on your primary to see what really happens. Better to sweat now than bleed later.