Automated Backups: The "rm -rf" Insurance Policy for Serious Sysadmins

There are two types of system administrators: those who have lost data, and those who are about to. If you are reading this, you are hopefully looking to avoid joining the first group. Last month, I watched a junior developer at a digital agency in Oslo accidentally wipe a production database because he thought he was in the staging environment. There was no backup script. The RAID-10 array did exactly what it was designed to do: it faithfully mirrored the empty database tables across four disks in milliseconds. The client lost three weeks of orders.

RAID is not a backup. Snapshots are not a backup strategy. If you don't have an automated, verified, off-site copy of your data, you don't have data—you have a temporary lease on digital information.

In this guide, we aren't going to talk about expensive enterprise tape libraries. We are going to build a battle-tested, automated backup solution using standard Linux tools available on any CentOS 6 or Ubuntu 10.04 LTS server. Whether you are hosting on a budget VPS or a high-performance CoolVDS instance, the principles remain the same.

The Golden Rule: 3-2-1

Before touching the command line, memorize the 3-2-1 rule. It is the only thing standing between you and professional negligence.

• 3 Copies of your data: One production, two backups.
• 2 Different formats: E.g., the live file system and a compressed tarball.
• 1 Off-site: If your datacenter catches fire (it happens), your local backup burns with it.

Step 1: Database Consistency is King

Copying /var/lib/mysql while the database is running is a guarantee for corruption. You need a logical dump. With the release of MySQL 5.5 (standard on CoolVDS images), we have reliable tools to do this without locking your tables for minutes at a time.

For InnoDB tables, use the --single-transaction flag. This ensures data consistency without locking the entire database, essential for high-traffic e-commerce sites.

Pro Tip: If you are still using MyISAM tables, stop. Migrate to InnoDB now. MyISAM does not support transactional backups, meaning you must lock tables during the dump, causing downtime. On CoolVDS high-I/O instances, the migration is swift.

Step 2: Scripting the Logic

Do not rely on your memory to run backups. We use cron. Below is a robust Bash script I use on production servers. It creates a dated archive and removes backups older than 7 days to save space.

#!/bin/bash

# CONFIGURATION
BACKUP_ROOT="/var/backups/automated"
DATE_DIR=$(date +"%Y-%m-%d")
TARGET_DIR="$BACKUP_ROOT/$DATE_DIR"
MYSQL_USER="root"
MYSQL_PASS="YourSecurePassword123!"
LOG_FILE="/var/log/backup_script.log"

# Create target directory
mkdir -p $TARGET_DIR

echo "[$(date)] Backup started" >> $LOG_FILE

# 1. DATABASE DUMP
# Using --single-transaction for InnoDB consistency
echo "Dumping databases..." >> $LOG_FILE
mysqldump -u $MYSQL_USER -p$MYSQL_PASS --all-databases --single-transaction --events | gzip > "$TARGET_DIR/mysql_dump.sql.gz"

# 2. FILE SYSTEM BACKUP
# Exclude temporary files and existing backups
echo "Archiving web files..." >> $LOG_FILE
tar -czf "$TARGET_DIR/www_files.tar.gz" /var/www/html --exclude=*.tmp --exclude=*.log

# 3. ROTATION (Delete backups older than 7 days)
find $BACKUP_ROOT -maxdepth 1 -type d -mtime +7 -exec rm -rf {} \;

echo "[$(date)] Backup completed locally" >> $LOG_FILE

Step 3: getting it Off-Site (The "1" in 3-2-1)

Having the backup on the same disk is useless if the disk fails. You need to ship it out. rsync is the industry standard for this. It is efficient, resumable, and works over SSH.

Add this to the end of your script:

For this to work without a password prompt, you must generate an SSH key pair (ssh-keygen -t rsa) and copy the public key to your remote storage server using ssh-copy-id.

Network Latency and Norwegian Compliance

For our clients in Norway, where data sovereignty is critical under the Personopplysningsloven (Personal Data Act), sending backups to a cheap storage bucket in the US is a legal minefield. The Datatilsynet (Data Inspectorate) is clear about the responsibilities of data controllers.

Furthermore, latency matters. Transferring gigabytes of data nightly requires a solid connection. Hosting your primary infrastructure and your backup storage within the NIX (Norwegian Internet Exchange) ecosystem ensures low latency and high throughput. This is why CoolVDS keeps all backup storage nodes within the EEA, connected via high-speed fiber.

Performance Considerations: I/O Wait

Running tar and mysqldump is I/O intensive. On traditional SATA hard drives, this causes "iowait," making your website sluggish while the backup runs. This is the "backup window" problem.

This is where hardware choice matters. We built CoolVDS on Enterprise-grade SSD (Solid State Drives) and fast SAS arrays in RAID-10. Unlike standard VPS providers still spinning 7200 RPM SATA disks, SSDs handle the random read/write operations of a backup script without choking the CPU. You can run your backups during the day if you really have to (though 3 AM is still polite).

Final Thoughts: Test Your Restores

An untested backup is just a file taking up space. Once a month, grab your latest tar.gz, spin up a fresh CoolVDS instance (it takes about 55 seconds), and try to restore the site. If it doesn't work in a controlled environment, it definitely won't work at 4 AM when your boss is screaming.

Don't wait for a catastrophe to learn this lesson. Write the script, set the cron job, and sleep better.

Need a remote destination for your backups? CoolVDS offers high-performance storage instances with unmetered internal traffic, perfect for secure, compliant off-site backups. Deploy your backup node today.