Why Your RAID Array Won't Save You From Yourself
There are two types of system administrators: those who have lost data, and those who are about to. If you are relying solely on your hosting provider's RAID 10 array to save you, you are playing Russian Roulette with your business. RAID provides redundancy against disk failure; it provides zero protection against file corruption, malicious hacks, or the dreaded accidental rm -rf /var/www.
As we settle into 2012, the toolset for Linux automation is robust, yet I still see Senior Devs manually FTPing tarballs. Stop it. Here is how we build a set-and-forget backup architecture that respects both your uptime and the Norwegian Personal Data Act.
The 3-2-1 Rule Still Applies
The golden rule of backups hasn't changed. You need:
- 3 copies of your data.
- 2 different media types (e.g., your live VPS disk and a remote storage server).
- 1 copy off-site (outside the primary datacenter).
At CoolVDS, we see clients hosting critical Magento and Drupal sites without off-site redundancy. Even though our datacenter in Oslo is built like a fortress with redundant power feeds, a logical error in your application can wipe your data instantly. You need a snapshot that sits somewhere else.
Scripting the Solution: Rsync & Cron
Don't buy expensive enterprise backup software when rsync exists. It is efficient, handling delta transfers so you only move changed bits. This is crucial if you are pushing gigabytes of data over the wire.
Here is a battle-tested Bash snippet for a nightly backup rotation. It creates a dated archive and removes backups older than 7 days to save space.
#!/bin/bash
# Simple Backup Rotation Script
TIMESTAMP=$(date +"%F")
BACKUP_DIR="/backup/$TIMESTAMP"
MYSQL_USER="root"
MYSQL_PASS="your_password"
# Create directory
mkdir -p $BACKUP_DIR
# 1. Dump Databases
# Using --single-transaction for InnoDB ensures no locking
echo "Dumping MySQL..."
mysqldump -u$MYSQL_USER -p$MYSQL_PASS --all-databases --single-transaction | gzip > $BACKUP_DIR/db_dump.sql.gz
# 2. Archive Web Files
echo "Archiving Files..."
tar -czf $BACKUP_DIR/www_files.tar.gz /var/www/html
# 3. Push to Remote Server (Off-site)
# Requires SSH keys setup between servers
rsync -avz -e ssh $BACKUP_DIR [email protected]:/var/backups/coolvds-node/
# 4. Cleanup local old backups (older than 7 days)
find /backup/* -mtime +7 -exec rm -rf {} \;Pro Tip: If you are running high-traffic MySQL databases (MyISAM engine), mysqldump will lock your tables, causing site downtime. Convert your tables to InnoDB or use a master-slave replication setup where you backup from the slave.Data Sovereignty: The Norwegian Context
If you are handling customer data in Norway, you are bound by the Personopplysningsloven (Personal Data Act). The Data Inspectorate (Datatilsynet) is increasingly strict about where data lives.
Sending your backups to a cheap storage bucket in the US might violate Safe Harbor frameworks if sensitive personal ID numbers (fødselsnummer) are involved. The safest route is keeping your primary data and your backup data within Norwegian borders, or at least within the EEA.
This is where network topology matters. CoolVDS infrastructure is peered directly at NIX (Norwegian Internet Exchange). If you push your backups to another Norwegian provider or your office in Oslo, the latency is practically non-existent (often under 2ms). High latency connections cause rsync to hang on large file lists, leading to "backup drift" where the backup never finishes before the next cron job starts.
Snapshotting vs. File-Level Backup
Filesystem backups are great, but full system recovery takes time. You have to reinstall the OS, install Apache/Nginx, configure PHP, and then restore files.
For faster RTO (Recovery Time Objective), you should leverage the virtualization layer. Because CoolVDS is built on KVM (Kernel-based Virtual Machine), not the older shared-kernel OpenVZ, we can offer full block-level snapshots. This freezes your entire server state—kernel, OS, and data—in time.
While scripts are good for granular file recovery (e.g., "I deleted one image"), snapshots are for disaster recovery (e.g., "The server was hacked"). A pragmatic CTO uses both.
The "Check Your Restore" Drill
A backup is not a backup until you have successfully restored from it. Set a calendar reminder for the first Monday of every month. Spin up a fresh test VPS—CoolVDS instances provision in about 55 seconds—and attempt to restore your data. If it takes you 4 hours to figure out the restoration process, that is 4 hours of downtime you can't afford during a real emergency.
Don't let a simple script failure destroy your reputation. Automate it, test it, and keep your data close.