Sleeping Soundly: The Art of Automated Backups in Linux

There are two types of system administrators: those who have lost data, and those who are about to. If you are managing servers in Oslo or dealing with clients across the Nordics, relying on manual FTP transfers or wishing on a star is professional negligence.

I learned this the hard way back in '04. A RAID controller failure on a legacy box didn't just corrupt the filesystem; it wrote garbage across the mirrors. We spent three weeks reconstructing a client's database from log files. Never again.

In this guide, we aren't discussing expensive enterprise appliances. We are talking about the tools already installed on your CentOS 5 or Debian Lenny server: rsync, cron, and shell scripting. This is how you build a bulletproof backup strategy that satisfies both your paranoia and the Datatilsynet (Data Inspectorate).

The 3-2-1 Rule Still Rules

Before we touch the command line, understand the architecture. Your backup strategy must follow the 3-2-1 logic:

• 3 Copies of Data: The live data and two backups.
• 2 Different Media: Don't keep backups on the same partition. Even better, not on the same hard drive.
• 1 Offsite: If your datacenter floods or catches fire, your local backup burns with it.

At CoolVDS, we utilize enterprise-grade 15k RPM SAS drives in Hardware RAID-10. This provides redundancy against a single drive failure. However, RAID is not a backup. RAID will happily mirror a rm -rf /var/www command to all drives instantly. You need historical snapshots.

The Weapon of Choice: Rsync

Forget FTP. It is insecure and inefficient. rsync is the industry standard for a reason. It only transfers the deltas (changes) between files, saving massive amounts of bandwidth—crucial if you are pushing gigabytes across the Atlantic or just to a backup server in Tronheim.

Basic Synchronization

Here is the command every junior admin needs to memorize:

rsync -avz --delete /var/www/html/ backup_user@192.168.1.50:/home/backup_user/remote_mirror/

• -a: Archive mode (preserves permissions, symlinks, times).
• -v: Verbose.
• -z: Compress during transfer (saves bandwidth).
• --delete: If a file is deleted on the source, delete it on the destination (use with caution).

Database Consistency is Key

Copying raw MySQL data files (/var/lib/mysql) while the server is running is a recipe for corruption. You need to lock the tables and dump them properly before the file transfer occurs.

Here is a battle-tested bash script snippet for a full rotational backup strategy:

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

# Configuration
DB_USER="root"
DB_PASS="SuperSecretPassword123"
BACKUP_DIR="/backup/daily"
DATE=$(date +"%Y-%m-%d")

# 1. Dump the Database
echo "Starting MySQL Dump..."
mysqldump -u $DB_USER -p$DB_PASS --all-databases --opt | gzip > $BACKUP_DIR/db_dump_$DATE.sql.gz

# 2. Archive Web Files
echo "Archiving Web Root..."
tar -czf $BACKUP_DIR/files_$DATE.tar.gz /var/www/vhosts

# 3. Ship it Offsite (using SSH keys)
echo "Syncing to Remote Storage..."
rsync -avz -e "ssh -p 22" $BACKUP_DIR/ remote_user@backup.coolvds.net:~/backups/

# 4. Cleanup old local files (older than 7 days)
find $BACKUP_DIR -type f -mtime +7 -exec rm {} \;

Pro Tip: Always use SSH keys for password-less authentication in scripts. Generating a key with ssh-keygen -t dsa (or rsa) allows your cron job to run without human intervention. Just ensure the private key has strict permissions (600).

Automation with Cron

A script is useless if you forget to run it. Edit your crontab:

Add the following line to run the backup every morning at 3:00 AM, when traffic is lowest:

Compliance and Norwegian Law

Operating in Norway means adhering to the Personopplysningsloven (Personal Data Act). If you are hosting customer data, you are responsible for its integrity. While offsite backups are mandatory for disaster recovery, ensure your remote storage location complies with data export regulations. Keeping your offsite backup within the EEA (European Economic Area) is the safest bet for compliance.

The CoolVDS Advantage

We built our infrastructure to support this exact workflow. Unlike budget hosts overselling their bandwidth, CoolVDS offers unmetered internal traffic on our private backend network. If you spin up a secondary VPS with us for storage, your rsync transfers won't eat into your public bandwidth quota.

Furthermore, our Xen-based virtualization ensures true hardware isolation. If a neighbor's I/O spikes, your backup process won't stall. We provide the raw stability; you provide the scripts.

Final Thoughts

Hardware fails. It is a matter of when, not if. Your job isn't to prevent failure, but to ensure recovery is boring, predictable, and fast. Don't wait for the crash to test your restore process.

Need a reliable sandbox to test your recovery scripts? Deploy a CoolVDS instance today and get full root access in under 60 seconds.