Disaster Recovery in the GDPR Era: A Norwegian Survival Guide

Let’s be brutally honest: nobody cares about your backups until the database is corrupted. By then, it is too late. With the General Data Protection Regulation (GDPR) fully enforceable as of May this year, the stakes have shifted. Losing customer data is no longer just an embarrassing operational hiccup; it is a potentially company-ending event involving Datatilsynet (The Norwegian Data Protection Authority) and fines up to 4% of your global turnover.

I have spent the last decade watching servers fail. Hard drives seize, RAID controllers lie, and data centers go dark due to fiber cuts. The difference in 2018 is that your disaster recovery (DR) plan must be as legally compliant as it is technically sound.

The RPO and RTO Equation

Before we touch a single configuration file, you need to define two variables. If you cannot answer these, you do not have a DR plan; you have a wish list.

• Recovery Point Objective (RPO): How much data are you willing to lose? Five minutes? One hour? If your RPO is zero, you need synchronous replication (and a massive budget).
• Recovery Time Objective (RTO): How long can you be offline? If your RTO is 4 hours, you can rely on cold backups. If it is 5 minutes, you need a warm standby.

Pro Tip: Most VPS providers oversell their storage speed. When you are restoring 500GB of data, standard SATA SSDs will bottleneck your RTO. We strictly use NVMe storage at CoolVDS because during a restore, I/O wait is the enemy.

Step 1: The "Immutable" Encrypted Backup

In the post-GDPR world, a backup that isn't encrypted is a liability. If someone steals your backup tape or dumps your S3 bucket, that is a data breach. We need to script a solution that dumps, compresses, encrypts, and ships the data off-site.

Here is a battle-tested Bash script compatible with Ubuntu 18.04 LTS and MySQL 5.7/8.0. It uses mysqldump for consistency and GPG for encryption.

#!/bin/bash
# GDPR-Compliant MySQL Backup Script
# Date: July 2018

TIMESTAMP=$(date +"%F")
BACKUP_DIR="/backup/mysql"
MYSQL_USER="backup_user"
MYSQL_PASSWORD="YourStrongPassword"
MYSQL_DATABASE="production_db"
GPG_RECIPIENT="admin@yourcompany.no"

# Ensure backup directory exists
mkdir -p $BACKUP_DIR

# 1. Dump & Compress & Encrypt
# We pipe directly to avoid writing unencrypted SQL to disk
mysqldump -u $MYSQL_USER -p$MYSQL_PASSWORD --single-transaction --quick --lock-tables=false $MYSQL_DATABASE | \
gzip | \
gpg --encrypt --recipient $GPG_RECIPIENT --trust-model always --output $BACKUP_DIR/$MYSQL_DATABASE-$TIMESTAMP.sql.gz.gpg

# 2. Verify existence
if [ -f "$BACKUP_DIR/$MYSQL_DATABASE-$TIMESTAMP.sql.gz.gpg" ]; then
    echo "Backup success: $TIMESTAMP"
    # 3. Offsite Sync (using rsync over SSH)
    rsync -avz -e "ssh -p 22" $BACKUP_DIR/ remote_user@offsite-storage.coolvds.com:/remote/backup/
else
    echo "Backup FAILED" | mail -s "CRITICAL: Backup Failed" admin@yourcompany.no
fi

This script ensures that clear-text customer data never touches the disk at rest in the backup folder. It is piped directly into GPG. This satisfies Article 32 of the GDPR regarding "pseudonymisation and encryption of personal data."

Step 2: Infrastructure as Code (IaC) for Rapid Recovery

Restoring the data is only half the battle. You need a server to put it on. If your primary node in Oslo goes down, manually installing Nginx, PHP-FPM, and configuring firewalls will blow your RTO window.

In 2018, there is no excuse for manual server configuration. We use Ansible. Below is a snippet of a playbook that configures a fresh CoolVDS instance to be web-ready in under 3 minutes.

---
- name: Provision Disaster Recovery Node
  hosts: dr_servers
  become: yes
  vars:
    http_port: 80
    max_clients: 200

  tasks:
  - name: Install Nginx and PHP-FPM
    apt:
      name: "{{ item }}"
      state: present
      update_cache: yes
    with_items:
      - nginx
      - php-fpm
      - php-mysql

  - name: Push Optimized Nginx Config
    template:
      src: templates/nginx.conf.j2
      dest: /etc/nginx/nginx.conf
    notify:
    - restart nginx

  - name: Ensure Firewall allows HTTP
    ufw:
      rule: allow
      port: "{{ http_port }}"
      proto: tcp

By keeping this playbook in a private Git repository, you can spin up a new KVM instance on CoolVDS, run one command, and have an environment ready to accept the database restore we created in Step 1.

Step 3: The Norwegian Jurisdiction Advantage

Why does geography matter? Latency and Law.

1. Latency: If your primary market is Norway, hosting your DR site in Frankfurt adds 20-30ms of latency. That might be acceptable for a static site, but for a high-transaction e-commerce store, it is noticeable. CoolVDS infrastructure peers directly at NIX (Norwegian Internet Exchange) in Oslo. Pinging `8.8.8.8` is fine, but pinging your customers in milliseconds is better.

2. Data Sovereignty: While the EU-US Privacy Shield is technically active, it is under heavy scrutiny. Many Norwegian CTOs prefer to keep data within the EEA (European Economic Area) to simplify compliance. Hosting on a US-owned cloud provider can introduce legal complexity regarding the CLOUD Act. Hosting on a Norwegian/European provider like CoolVDS keeps the data under clear jurisdiction.

Step 4: Handling the Switchover (DNS Failover)

When the primary server dies, you need to redirect traffic. In a sophisticated setup, you might use BGP Anycast, but for most SMEs, a low-TTL DNS switch is sufficient.

Set your DNS TTL (Time To Live) to 300 seconds (5 minutes). During an outage, update the A record to point to your DR IP. While propagation happens, you should serve a "Maintenance Mode" page from a lightweight Nginx instance if possible.

# Nginx Maintenance Mode Config
server {
    listen 80;
    server_name example.no;

    location / {
        return 503;
    }

    error_page 503 @maintenance;
    location @maintenance {
        rewrite ^(.*)$ /maintenance.html break;
    }
}

Conclusion: Test or Fail

A backup is not a backup until you have successfully restored it. I recommend a "Fire Drill" every quarter. Spin up a fresh CoolVDS instance, run your Ansible playbook, decrypt your latest backup, and verify the application loads.

Hardware failure is inevitable. In 2018, data loss is a choice. Choose robust architecture, choose encryption, and choose infrastructure that respects your data sovereignty.

Ready to harden your infrastructure? Deploy a KVM-based, NVMe-powered instance on CoolVDS today and get 1Gbps connectivity to NIX.