Automatisierte VPS-Backup-Strategien

Backups sind das, was man sich wünscht, gestern eingerichtet zu haben. Dieser Leitfaden behandelt alles von schnellen Skripten bis hin zu narrensicheren automatisierten Backup-Systemen.

Warum das wichtig ist

Ihr VPS wird ausfallen. Hardware stirbt, Rechenzentren haben Ausfälle, Sie werden einen falschen Befehl ausführen, oder Ransomware wird Sie finden. Die Frage ist nicht ob Sie Backups brauchen werden – sondern wann.

Was ohne Backups schiefgehen kann:

• Versehentliches rm -rf / im falschen Verzeichnis
• Datenbankkorruption bei einem Update
• Der Anbieter hat einen Ausfall und verliert Ihre Daten
• Malware verschlüsselt alles
• Jahre an Arbeit, in Sekunden verloren

Die 3-2-1-Regel:

• 3 Kopien Ihrer Daten
• 2 verschiedene Speichertypen
• 1 Offsite-Standort

Voraussetzungen

• Ein VPS (wir empfehlen Hostinger VPS, das in den meisten Tarifen automatische Backups enthält)
• Externer Speicher (S3, Backblaze B2, ein anderer Server usw.)
• Grundlegende Shell-Scripting-Kenntnisse

Schritt 1: Bestimmen, was gesichert werden soll

Nicht alles muss gesichert werden. Konzentrieren Sie sich auf:

Muss gesichert werden:

• Datenbanken (PostgreSQL, MySQL, MongoDB)
• Benutzer-Uploads und Medien
• Konfigurationsdateien
• SSL-Zertifikate
• Umgebungsdateien (.env)

Optional (kann neu erstellt werden):

• Anwendungscode (wenn in git)
• Docker-Images (wenn in einer Registry)
• Systempakete (neu installierbar)

Nicht sichern:

• Logs (normalerweise)
• Cache-Verzeichnisse
• Temporäre Dateien
• node_modules, vendor usw.

Schritt 2: Lokale Backups einrichten

Erstellen Sie eine Backup-Verzeichnisstruktur:

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

Einfaches Backup-Skript:

#!/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"

Ausführbar machen:

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

Schritt 3: Remote-Backups mit Restic einrichten

Restic ist ein modernes Backup-Tool mit Verschlüsselung und Deduplizierung.

Restic installieren:

sudo apt install restic -y

Option A: Backblaze B2 (Günstigste Option)

Erstellen Sie ein B2-Konto und einen Bucket, dann:

# 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

Option 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

Option C: Weiterer Server via SFTP

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

restic init
restic backup /home/deploy/apps

Schritt 4: Vollständiges Backup-Skript

#!/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"

Passwortdatei erstellen:

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

Schritt 5: Mit Cron planen

# Edit crontab
sudo crontab -e

Hinzufügen:

# 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

Schritt 6: Wiederherstellungsverfahren

Lernen Sie, wie man wiederherstellt, BEVOR Sie es brauchen.

Wiederherstellung aus 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 wiederherstellen

# 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 wiederherstellen

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

Schritt 7: Backups testen

Ungetestete Backups sind keine Backups. Planen Sie monatliche Wiederherstellungstests:

#!/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."

Schritt 8: Backup-Überwachung

Lassen Sie sich benachrichtigen, wenn Backups fehlschlagen:

#!/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

Verwenden Sie Healthchecks.io (kostenloser Tarif verfügbar) zur Überwachung:

• Benachrichtigung, wenn ein Backup nicht ausgeführt wird
• Backup-Dauer im Zeitverlauf verfolgen
• Backup-Verlauf anzeigen

Schritt 9: Datenbankspezifische Strategien

PostgreSQL Continuous Archiving (WAL)

Für null Datenverlust:

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

MySQL Binary Logs

# 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

Backup-Strategien im Vergleich

Strategie	RPO	Kosten	Komplexität
Tägliche Dumps	24h	Niedrig	Niedrig
Stündliche Dumps	1h	Mittel	Niedrig
WAL-Archivierung	Minuten	Mittel	Mittel
Replikation	Sekunden	Hoch	Hoch

RPO = Recovery Point Objective (maximaler Datenverlust, den Sie sich leisten können)

Best Practices

1. Alles verschlüsseln – Backups enthalten sensible Daten
2. Wiederherstellungen monatlich testen – Ein Backup, das sich nicht wiederherstellen lässt, ist wertlos
3. Mehrere Zielorte – Legen Sie nicht alle Backups an einem Ort ab
4. Backup-Jobs überwachen – Sofort wissen, wenn sie fehlschlagen
5. Verfahren dokumentieren – Runbooks für Wiederherstellungen schreiben
6. Alles automatisieren – Manuelle Backups werden vergessen
7. Backup-Skripte versionieren – In git aufbewahren
8. Separate Backup-Anmeldedaten – Schadensradius bei Kompromittierung begrenzen

Häufige Fehler, die vermieden werden sollten

❌ Nur lokale Backups – Server stirbt, Backups sterben mit ihm

❌ Wiederherstellungen nie testen – Korruption wird entdeckt, wenn man die Daten am dringendsten braucht

❌ Keine Verschlüsselung – Backup-Speicher wird gehackt, alle Daten werden offengelegt

❌ Laufende Datenbanken sichern – Beschädigte Dumps, die sich nicht wiederherstellen lassen

❌ Keine Aufbewahrungsrichtlinie – Speicher füllt sich, Backups hören auf

❌ Gleiche Anmeldedaten überall – Angreifer löscht auch Backups

❌ Keine Überwachung – Backups schlagen still wochenlang fehl

❌ Backup-Passwort mit Backups speichern – Untergräbt die Verschlüsselung vollständig

Notfall-Wiederherstellungs-Checkliste

Wenn eine Katastrophe eintritt:

1. Nicht in Panik geraten – Überstürzte Wiederherstellung verursacht mehr Schaden
2. Den Schaden einschätzen – Was genau ist verloren?
3. Neuen Server aufsetzen – Hostinger VPS kann in Minuten einen neuen Server bereitstellen. Folgen Sie unserem VPS-Sicherheitsleitfaden beim Einrichten
4. Letztes Backup wiederherstellen – Dokumentiertes Verfahren verwenden
5. Datenbanken wiederherstellen – Datenintegrität prüfen
6. DNS aktualisieren, falls nötig – Auf neuen Server zeigen
7. Dokumentieren, was passiert ist – Post-mortem verhindert Wiederholungen

FAQ

Wie oft sollte ich Backups erstellen?

Hängt davon ab, wie viel Datenverlust Sie sich leisten können. Die meisten Websites: täglich. E-Commerce/Finanzen: stündlich. Kritische Systeme: kontinuierliche Replikation.

Wo sollte ich Backups speichern?

Bei einem anderen Anbieter als Ihrem VPS. Wenn Hostinger Ihren Server hostet, verwenden Sie Backblaze B2 oder AWS S3 für Backups. Niemals denselben Anbieter für Produktion und Backups.

Wie lange sollte ich Backups aufbewahren?

7 täglich + 4 wöchentlich + 12 monatlich ist ein guter Ausgangspunkt. Anpassen basierend auf Compliance-Anforderungen und Speicherkosten.

Reichen Anbieter-Snapshots aus?

Nein. Snapshots sind praktisch, befinden sich aber im selben Rechenzentrum. Verwenden Sie sie für schnelle Rollbacks, nicht für die Notfallwiederherstellung.

Wie sichere ich Docker-Volumes?

Wenn Sie einen Docker Compose Stack betreiben, stoppen Sie den Container kurz oder verwenden Sie Volume-Backup-Tools:

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

Ist Restic besser als duplicity/borg?

Alle sind gut. Restic hat die beste Cloud-Speicher-Unterstützung. Borg ist am schnellsten für lokal/SFTP. Wählen Sie eines und bleiben Sie dabei.

---

Nächste Schritte: Richten Sie Monitoring ein, um Probleme zu erkennen, bevor Sie diese Backups brauchen!