Geautomatiseerde VPS Back-upstrategieën

Back-ups zijn iets waarvan je wenst dat je ze gisteren al had ingesteld. Deze gids behandelt alles van snelle scripts tot onfeilbare geautomatiseerde back-upsystemen.

Waarom Dit Belangrijk Is

Je VPS zal het uiteindelijk begeven. Hardware gaat dood, datacenters hebben storingen, je voert een verkeerd commando uit, of ransomware vindt je. De vraag is niet óf je back-ups nodig hebt, maar wanneer.

Wat er mis kan gaan zonder back-ups:

• Per ongeluk rm -rf / in de verkeerde map
• Databasecorruptie tijdens een update
• Provider heeft een storing en verliest je gegevens
• Malware versleutelt alles
• Jaren werk, in seconden verdwenen

De 3-2-1 Regel:

• 3 kopieën van je gegevens
• 2 verschillende opslagtypen
• 1 offsite locatie

Vereisten

• Een VPS (we raden Hostinger VPS aan, dat bij de meeste abonnementen automatische back-ups bevat)
• Externe opslag (S3, Backblaze B2, een andere server, enz.)
• Basiskennis van shell scripting

Stap 1: Bepaal Wat Je Moet Back-uppen

Niet alles hoeft te worden geback-upt. Concentreer je op:

Verplicht back-uppen:

• Databases (PostgreSQL, MySQL, MongoDB)
• Gebruikersbestanden en media
• Configuratiebestanden
• SSL-certificaten
• Omgevingsbestanden (.env)

Optioneel (kan opnieuw worden aangemaakt):

• Applicatiecode (als die in git staat)
• Docker-images (als die in een registry staan)
• Systeempakketten (opnieuw installeerbaar)

Niet back-uppen:

• Logbestanden (meestal)
• Cachemappen
• Tijdelijke bestanden
• node_modules, vendor, enz.

Stap 2: Lokale Back-ups Instellen

Maak een back-upmapstructuur aan:

sudo mkdir -p /backups/{daily,weekly,monthly}
sudo chown $USER:$USER /backups

Basis back-upscript:

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

set -e

DATE=$(date +%Y-%m-%d_%H-%M)
BACKUP_DIR="/backups/daily"
RETENTION_DAYS=7

# Create backup directory
mkdir -p "$BACKUP_DIR/$DATE"

# Backup PostgreSQL
echo "Backing up PostgreSQL..."
docker exec postgres pg_dumpall -U postgres | gzip > "$BACKUP_DIR/$DATE/postgres.sql.gz"

# Backup MySQL
echo "Backing up MySQL..."
docker exec mysql mysqldump -u root -p"$MYSQL_ROOT_PASSWORD" --all-databases | gzip > "$BACKUP_DIR/$DATE/mysql.sql.gz"

# Backup application data
echo "Backing up app data..."
tar -czf "$BACKUP_DIR/$DATE/app-data.tar.gz" /home/deploy/apps/*/data/ 2>/dev/null || true

# Backup configurations
echo "Backing up configs..."
tar -czf "$BACKUP_DIR/$DATE/configs.tar.gz" \
  /etc/nginx/sites-available \
  /etc/letsencrypt \
  /home/deploy/apps/*/.env \
  /home/deploy/apps/*/docker-compose.yml \
  2>/dev/null || true

# Remove old backups
echo "Cleaning old backups..."
find "$BACKUP_DIR" -type d -mtime +$RETENTION_DAYS -exec rm -rf {} + 2>/dev/null || true

echo "Local backup completed: $BACKUP_DIR/$DATE"

Maak het uitvoerbaar:

chmod +x /usr/local/bin/backup-local.sh

Stap 3: Externe Back-ups Instellen met Restic

Restic is een modern back-uptool met versleuteling en deduplicatie.

Installeer Restic:

sudo apt install restic -y

Optie A: Backblaze B2 (Goedkoopst)

Maak een B2-account en bucket aan, dan:

# Set environment variables
export B2_ACCOUNT_ID="your-account-id"
export B2_ACCOUNT_KEY="your-account-key"
export RESTIC_REPOSITORY="b2:your-bucket-name:backups"
export RESTIC_PASSWORD="your-encryption-password"

# Initialize repository (only once)
restic init

# Run backup
restic backup /home/deploy/apps /etc/nginx /etc/letsencrypt

# Check snapshots
restic snapshots

Optie B: AWS S3

export AWS_ACCESS_KEY_ID="your-key"
export AWS_SECRET_ACCESS_KEY="your-secret"
export RESTIC_REPOSITORY="s3:s3.amazonaws.com/your-bucket/backups"
export RESTIC_PASSWORD="your-encryption-password"

restic init
restic backup /home/deploy/apps

Optie C: Een Andere Server via SFTP

export RESTIC_REPOSITORY="sftp:user@backup-server:/backups"
export RESTIC_PASSWORD="your-encryption-password"

restic init
restic backup /home/deploy/apps

Stap 4: Volledig Back-upscript

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

set -e

# Configuration
export RESTIC_REPOSITORY="b2:mybucket:vps-backups"
export RESTIC_PASSWORD_FILE="/root/.restic-password"
export B2_ACCOUNT_ID="your-id"
export B2_ACCOUNT_KEY="your-key"

BACKUP_DIR="/tmp/backup-$(date +%Y%m%d)"
LOG_FILE="/var/log/backup.log"

log() {
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] $1" | tee -a "$LOG_FILE"
}

# Create temp directory
mkdir -p "$BACKUP_DIR"

log "Starting backup..."

# Dump databases
log "Dumping PostgreSQL..."
docker exec -t postgres pg_dumpall -U postgres > "$BACKUP_DIR/postgres.sql" 2>/dev/null || log "PostgreSQL dump failed or not running"

log "Dumping MySQL..."
docker exec -t mysql mysqldump -u root -p"${MYSQL_ROOT_PASSWORD}" --all-databases > "$BACKUP_DIR/mysql.sql" 2>/dev/null || log "MySQL dump failed or not running"

# Backup Redis
log "Backing up Redis..."
docker exec -t redis redis-cli BGSAVE 2>/dev/null || true
sleep 2
docker cp $(docker ps -qf name=redis):/data/dump.rdb "$BACKUP_DIR/redis.rdb" 2>/dev/null || log "Redis backup failed or not running"

# Backup files with restic
log "Running restic backup..."
restic backup \
    --verbose \
    --exclude='*.log' \
    --exclude='node_modules' \
    --exclude='.git' \
    --exclude='__pycache__' \
    --exclude='.cache' \
    "$BACKUP_DIR" \
    /home/deploy/apps \
    /etc/nginx \
    /etc/letsencrypt

# Cleanup old snapshots (keep 7 daily, 4 weekly, 6 monthly)
log "Pruning old backups..."
restic forget \
    --keep-daily 7 \
    --keep-weekly 4 \
    --keep-monthly 6 \
    --prune

# Cleanup temp directory
rm -rf "$BACKUP_DIR"

# Check repository health
log "Checking repository..."
restic check

log "Backup completed successfully!"

# Optional: Send notification
# curl -X POST "https://api.pushover.net/1/messages.json" \
#     -d "token=xxx&user=xxx&message=Backup completed"

Maak een wachtwoordbestand aan:

echo "your-secure-password" | sudo tee /root/.restic-password
sudo chmod 600 /root/.restic-password

Stap 5: Plannen met Cron

# Edit crontab
sudo crontab -e

Voeg toe:

# Daily backup at 3 AM
0 3 * * * /usr/local/bin/backup-full.sh >> /var/log/backup.log 2>&1

# Weekly integrity check on Sundays at 4 AM
0 4 * * 0 restic check --read-data-subset=10% >> /var/log/backup-check.log 2>&1

Stap 6: Herstelprocedures

Weet hoe je moet herstellen VOORDAT je het nodig hebt.

Herstellen vanuit Restic

# List snapshots
restic snapshots

# Restore specific snapshot
restic restore latest --target /restore-point

# Restore specific files
restic restore latest --target /restore-point --include "/home/deploy/apps/myapp"

# Mount backups (browse like filesystem)
mkdir /mnt/restic
restic mount /mnt/restic
# Browse at /mnt/restic/snapshots/

PostgreSQL Herstellen

# Drop and recreate database
docker exec -it postgres psql -U postgres -c "DROP DATABASE myapp;"
docker exec -it postgres psql -U postgres -c "CREATE DATABASE myapp;"

# Restore
cat backup/postgres.sql | docker exec -i postgres psql -U postgres

MySQL Herstellen

cat backup/mysql.sql | docker exec -i mysql mysql -u root -p"$MYSQL_ROOT_PASSWORD"

Stap 7: Test Je Back-ups

Ongeteste back-ups zijn geen back-ups. Plan maandelijkse hersteltests:

#!/bin/bash
# /usr/local/bin/test-restore.sh

TEST_DIR="/tmp/restore-test-$(date +%Y%m%d)"
mkdir -p "$TEST_DIR"

echo "Restoring latest snapshot to $TEST_DIR..."
restic restore latest --target "$TEST_DIR"

# Verify database dump is valid
echo "Verifying PostgreSQL dump..."
head -20 "$TEST_DIR/tmp/backup-*/postgres.sql"

# Check file integrity
echo "Checking restored files..."
find "$TEST_DIR" -type f | wc -l

# Cleanup
rm -rf "$TEST_DIR"

echo "Restore test completed. Review output above."

Stap 8: Back-upmonitoring

Ontvang een melding wanneer back-ups mislukken:

#!/bin/bash
# Add to end of backup script

HEALTHCHECK_URL="https://hc-ping.com/your-uuid"

# On success
curl -fsS --retry 3 "$HEALTHCHECK_URL"

# On failure (add to trap)
trap 'curl -fsS --retry 3 "$HEALTHCHECK_URL/fail"' ERR

Gebruik Healthchecks.io (gratis tier beschikbaar) voor monitoring:

• Ontvang een melding als de back-up niet wordt uitgevoerd
• Houd de back-upduur bij over de tijd
• Bekijk de back-upgeschiedenis

Stap 9: Databasespecifieke Strategieën

PostgreSQL Continue Archivering (WAL)

Voor nul gegevensverlies:

# postgresql.conf
archive_mode = on
archive_command = 'restic backup --tag wal %p'

MySQL Binaire Logbestanden

# my.cnf
log-bin = /var/log/mysql/mysql-bin.log
expire_logs_days = 7

MongoDB

# Use mongodump for consistent backups
mongodump --archive --gzip | restic backup --stdin --stdin-filename mongo.archive.gz

Back-upstrategieën Vergeleken

Strategie	RPO	Kosten	Complexiteit
Dagelijkse dumps	24u	Laag	Laag
Uurlijkse dumps	1u	Gemiddeld	Laag
WAL-archivering	Minuten	Gemiddeld	Gemiddeld
Replicatie	Seconden	Hoog	Hoog

RPO = Recovery Point Objective (maximale hoeveelheid gegevens die je kunt verliezen)

Best Practices

1. Versleutel alles - Back-ups bevatten gevoelige gegevens
2. Test maandelijks herstelprocedures - Een back-up die je niet kunt herstellen is waardeloos
3. Meerdere bestemmingen - Zet niet al je back-ups op één plek
4. Monitor back-uptaken - Weet direct wanneer ze mislukken
5. Documenteer procedures - Schrijf runbooks voor herstelprocedures
6. Automatiseer alles - Handmatige back-ups worden vergeten
7. Versiebeheer voor je back-upscripts - Bewaar ze in git
8. Gescheiden back-upinloggegevens - Beperk de schade als ze worden gecompromitteerd

Veelgemaakte Fouten om te Vermijden

❌ Alleen lokale back-ups - Als de server sterft, gaan de back-ups mee

❌ Nooit herstelprocedures testen - Je ontdekt corruptie precies wanneer je de gegevens het hardst nodig hebt

❌ Geen versleuteling - Back-upopslag wordt gehackt, alle gegevens worden blootgesteld

❌ Back-up maken van draaiende databases - Beschadigde dumps die niet hersteld kunnen worden

❌ Geen retentiebeleid - Opslag loopt vol, back-ups stoppen

❌ Dezelfde inloggegevens overal - Een aanvaller verwijdert ook de back-ups

❌ Geen monitoring - Back-ups mislukken stilletjes gedurende weken

❌ Back-upwachtwoord samen met back-ups opslaan - Maakt versleuteling volledig zinloos

Noodhersteloverzicht

Wanneer er een ramp plaatsvindt:

1. Raak niet in paniek - Overhaast herstel veroorzaakt meer schade
2. Beoordeel de schade - Wat is er precies verloren gegaan?
3. Start een nieuwe server - Hostinger VPS kan binnen minuten een nieuwe server gereed hebben. Volg onze VPS-beveiligingsgids bij het instellen
4. Herstel de laatste back-up - Gebruik je gedocumenteerde procedure
5. Herstel databases - Controleer de gegevensintegriteit
6. Werk DNS bij indien nodig - Verwijs naar de nieuwe server
7. Documenteer wat er is gebeurd - Een post-mortem voorkomt herhaling

Veelgestelde Vragen

Hoe vaak moet ik back-ups maken?

Dat hangt af van hoeveel gegevensverlies je je kunt permitteren. De meeste sites: dagelijks. E-commerce/financieel: elk uur. Kritieke systemen: continue replicatie.

Waar moet ik back-ups opslaan?

Bij een andere provider dan je VPS. Als Hostinger je server host, gebruik dan Backblaze B2 of AWS S3 voor back-ups. Gebruik nooit dezelfde provider voor productie en back-ups.

Hoe lang moet ik back-ups bewaren?

7 dagelijks + 4 wekelijks + 12 maandelijks is een goed uitgangspunt. Pas aan op basis van compliancevereisten en opslagkosten.

Zijn provider-snapshots voldoende?

Nee. Snapshots zijn handig, maar ze bevinden zich in hetzelfde datacenter. Gebruik ze voor snelle terugdraaiacties, niet voor noodherstel.

Hoe maak ik een back-up van Docker-volumes?

Als je een Docker Compose-stack gebruikt, stop de container kort, of gebruik tools voor volumeback-up:

docker run --rm -v myvolume:/data -v /backups:/backup alpine tar czf /backup/myvolume.tar.gz /data

Is Restic beter dan duplicity/borg?

Ze zijn allemaal goed. Restic heeft de beste ondersteuning voor cloudopslag. Borg is het snelst voor lokaal/SFTP. Kies er één en houd je eraan.

---

Volgende stappen: Stel monitoring in om problemen op te sporen voordat je die back-ups nodig hebt!