Automated Backups: The Only Insurance That Matters

There are two types of system administrators in this world: those who have lost data, and those who are about to. I learned this the hard way back in '09 when a RAID controller in a budget datacenter decided to write garbage across a mirrored array. The redundancy we paid for became a mechanism to corrupt data twice as fast.

If you are relying on manual backups or, heaven forbid, FTP-ing tarballs once a month, you are negligent. In the high-stakes environment of hosting—whether you are running a Magento cluster or a simple LAMP stack—uptime is vanity, but data integrity is sanity. Today, we are going to fix your backup strategy using tools that have stood the test of time: rsync, mysqldump, and the relentless clockwork of cron.

The 3-2-1 Rule: Non-Negotiable

Before we touch the terminal, let's establish the architecture. The 3-2-1 rule is the gold standard for a reason:

• 3 copies of your data: One production, two backups.
• 2 different media types: Disk and Tape, or Local and Remote.
• 1 copy off-site: Because if your datacenter in Oslo floods or catches fire, your local backups burn with it.

In Norway, we have the added complexity of the Personopplysningsloven (Personal Data Act). Datatilsynet is not known for its sense of humor regarding data loss or unauthorized transfers. Keeping your off-site backups encrypted and, ideally, within national borders or the EEA is not just good practice; it's practically a legal requirement for sensitive data.

Step 1: The Database Dump

Files are easy. Databases are tricky. If you just copy the raw /var/lib/mysql directory while the server is running, you will end up with a corrupted, inconsistent mess. You need a logical backup.

Here is a robust Bash script pattern I use for MySQL 5.1/5.5 environments. It locks tables only momentarily or uses transactions for InnoDB to ensure consistency without downtime.

#!/bin/bash

# Configuration
DB_USER="backup_user"
DB_PASS="SuperSecretPassword123!"
BACKUP_DIR="/var/backups/mysql"
DATE=$(date +%Y-%m-%d_%H%M)

# Ensure backup directory exists
mkdir -p $BACKUP_DIR

# Get list of databases, exclude system dbs
DATABASES=$(mysql -u $DB_USER -p$DB_PASS -e "SHOW DATABASES;" | grep -Ev "(Database|information_schema|performance_schema)")

for db in $DATABASES; do
    echo "Dumping database: $db"
    # Use --single-transaction for InnoDB to avoid locking tables
    mysqldump -u $DB_USER -p$DB_PASS --single-transaction --quick --lock-tables=false $db | gzip > $BACKUP_DIR/$db-$DATE.sql.gz
done

# Retention: Delete backups older than 7 days
find $BACKUP_DIR -type f -name "*.sql.gz" -mtime +7 -exec rm {} \;

echo "MySQL Backup Complete: $DATE"

Pro Tip: Never run backups as the root database user. Create a dedicated user with SELECT, LOCK TABLES, and SHOW VIEW privileges only. Security depth matters.

Step 2: Filesystem Synchronization

For your web files (/var/www, /etc/nginx, etc.), rsync is the undisputed king. It calculates deltas, meaning it only transfers the parts of files that have changed. This is critical when you are moving gigabytes of data over a WAN link.

Do not use cp. Do not use scp for recurring jobs. Use rsync.

rsync -avz --delete /var/www/vhosts/ /mnt/backup_drive/vhosts/

Breakdown of flags:

• -a: Archive mode (preserves permissions, symlinks, users, groups).
• -v: Verbose (so you can see what failed in the logs).
• -z: Compress during transfer (saves bandwidth).
• --delete: This is dangerous but necessary. It ensures that if you delete a file in production, it eventually gets removed from the backup, preventing the backup drive from filling up with ghosts.

Step 3: Off-Site Transport

Backing up to a second drive on the same server saves you from a disk failure, but it doesn't save you from a chassis failure or a compromised root account. You need to ship these bits out.

If you are hosting in a robust facility, you might have a dedicated backup VLAN. If not, tunneling rsync over SSH to a remote storage box is the standard way.

# Push to remote backup server
rsync -avz -e "ssh -p 2222" /var/backups/mysql user@remote-storage.no:/home/user/backups/

Ensure you have set up SSH Key-based authentication (RSA keys) so this can run without a password prompt. And please, passphrase-protect your private keys, but use `ssh-agent` or a dedicated key without a passphrase restricted by `command=` options in the `authorized_keys` file for full automation.

Step 4: Automation

A script that isn't automated is just a suggestion. Open your crontab:

Add the following line to run your master backup script at 3:00 AM, typically a low-traffic window for Norwegian users.

0 3 * * * /bin/bash /root/scripts/full_backup.sh >> /var/log/backup.log 2>&1

Why Infrastructure Choice Dictates Backup Speed

Here is the uncomfortable truth: Backup scripts are I/O intensive. They hammer your disk reading thousands of small files or dumping massive tables. On oversold hosting platforms (we all know the ones), starting a backup job can cause your "Wait I/O" (wa) to spike, making your website sluggish or unresponsive.

This is where virtualization technology matters. At CoolVDS, we rely on KVM (Kernel-based Virtual Machine) rather than container-based virtualization like OpenVZ. With KVM, your resources are hardware-isolated. When you hammer your disk I/O for a backup, you aren't fighting for the same syscall queue as the noisy neighbor next door.

The SSD Advantage

Furthermore, spinning rust is dying. 15k RPM SAS drives are reliable, but they cannot compete with the random read/write speeds of modern Enterprise SSDs. When you perform a backup, you are essentially doing a massive read operation. On CoolVDS SSD instances, we regularly see backup windows shrink from 4 hours to 45 minutes simply due to the superior throughput. Less time backing up means less time in the danger zone.

Final Thoughts

It is 2011. There is no excuse for data loss. Storage is cheap, bandwidth in Europe is plentiful, and the tools are open source. If you haven't tested your restore process, you don't have backups; you have hope. And hope is not a strategy.

Don't let slow I/O kill your backup windows. Deploy a high-performance SSD instance on CoolVDS today and sleep better knowing your cron jobs finish before your morning coffee.