The "rm -rf" Nightmare: Why Manual Backups Are Suicide in 2012

It’s 4:00 PM on a Friday. A junior developer issues a command to clear a cache directory, but a misplaced space turns rm -rf /tmp/cache / into a resume-generating event. In milliseconds, the inode table begins to vanish. If your strategy relies on "I'll remember to FTP the files this weekend," you are already dead. I have seen grown men weep in server rooms because they trusted a RAID-5 array as a backup solution. Let’s be clear: RAID is redundancy, not backup.

In the Nordic hosting market, where we pride ourselves on stability and adherence to the Personopplysningsloven (Personal Data Act), losing customer data isn't just an inconvenience; it's a visit from Datatilsynet. Today, we are going to stop playing with fire. We are going to build a bulletproof, automated backup system using tools that have stood the test of time: rsync, mysqldump, and Cron.

The 3-2-1 Rule: Non-Negotiable

Before we touch the command line, understand the architecture. If your data doesn't exist in three places, it doesn't exist.

• 3 Copies of Data: The production data, a local backup, and a remote backup.
• 2 Different Media: Disk and tape (or in modern VPS terms, your primary virtual disk and a separate storage mount).
• 1 Offsite Copy: If the datacenter in Oslo floods or loses power, your data must be safe in Bergen or Frankfurt.

At CoolVDS, we see clients deploying single instances without secondary storage every day. It is terrifying. High-performance SSD storage (often marketed as the future of I/O) is great for speed, but if the filesystem corrupts, speed won't save you.

Phase 1: The Database (MySQL/PostgreSQL)

Files are easy. Databases are hard. If you simply copy the /var/lib/mysql directory while the server is running, you will end up with corrupted, inconsistent tables. You need a logical dump.

For MySQL (the standard on our CentOS 6 and Ubuntu 12.04 images), you must use mysqldump. However, the default command locks your tables, killing your site's performance during the backup. The fix? The --single-transaction flag for InnoDB tables.

The Backup Script

Create a script at /root/scripts/db_backup.sh:

#!/bin/bash

# Configuration
DB_USER="root"
DB_PASS="StrongPassword123"
BACKUP_DIR="/backup/mysql"
DATE=$(date +%F_%H-%M)

# 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|performance_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

# Retention: Delete backups older than 7 days
find $BACKUP_DIR -type f -name "*.sql.gz" -mtime +7 -exec rm {} \;

Pro Tip: Ensure your my.cnf is tuned. If your innodb_buffer_pool_size is too small, this dump process will cause I/O thrashing, slowing down your web server. On CoolVDS instances, we recommend allocating 60-70% of RAM to the buffer pool if it's a dedicated database server.

Phase 2: The Filesystem (Rsync)

For your web files (/var/www or /home), tar is acceptable, but rsync is superior because it supports incremental transfers. We want to ship these files to a remote server. This is critical for disaster recovery.

We will use SSH keys for password-less authentication. If you haven't generated a key pair yet:

ssh-keygen -t rsa -b 4096
ssh-copy-id user@backup-server.coolvds.net

Now, the synchronization script /root/scripts/file_sync.sh:

#!/bin/bash

SOURCE_DIR="/var/www/html"
REMOTE_USER="backupuser"
REMOTE_HOST="192.168.1.50"
REMOTE_DIR="/home/backupuser/backups/"

# The --delete flag removes files on destination that no longer exist on source.
# BE CAREFUL with this.
rsync -avz -e ssh --delete $SOURCE_DIR $REMOTE_USER@$REMOTE_HOST:$REMOTE_DIR

The -z flag compresses data during transfer, which is vital if you are pushing gigabytes across the wire, though with the low latency we see within Norwegian networks, throughput is rarely the bottleneck.

Phase 3: Automation via Cron

A script that isn't run is useless. We add these to the root crontab. Run crontab -e:

# Run database backup every day at 2:00 AM (Low traffic time)
0 2 * * * /bin/bash /root/scripts/db_backup.sh >> /var/log/db_backup.log 2>&1

# Run remote file sync at 3:00 AM
0 3 * * * /bin/bash /root/scripts/file_sync.sh >> /var/log/file_sync.log 2>&1

The Infrastructure Factor

Scripts are powerful, but the underlying hardware dictates reliability. In 2012, we are seeing a shift. Traditional spinning rust (HDD) struggles with the random I/O required during a heavy backup process. This is where CoolVDS separates itself from budget hosting.

We utilize enterprise-grade SSD storage in RAID-10 configurations. Why? Because when mysqldump is reading millions of rows, you don't want your website's load time to spike to 5 seconds. SSDs handle the read operations effortlessly while serving live traffic. Furthermore, our KVM virtualization ensures that your resources are truly isolated—no "noisy neighbors" stealing your I/O cycles during their own backup windows.

A Note on Compliance (Norway & Europe)

If you are hosting data for Norwegian citizens, you are bound by the Personopplysningsloven. Storing backups on servers located outside the EEA (European Economic Area) without Safe Harbor compliance is a legal minefield. CoolVDS infrastructure is located locally or within strictly compliant European zones, ensuring low latency to Oslo and full legal adherence.

Final Thoughts

Automation is the only way to sleep at night. But remember: a backup is not successful until you have successfully restored from it. Dedicate one day a month to a "Fire Drill." Spin up a fresh CoolVDS instance and try to restore your application using only your backup files. If it fails, fix the script.

Don't wait for a hardware failure or a hacker to teach you this lesson. Secure your infrastructure today.

Ready for resilient hosting? Deploy a KVM-based instance on CoolVDS with high-speed SSD storage in under 60 seconds. Start your trial now.