Automated Backups: The Only Thing Standing Between You and Unemployment

It is 3:00 AM. Your pager is buzzing. The MySQL database for your client's e-commerce site in Oslo has just been corrupted due to a file system error, or perhaps an intern ran a DROP TABLE in production. If your next move is to pray that the RAID controller saved you, you are already dead. RAID provides redundancy, not recovery. It mirrors corruption just as fast as it mirrors data.

In the Norwegian hosting market, where we pride ourselves on reliability and adherence to strict Datatilsynet standards, manual backups are a liability. I have seen seasoned systems administrators weep because they relied on a "weekly manual tarball" that they forgot to run for a month. Today, we are going to fix this. We will build a bulletproof, automated backup system using tools that have stood the test of time: Bash, Cron, and Rsync.

The Philosophy of "Set It and Forget It" (But Verify It)

The 3-2-1 rule is the holy scripture of data retention:

• 3 copies of your data.
• 2 different media types (e.g., local disk + remote storage server).
• 1 copy off-site (outside your primary datacenter).

For a VPS hosted in Norway, "off-site" implies legal considerations. Under the Personopplysningsloven (Personal Data Act), if you are handling sensitive Norwegian citizen data, you cannot just dump your backups onto a cheap FTP server in the US without jumping through Safe Harbor hoops. You need a secondary location, preferably within the EEA or ideally, a separate datacenter in Norway.

Step 1: Database Consistency is King

Copying /var/lib/mysql while the server is running is a recipe for a broken database. You need a logical dump. If you are running MySQL 5.1 or 5.5 (which you should be on CentOS 6 or Debian Squeeze), locking tables during backup can kill your site's availability.

The solution? InnoDB and --single-transaction. This flag ensures a consistent snapshot without locking the entire database, keeping your shop online.

Pro Tip: Never put your password directly in the command line if you have multi-user shell access; it shows up in ps aux. Create a ~/.my.cnf file with your credentials instead.

Step 2: The Filesystem Snapshot

Once the database is safe, we need the web files. tar is the standard, but plain cp is wasteful. We want incremental backups. However, for a simple nightly rotation, a compressed tarball is portable and easy to verify.

Here is a robust Bash function to handle the compression, ensuring we capture permissions correctly:

#!/bin/bash

# Configuration
BACKUP_ROOT="/var/backups/web"
SOURCE_DIR="/var/www/html"
DATE=$(date +%F_%H-%M)
FILENAME="web_backup_$DATE.tar.gz"

# Ensure backup dir exists
mkdir -p $BACKUP_ROOT

# Compress
echo "Starting backup of $SOURCE_DIR..."
tar -czpf $BACKUP_ROOT/$FILENAME $SOURCE_DIR 2>/dev/null

# Check exit status
if [ $? -eq 0 ]; then
    echo "Backup Success: $FILENAME"
else
    echo "Backup FAILED"
    exit 1
fi

Step 3: Off-Site Replication with Rsync

Local backups save you from accidental deletion. They do not save you from a datacenter fire or a hardware node failure. You need to push this data away. rsync over SSH is the industry standard for secure, bandwidth-efficient transfer.

Assuming you have a secondary storage VPS (CoolVDS offers excellent secondary storage instances in separate availability zones), you exchange SSH keys to allow password-less login.

Now, add this to your script to sync the data. Note the use of the --delete flag, which keeps the remote directory clean, but be careful—it deletes files on the destination that don't exist on the source.

# Sync to remote storage
REMOTE_HOST="user@backup.coolvds.no"
REMOTE_DIR="/home/user/backups/"

rsync -avz -e ssh $BACKUP_ROOT/ $REMOTE_HOST:$REMOTE_DIR

The "CoolVDS" Factor: I/O Wait is the Enemy

Here is the ugly truth about virtualization: Backups are I/O heavy. On a standard budget VPS running on oversold SATA drives, running a tar command or a massive rsync can cause your "Wait I/O" (wa) to spike to 40-50%. This creates a bottleneck that slows down your actual web server, causing 502 errors for your users.

This is where infrastructure matters. At CoolVDS, we utilize enterprise-grade SSD caching and RAID-10 SAS arrays. This high-throughput storage architecture means you can run intensive gzip compression and network transfers without starving your Apache or Nginx processes of disk access. Low latency isn't just about network ping to NIX; it's about disk response time.

Putting It All Together: The Master Script

Let's combine this into a production-ready script you can drop into /etc/cron.daily/.

#!/bin/bash
# /usr/local/bin/nightly_backup.sh
# Author: Sysadmin Ops
# Date: 2011-07-14

# Variables
DB_USER="backup_user"
DB_PASS="secure_password"
BACKUP_DIR="/backup/nightly"
REMOTE_DEST="user@192.168.1.50:/backups/"
RETENTION_DAYS=7

# 1. Prep Directory
mkdir -p $BACKUP_DIR
cd $BACKUP_DIR

# 2. Dump Databases (Compressed on the fly)
for db in $(mysql -u$DB_USER -p$DB_PASS -e 'show databases' -s --skip-column-names); do
    if [ "$db" != "information_schema" ] && [ "$db" != "mysql" ]; then
        mysqldump -u$DB_USER -p$DB_PASS --single-transaction --quick $db | gzip > "$BACKUP_DIR/$db.sql.gz"
    fi
done

# 3. Archive Web Files
tar -czpf "$BACKUP_DIR/www_files_$(date +%F).tar.gz" /var/www/vhosts

# 4. Push Off-site
rsync -avz --bwlimit=2000 -e ssh $BACKUP_DIR $REMOTE_DEST

# 5. Cleanup Local Old Files (Keep 7 days)
find $BACKUP_DIR -type f -mtime +$RETENTION_DAYS -delete

echo "Backup routine completed at $(date)" >> /var/log/backup.log

Automation via Cron

A script is useless if you have to remember to run it. Edit your crontab:

Add the following line to run it every morning at 3:30 AM, a time when traffic in Norway is typically lowest.

Final Thoughts: Trust No One, Verify Everything

Do not assume this works. Tomorrow morning, check /var/log/backup.log. Next week, try to restore a single file from the remote server. A backup that cannot be restored is just a large file taking up expensive disk space.

In the world of Systems Administration, paranoia is a virtue. By leveraging the high-performance storage of CoolVDS and the reliability of simple Linux primitives, you can ensure that when disaster strikes—and it will—you will be the calmest person in the room.

Don't let slow I/O kill your uptime during backup windows. Deploy a test instance on CoolVDS today and experience the stability of true hardware virtualization.