Automated Backups: Why Your RAID-10 Array Won't Save You

There is a dangerous misconception I see in too many /etc/fstab configurations across Oslo: the belief that because you are paying for RAID-10 or RAID-5 storage, your data is safe. It is not.

RAID is redundancy. It protects you from hardware failure. It does not protect you from human error, malicious scripts, or a corrupt file system. If you accidentally run rm -rf /var/www/html/ on a RAID array, the controller will dutifully, instantly, and redundantly delete those files from every single disk. Your redundancy just made your data loss more efficient.

As System Administrators, our job isn't just to keep the uptime high; it's to ensure that when the inevitable catastrophe strikes, we can restore the business. Today, we are going back to basics with a battle-tested approach to automated, offsite backups using tools available in every standard Linux environment.

The 3-2-1 Rule (and Why Local Isn't Enough)

If your backup sits on the same physical server as your production data (even on a separate partition), you are one motherboard failure or power surge away from total darkness. The standard we enforce at CoolVDS is the 3-2-1 rule:

• 3 copies of your data (Production, Local Backup, Offsite Backup).
• 2 different media types (Disk, Tape, or Remote Storage).
• 1 copy strictly offsite.

For Norwegian businesses, "offsite" comes with a caveat: Personopplysningsloven (The Personal Data Act). If you are dumping customer databases onto an unmanaged FTP server in Texas, you are likely crossing lines with the Data Inspectorate (Datatilsynet). Keeping data within the EEA—or better yet, within Norway—is not just about latency; it's about legal survival.

Scripting the Solution: Rsync & Cron

Forget expensive proprietary backup agents. The most robust tools are already installed on your CentOS or Debian system: rsync and cron.

Here is a production-grade approach to backing up a web directory. We use SSH keys for authentication because putting cleartext passwords in scripts is a firing offense.

1. The Database Dump

Files are easy; databases are hard. If you copy the raw /var/lib/mysql directory while MySQL is running, you will get corrupt tables. You must dump it properly.

#!/bin/bash
# /root/scripts/backup_db.sh

TIMESTAMP=$(date +"%F")
BACKUP_DIR="/backup/mysql"
MYSQL_USER="root"
MYSQL_PASS="YourComplexPassword"

# Create dir if not exists
mkdir -p $BACKUP_DIR

# Dump all databases
# --single-transaction is crucial for InnoDB tables to avoid locking the site
# --routines ensures stored procedures are saved

echo "Starting Dump for $TIMESTAMP"
mysqldump -u$MYSQL_USER -p$MYSQL_PASS --all-databases --single-transaction --routines --triggers | gzip > $BACKUP_DIR/db_full_$TIMESTAMP.sql.gz

echo "Dump Complete"

Pro Tip: If you are still using the MyISAM storage engine (default in older MySQL versions), --single-transaction won't help you. The table will lock during dump. Consider migrating to InnoDB for better concurrency and crash recovery.

2. The Offsite Push

Once your database is dumped and compressed, you need to ship it along with your web files to a remote server. We use rsync because it only transfers the differences (deltas), saving bandwidth—a precious commodity even with today's speeds.

#!/bin/bash
# /root/scripts/push_offsite.sh

REMOTE_USER="backupuser"
REMOTE_HOST="backup.coolvds-storage.no"
LOCAL_DIR="/backup/"
REMOTE_DIR="/home/backupuser/server1/"

# -a: archive mode (preserves permissions, owners, times)
# -v: verbose
# -z: compress during transfer
# --delete: remove files on remote that are gone from local (Use with caution!)

rsync -avz -e "ssh -i /root/.ssh/id_rsa_backup" $LOCAL_DIR $REMOTE_USER@$REMOTE_HOST:$REMOTE_DIR

The Importance of Network Latency

When you are syncing gigabytes of data nightly, the network path matters. If your backup server is in Amsterdam and your production server is in Oslo, you are adding latency to every packet. While bandwidth is getting cheaper, TCP window scaling only does so much.

This is why we architect CoolVDS with direct peering at NIX (Norwegian Internet Exchange). When you transfer data between a CoolVDS production node and a backup node within our Norwegian datacenters, you are hitting sub-millisecond latency. This means your backup window shrinks from hours to minutes, reducing the load on your I/O subsystem.

Security Considerations

Never transfer data in the clear. FTP is dead; long live SFTP/SCP. Furthermore, if you are storing sensitive data offsite, consider encrypting the tarball before it leaves your server using GPG:

This ensures that even if your backup server is compromised, the data remains unreadable without your private key.

The CoolVDS Advantage

We built CoolVDS because we were tired of "Managed Hosting" that didn't actually manage the hard stuff. While we provide the raw performance—using high-speed 15k RPM SAS arrays and cutting-edge KVM virtualization for true hardware isolation—we also provide the infrastructure to make backups easy.

We don't oversell our lines. When your cron job fires at 3:00 AM, you get the full throughput of the port to push your data to safety. In an era where DDOS attacks are becoming more frequent, having your data safely replicated on an internal, protected network is not just a luxury; it's a requirement for staying in business.

Don't wait for a disk failure to test your backup strategy. Write the script, set the cron, and verify the restore.

Need a test environment to practice your disaster recovery? Deploy a KVM instance on CoolVDS today and see what real I/O performance feels like.