Beyond Backups: Architecting Disaster Recovery in a Post-Schrems II World

The July 2020 ruling by the Court of Justice of the European Union (CJEU) in the Schrems II case didn't just invalidate the Privacy Shield; it fundamentally broke the Disaster Recovery (DR) strategies of half the CTOs in Oslo. If your current DR plan involves silently piping customer data to a generic object storage bucket in US-East-1, you aren't just risking latency—you are risking illegal data transfer.

Compliance is no longer a checkbox; it is an architectural constraint. But let's put the legal panic aside for a moment. Even without the looming shadow of Datatilsynet (The Norwegian Data Protection Authority), the technical reality of recovery often fails to match the glossy promises of SLA documents. Backups are useless if your Time to Recovery (TTR) exceeds your business's tolerance for silence.

We are going to look at a pragmatic, battle-tested approach to DR that keeps your data sovereign within the EEA, specifically leveraging high-performance infrastructure like CoolVDS to minimize downtime.

The Mathematics of Failure: RPO vs. RTO

Before we write a single line of config, we must define the failure tolerances. Most hosting providers sell you "99.9% uptime," but they rarely discuss the recovery velocity.

• RPO (Recovery Point Objective): How much data are you willing to lose? If your database crashes at 14:00 and your last backup was at 02:00, your RPO is 12 hours. For a financial ledger, this is unacceptable.
• RTO (Recovery Time Objective): How long does it take to restore service? This is where disk I/O matters. Restoring 500GB of data on standard SATA SSDs is painful. On the NVMe arrays we use at CoolVDS, it is a coffee break.

Pro Tip: Network latency is the silent killer of RPO. Replicating data synchronously from Oslo to Frankfurt adds roughly 15-20ms of round-trip latency per transaction. For high-throughput workloads, keep your hot DR site local—within Norway or the Nordics—to keep application performance snappy while satisfying redundancy requirements.

Scenario: The Indestructible PostgreSQL Cluster

Let's move away from theory. We will configure a disaster recovery mechanism for a PostgreSQL 12 database (the current stable workhorse). We aren't relying on proprietary cloud magic; we are using standard tools that allow you to migrate anywhere if you need to.

1. Point-in-Time Recovery (PITR) Configuration

Snapshots are not enough. You need Continuous Archiving to replay the Write Ahead Log (WAL). This allows you to restore the database to the exact second before the crash.

In your postgresql.conf on the primary node:

# /etc/postgresql/12/main/postgresql.conf

wal_level = replica
archive_mode = on
# We use rsync here, but this could be a script pushing to a MinIO instance
archive_command = 'test ! -f /mnt/nfs_backup/%f && cp %p /mnt/nfs_backup/%f'

# Performance tuning for recovery
max_wal_senders = 10
wal_keep_segments = 64

2. The Off-Site Transport

To satisfy the "3-2-1" backup rule (3 copies, 2 media types, 1 off-site), we need to ship these WAL files out of the primary datacenter. If your primary server is in Oslo, your backup should be physically separate.

Here is a robust bash script using rsync over SSH. It handles the transfer securely without exposing the database port to the public internet.

#!/bin/bash
# /usr/local/bin/ship_logs.sh

SOURCE_DIR="/var/lib/postgresql/12/main/pg_wal/"
DEST_HOST="dr-user@backup.coolvds.net"
DEST_DIR="/home/dr-user/wal_archive/"

# -a: archive mode
# -v: verbose
# -z: compress during transfer (saves bandwidth on the WAN)
# --bwlimit: protect your production bandwidth

rsync -avz --bwlimit=5000 -e "ssh -i /root/.ssh/id_rsa_dr" $SOURCE_DIR $DEST_HOST:$DEST_DIR

if [ $? -eq 0 ]; then
    echo "$(date): WAL shipment successful"
else
    echo "$(date): WAL shipment FAILED" | mail -s "DR ALERT" ops@yourcompany.no
fi

3. Automating Restoration with Ansible

When the primary server melts, you don't want to be manually typing commands while the CEO breathes down your neck. Automation provides consistency.

Here is an Ansible 2.9 playbook snippet that provisions a fresh CoolVDS instance and initiates the recovery process. This assumes you have already provisioned the base VM via API.

--- 
- name: Restore Database from Disaster
  hosts: recovery_node
  become: yes
  vars:
    postgres_version: 12
    backup_path: /mnt/recovery_data

  tasks:
    - name: Stop PostgreSQL service before restore
      systemd:
        name: postgresql
        state: stopped

    - name: Clean current data directory
      file:
        path: "/var/lib/postgresql/{{ postgres_version }}/main"
        state: absent

    - name: Restore Base Backup
      command: >
        pg_basebackup -h backup.coolvds.net -D /var/lib/postgresql/{{ postgres_version }}/main -U replicator -v -P
      environment:
        PGPASSWORD: "{{ vault_db_password }}"

    - name: Configure recovery.conf (Postgres 11 and older style, or recovery.signal for 12+)
      copy:
        dest: "/var/lib/postgresql/{{ postgres_version }}/main/recovery.signal"
        content: ""
        owner: postgres
        group: postgres

    - name: Set restore command in postgresql.conf
      lineinfile:
        path: "/etc/postgresql/{{ postgres_version }}/main/postgresql.conf"
        line: "restore_command = 'cp /mnt/recovery_data/%f %p'"

    - name: Start PostgreSQL to begin replay
      systemd:
        name: postgresql
        state: started

The Hardware Factor: Why Infrastructure Choice Matters

Software configuration is only half the battle. The underlying infrastructure dictates the physical limits of your recovery speed.

In a recovery scenario, your disk I/O hits a massive spike. You are essentially rewriting the entire state of your application at once. Shared, noisy-neighbor storage environments often choke here, throttling your IOPS just when you need them most.

This is why we architect CoolVDS on KVM with local NVMe storage rather than relying purely on networked CEPH clusters or legacy SANs. The path from the CPU to the disk is shorter. In benchmarks running pgbench restoration tests, NVMe instances consistently show a 40-60% reduction in restoration time compared to standard SSD VPS options.

Data Sovereignty & The Norwegian Advantage

Post-Schrems II, the physical location of the server is a legal attribute. By hosting your primary and DR sites within Norwegian borders (or strictly within the EEA), you simplify your GDPR compliance posture significantly. You are not relying on Standard Contractual Clauses (SCCs) that might be challenged in court next month.

Conclusion: Don't Wait for the Kernel Panic

A disaster recovery plan that hasn't been tested is just a hypothesis. The technology exists to make redundancy painless, compliant, and fast. By combining robust open-source tools like PostgreSQL and Ansible with high-performance, legally compliant infrastructure, you can survive the worst-case scenario.

Do not let your data simply vanish. Audit your RPO today, and if you need a compliant, high-speed destination for your off-site backups, deploy a CoolVDS storage instance. It takes less than 60 seconds to spin up, but it could save your entire company.