The Paranoia That Saves Your Job

There are two types of system administrators: those who have lost data, and those who will. In 2010, I watched a junior developer accidentally run a drop table command on a production Magento database. The site was handling thousands of kroner in transactions per hour. The blood drained from his face.

We were back online in 15 minutes. Not because we were lucky, but because we were paranoid. We had a remote dump sync running every hour.

If you are relying on manual FTP transfers or, God forbid, believing that your RAID-10 array constitutes a "backup strategy," you are negligent. Hard drives fail. File systems corrupt. Datacenters have power outages (even in stable Norway). Today, we implement the industry standard for 2012: automated, encrypted, incremental backups using rsync and cron.

The Golden Rule: RAID != Backup

Let’s get this out of the way. CoolVDS offers enterprise-grade RAID-10 on our SAS and SSD nodes. This protects you against hardware failure. It does not protect you against human stupidity, malicious hacking, or rm -rf /.

For true disaster recovery, your data must exist in two physical locations. If your primary VPS is in Oslo, your backup should be in a different facility, perhaps even outside the firewall.

Why rsync?

We don't use heavy commercial backup agents that chew up RAM. We use rsync. It has been around since 1996 for a reason.

• Delta Transfer: It only sends the parts of files that changed. If you have a 10GB log file and append 1KB of text, rsync sends 1KB. This saves massive amounts of bandwidth.
• Security: It runs over SSH. Your data is encrypted in transit.
• Preservation: It keeps permissions, ownerships, and timestamps intact.

Step 1: Passwordless SSH Authentication

Automation fails if it stops to ask for a password. You need an SSH key pair. Assume Server A is your production CoolVDS node, and Server B is your backup storage.

On Server A (as root or your backup user):

Press enter through the prompts. Do not set a passphrase. Now, copy the public key to your backup server:

Test it: ssh user@backup-server-ip. If you get in without a password, you’re ready.

Step 2: The Script

Don't just put the command in cron. Put it in a script so you can add logging and error handling. Create /root/scripts/nightly_backup.sh:

#!/bin/bash

# Configuration
SOURCE_DIR="/var/www/html/"
DEST_IP="192.168.1.50"
DEST_DIR="/home/backup/"
LOG_FILE="/var/log/rsync_backup.log"

echo "Starting backup at $(date)" >> $LOG_FILE

# The heavy lifting
# -a: archive mode (preserves permissions, times, etc)
# -v: verbose
# -z: compress during transfer
# --delete: remove files on destination that no longer exist on source

rsync -avz --delete -e ssh $SOURCE_DIR user@$DEST_IP:$DEST_DIR >> $LOG_FILE 2>&1

if [ $? -eq 0 ]; then
    echo "Backup Success at $(date)" >> $LOG_FILE
else
    echo "Backup FAILED at $(date)" >> $LOG_FILE
    # In a real setup, pipe this to sendmail here
fi

Make it executable: chmod +x /root/scripts/nightly_backup.sh.

Pro Tip: Database Consistency
Rsyncing a running MySQL database leads to corruption. Always run mysqldump to a file before the rsync command runs. Include the dump file in the rsync directory.

Step 3: Scheduling with Cron

We want this to run at 3:00 AM, when traffic is lowest. In Norway, traffic to NIX (Norwegian Internet Exchange) usually dips significantly between 02:00 and 05:00.

Run crontab -e and add:

The Infrastructure Factor

Scripts are great, but the pipe matters. If you are pushing gigabytes of data nightly, you need a host that doesn't throttle your uplink.

This is where the architecture of the provider becomes critical. At CoolVDS, we don't oversell our bandwidth. Our nodes in Oslo are connected via high-capacity uplinks directly to major peering points. Whether you are moving data to a backup server in Frankfurt or a local NAS in Stavanger, the latency is minimal.

Furthermore, standard IOPS on cheap VPS providers choke during backups. When rsync scans millions of small files (common in PHP frameworks), it generates high I/O wait (iowait). This slows down your website. We utilize high-performance storage arrays specifically tuned to handle this mixed workload without degrading your web server's response time.

Compliance & The "Datatilsynet" Angle

Under the Norwegian Personal Data Act (Personopplysningsloven), you have a responsibility to secure sensitive user data. An offsite backup isn't just a technical good practice; it's practically a legal requirement for risk mitigation. If your datacenter catches fire and you lose customer data, "the server burned down" is not an acceptable legal defense.

Final Check

A backup is not a backup until you have restored from it. Tomorrow morning, take your fresh backup and try to spin it up on a development VDS. If it works, you’re safe. If it doesn't, fix your script.

Need a sandbox to test your recovery scripts? Deploy a high-speed CoolVDS instance in 55 seconds and break things safely.