RAID Is Not a Backup. Repeat It.
I have lost count of the number of times I have walked into a meeting room in Oslo, listened to a CTO explain their "robust" disaster recovery plan, and realized their entire strategy relies on RAID 10. Let me be perfectly clear: RAID is redundancy. It protects you from hardware failure. It does not protect you from rm -rf /var/www.
If you corrupt your data on disk A, the RAID controller dutifully and instantly corrupts it on disk B. Congratulations, you now have two perfect copies of garbage.
In the Norwegian hosting market, where data integrity is mandated by the Personopplysningsloven (Personal Data Act), relying on snapshots alone isn't enough. You need the 3-2-1 strategy: 3 copies of data, on 2 different media, with 1 off-site. Today, we are going to script this. No expensive enterprise bloatware. Just Bash, rsync, and cron.
The Anatomy of a Bulletproof Backup Script
We are targeting a standard LAMP stack running on CentOS 6 or Ubuntu 12.04 LTS. The goal is zero user interaction. If you have to click a button to backup, you will forget to click it.
1. Securing MySQL Credentials
Never put your password in the script command line. It shows up in ps aux. Create a .my.cnf file in your home directory.
[client]
user=backup_user
password=YourComplexPassword2012!
Now, secure it so only root can read it:
chmod 600 /root/.my.cnf
2. The Dump Script
Here is a script that dumps databases, compresses them, and prepares them for transport. It handles log rotation locally to prevent filling your disk.
#!/bin/bash
# Configuration
BACKUP_DIR="/var/backups/mysql"
DATE=$(date +%Y-%m-%d_%H%M)
RETENTION=7
# Ensure directory exists
mkdir -p $BACKUP_DIR
# Dump all databases
echo "Starting backup for $DATE..."
mysqldump --defaults-extra-file=/root/.my.cnf --all-databases --events | gzip > $BACKUP_DIR/db_full_$DATE.sql.gz
# Verify the dump existed and has size
if [ -s $BACKUP_DIR/db_full_$DATE.sql.gz ]; then
echo "Backup successful."
else
echo "Backup FAILED."
exit 1
fi
# Delete backups older than 7 days
find $BACKUP_DIR -name "db_full_*.sql.gz" -type f -mtime +$RETENTION -exec rm {} \;
echo "Local rotation complete."
Pro Tip: On high-traffic sites, mysqldump can lock tables (MyISAM) or cause I/O spikes. If you are running on CoolVDS, our underlying storage is built on high-performance Enterprise SSDs, which significantly reduces the "lock time" compared to traditional SATA spinning rust used by budget hosts. Faster I/O means shorter backup windows.
Off-Site Transport: The "1" in 3-2-1
A backup sitting on the same server as the live data is a suicide pact. If the server catches fire, or if a hacker compromises root, they delete the backup too. You need to push this data to a remote storage server.
We use rsync over SSH. It is the standard for a reason. It is incremental, bandwidth-efficient, and secure.
Setting up Keys
On your source server (the web server):
ssh-keygen -t rsa -b 4096
ssh-copy-id -i ~/.ssh/id_rsa.pub user@backup-server.coolvds.net
The Sync Command
Add this to the end of your backup script:
REMOTE_USER="backup_user"
REMOTE_HOST="10.0.0.50"
REMOTE_DIR="/home/backup_user/storage/"
rsync -avz -e "ssh -p 22" $BACKUP_DIR $REMOTE_USER@$REMOTE_HOST:$REMOTE_DIRThe -z flag enables compression, critical if you are transferring between data centers, though latency within Norway (e.g., Oslo to Trondheim) is negligible on our network.
Automation via Cron
A script that doesn't run is useless. Edit your crontab:
crontab -e
Add the following line to run at 3:00 AM, typically the lowest traffic window for European audiences:
0 3 * * * /bin/bash /root/scripts/daily_backup.sh >> /var/log/daily_backup.log 2>&1
The "CoolVDS" Factor: Infrastructure Matters
You can write the best scripts in the world, but hardware limitations will eventually catch you. In 2012, many providers are still over-selling consumer-grade HDDs. When mysqldump runs on those drives, your website's latency spikes, causing 502 errors for users.
CoolVDS uses KVM (Kernel-based Virtual Machine) virtualization. Unlike OpenVZ, KVM provides true hardware isolation. This means when your neighbor runs a massive backup, it doesn't steal your I/O operations. Combined with our pure SSD storage tiers, your backups complete in seconds, not minutes.
Restoration Test
A backup is Schrödinger's file until you restore it. Once a month, grab a fresh VPS Norway instance from CoolVDS (it takes about 55 seconds to provision), transfer your backup, and try to import it:
gunzip < db_full_2012-09-17.sql.gz | mysql -u root -p
If this throws errors, fix your script. Do not wait for a disaster to find out your gzip binary was corrupt.
Summary
1. Script it. Humans make mistakes. Computers don't.
2. Encrypt it. Use SSH tunnels.
3. Move it. Get the data off the production server immediately.
4. Test it. Restore frequently.
Data loss is an extinction event for small businesses. Don't let a hardware failure become a business failure. If you need a staging environment to test your recovery procedures without affecting production, spin up a high-performance SSD VPS with CoolVDS today.