The Art of Paranoia: Automated Backup Strategies for the Norwegian Sysadmin

Let’s get one thing straight immediately: RAID is not a backup.

I cannot count the number of times I have walked into a crisis meeting in Oslo where a CTO is sweating through their shirt because a RAID controller corrupted data across all mirrored drives, or worse, someone fat-fingered rm -rf /var/www on the wrong terminal. RAID provides redundancy against hardware failure. It provides zero protection against human stupidity, software corruption, or malicious intrusion.

If you are managing servers in 2012, you need a robust, automated, and off-site backup strategy. And if you are dealing with Norwegian customer data, you have Datatilsynet breathing down your neck to ensure that data is handled according to Personopplysningsloven (Personal Data Act).

Here is how we build a battle-hardened backup solution that lets you sleep at night.

The 3-2-1 Rule (It Still Applies)

Before we touch a single line of Bash, memorize this architecture. It is the only thing standing between you and unemployment:

• 3 copies of your data (Production + 2 backups).
• 2 different media types (e.g., your server's SSD and an external storage array).
• 1 copy off-site (If your datacenter in Oslo floods, your backup in Bergen survives).

Scripting the Solution: Rsync is King

Forget expensive enterprise bloatware. The most reliable tool for file-level backups on Linux is rsync. It is efficient, it handles incremental changes natively, and it encrypts data in transit via SSH.

Here is a production-grade script I use on CentOS 6 and Ubuntu 12.04 LTS systems. It rotates snapshots so you can go back in time, not just to yesterday.

#!/bin/bash
# /usr/local/bin/backup-rotate.sh

SOURCE_DIR="/var/www/html"
BACKUP_ROOT="/mnt/backups"
DATE=$(date +%Y-%m-%d)

# Ensure the backup directory exists
mkdir -p $BACKUP_ROOT

# Rotate old backups (simple 3-day rotation example)
if [ -d "$BACKUP_ROOT/backup.2" ]; then
  rm -rf $BACKUP_ROOT/backup.2
fi
if [ -d "$BACKUP_ROOT/backup.1" ]; then
  mv $BACKUP_ROOT/backup.1 $BACKUP_ROOT/backup.2
fi
if [ -d "$BACKUP_ROOT/backup.0" ]; then
  cp -al $BACKUP_ROOT/backup.0 $BACKUP_ROOT/backup.1
fi

# Perform the rsync
# -a: archive mode (preserves permissions, owners, times)
# -v: verbose
# --delete: delete files in backup that are gone in source
rsync -av --delete $SOURCE_DIR $BACKUP_ROOT/backup.0/

logger "Backup for $DATE completed successfully."

Pro Tip: The cp -al command creates hard links. This means your "copy" takes up almost zero space unless files have changed. This is how you get "Time Machine" style backups on a Linux server without filling up your disk in a week.

The Database Dilemma: MySQL Consistency

Backing up files is easy. Backing up a running database without locking it up for five minutes (and killing your storefront) is the real challenge. If you just copy /var/lib/mysql while the server is running, you will get corrupted tables.

For MySQL 5.5 (standard on most CoolVDS instances), the approach depends on your storage engine. If you are still using MyISAM, you are forced to lock tables. If you have migrated to InnoDB (which you should), you can use the --single-transaction flag to dump data without locking the site.

#!/bin/bash
# MySQL Backup Script

USER="root"
PASSWORD="CorrectHorseBatteryStaple"
OUTPUT="/mnt/backups/db/db_$(date +%F).sql.gz"

# Dump, compress, and secure
mysqldump -u $USER -p$PASSWORD --all-databases --single-transaction --quick --lock-tables=false | gzip > $OUTPUT

# restrict permission immediately
chmod 600 $OUTPUT

Warning: Be extremely careful putting passwords in scripts. Ensure the script file itself is chmod 700 and owned by root.

Network Latency and Off-site Storage

Norway has unique geography. If your primary VPS is in Oslo, you want your off-site backup relatively close to keep transfer speeds high, but far enough to avoid shared physical risks. Transferring 50GB of data nightly to a server in the US is going to be painful due to latency and bandwidth caps.

We recommend using a secondary VPS in a different datacenter, or a dedicated storage service accessible via SCP/SFTP. Leveraging the NIX (Norwegian Internet Exchange) peering points ensures that traffic between major Norwegian ISPs stays within the country, keeping latency low (often sub-5ms) and throughput high.

Legal Compliance: The Datatilsynet Factor

Technical implementation is only half the battle. In Norway, the Personopplysningsloven places strict requirements on how you secure personal data.

If you are dumping customer databases to an unencrypted text file and FTP-ing it to a server in a non-EU/EEA country, you are likely violating the law. With the uncertainty regarding the US Safe Harbor framework, keeping data within Europe—and preferably within Norway—is the safest bet for compliance.

Always encrypt your backups before they leave your server. Here is a quick way to do it with OpenSSL on the fly:

tar -czf - /var/www/html | openssl des3 -salt -k "YourSecretPass" | dd of=/mnt/external_drive/backup.tar.gz.des3

Why Infrastructure Matters: The CoolVDS Advantage

Your backup script is only as fast as your disk I/O. On traditional shared hosting or budget VPS providers using oversold SATA drives, running an rsync or a large mysqldump causes "iowait" to spike. This steals CPU cycles from your web server, causing your site to load slowly for visitors while the backup runs.

This is where CoolVDS architecture makes a difference. We utilize enterprise-grade SSD storage configurations. The high IOPS (Input/Output Operations Per Second) of SSDs means your backup tasks complete in seconds rather than minutes, without choking the system.

Furthermore, because CoolVDS uses KVM virtualization (Kernel-based Virtual Machine) rather than container-based tech like OpenVZ, you have full control over your kernel modules. This allows you to install advanced backup agents (like R1Soft) or mount FUSE filesystems for encrypted remote storage without hitting "permission denied" errors common on shared kernels.

The Final Step: Automation

A manual backup is a forgotten backup. Add your scripts to /etc/crontab and check your logs.

# /etc/crontab
# Run file backup at 03:00 AM
0 3 * * * root /usr/local/bin/backup-rotate.sh

# Run DB backup at 03:30 AM
30 3 * * * root /usr/local/bin/backup-db.sh

Don't wait for a disaster to test your recovery plan. Spin up a test instance on CoolVDS today, break it intentionally, and see if you can restore it. Trust me, you do not want to be learning how to restore a MySQL database at 4:00 AM on a Saturday while your boss is calling you.