The "rm -rf" Nightmare and the Lie of RAID
It is currently 3:00 AM in a freezing server room. Do you know where your data is? If your answer is "It's safe, I have RAID 10," you are already a casualty waiting to happen. I have seen seasoned systems administrators cry over array corruptions that mirrored garbage data across four drives simultaneously. RAID is redundancy, not backup. It protects you from hardware failure, not human stupidity or malicious scripts.
As we close out 2009, the web is becoming increasingly dynamic. With the rise of heavy CMS platforms like Magento and Drupal, simple file copies aren't enough. We need atomic database dumps, off-site replication, and we need it to happen while we sleep. Furthermore, for those of us hosting in Norway, we have the Personopplysningsloven (Personal Data Act) and the Datatilsynet to answer to. Losing customer data isn't just an inconvenience; it is a legal catastrophe.
This guide isn't about expensive enterprise software. It's about using the battle-tested tools already inside your Linux kernel: Bash, Cron, and Rsync. We will build a robust, automated backup system that costs nothing but CPU cycles.
1. The Strategy: 3-2-1 Rule
Before we touch the command line, understand the architecture. The gold standard in 2009 is the 3-2-1 rule:
- 3 copies of data.
- 2 different media types (e.g., Live Disk + Backup Disk).
- 1 copy off-site (e.g., a secondary VPS or remote storage).
At CoolVDS, we see clients hosting their primary site and their backup on the same physical node. If that node suffers a catastrophic controller failure, you lose everything. Don't do that. Use our internal network to push data to a separate slice.
2. The Database: Locking and Dumping
Backing up a running MySQL server is tricky. If you just copy the /var/lib/mysql directory while writes are happening, you get corrupted MyISAM tables. You need mysqldump.
For modern InnoDB tables (which you should be using over MyISAM for crash recovery), use the --single-transaction flag to ensure data consistency without locking the entire site for seconds (or minutes).
The MySQL Dump Script
Create a file at /root/scripts/db_backup.sh:
#!/bin/bash
# Configuration
USER="root"
PASSWORD="SuperSecretPassword123"
OUTPUT="/backup/mysql"
DATE=$(date +%Y-%m-%d_%H%M)
# Ensure directory exists
mkdir -p $OUTPUT
# Dump all databases
# We use --routines to grab stored procs and --triggers for automation rules
/usr/bin/mysqldump -u $USER -p$PASSWORD --all-databases --single-transaction --routines --triggers | gzip > $OUTPUT/db_dump_$DATE.sql.gz
# Remove backups older than 7 days to save space
find $OUTPUT -type f -mtime +7 -name '*.gz' -exec rm {} \;
Pro Tip: Never put your password directly in the command line arguments if you have multiple users on the shell, as it shows up inps aux. Create a.my.cnffile in the root home directory with permissions 600.
3. The Filesystem: The Power of Rsync
FTP is dead for backups. It is insecure and inefficient. rsync is the only tool a serious sysadmin needs. It only transfers the deltas (changes) between files. If you change 4KB of a 1GB file, rsync transmits 4KB. FTP transmits 1GB.
When transferring sensitive Norwegian user data, encryption is non-negotiable. We will tunnel rsync over SSH.
The Mirroring Command
Assuming you have a secondary storage VPS (perhaps a low-cost CoolVDS storage instance) at IP 10.0.0.5:
rsync -avz --delete -e "ssh -i /root/.ssh/id_rsa_backup" /var/www/html/ remote_user@10.0.0.5:/var/backups/web_mirror/
-a: Archive mode (preserves permissions, symlinks, users).-v: Verbose.-z: Compress during transfer (saves bandwidth, critical if you have limited peering).--delete: If a file is deleted on source, delete it on destination. (Warning: Be careful with this. If you accidentally delete your site, your backup deletes itself too. I prefer using incremental rotations with hard links, akin to Apple's Time Machine, using the--link-destflag).
4. Automating with Cron
A script you run manually is not a backup plan. It's a hobby. We need reliability. Open your crontab:
crontab -e
Add the following lines. We schedule this for 03:30 AM Oslo time, typically the lowest traffic window for Norwegian businesses.
# Database Backup at 03:00
0 3 * * * /bin/bash /root/scripts/db_backup.sh >> /var/log/backup_db.log 2>&1
# File Sync to Offsite Storage at 03:30
30 3 * * * /usr/bin/rsync -avz -e ssh /var/www/ remote_user@192.168.1.50:/backups/ >> /var/log/backup_files.log 2>&1
5. Infrastructure Matters: The Hardware Beneath
Scripts are only as good as the hardware they run on. In 2009, many hosting providers are still cramming users onto slow 7.2k SATA drives. When your backup script hits at 3 AM, the I/O Wait shoots up, and your web server stops responding to HTTP requests.
This is where the "Noisy Neighbor" effect destroys uptime. If the guy next to you runs a backup, you suffer.
At CoolVDS, we mitigate this by utilizing high-performance 15k RPM SAS RAID-10 arrays. We also strictly limit I/O contention using Xen hypervisor scheduling. This means your gzip compression and rsync processes won't choke your CPU or disk queue. Furthermore, our datacenter peering at NIX (Norwegian Internet Exchange) ensures that if you are pushing backups to another provider within Norway, latency is virtually non-existent (often under 2ms).
| Feature | Budget Hosting | CoolVDS Architecture |
|---|---|---|
| Disk Technology | SATA (Slow Seek) | SAS 15k / Enterprise RAID-10 |
| Network | Congested Public Line | Dedicated VLANs & NIX Peering |
| Virtualization | Virtuozzo (Shared Kernel) | Xen / KVM (Isolated Resources) |
6. Verification: The Step Everyone Skips
A backup is Schrödinger's data until you restore it. It exists and doesn't exist simultaneously.
Once a month, perform a "Fire Drill." Spin up a fresh CoolVDS instance (it takes about 60 seconds), deploy your OS, and try to restore your application only using your backup files. If it takes you 4 hours to figure out the dependencies, your backup plan has failed. Documentation is part of the backup.
Summary
Data loss is an extinction-level event for digital businesses. By combining mysqldump with transaction safety, rsync over secure SSH tunnels, and the raw I/O performance of CoolVDS's enterprise arrays, you ensure that even if the worst happens, you are back online before your morning coffee is cold.
Is your current host choking during backup windows? Switch to a CoolVDS High-Performance plan today and experience the stability of true resource isolation.