Automated Disaster Recovery: Shell Scripting Robust Backups for High-Traffic VPS

Let’s be honest: there are two types of system administrators. Those who have lost data, and those who are about to. I recently watched a senior developer turn pale when he realized his recursive rm -rf command on a production node included the mounted database volume. There were no snapshots. The "backup" was a three-month-old tarball on the same physical disk.

That is not acceptable. In the high-stakes world of hosting—whether you are running a Magento storefront or a custom SaaS application—uptime is money, but data is existence. If you lose the data, the company is gone.

Today, we are going to stop trusting luck and start trusting mathematics and shell scripts. We will build a bulletproof, automated backup solution suitable for the rigorous demands of the Norwegian market, keeping VPS Norway standards and the Personal Data Act (Personopplysningsloven) in mind.

The Fallacy of "RAID is Backup"

I see this constantly on forums. "I don't need external backups; I have RAID 10." RAID protects you from physical drive failure. It does not protect you from:

• File corruption (bit rot).
• Human error (accidental deletion).
• Malicious intrusion (hackers wiping drives).
• Catastrophic hardware failure (RAID controller frying all disks).

For serious redundancy, you need the 3-2-1 rule: 3 copies of data, 2 different media, 1 off-site location. With CoolVDS, we utilize enterprise-grade hardware RAID for performance and immediate failover, but we always advocate for customer-managed off-site backups.

Step 1: The Database Dump (MySQL/MariaDB)

If you are running a high-traffic site, you cannot simply copy the raw /var/lib/mysql directory while the server is running. You will end up with corrupted tables. You need mysqldump.

For InnoDB tables (the standard in MySQL 5.5+), you must use the --single-transaction flag. This ensures a consistent snapshot without locking the entire database and halting your application—crucial for maintaining low latency during backup windows.

#!/bin/bash

# Configuration
DB_USER="backup_user"
DB_PASS="ComplexPassword123!"
BACKUP_DIR="/backup/mysql"
DATE=$(date +%F_%H-%M)

# Ensure backup directory exists
mkdir -p $BACKUP_DIR

# Dump all databases
# --single-transaction: Critical for InnoDB consistency without locking
# --quick: Retrieves rows row-by-row rather than retrieving the whole result set
mysqldump -u$DB_USER -p$DB_PASS --all-databases --single-transaction --quick --events | gzip > $BACKUP_DIR/full_dump_$DATE.sql.gz

# Clean up files older than 7 days
find $BACKUP_DIR -type f -name "*.sql.gz" -mtime +7 -exec rm {} \;

echo "Database backup complete: full_dump_$DATE.sql.gz"

Pro Tip: Never run backups as the `root` MySQL user. Create a dedicated user with `SELECT`, `LOCK TABLES`, and `SHOW VIEW` privileges only. This minimizes risk if your backup script credentials are compromised.

Step 2: File System Synchronization

For static files (images, uploads, configuration), rsync is the king. Unlike FTP, which transfers everything every time, rsync only transfers the deltas (changes). This saves bandwidth and reduces I/O load, which is vital if you aren't yet on SSD storage infrastructure.

However, simply copying files to another folder on the same server is useless if the server melts. We need to push this off-site.

The Push Strategy

We will use an SSH key pair to allow our web server to push backups to a storage server securely without a password prompt.

# On the source server (Web Server)
ssh-keygen -t rsa -b 4096
# Copy the public key to your backup storage server
ssh-copy-id user@backup.coolvds-storage.net

Now, let's script the file backup. This script archives the web root and sends it away.

#!/bin/bash

SOURCE_DIR="/var/www/html"
REMOTE_DEST="user@backup.coolvds-storage.net:/home/user/backups/"
LOG_FILE="/var/log/backup_job.log"

echo "Starting rsync job at $(date)" >> $LOG_FILE

# -a: archive mode (preserves permissions, times, owners)
# -v: verbose
# -z: compress during transfer
# --delete: remove files on destination that no longer exist on source (Be careful!)
rsync -avz --delete $SOURCE_DIR $REMOTE_DEST >> $LOG_FILE 2>&1

if [ $? -eq 0 ]; then
    echo "Rsync successful" >> $LOG_FILE
else
    echo "Rsync FAILED" >> $LOG_FILE
    # Send alert email (requires mailx)
    echo "Backup Failed" | mail -s "ALERT: Backup Failed on $(hostname)" admin@example.com
fi

Step 3: Encryption and Compliance

We operate in Europe. Even before the strict enforcement of upcoming regulations, the Norwegian Datatilsynet has made it clear that personal data must be secured. If you are dumping customer databases to a remote server, that file must be encrypted.

We can pipe our gzip output directly through GPG before it even hits the disk. This is a "Battle-Hardened" technique that saves disk space and secures data instantly.

# Encrypting on the fly
mysqldump -u$DB_USER -p$DB_PASS --all-databases --single-transaction | gzip | gpg -c --passphrase "YourSecretPassphrase" --cipher-algo AES256 -o $BACKUP_DIR/db_$DATE.sql.gz.gpg

Note: Storing the passphrase in the script is a risk. For higher security, use GPG keys, but for this tutorial, we focus on the mechanics of the pipe.

The CoolVDS Advantage: Infrastructure that Supports You

Scripts are great, but they depend on the underlying hardware. One of the biggest challenges with backups is "I/O Wait". When `mysqldump` or `tar` runs, it reads gigabytes of data. On traditional SATA hard drives, this can cause your website to become unresponsive during the backup window.

At CoolVDS, we deploy strictly on high-performance SSD storage arrays with KVM virtualization.

This hardware difference means you can run backups more frequently—every hour instead of every night—without degrading the user experience. Furthermore, hosting your data in Oslo ensures compliance with Norwegian privacy laws, keeping your data within legal jurisdiction.

Final Thoughts: Automation is Peace of Mind

Set these scripts up in your /etc/crontab. Test the restore process—a backup is not a backup until you have successfully restored from it. Do not wait for a hardware failure or a hacker to teach you this lesson.

If you are looking for a platform that respects your need for raw performance, low latency, and managed hosting support when things get tricky, it is time to upgrade.

Don't let slow I/O kill your backup strategy. Deploy a high-performance KVM instance on CoolVDS today and secure your data properly.