Disaster Recovery in the GDPR Era: Surviving Data Loss and Compliance Audits in 2018

It is May 2018. The GDPR enforcement deadline is less than a month away, and panic is setting in across IT departments from Oslo to Bergen. While everyone is frantically updating privacy policies and cookie banners, a critical aspect of the regulation is being dangerously overlooked: Availability.

Article 32 of the GDPR explicitly mandates the "ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident." If your server melts down and you lose customer data, you aren't just facing downtime; you are facing fines from Datatilsynet (The Norwegian Data Protection Authority). As a CTO, I don't rely on hope. I rely on cold, hard replication and verifiable backups.

Most VPS providers will sell you a "backup solution" that is nothing more than a snapshot stored on the same SAN as your production disk. If that storage array fails, your data and your backups vanish simultaneously. That is not a disaster recovery plan; that is a suicide pact. Here is how we architect resilience using standard tools available today on CoolVDS infrastructure.

The 3-2-1 Rule: Updated for 2018

The classic rule still applies: Keep 3 copies of your data, on 2 different media types, with 1 copy offsite. In the context of a Norwegian VPS environment, this translates to:

• Copy 1: Production data (Running on high-performance NVMe).
• Copy 2: Local snapshot/backup (Stored on a separate storage server within the same datacenter for fast restoration).
• Copy 3: Remote replica (Stored in a geographically distinct location, preferably another Norwegian city or a secure EU facility to maintain EEA compliance).

Pro Tip: Latency matters for replication. If your primary server is in Oslo, a secondary site in Stockholm or Amsterdam offers a good balance between ping times (essential for async replication lag) and geographical separation. CoolVDS's peering at NIX (Norwegian Internet Exchange) ensures that data transfer within the region remains exceptionally fast.

Efficient Encrypted Backups with BorgBackup

Gone are the days where we simply `tar` and `gzip` entire directories. That consumes too much CPU and bandwidth. In 2018, the tool of choice for Linux systems is BorgBackup. It offers deduplication, compression, and—crucially for GDPR—authenticated encryption.

If you are running the newly released Ubuntu 18.04 LTS (Bionic Beaver), Borg is available directly in the repositories. Here is how you initialize a secure, encrypted backup repository on a mounted external volume or remote server.

1. Initializing the Repository

2. The Daily Backup Script

Do not run commands manually. Automate them. Here is a production-ready bash snippet that backs up your `/etc` and `/var/www` directories, pruning old archives automatically to save space.

#!/bin/bash

# Configuration
REPOSITORY="/mnt/backup/my-repo"
LOG="/var/log/borg-backup.log"

# Export the passphrase for automation (secure this file with chmod 600!)
export BORG_PASSPHRASE="Correct-Horse-Battery-Staple-2018"

# 1. Create the backup
echo "Starting backup at $(date)" >> $LOG
borg create --stats --compression lz4 \
    $REPOSITORY::'{hostname}-{now:%Y-%m-%d_%H:%M}' \
    /etc /var/www /home \
    --exclude '*.tmp' \
    --exclude '/var/www/*/cache' >> $LOG 2>&1

# 2. Prune old backups (Keep 7 dailies, 4 weeklies, 6 monthlies)
echo "Pruning old archives" >> $LOG
borg prune -v $REPOSITORY \
    --keep-daily=7 \
    --keep-weekly=4 \
    --keep-monthly=6 >> $LOG 2>&1

# 3. Sync to offsite (Optional: using rsync to a remote disaster site)
# rsync -avz -e ssh /mnt/backup/my-repo user@backup-server.coolvds.net:/backups/

This script uses LZ4 compression, which is incredibly fast and has minimal CPU overhead—perfect for production servers where you don't want the backup process to degrade web performance.

Database Consistency: The Hidden Trap

File-level backups are useless if your database is in an inconsistent state during the copy. For MySQL (or MariaDB 10.2, which is standard on CentOS 7), you have two main options: mysqldump for logical backups or binary log replication for near-real-time recovery.

Configuring Master-Slave Replication

For a Recovery Point Objective (RPO) of near-zero, you need replication. If your main node dies, the slave is ready. However, you must configure `my.cnf` correctly to ensure the binary logs don't eat all your disk space.

Edit `/etc/mysql/my.cnf` (or `/etc/my.cnf` on RHEL/CentOS systems):

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

# Safety net: Ensure InnoDB survives crashes
innodb_flush_log_at_trx_commit = 1
sync_binlog = 1

Setting sync_binlog = 1 and innodb_flush_log_at_trx_commit = 1 is the safest configuration for data integrity (ACID compliance), though it introduces a slight I/O penalty. On standard spinning rust, this hurts. However, CoolVDS instances run on enterprise NVMe storage, which handles the increased IOPS requirement of these settings without breaking a sweat. This is where hardware choice dictates software configuration.

The CoolVDS Advantage: KVM vs. OpenVZ

When planning for disaster recovery, the underlying virtualization technology is paramount. Many budget hosts use OpenVZ or LXC. While efficient, these container-based technologies share the host kernel. If the host kernel panics, everyone goes down. Furthermore, you cannot load your own kernel modules for specific backup file systems or encryption tools.

At CoolVDS, we utilize KVM (Kernel-based Virtual Machine). This provides full hardware virtualization. Why does this matter for DR?

1. Kernel Independence: If another tenant crashes their kernel, your instance keeps running.
2. Block-Level Snapshots: We can take consistent snapshots of your entire virtual disk at the block level, ensuring that even if your OS is corrupted during an update (looking at you, `yum update`), we can roll back the entire machine state.
3. Custom ISOs: In a total disaster scenario, you can mount a rescue ISO (like SystemRescueCd) via our VNC console to repair filesystems manually.

Testing: The Step You Skip

A backup is not a backup until you have successfully restored from it. The "Schrödinger's Backup" states that the condition of any backup is unknown until a restore is attempted.

Set a calendar reminder for once a quarter. Spin up a fresh, small CoolVDS instance (our hourly billing makes this cost cents). Run your restore script. Does the application boot? Is the database consistent? If yes, terminate the instance. If no, you just saved your company from a future catastrophe.

In the regulatory landscape of 2018, "I thought the backup was working" is not a valid legal defense. Ensure your data stays within Norwegian or EEA borders, encrypt everything at rest, and test your recovery paths.

Is your current hosting provider GDPR-ready and resilient? Stop gambling with compliance. Deploy a high-availability KVM instance on CoolVDS today and sleep soundly knowing your data is safe.