The Paranoia of Persistence: Why Your RAID Array Won't Save You

It is 3:00 AM. Your pager buzzes. The RAID controller on your primary database server has panicked, and the filesystem is reporting corruption. If your stomach just dropped reading that, it's because you know the golden rule of systems administration: RAID is redundancy, not backup.

In the Norwegian hosting market, where we pride ourselves on stability and adherence to the Personopplysningsloven (Personal Data Act), relying solely on hardware redundancy is professional negligence. I have seen seasoned SysAdmins weep over a `rm -rf` command executed in the wrong window. No amount of RAID 10 mirroring recovers a deleted file.

At CoolVDS, we engineer our infrastructure with high-performance Enterprise SAS and early-generation SSD caching for speed, but we explicitly tell our clients: You are responsible for your data integrity. Here is how to build a backup strategy that actually works in 2010.

1. The Anatomy of a Robust Backup Script

Forget manual FTP transfers. If it requires a human, it will fail. You need a Bash script, a cron job, and a remote destination.

The standard tool for this remains rsync. It is efficient, handles incremental changes delta-transfer, and works seamlessly over SSH. Below is a production-ready snippet we use for CentOS 5.5 environments:

#!/bin/bash
# /usr/local/sbin/daily_backup.sh

DATE=$(date +"%Y-%m-%d")
BACKUP_DIR="/var/backups/daily/$DATE"
REMOTE_HOST="backup.coolvds.net"
REMOTE_USER="user123"

# Ensure local directory exists
mkdir -p $BACKUP_DIR

# 1. System Configs
tar -czf $BACKUP_DIR/etc.tar.gz /etc

# 2. Web Data (incorporating rsync for bandwidth efficiency)
rsync -avz --delete /var/www/html/ $BACKUP_DIR/www/

# 3. Ship it offsite securely
rsync -avz -e "ssh -p 22" $BACKUP_DIR $REMOTE_USER@$REMOTE_HOST:~/backups/

# Log result
logger "Backup for $DATE completed."

Pro Tip: Always use SSH keys (ssh-keygen -t rsa) without passphrases for automation, but restrict the key's capabilities in the `authorized_keys` file on the receiving end using the `command="..."` option to prevent security breaches.

2. The MySQL Locking Nightmare

Backing up a running database is where most scripts fail. If you just copy the `/var/lib/mysql` directory while the server is running, you will get corrupt tables. Guaranteed.

For MyISAM tables (still the default in many MySQL 5.0/5.1 installs), you must lock tables. For InnoDB, you can perform a hot backup. Know your storage engine.

# For InnoDB (Non-blocking)
mysqldump --user=root --password=$PASS --all-databases --single-transaction | gzip > $BACKUP_DIR/db_dump.sql.gz

# For MyISAM (Blocking - run this at 4 AM!)
mysqldump --user=root --password=$PASS --all-databases --lock-tables | gzip > $BACKUP_DIR/db_dump.sql.gz

If you are running a high-traffic e-commerce site (like Magento or osCommerce), the locking time on MyISAM can cause timeouts. This is why we advocate moving to InnoDB where possible, despite the higher RAM footprint.

3. The "3-2-1" Rule and Geographic Redundancy

A backup on the same physical disk is useless. A backup in the same datacenter is risky. You need the 3-2-1 strategy:

• 3 copies of your data.
• 2 different media types (e.g., Server Disk and Tape/Remote Storage).
• 1 copy offsite.

For our Norwegian clients, data sovereignty is critical under the Data Protection Directive (95/46/EC). You cannot just dump customer data onto a US-based S3 bucket without navigating Safe Harbor complexities. The safest route? Replicate your backups to a secondary Norwegian facility.

4. Network Performance: Don't Choke Your Pipe

Running a backup during peak hours (18:00 - 22:00 CET) will kill your web server's latency. While rsync has a --bwlimit flag, a better architectural decision is to use a private network interface.

At CoolVDS, every instance comes with a public interface (eth0) and a private backend interface (eth1). We recommend configuring your backups to run over eth1. This ensures that your massive 50GB file transfer doesn't saturate the public line connected to NIX (Norwegian Internet Exchange), keeping your site snappy for visitors in Oslo and Bergen.

Testing is Not Optional

An untested backup is Schrödinger's Backup: it exists and doesn't exist simultaneously until you try to restore it. Once a month, perform a "Fire Drill." Spin up a fresh CoolVDS instance and attempt to restore your system from your backups. If it takes you longer than 4 hours to recover, your script needs work.

Disaster strikes when you least expect it. Don't let a hard drive failure become a business failure. Secure your data with a compliant, automated strategy today.