The "rm -rf" Nightmare Scenario
It happens to the best of us. It's 3:00 AM on a Tuesday. You are tired. You are logged into the production server as root. You mean to delete a log directory, but a misplaced space or a wildcard in the wrong place wipes out your /var/www/html folder instead.
If your stomach just dropped reading that, good. That fear is what keeps systems alive.
In the Nordic hosting market, I see too many developers treating RAID 10 as a backup strategy. Let me be clear: RAID provides redundancy against disk failure. It offers zero protection against file corruption, accidental deletion, or malicious attacks. If you delete a file, the RAID controller happily deletes it from both mirrors instantly.
We need to talk about proper, automated, off-site retention. No manual FTP. No drag-and-drop. Pure script automation.
The 2009 Standard: Bash, Tar, and Rsync
You don't need expensive proprietary software to secure your data. The tools built into CentOS 5 and Ubuntu 8.04 LTS are battle-tested. The holy trinity of backup logic is simple:
- Dump database content to a flat file.
- Compress files and database dumps into an archive.
- Transport the archive to a remote location (off-site).
- Rotate old backups to save space.
Step 1: The Database Dump (The Tricky Part)
Hot backups of MySQL are risky if you don't handle table locking correctly. If you just copy the raw /var/lib/mysql directory while the server is running, you will end up with corrupted MyISAM tables.
Here is the robust way to handle a MySQL dump inside a bash script:
mysqldump -u root -p'YOUR_PASSWORD' --all-databases --single-transaction --quick > /backup/db_dump_$(date +%F).sql
Using --single-transaction is critical for InnoDB tables (standard in many Magento and Drupal installs) as it ensures data consistency without locking the entire database for the duration of the dump.
Step 2: The Transport Layer (Rsync over SSH)
Once you have your tarball (tar -czf is your friend), you need to get it off the server. Keeping backups on the same machine is useless if the motherboard fries or the datacenter has a fire.
We use rsync because it is incremental. If you have a 50GB web directory but only 100MB changed, rsync only moves the 100MB diffs. This saves massive amounts of bandwidth and time.
Pro Tip: Never use plain FTP for backups. Passwords are sent in cleartext. Always tunnel through SSH using public/private key pairs for passwordless automation.
Implementation: The Script
Here is a stripped-down version of the rotation script we use on CoolVDS internal management nodes. Place this in /etc/cron.daily/:
#!/bin/bash
# Config
BACKUP_DIR="/backup"
REMOTE_DEST="[email protected]:/home/user/backups/"
DATE=$(date +%F)
# 1. MySQL Dump
mysqldump -u root --all-databases | gzip > $BACKUP_DIR/db_$DATE.sql.gz
# 2. Filesystem Archive
tar -czf $BACKUP_DIR/files_$DATE.tar.gz /var/www/html
# 3. Ship it off-site
rsync -avz -e "ssh -i /root/.ssh/id_rsa" $BACKUP_DIR/ $REMOTE_DEST
# 4. Cleanup local older than 7 days
find $BACKUP_DIR -type f -mtime +7 -exec rm {} \;
The Infrastructure Factor: Latency and Jurisdiction
Scripts are great, but they depend on the network. When you are pushing gigabytes of data every night, the pipe matters. This is where generic budget hosting falls apart—their upstream providers often throttle upload speeds, causing backup jobs to overlap with production traffic in the morning.
At CoolVDS, we configure our network interfaces without artificial throttling on the private backend network. This allows your backup jobs to complete in minutes, not hours. Furthermore, for our Norwegian clients, utilizing our Oslo-based datacenter ensures you remain compliant with the Personal Data Act (Personopplysningsloven) of 2000. Datatilsynet (The Data Inspectorate) looks favorably on keeping sensitive user data within national borders rather than shipping it to US servers under the "Safe Harbor" framework.
Conclusion: Test Your Restores
A backup that hasn't been restored is just a hopeful wish. Dedicate one day a month to grabbing a backup file from your remote storage and deploying it to a fresh CoolVDS instance. If it takes you more than 30 minutes to get back online, your disaster recovery plan is too complex.
Don't wait for a hardware failure to find out your scripts are broken. Secure your data today.