Disaster Recovery in 2020: Why Off-Site Backups Are Not Enough for Norwegian Enterprises

The Myth of the "Safe" Datacenter

If you have been in the hosting game long enough, you know that "uptime guarantees" are legal fiction. They are refund policies, not engineering promises. In my fifteen years managing infrastructure across Europe, I have seen fiber cables cut by excavators in Oslo, power distribution units fail in Frankfurt, and routing tables get poisoned by fat-finger errors in London.

Here is the hard truth for June 2020: If your Disaster Recovery (DR) plan consists solely of a nightly tarball sent to an FTP server, you do not have a DR plan. You have a digital archive.

Recovery Time Objective (RTO)—how long it takes to get back online—is the only metric that matters when the C-suite is breathing down your neck. Restoring 500GB of data from a cold spinning hard drive (HDD) backup can take upwards of 6 hours just for I/O. On a high-performance NVMe platform like CoolVDS, that same operation is constrained only by the network pipe. Speed is not a luxury; in DR, it is survival.

1. The Architecture of Survival: Active-Passive Replication

For mission-critical applications targeting the Norwegian market, latency and data sovereignty are paramount. You want your primary data in Oslo or close by. But your DR site must be geographically distinct—at least 100km away—while remaining within the EEA to satisfy GDPR and strict Datatilsynet requirements.

We need to move from "Backups" to "Replication".

Database Streaming (PostgreSQL Example)

Stop relying on pg_dump for your RTO strategy. It locks tables and restoration is slow. Instead, use Write-Ahead Log (WAL) streaming. In PostgreSQL 12 (the current stable standard), this is handled cleanly without the messy recovery.conf files of the past.

Primary Node Configuration (postgresql.conf):

# /etc/postgresql/12/main/postgresql.conf
listen_addresses = '*'
wal_level = replica
max_wal_senders = 10
wal_keep_segments = 64 # Vital for network jitter
synchronous_commit = on # optional, strictly for zero-data-loss requirements

Standby Node Configuration:

To set up the standby on a secondary CoolVDS instance, we use pg_basebackup. This commands streams the binary data directly, bypassing the filesystem overhead.

# Run this on the DR server
systemctl stop postgresql
rm -rf /var/lib/postgresql/12/main/*

pg_basebackup -h primary_ip_address -D /var/lib/postgresql/12/main/ -U replicator -P -v -R -X stream

chown -R postgres:postgres /var/lib/postgresql/12/main/
systemctl start postgresql

The -R flag automatically generates the standby.signal file and appends connection settings to postgresql.auto.conf. This setup ensures that if your primary node in Oslo goes dark, your secondary node in a separate fault domain has an up-to-the-second copy of the data.

Pro Tip: Network latency between your primary and DR site affects write performance if you use synchronous_commit. Test your latency using ping or mtr. If it exceeds 10ms, consider asynchronous replication to avoid killing your app's response time.

2. Infrastructure as Code: The "Phoenix" Server

Data is useless if you don't have a server to host it. In 2020, manual server configuration is negligence. If your primary server melts, you should not be SSH-ing into a blank VPS to apt-get install nginx.

You need Ansible. Your recovery plan is a playbook.

Here is a battle-tested Ansible snippet that ensures your web server environment is identical on your DR node as it is on production. Note the use of variables to handle environment differences.

---
- hosts: dr_servers
  become: yes
  vars:
    nginx_worker_connections: 1024
    domain_name: "coolvds-recovery.example.no"

  tasks:
    - name: Ensure Nginx is installed
      apt:
        name: nginx
        state: present
        update_cache: yes

    - name: Deploy optimized nginx.conf
      template:
        src: templates/nginx.conf.j2
        dest: /etc/nginx/nginx.conf
        validate: 'nginx -t -c %s'
      notify: Restart Nginx

    - name: Ensure sysctl tweaks for high throughput
      sysctl:
        name: "{{ item.key }}"
        value: "{{ item.value }}"
        state: present
      loop:
        - { key: 'net.core.somaxconn', value: '65535' }
        - { key: 'net.ipv4.tcp_tw_reuse', value: '1' }

  handlers:
    - name: Restart Nginx
      service:
        name: nginx
        state: restarted

Running this playbook against a fresh CoolVDS instance takes approximately 90 seconds. Doing it manually takes 45 minutes of stress-induced typing errors.

3. The Storage Bottleneck: Why NVMe Matters

This is where hardware choice dictates RTO. When you trigger a restoration process, your disk I/O hits 100%. You are writing gigabytes of data while simultaneously trying to read it to serve requests.

Standard SATA SSDs top out around 550 MB/s. In a shared VPS environment (the "noisy neighbor" problem), this can drop to 200 MB/s. NVMe drives, which bypass the SATA controller and speak directly to the PCIe bus, deliver speeds over 3000 MB/s.

Real-world math: Restoring a 100GB database dump.

• SATA SSD: ~3-5 minutes (best case).
• CoolVDS NVMe: ~30-45 seconds.

When your e-commerce site is down, those 4 minutes cost significantly more than the monthly price difference of the hosting plan.

4. Essential Health Checks

A DR plan is only valid if you test it. Do not wait for a disaster. Automate these checks.

Check 1: Verify MySQL Replication lag.

Check 2: Ensure the standby server port is open and reachable.

Check 3: Verify IP Failover capability (essential for Floating IPs).

(Should return 1 to allow binding to a floating IP that hasn't routed yet).

Check 4: Check ZFS snapshot integrity (if using ZFS storage).

Check 5: Monitor disk I/O wait to ensure your backup jobs aren't killing production performance.

5. The BorgBackup Strategy for Files

For static assets (images, uploads) that aren't in the database, rsync is fine, but borgbackup is better. It offers deduplication, compression, and authenticated encryption—crucial for GDPR compliance when storing data off-site.

Here is a robust script to push encrypted backups to your CoolVDS storage instance:

#!/bin/bash
# /usr/local/bin/run-backup.sh

export BORG_PASSPHRASE='CorrectHorseBatteryStaple'
REPOSITORY="ssh://user@backup.coolvds.net:22/./backup/repo"

# Backup everything in /var/www
# --stats shows us exactly how much data changed
# --compression lz4 is fast and low-CPU overhead
borg create                         \
    --verbose                       \
    --filter AME                    \
    --list                          \
    --stats                         \
    --show-rc                       \
    --compression lz4               \
    --exclude-caches                \
    $REPOSITORY::'{hostname}-{now}' \
    /var/www/html                   \
    /etc/nginx

# Prune old backups (keep 7 daily, 4 weekly, 6 monthly)
borg prune                          \
    --list                          \
    --prefix '{hostname}-'          \
    --show-rc                       \
    --keep-daily    7               \
    --keep-weekly   4               \
    --keep-monthly  6               \
    $REPOSITORY

Conclusion: Control What You Can

We cannot control the weather in Norway or the routing tables of upstream ISPs. But we can control our stack.

By leveraging modern KVM virtualization for isolation, Ansible for rapid provisioning, and the raw throughput of NVMe storage, you transform disaster recovery from a panic-induced nightmare into a boring, predictable procedure. That is the definition of professional engineering.

Don't let slow I/O be the reason your recovery fails. Deploy a high-availability test environment on CoolVDS today and see the NVMe difference yourself.