Stop Trusting Your RAID Controller with Your Life
I have seen grown men cry in server rooms. It usually happens around 3:00 AM. They stare at a blinking amber light on a chassis, realizing that the RAID 5 array didn't just rebuildâit corrupted the entire file system during the sync. Or worse, a junior developer just ran a drop table command on the production MySQL database.
Here is the hard truth for 2009: Redundancy is not a backup.
If you are hosting critical services for Norwegian clientsâwhether it's a Magento shop or a Joomla content portalâyou need a strategy that survives hardware failure, human error, and malicious attacks. Letâs talk about how to automate this properly using standard Linux tools, without breaking the bank or violating Datatilsynet regulations.
The "3-2-1" Rule Still Applies
Before we touch a single line of Bash, memorize this architecture. It is the only thing standing between you and total data loss:
- 3 Copies of Data: Production, Local Backup, Remote Backup.
- 2 Different Media: Your fast SAS disks and a separate storage server (or tape, if you're old school).
- 1 Offsite: If the datacenter in Oslo floods, your data must exist in Bergen or a secure safe.
Scripting the Solution: The Battle-Tested Stack
Forget expensive enterprise backup suites. In a Linux environment (CentOS 5 or Debian Lenny), `rsync` and `cron` are your best friends. They are lightweight, verifiable, and free.
1. The Database Dump
For MySQL 5.0/5.1, you cannot just copy the `/var/lib/mysql` folder while the server is running. You will get corrupted MyISAM tables. You need a consistent dump.
Create a script `/root/scripts/backup_db.sh`:
#!/bin/bash
# Date format for the filename
DATE=$(date +%Y-%m-%d)
DIR="/backup/mysql"
# Dump all databases
mysqldump -u root -p'YourComplexPassword' --all-databases | gzip > $DIR/db_backup_$DATE.sql.gz
# Delete backups older than 7 days to save space
find $DIR -type f -name "*.gz" -mtime +7 -exec rm {} \;
Pro Tip: If you are using InnoDB tables, add the --single-transaction flag to avoid locking your tables during the backup. Your users shouldn't face timeout errors just because you are being responsible.
2. The Remote Sync
Storing the backup locally is useless if the physical server melts. You need to push this to a remote file server. At CoolVDS, we see savvy admins using our secondary FTP storage accounts for this exact purpose.
#!/bin/bash
# Sync /backup to remote server securely
rsync -avz -e "ssh -p 22" /backup/ [email protected]:/home/user/backups/
Add this to your crontab to run every night at 04:00 AM, when traffic from Oslo is lowest.
Compliance: The Norwegian Context (Personopplysningsloven)
Here is where hosting in Norway matters. If you are handling personal data for Norwegian citizens, you are bound by the Personal Data Act (Personopplysningsloven).
Sending backups to a cheap storage bucket in the US might violate the Safe Harbor principles if not managed strictly. The safest bet for compliance and latency is keeping your data within Norwegian borders. The Datatilsynet (Data Inspectorate) is becoming increasingly strict about where sensitive data resides.
Why Latency Matters for Backups
Network throughput isn't infinite. If you have 50GB of data to sync nightly:
| Destination | Latency (Ping) | Throughput Impact |
|---|---|---|
| Oslo (Local) | < 2ms | High (Near Line Speed) |
| Frankfurt | 25-30ms | Medium (TCP Windowing limits) |
| US East | 100ms+ | Low (Slow syncs, potential overlap) |
Using a local Norwegian provider like CoolVDS ensures that your nightly `rsync` completes before the business day starts at 08:00, preventing I/O wait (iowait) from slowing down your site for early risers.
The CoolVDS Advantage: Managed Peace of Mind
We built our infrastructure on Enterprise RAID-10 SAS arrays because they offer the best balance of write speed and redundancy available today. But as I said, hardware redundancy is not a backup.
That is why every CoolVDS instance comes with options for:
- Private VLANs: Transfer data to a backup server without exposing traffic to the public internet.
- Secondary Storage Mounts: Attach a large, cheap disk to your high-performance VPS just for dumping `tar` archives.
- Local Compliance: Our servers are physically located in Oslo, keeping you compliant with Norwegian law by default.
Don't wait for a disk failure to test your recovery plan. Write the script, set the cron job, and sleep better knowing your data is safe in Norway.
Need a reliable sandbox to test your recovery scripts? Deploy a CoolVDS instance in Oslo today.