When "rm -rf" Meets Reality: A 2021 Guide to Survival
I still wake up in a cold sweat thinking about March 2021. When the OVH data center in Strasbourg caught fire, it wasn't just servers that burned; it was the careers of CTOs who thought "cloud" meant "invincible." If your disaster recovery (DR) plan relies on a single provider's availability zone, you don't have a plan. You have a prayer.
In the Norwegian market, we face a double-edged sword: the technical necessity of low latency to NIX (Norwegian Internet Exchange) and the legal stranglehold of GDPR and Schrems II. You can't just dump your encrypted blobs into an AWS S3 bucket in Virginia anymore. The Datatilsynet (Norwegian Data Protection Authority) is watching, and frankly, so are your customers.
This isn't a high-level fluff piece about "synergy." This is about how we configure CoolVDS instances to survive the worst, using tools available right now in late 2021: WireGuard, BorgBackup, and KVM isolation.
The "3-2-1" Rule is Dead. Long Live "3-2-1-0".
The traditional 3-2-1 rule (3 copies, 2 media types, 1 offsite) is insufficient for modern DevOps. We add a "0": Zero errors on restore.
I recently audited a setup for a client running a high-traffic Magento store. They had backups. Terabytes of them. But when we tried to restore to a staging environment, the InnoDB log sequence numbers were mismatched because they were using raw `cp` on a running database. The Restore Time Objective (RTO) went from 1 hour to 3 days of manual hex-editing. Disaster.
The Architecture of Resilience
Here is the reference architecture we deploy on CoolVDS NVMe instances. We favor NVMe not just for speed, but because during a restore, your disk I/O is the bottleneck. Spinning rust (HDDs) will kill your RTO.
- Primary Node: CoolVDS Instance A (Oslo) - Hosting the App & DB.
- Backup Node: CoolVDS Storage Instance B (Separate physical host/rack) or external provider via SFTP.
- Transport: WireGuard VPN (Kernel level in Linux 5.6+).
- Tooling: BorgBackup (Deduplication is non-negotiable).
Step 1: Secure the Transport with WireGuard
Stop using OpenVPN for backup tunnels. It's too slow and the context switching kills CPU. WireGuard is lean, mean, and built into the kernel of the Ubuntu 20.04 images we run.
On your Primary Node (`/etc/wireguard/wg0.conf`):
[Interface]
PrivateKey =
Address = 10.100.0.1/24
ListenPort = 51820
[Peer]
PublicKey =
AllowedIPs = 10.100.0.2/32
Endpoint = backup.coolvds.net:51820 Pro Tip: Always set your MTU correctly. If you are tunneling over a connection with standard 1500 MTU, set WireGuard to 1420 to account for headers. Fragmented packets during a multi-gigabyte restore will destroy your throughput.
Step 2: Database Consistency is King
You cannot backup a live MySQL/MariaDB file system without locking. If you can't afford downtime, you must use `mysqldump` with a single transaction or Percona XtraBackup.
Here is the snippet we use in our cron jobs. Note the flags specifically for InnoDB integrity:
#!/bin/bash
# DB Backup Script - 2021 Standard
TIMESTAMP=$(date +"%F")
BACKUP_DIR="/var/backups/sql"
MYSQL_USER="backup_user"
MYSQL_PASSWORD="StartUsingVaultOrEnvVarsPlease"
mkdir -p $BACKUP_DIR
# The critical flags:
# --single-transaction: Does not lock InnoDB tables
# --quick: Retrieves rows one by one, saves RAM
# --routines --triggers: Don't forget stored procs!
mysqldump -u$MYSQL_USER -p$MYSQL_PASSWORD \
--all-databases \
--single-transaction \
--quick \
--routines \
--triggers \
--events \
--hex-blob | gzip > "$BACKUP_DIR/db_dump_$TIMESTAMP.sql.gz"
# Verification (The step everyone skips)
if [ -s "$BACKUP_DIR/db_dump_$TIMESTAMP.sql.gz" ]; then
echo "Dump successful: $(du -h $BACKUP_DIR/db_dump_$TIMESTAMP.sql.gz)"
else
echo "Dump FAILED!"
exit 1
fiStep 3: Deduplicated Snapshots with Borg
Rsync is fine for mirroring, but it doesn't give you point-in-time recovery without complex hard-link scripts. BorgBackup handles encryption and deduplication natively. This is crucial for GDPR compliance—if the backup server is compromised, the data is useless without the key.
Initialize the repo on your remote CoolVDS storage instance:
borg init --encryption=repokey user@10.100.0.2:/mnt/storage/backups/repoThen, run the backup. This script mounts the backup procedure:
#!/bin/bash
# /usr/local/bin/run_borg.sh
export BORG_PASSPHRASE="YourVeryLongSecretPassphrase"
REPOSITORY="ssh://user@10.100.0.2/mnt/storage/backups/repo"
# Backup everything except temp files and /proc /sys etc.
echo "Starting Backup to $REPOSITORY"
borg create --verbose --stats --progress \
--compression lz4 \
$REPOSITORY::'{hostname}-{now:%Y-%m-%d-%H%M}' \
/etc \
/var/www \
/var/backups/sql \
--exclude '/var/www/*/var/cache' \
--exclude '/var/www/*/var/log'
# Prune old backups to manage cost
# Keep 7 dailies, 4 weeklies, 6 monthlies
borg prune -v $REPOSITORY \
--keep-daily=7 \
--keep-weekly=4 \
--keep-monthly=6
echo "Backup Complete"The Latency Truth: Why Geography Matters
Why do we insist on running this infrastructure on CoolVDS in Norway? Physics and Law.
| Factor | US Cloud Provider | CoolVDS (Norway) |
|---|---|---|
| Ping to Oslo | 30ms - 120ms | < 5ms |
| Throughput | Metered Egress ($$$) | Unmetered / High Cap |
| GDPR Status | Schrems II Uncertainty | EEA Compliant |
| Disk I/O | Often Shared (Noisy Neighbors) | Dedicated NVMe allocation |
When you are restoring 500GB of data, latency and throughput limitations throttle your recovery. If your "cheap" VPS provider caps your port speed at 100Mbps, your recovery will take 11 hours. On a CoolVDS 1Gbps link with NVMe, that drops to under an hour.
The "Drill"
A backup is Schrödinger's file until you restore it. Every Friday, our internal teams run a "Chaos Monkey" script that spins up a fresh CoolVDS instance via API and attempts to provision the application solely from the Borg repository.
If the script fails, we don't go home.
Security in 2021 isn't just about firewalls; it's about data sovereignty and recoverability. Don't let your infrastructure become a casualty of a bad `rm -rf` command or a legal ruling from Brussels. Secure your data on soil you can trust, with hardware that screams.
Ready to harden your stack? Deploy a high-performance NVMe instance on CoolVDS today and test your restore speeds before you actually need them.