The "RM -RF" Nightmare: Automated Backup Strategies for the Paralyzed Sysadmin

I still remember the silence. It was 3:00 AM, inside a cold server room in Oslo, when a junior admin typed rm -rf / var/www instead of rm -rf /var/www. That single space wiped the entire filesystem. The RAID 10 array did exactly what it was designed to do: it mirrored that deletion instantly across all four drives. The site was gone. The backups? Two weeks old and corrupt.

If you rely on manual backups or, heaven forbid, you think RAID 5 constitutes a disaster recovery plan, you are already dead in the water. In the unforgiving landscape of systems administration, data survival requires paranoia, automation, and bash scripting.

The First Rule: RAID is Not a Backup

Let’s clear this up immediately. RAID protects you from hardware failure. It does not protect you from human stupidity, malicious software, or filesystem corruption. If you overwrite a file on a CoolVDS high-performance SAS array, the redundancy just ensures the error is written to disk faster.

For a robust strategy, we look to the standard 3-2-1 Rule:

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

The Database Dilemma: Dumping Without Downtime

Flat files are easy to copy. Databases are the real headache. If you just copy the raw /var/lib/mysql directory while MySQL is running, you will end up with corrupted tables. You need a consistent snapshot.

For MyISAM tables, you are forced to lock tables, which kills site performance. However, if you are running modern applications on CoolVDS, you should be using the InnoDB engine. This allows us to use the --single-transaction flag to dump data without locking up the shop.

Here is the battle-tested command you should be running inside your cron jobs:

mysqldump -u root -p[PASSWORD] --all-databases --single-transaction --quick --lock-tables=false > /backup/db/full_dump_$(date +%F).sql

Pro Tip: Never leave your password visible in the process list. Use a .my.cnf file in your home directory with chmod 600 permissions to store credentials safely.

Scripting the Solution: Bash and Rsync

Proprietary backup software is expensive and often bloated. The most reliable tool in a Linux admin's arsenal in 2010 is still rsync. It’s incremental, supports SSH natively, and preserves permissions.

Here is a foundational script structure we use to push backups from a CoolVDS production node to a remote storage server. This assumes you have set up SSH key-based authentication for passwordless transfers.

#!/bin/bash
# /usr/local/bin/nightly_backup.sh

SOURCE="/var/www/html"
DEST="user@backup.server.no:/home/backups/"
LOG="/var/log/backup.log"

echo "Starting backup at $(date)" >> $LOG

# 1. Archive files
tar -czf /tmp/files.tar.gz $SOURCE

# 2. Dump DB
mysqldump --defaults-file=/root/.my.cnf --all-databases | gzip > /tmp/db.sql.gz

# 3. Ship it off-site via rsync
rsync -avz -e "ssh -p 22" /tmp/files.tar.gz /tmp/db.sql.gz $DEST

# 4. Cleanup
rm /tmp/files.tar.gz /tmp/db.sql.gz

echo "Backup finished at $(date)" >> $LOG

Add this to your crontab (crontab -e) to run at 04:00 AM, when traffic is lowest:

The CoolVDS Advantage: I/O and Latency

Backup scripts are I/O intensive. When tar and mysqldump are running, they hammer your disk subsystem. On budget providers overselling their hardware, this causes "I/O Wait" (iowait) to spike, making your website sluggish or unresponsive during the backup window.

This is why hardware matters. At CoolVDS, we utilize enterprise-grade RAID-10 arrays that provide high IOPS (Input/Output Operations Per Second). This ensures your backup script finishes in minutes, not hours, keeping your CPU cycles free for serving customers.

Geographic Redundancy and Norwegian Law

For our clients in Norway, compliance with the Personal Data Act (Personopplysningsloven) and Datatilsynet guidelines is mandatory. You are responsible for ensuring data integrity.

Using CoolVDS, you benefit from our low-latency peering at NIX (Norwegian Internet Exchange). Pushing gigabytes of backup data to a secondary storage server within Norway remains fast and secure, keeping data within legal jurisdiction while ensuring it survives a local catastrophe.

Final Thoughts

Automation is the only way to sleep at night. If you have to remember to run a backup, you have already failed. Configure your cron jobs, test your restoration process (a backup that cannot be restored is useless), and host on infrastructure that can handle the load.

Don't let a typo destroy your business. Deploy a high-performance CoolVDS instance today and get the I/O headroom you need for rock-solid disaster recovery.