Disaster Recovery in 2018: Why Your "Backup Strategy" Will Fail GDPR Audits

It is 3:00 AM. Your phone buzzes. It’s not a text from a friend; it’s PagerDuty. The primary database node in Oslo just went dark. You log in via SSH—connection timed out. You try the console. Nothing. The silence of a dead server is the loudest sound in the world.

If your plan relies on a nightly tarball stored on the same disk, you are already dead. With the General Data Protection Regulation (GDPR) enforcement date hitting us on May 25th, losing data isn't just an operational failure anymore. It is a legal liability that could cost your company 4% of its global turnover.

I have spent the last decade architecting systems across the Nordics. I've seen simple configuration errors wipe out weeks of work. Today, we are going to look at how to build a Disaster Recovery (DR) plan that actually works in 2018, ensuring data residency in Norway while maintaining uptime.

The Difference Between Backups and Disaster Recovery

Most sysadmins confuse these two.

• Backups are copies of data at a specific point in time. They are for when you accidentally delete a table.
• Disaster Recovery is the plan for when the entire datacenter goes offline or the hardware melts. It focuses on RTO (Recovery Time Objective) and RPO (Recovery Point Objective).

If your boss asks, "How much data will we lose if the server burns down right now?" and your answer is "Since last night," your RPO is 24 hours. In modern e-commerce, that is unacceptable.

The Norwegian Context: Latency and Legality

Here in Norway, we have specific constraints. Datatilsynet is clear about data processor agreements. Hosting your failover node on a cheap VPS in Ohio is a bad idea. Not only does it introduce latency that kills replication, but moving personal data of Norwegian citizens outside the EEA introduces a compliance nightmare under the current Privacy Shield framework.

You need your failover infrastructure to be local. Low latency is critical for synchronous replication. At CoolVDS, we see ping times between major Norwegian ISPs and our infrastructure consistently under 10ms. That allows for near real-time data syncing without locking up your application threads.

Step 1: The Database Layer (MySQL 5.7)

In 2018, MySQL 5.7 is the king of the hill (MySQL 8.0 is promising, but let's stick to stable for production). You shouldn't rely solely on `mysqldump` for DR. You need replication.

However, you still need a raw dump for catastrophic corruption. Here is how you do a proper, consistent dump without locking your tables for minutes:

For the `my.cnf` configuration on your master node, ensure binary logging is enabled and you are using a secure format. Many default VPS images have insecure defaults.

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

Pro Tip: Setting `innodb_flush_log_at_trx_commit = 1` and `sync_binlog = 1` ensures ACID compliance. It impacts I/O heavily. This is why we deploy CoolVDS instances on NVMe storage. On standard SATA SSDs, these settings can tank your write throughput. On NVMe, the latency penalty is negligible.

Step 2: File Synchronization

Don't use FTP. Don't use unencrypted transfer protocols. `rsync` over SSH is the industry standard for a reason. It is robust, it supports resume, and it only transfers deltas.

Here is a script snippet I use to push web content to a DR standby server (e.g., a secondary CoolVDS instance in a different zone):

#!/bin/bash
# Disaster Recovery Sync Script
# Date: 2018-03-14

SOURCE_DIR="/var/www/html/"
REMOTE_USER="dr_user"
REMOTE_HOST="10.20.30.40" # Your CoolVDS Standby IP
REMOTE_DIR="/var/www/html/"
LOG_FILE="/var/log/dr_sync.log"

echo "Starting Sync at $(date)" >> $LOG_FILE

rsync -avz --delete --exclude 'cache/*' --exclude 'logs/*' \
    -e "ssh -i /home/admin/.ssh/id_rsa_dr" \
    $SOURCE_DIR $REMOTE_USER@$REMOTE_HOST:$REMOTE_DIR >> $LOG_FILE 2>&1

if [ $? -eq 0 ]; then
    echo "Sync Successful" >> $LOG_FILE
else
    echo "Sync FAILED - ALERT ADMIN" >> $LOG_FILE
    # In 2018, maybe you hook this into Nagios or Zabbix
fi

Step 3: Virtualization Matters (KVM vs. Containers)

A major pain point in disaster recovery is the kernel. If you are using OpenVZ or LXC (common on budget hosts), you are sharing a kernel with the host. You cannot load specific kernel modules required for advanced block-level replication (like DRBD) or specific firewall rules (ipset).

This is where KVM (Kernel-based Virtual Machine) shines. CoolVDS uses KVM exclusively. This means your virtual machine acts like a dedicated server. You have your own kernel. You can encrypt your disk partitions using LUKS if your compliance officer demands encryption at rest—something nearly impossible to do securely inside a containerized VPS environment.

The "Cold Standby" Approach

If you cannot afford a load balancer and two active nodes, use the Cold Standby method:

1. Spin up a small CoolVDS instance (minimal cost).
2. Configure it with your software stack (Nginx, PHP-FPM 7.2, MySQL).
3. Keep the services stopped to save RAM.
4. Sync data every hour.
5. In an emergency, change DNS A-records (TTL should be low, e.g., 300 seconds) and start the services.

Testing is Everything

A backup is not a backup until you have restored it. I have seen companies lose everything because their `mysqldump` was capturing an empty database due to a permissions error, but the file size looked "about right."

Schedule a "Fire Drill" once a quarter. Spin up a fresh CoolVDS instance and try to bring your application online using only your offsite backups. If it takes you more than 4 hours, your RTO is failing.

Summary

The regulatory landscape in Europe is shifting. By May, GDPR won't be a suggestion; it will be law. Your infrastructure needs to be robust, local, and fast. Don't let slow I/O or shared kernels be the reason your recovery fails.

Need a sandbox to test your recovery scripts? Deploy a high-performance KVM instance on CoolVDS today. Our NVMe storage handles the I/O of strict database replication without breaking a sweat, giving you the peace of mind that your data is safe, compliant, and ready for anything.