The Parity Bit Will Not Save You

Let’s get one thing straight immediately: RAID is not a backup.

I cannot count the number of times I have walked into a datacenter (or an IRC channel) and heard a developer claim their data is safe because they are running RAID-10. RAID provides redundancy against hardware failure. It keeps the site online when a drive spins its last rotation. But RAID mirrors everything—including the moment you accidentally type rm -rf /var/www/html/ or when a SQL injection drops your users table.

If you are managing servers in 2012, you need an automated, versioned, and offsite backup strategy. And if you are hosting here in Norway, you need to do it while keeping Datatilsynet (The Data Protection Authority) happy. We are going to build a bulletproof backup system using tools that have stood the test of time: Bash, Cron, and Rsync.

The 3-2-1 Rule: The Gold Standard

Before we touch the command line, we adhere to the philosophy. The 3-2-1 rule is simple but non-negotiable for professional environments:

• 3 copies of your data (Production + 2 Backups).
• 2 different media types (e.g., Disk on server, Tape/External Storage).
• 1 copy offsite (This is where CoolVDS shines).

In the context of a VPS, "Media Types" usually means your local filesystem and a remote storage server. Do not store your backups on the same physical node as your VM. If the host node has a catastrophic failure, your production data and your backups die together.

Step 1: Database Consistency (MySQL/PostgreSQL)

You cannot just copy the /var/lib/mysql directory while the server is running. You will end up with corrupted tables. You need a logical dump. For high-traffic Magento or Drupal sites running on InnoDB, we need to ensure we don't lock the tables during the backup.

Here is a robust Bash script for CentOS 6 or Debian Squeeze that handles rotation automatically:

#!/bin/bash
# /root/scripts/automysqlbackup.sh

# Configuration
DB_USER="root"
DB_PASS="SuperSecretPassword123"
BACKUP_DIR="/var/backups/mysql"
DATE=$(date +"%Y-%m-%d_%H%M")
RETENTION=7

# Create directory if not exists
mkdir -p $BACKUP_DIR

# Dump all databases
# --single-transaction is CRITICAL for InnoDB to avoid locking tables
# --routines ensures stored procedures are saved
echo "Starting backup for $DATE..."
mysqldump -u$DB_USER -p$DB_PASS --all-databases --single-transaction --routines --triggers | gzip > "$BACKUP_DIR/db_backup_$DATE.sql.gz"

# Verification
if [ $? -eq 0 ]; then
    echo "Database backup successful: db_backup_$DATE.sql.gz"
else
    echo "ERROR: Database backup failed!"
    exit 1
fi

# Rotation: Delete backups older than 7 days
find $BACKUP_DIR -name "db_backup_*.sql.gz" -mtime +$RETENTION -exec rm {} \;
echo "Old backups cleaned up."

Make sure to chmod 700 this script. You do not want other users on the system reading your root database password.

Pro Tip: If you are running MyISAM tables (which you shouldn't be in 2012, switch to InnoDB), the --single-transaction flag won't help you. You will experience table locks. This is why performance obsessives choose CoolVDS instances tuned for InnoDB buffering—write speeds matter during dumps.

Step 2: File System Synchronization with Rsync

Now that the database is dumped to a file, we need to ship it (and your web files) offsite. FTP is insecure and slow. SCP is secure but doesn't handle differential transfers well. Rsync is the only professional choice here.

Rsync only transfers the "deltas" (changes). If you have a 10GB image library and only add 5MB of photos today, rsync only sends 5MB. This saves massive amounts of bandwidth and reduces the backup window.

Here is how to sync your webroot and your database dumps to a remote backup server:

rsync -avz -e "ssh -p 22" --delete /var/www/html/ /var/backups/mysql/ backupuser@remote.storage-server.no:/home/backupuser/server1/

Understanding the Flags

Step 3: Automating with Cron

A script you have to run manually is a script you will forget to run. We add this to the crontab.

Edit the crontab: crontab -e

# Run Daily at 3:00 AM (Low traffic time in Norway)
0 3 * * * /root/scripts/automysqlbackup.sh >> /var/log/backup_db.log 2>&1

# Sync to offsite storage at 3:30 AM
30 3 * * * /root/scripts/offsite_sync.sh >> /var/log/backup_rsync.log 2>&1

The Norwegian Context: Latency and Legality

In Norway, we have the Personopplysningsloven (Personal Data Act). While Safe Harbor allows data transfer to the US, many Norwegian sysadmins prefer keeping data within the EEA (European Economic Area) or specifically within Norway to satisfy strict Datatilsynet requirements regarding sensitive data handling.

This is where physical location impacts technical performance. If your backup server is in Texas and your VPS is in Oslo, your rsync is going to crawl due to TCP windowing limits over high latency. You want your offsite backup to be geographically separate (fire safety) but topologically close (network speed).

Hosting with CoolVDS means you are plugging directly into the Nordic infrastructure. Our connectivity to NIX (Norwegian Internet Exchange) ensures that if you are rsyncing to a backup server in a neighboring Norwegian datacenter, you are getting sub-5ms latency and maximum throughput. Don't let your backup window bleed into business hours because of a slow Atlantic crossing.

Hardware Matters: The I/O Bottleneck

Running backups is I/O intensive. mysqldump reads the entire database. gzip crushes the CPU. If you are on a cheap VPS provider that oversells their mechanical hard drives, your website will slow down while the backup runs. This is "IO Wait" and it is the silent killer of performance.

This is why CoolVDS utilizes high-performance SSD storage arrays. While mechanical SAS drives are still industry standard for bulk storage, our use of Solid State technology for compute instances means your backups complete in minutes, not hours. The random read/write speeds of SSDs allow your database to serve customers while simultaneously dumping data to disk.

Conclusion

Recovery is not about if, but when. A RAID array protects uptime; a backup protects your business. By implementing the scripts above, you move from "hoping" your data is safe to knowing it is.

Do not wait for a disk failure to test your recovery plan. Deploy a high-speed SSD VPS with CoolVDS today, configure your rsync keys, and sleep soundly knowing your data is safe, secure, and right here in Norway.