Disaster Recovery in 2025: Architecting Resilience for Norwegian Infrastructure
The silence after a ping timeout is the loudest sound in a sysadmin's career. It’s 03:14 AM. Your primary data center in Oslo just went dark. Is it a fiber cut? A ransomware encryption underway? Or did the interns trip over the main breaker?
It doesn't matter. What matters is your RTO (Recovery Time Objective). If you are reading this during an outage, it's already too late. Close this tab and start updating your resume.
If you are reading this while your green lights are blinking steadily, we have work to do. Most VPS providers sell you "uptime SLAs" that amount to a partial refund on your monthly bill. A refund doesn't restore your reputation or recover the 400 GB of customer data required by the Norwegian Accounting Act (Bokføringsloven).
Let's strip away the buzzwords and build a Disaster Recovery (DR) plan that actually functions when the world is burning.
The Geopolitical & Legal Reality: Why Location Matters
In 2025, you cannot simply dump your encrypted archives into an AWS S3 bucket in Virginia and call it a day. Post-Schrems II and the subsequent data privacy frameworks, European data needs to stay in Europe. For Norwegian businesses, keeping data within the borders isn't just patriotism; it's often a compliance necessity dictated by Datatilsynet.
When we architect infrastructure at CoolVDS, we see a distinct pattern: smart CTOs use a split-site strategy. Primary workload in Oslo (low latency via NIX), and a "warm" DR site in a geographically distinct Norwegian facility or a highly compliant Nordic neighbor. This satisfies the 3-2-1 backup rule while keeping latency low enough for synchronous or near-synchronous replication.
The Filesystem Layer: Immutable Snapshots
`rsync` is great, but it's not a DR strategy. If a ransomware script hits your server and you run a cron job to sync, you just synced the encrypted garbage to your backup server. Congratulations, you are now doubly ransomwared.
You need versioned, deduplicated, and ideally immutable backups. In 2025, BorgBackup (or Restic) remains the gold standard for Linux environments. It’s efficient, encrypted, and mountable.
Implementation: Borg over SSH
Do not pull backups from the production server. Push them to the backup server, or better yet, have the backup server pull them (pull-mode) to isolate credentials. Here is a robust setup for a push-mode configuration to a storage instance:
# On the production server (the client)
# 1. Initialize the repo (do this once)
borg init --encryption=repokey user@backup-node.coolvds.com:/var/backups/prod-repo
# 2. The Daily Backup Script
#!/bin/bash
export BORG_PASSPHRASE='CorrectHorseBatteryStaple2025'
# Create the archive
borg create \
--verbose \
--filter AME \
--list \
--stats \
--show-rc \
--compression lz4 \
--exclude-caches \
user@backup-node.coolvds.com:/var/backups/prod-repo::{hostname}-{now:%Y-%m-%d} \
/etc \
/var/www/html \
/var/lib/docker/volumes
# Prune old backups (Keep 7 dailies, 4 weeklies, 6 monthlies)
borg prune \
--list \
--prefix '{hostname}-' \
--show-rc \
--keep-daily 7 \
--keep-weekly 4 \
--keep-monthly 6 \
user@backup-node.coolvds.com:/var/backups/prod-repo
Pro Tip: Store your Borg passphrase in a password manager, not just in the script. Better yet, use `pass` or a secure vault injection during the cron execution.
The Database Layer: Real-Time Replication
Filesystem backups cover your assets, but databases need consistency. Dumping a 50GB database with `mysqldump` locks tables and kills performance. For a warm standby, you need Master-Slave replication.
However, exposing MySQL (port 3306) over the public internet is suicide. We use WireGuard to create a secure, private mesh between your production server and your CoolVDS DR node. WireGuard kernel support is standard in Linux 6.x+, making it incredibly fast compared to OpenVPN.
Step 1: The Tunnel (WireGuard)
Production (Interface wg0): 10.10.0.1
DR Node (Interface wg0): 10.10.0.2
# /etc/wireguard/wg0.conf on DR Node
[Interface]
PrivateKey =
Address = 10.10.0.2/24
ListenPort = 51820
[Peer]
PublicKey =
AllowedIPs = 10.10.0.1/32
Endpoint = prod.example.com:51820
PersistentKeepalive = 25
Step 2: MySQL Configuration
On the Master (Production), enable binary logging. In 2025, GTID (Global Transaction ID) is the only sane way to manage replication.
# /etc/mysql/my.cnf (Production)
[mysqld]
bind-address = 10.10.0.1 # Bind to WireGuard IP only
server-id = 1
log_bin = /var/log/mysql/mysql-bin.log
binlog_format = ROW
gtid_mode = ON
enforce_gtid_consistency = ON
expire_logs_days = 7
This setup ensures that your DR node at CoolVDS receives data changes milliseconds after they happen in production. If the primary node melts, you can promote the slave to master with a single command.
Infrastructure as Code (IaC): The Resurrection Kit
Having the data is useless if you don't have the machine to run it. If you are clicking around in a web panel to reinstall Nginx and PHP during an outage, you have already failed.
You should have a Terraform plan or an Ansible playbook ready to provision a fresh environment. At CoolVDS, we expose a standard KVM API that interacts perfectly with these tools.
Here is a snippet of an Ansible playbook that restores a web server state:
---
- name: Restore Web Environment
hosts: dr_site
become: yes
tasks:
- name: Install Nginx & PHP-FPM
apt:
name:
- nginx
- php8.3-fpm
- php8.3-mysql
state: present
update_cache: yes
- name: Tuning sysctl 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' }
- name: Pull latest config from git
git:
repo: 'git@github.com:yourcompany/configs.git'
dest: /etc/nginx/sites-available/
The Storage Bottleneck
Recovery speed is dictated by I/O. Restoring a 500GB database dump on a spinning HDD or a throttled "cloud" disk can take 8 to 10 hours. This is why underlying hardware matters.
We built CoolVDS on pure NVMe arrays not just for the "snappiness" of your WordPress admin panel, but for this exact scenario. When you pipe a `zcat backup.sql.gz | mysql` command, the bottleneck should be the CPU decompression, not the disk write speed. Our benchmarks show sustained write speeds that allow for massive restorations in minutes, drastically cutting your RTO.
The Fire Drill
A DR plan that hasn't been tested is a hallucination. You must schedule "Game Days." Once a quarter, actually shut down the production interface. Spin up the CoolVDS DR node. Switch the DNS A records (set TTL to 60 seconds beforehand).
Does the application load? Are the session handlers working? Is the replication lag zero? Document the failures. Fix them.
Disaster recovery isn't a product you buy; it's a discipline you practice. But having a partner like CoolVDS, who understands the specific latency and compliance needs of the Nordic market, provides the bedrock upon which that discipline is built.
Don't wait for the inevitable hardware failure. Deploy a high-performance DR node on CoolVDS today and sleep through the next thunderstorm.