Automated Backups or Die Trying: A Sysadmin’s Guide to Data Survival

Let’s get one thing straight before we even open a terminal: RAID is not a backup.

I cannot tell you how many developers I’ve met in Oslo coffee shops who think their RAID-10 array protects them from data loss. It doesn't. RAID protects uptime. It protects you from physical disk failure. It does absolutely nothing to stop rm -rf /var/www/html, a rogue SQL injection dropping your tables, or a corrupted file system writing garbage across all your mirrored drives simultaneously.

In the world of Server Administration, if your data doesn't exist in three places, it doesn't exist at all. I learned this the hard way back in '09 when a client's legacy ext3 filesystem ate itself due to a kernel panic during a write operation. We spent three days reconstructing customer orders from email logs. Never again.

The Anatomy of a Bulletproof Backup Strategy

In 2011, we don't have magic "cloud" buttons that solve all our problems. We rely on the holy trinity of Unix administration: cron, rsync, and bash. If you are running a business-critical application in Norway, you need a strategy that adheres to the Personopplysningsloven (Personal Data Act). This means you need to know exactly where your data is going. Sending it blindly to a US server might violate Safe Harbor principles if sensitive data is involved.

Here is the workflow we use at CoolVDS for our internal systems:

1. Local Dump: Export databases to a compressed file.
2. Local Archive: Tarball the web root.
3. Encryption: Encrypt the archives (crucial for compliance).
4. Off-site Transfer: Push to a remote storage server.
5. Rotation: Delete old backups to save space.

Step 1: Consistent Database Backups

You cannot just copy the raw MySQL data directory while the server is running. You will end up with corrupted tables. You need mysqldump. If you are using InnoDB (which you should be, MyISAM is archaic), you can perform a hot backup without locking tables using the --single-transaction flag.

Here is a snippet from a standard backup script used on CentOS 5 servers:

#!/bin/bash

# Configuration
DB_USER="root"
DB_PASS="StrictlySecretPassword123"
BACKUP_DIR="/backup/mysql"
DATE=$(date +"%Y-%m-%d")

# Ensure backup directory exists
mkdir -p $BACKUP_DIR

# Get list of databases, exclude system dbs
DATABASES=$(mysql -u $DB_USER -p$DB_PASS -e "SHOW DATABASES;" | grep -Ev "(Database|information_schema)")

for db in $DATABASES; do
  echo "Dumping database: $db"
  mysqldump -u $DB_USER -p$DB_PASS --single-transaction --quick --lock-tables=false $db | gzip > $BACKUP_DIR/$db-$DATE.sql.gz
done

Pro Tip: Never put passwords directly in the script command line if multiple users have shell access, as they can see it in ps aux. Use a .my.cnf file in the user's home directory instead.

Step 2: The Power of Rsync

Once you have your database dumps and your web files tarred, you need to get them off the server. rsync is efficient because it only transfers the deltas (changes). This is vital if you are pushing backups from Oslo to a secondary location in Bergen or Frankfurt over a limited uplink.

A robust rsync command looks like this:

rsync -avz -e "ssh -p 2222" --delete /backup/ user@backup-server.coolvds.net:/home/user/backups/

Let's break down those flags:

• -a: Archive mode (preserves permissions, owners, groups).
• -v: Verbose (so you can see what failed in the logs).
• -z: Compress during transfer (saves bandwidth).
• -e "ssh -p 2222": Use SSH on a custom port. Security through obscurity isn't security, but it reduces log noise from bots.
• --delete: If a file is deleted locally, delete it remotely. Be careful with this. I usually prefer rotation scripts on the remote end.

Step 3: Rotation and Retention

Disk space is not infinite, even with the competitive pricing on CoolVDS managed hosting plans. You need a retention policy. A common standard is keeping daily backups for 7 days, weekly backups for 4 weeks, and monthly backups for 6 months.

You can use the find command to clean up old files locally:

# Delete backups older than 7 days
find /backup/mysql -type f -name "*.sql.gz" -mtime +7 -exec rm {} \;

The Infrastructure Factor: Why CoolVDS?

Scripting is only half the battle. The other half is the infrastructure. You can write the perfect backup script, but if your I/O throughput is choked by "noisy neighbors" on a cheap oversold VPS, your backups will cause load spikes that take your website down every night at 3 AM.

This is why CoolVDS utilizes KVM virtualization. Unlike OpenVZ, where resources are often shared loosely, KVM provides stricter isolation. When we provision a slice with fast SAS RAID-10 storage or our new high-performance SSD tier, that I/O is yours. This means your tar and gzip operations finish in minutes, not hours.

Furthermore, for our Norwegian clients, we offer low-latency connectivity within the Scandinavian region. Backing up data between our data centers is lightning fast, ensuring your transfer window is short and your compliance with Datatilsynet guidelines is solid.

Security and Compliance Check

Final Thoughts

Automation is the difference between a panicked 3 AM phone call and a minor inconvenience. Do not wait for a disk failure or a hacker to test your recovery strategy.

If you need a reliable environment to test your disaster recovery scripts, or if you are tired of sluggish I/O killing your backup windows, it’s time to upgrade.

Don't let slow I/O kill your SEO or your sleep. Deploy a high-performance instance on CoolVDS today and sleep soundly knowing your data is safe.