92 ist die hälfte von 99

Proxmox Best Practice Teil 3 – Backup-Strategien: Daten sicher aufbewahren

Willkommen zurück bei den Best Practices für euren Proxmox Server oder euer Proxmox Cluster, heute schauen wir uns das Thema Backup im Detail an. Dazu brauchen wir – Ihr ahnt es bereits – richtig… den Kollegen hier:

Proxmox Backup Server (PBS)

PBS ist die professionelle Backup-Lösung von Proxmox und sollte definitiv auf eurem Radar stehen. Die wichtigsten Vorteile sind nicht nur Marketing-Gerede, sondern machen in der Praxis wirklich einen Unterschied:

  • Deduplication: Identische Datenblöcke werden nur einmal gespeichert – ihr spart damit oft bis zu 90% Speicherplatz
  • Incremental Backups: Nur Änderungen werden gesichert, was eure Backup-Zeiten dramatisch reduziert
  • Verschlüsselung: Client-seitige AES-256-GCM Verschlüsselung – selbst wenn jemand euren Backup-Server kompromittiert
  • Bandbreiten-Begrenzung: Eure Backups laufen im Hintergrund, ohne dass die Produktivsysteme leiden
  • Verify-Jobs: Automatische Integritätsprüfung – ihr wisst immer, ob eure Backups wirklich brauchbar sind
  • Retention Policies: Intelligente Löschregeln sorgen dafür, dass ihr nicht im Backup-Chaos versinkt
  • Web-GUI: Eine moderne Benutzeroberfläche, die tatsächlich Spaß macht zu bedienen

PBS Setup (Grundkonfiguration)

Hardware-Anforderungen und Planung

Bevor ihr loslegt, solltet ihr euch Gedanken über die Hardware machen. Ein PBS-Server ist nur so gut wie die Hardware, auf der er läuft. Hier sind realistische Mindestanforderungen, die sich in der Praxis bewährt haben:

Minimale Hardware-Empfehlungen für PBS:

  • CPU: 4 Kerne (mehr wenn ihr viele VMs parallel sichern wollt)
  • RAM: 8GB absolutes Minimum, 16GB+ wenn ihr „Ernst“ machen wollt
  • Storage: Eine schnelle SSD für Metadaten, große HDDs für die eigentlichen Backup-Daten
  • Netzwerk: Gigabit Ethernet als unterstes Minimum, besser 2,5 oder 5 GBE und 10GbE wenn ihr ständig große Datenmengen bewegt

Die Installation selbst ist erfreulich unkompliziert. Ihr solltet PBS definitiv auf einem separaten physischen Server installieren – ein virtualisierter PBS auf demselben Proxmox-Cluster, den er sichern soll, ist wie einen leeren Feuerlöscher im brennenden Haus zu haben. 😉

# Proxmox Backup Server Repository hinzufügen
echo "deb http://download.proxmox.com/debian/pbs bookworm pbs-no-subscription" > /etc/apt/sources.list.d/pbs.list
wget https://enterprise.proxmox.com/debian/proxmox-release-bookworm.gpg -O /etc/apt/trusted.gpg.d/proxmox-release-bookworm.gpg
apt update && apt install proxmox-backup-server

# Erste Konfiguration - einen Admin-User anlegen
proxmox-backup-manager user create backup@pbs --email admin@example.com
proxmox-backup-manager acl update / Backup@pbs --role Admin

Storage-Konfiguration optimieren

Die Storage-Konfiguration ist das Herzstück eures Backup-Systems. Hier lohnt es sich, etwas Zeit zu investieren. ZFS ist hier oft die beste Wahl, weil ihr damit Snapshots, Kompression und Checksumming out-of-the-box bekommt. Darüber hatten wir im zweiten Teil (Storage) ja auch bereits ausführlich gesprochen.

# ZFS Pool für optimale Performance erstellen
# Spiegelt zwei Disks und nutzt NVMe für Cache und Log
zpool create backup-pool \
  mirror /dev/sdb /dev/sdc \
  cache /dev/nvme0n1p1 \
  log /dev/nvme0n1p2

# Datastore mit durchdachten Retention-Einstellungen
proxmox-backup-manager datastore create backup-storage /backup-pool/data \
  --gc-schedule 'daily' \
  --prune-schedule 'daily' \
  --keep-daily 7 \
  --keep-weekly 4 \
  --keep-monthly 12 \
  --keep-yearly 2 \
  --notify-user backup@pbs

Backup-Jobs konfigurieren

Grundkonfiguration

Jetzt wird’s interessant – die eigentlichen Backup-Jobs. Hier entscheidet sich, ob euer Backup-System ein zuverlässiger Begleiter oder eine Quelle ständiger Frustration wird!

Die CLI-Variante gibt euch deutlich mehr Kontrolle über die Parameter. Besonders wichtig ist die Bandbreitenbegrenzung! Denn niemand will, dass Backups das restliche Netzwerk lahmlegen.

# Backup Job mit allen wichtigen Parametern
pvesh create /cluster/backup \
  --schedule "02:00" \
  --storage backup-pbs \
  --mode snapshot \
  --all 1 \
  --compress zstd \
  --protected 1 \
  --notes-template "{{cluster}}: {{guestname}} - {{job-id}}" \
  --mailnotification always \
  --mailto admin@example.com \
  --bwlimit 50000  # 50MB/s Bandbreitenbegrenzung

Alternativ könnt ihr das Ganze auch bequem über das Web-Interface machen: Datacenter → Backup → Add. Das ist besonders für Einsteiger oft übersichtlicher.

Wichtige Parameter erklärt

Diese Parameter sind entscheidend für ein funktionierendes Backup-System, deshalb hier die wichtigsten im Detail:

Schedule: Hier verwendet ihr das Standard-Cron-Format. 0 2 * * * bedeutet täglich um 2:00 Uhr. Plant eure Backup-Zeiten so, dass sie nicht mit anderen wartungsintensiven Tasks kollidieren.

Mode: Hier habt ihr drei Optionen, die alle ihre Vor- und Nachteile haben:

  • snapshot: Die VM läuft weiter, ihr bekommt einen konsistenten Snapshot. Ideal für Produktivsysteme.
  • suspend: Die VM wird kurz pausiert. Maximale Konsistenz, aber kurze Unterbrechung.
  • stop: VM wird heruntergefahren. Nur für unkritische Systeme empfehlenswert.

Compress: Hier müsst ihr zwischen Geschwindigkeit und Effizienz abwägen:

  • lz4 ist schnell und braucht wenig CPU, komprimiert aber weniger
  • zstd komprimiert deutlich besser, braucht aber mehr Rechenleistung

Protected: Schützt das Backup vor versehentlichem Löschen. Solltet ihr bei wichtigen Backups immer aktivieren.

BWLimit: Bandbreitenbegrenzung in KB/s. 50000 entspricht etwa 50MB/s – passt das an eure Netzwerkinfrastruktur an.

Backup-Verifikation aktivieren

Ein Backup ohne Verifikation ist wie ein Fallschirm ohne Test-Zertifikat – ihr merkt erst, dass es nicht funktioniert, wenn ihr es wirklich braucht, was dann im schlimmsten Fall zu spät sein kann. PBS hilft euch, denn es kann automatisch die Integrität eurer Backups prüfen.

# Verify-Job für automatische Backup-Integrität
pvesh create /admin/verify \
  --store backup-storage \
  --schedule 'weekly' \
  --outdated-after 7 \
  --ignore-verified

Der Verify-Job läuft einmal wöchentlich und prüft alle Backups, die älter als 7 Tage sind. Bereits verifizierte Backups werden übersprungen, um Zeit zu sparen.

3-2-1 Backup-Regel implementieren

Die 3-2-1 Regel verstehen

Die 3-2-1 Regel ist nicht nur ein Marketing-Gag, sondern bewährte Praxis aus Jahrzehnten der Erfahrung mit Datenverlust. Sie besagt:

  • 3 Kopien eurer Daten (1 Original + 2 Backups)
  • 2 verschiedene Medien/Speichertypen (nicht alles auf derselben Technologie)
  • 1 Offsite-Backup (geografisch getrennt – Brand, Ãœberschwemmung, Diebstahl)

Praktische Umsetzung

In einer typischen Proxmox-Umgebung könnte das so aussehen:

  1. Primärdaten: Auf eurem Proxmox-Server mit ZFS und Redundanz
  2. Lokales Backup: Auf dem PBS-Server im selben Rechenzentrum/Büro
  3. Offsite-Backup: PBS-Sync zu einem externen Standort oder Cloud-Provider

Die Remote-Konfiguration ist dabei relativ straightforward, aber ihr müsst auf die Netzwerkverbindung achten. Eine instabile Verbindung kann eure Sync-Jobs zum Albtraum machen.

# Remote-Backup konfigurieren - Fingerprint bekommt ihr vom Ziel-Server
pvesh create /admin/remote \
  --name offsite-backup \
  --host backup.external.com \
  --userid backup@pbs \
  --password "secure_password" \
  --fingerprint AA:BB:CC:DD:EE:FF:00:11:22:33:44:55:66:77:88:99:AA:BB:CC:DD

# Sync-Job mit Bandbreitenbegrenzung - läuft nachts wenn wenig los ist
pvesh create /admin/sync \
  --remote offsite-backup \
  --remote-store production \
  --store local-backup \
  --schedule "04:00" \
  --rate-in 10000 \
  --burst-in 15000 \
  --comment "Nächtlicher Offsite-Sync"

Erweiterte Backup-Strategien

Backup-Retention konfigurieren

Retention-Policies sind oft unterschätzt, aber extrem wichtig. Ohne sinnvolle Regeln sammelt ihr über die Jahre gigabyteweise alte Backups an, die niemand mehr braucht. Gleichzeitig wollt ihr aber auch nicht versehentlich das einzige brauchbare Backup von letztem Monat löschen.

Eine bewährte Strategie ist die „Großvater-Vater-Sohn“ Methode: viele neue Backups, weniger ältere, sehr wenige uralte. PBS macht das automatisch für euch.

# Durchdachte Retention-Policy konfigurieren
proxmox-backup-manager datastore update backup-storage \
  --keep-last 3 \      # Letzten 3 Backups immer behalten (Notfälle)
  --keep-hourly 24 \   # 24 stündliche Backups (letzter Tag)
  --keep-daily 7 \     # 7 tägliche Backups (letzte Woche)
  --keep-weekly 4 \    # 4 wöchentliche Backups (letzter Monat)
  --keep-monthly 12 \  # 12 monatliche Backups (letztes Jahr)
  --keep-yearly 5      # 5 jährliche Backups (Langzeitarchivierung)

Bandbreiten-Management

In Produktionsumgebungen müsst ihr oft mit begrenzter Bandbreite haushalten. Backups sollen nicht die Produktivsysteme ausbremsen, aber auch nicht ewig dauern. Traffic Shaping hilft euch dabei, das richtige Gleichgewicht zu finden.

# Traffic Shaping auf dem PBS-Server einrichten
tc qdisc add dev eth0 root handle 1: htb default 30
tc class add dev eth0 parent 1: classid 1:1 htb rate 1000mbit
tc class add dev eth0 parent 1:1 classid 1:10 htb rate 800mbit ceil 1000mbit
tc class add dev eth0 parent 1:1 classid 1:20 htb rate 200mbit ceil 400mbit

# Backup-Traffic in die langsamere Klasse einordnen
iptables -A OUTPUT -p tcp --dport 8007 -j CLASSIFY --set-class 1:20

Diese Konfiguration reserviert 80% der Bandbreite für normalen Traffic und begrenzt Backups auf maximal 40% – mit der Möglichkeit, ungenutzten Traffic zu nutzen.

Backup-Integration mit Storage

Storage-spezifische Optimierungen

Verschiedene Storage-Typen haben verschiedene Stärken. Nutzt das zu eurem Vorteil, indem ihr Metadaten und große Datenblöcke auf unterschiedlichen Medien speichert.

# Separate Datastores für verschiedene Anforderungen
# Schneller NVMe für Metadaten und kleine Dateien
proxmox-backup-manager datastore create vm-backups-meta \
  /nvme/backup-meta \
  --gc-schedule 'daily' \
  --prune-schedule 'daily'

# Großer RAID für die eigentlichen Backup-Daten
proxmox-backup-manager datastore create vm-backups-data \
  /raid/backup-data \
  --gc-schedule 'weekly' \
  --keep-daily 14 \
  --keep-weekly 8 \
  --keep-monthly 24

# Backup-Job der unnötige Dateien ausschließt
pvesh create /cluster/backup \
  --schedule "02:00" \
  --storage backup-pbs \
  --mode snapshot \
  --compress zstd \
  --notes-template "{{cluster}}: {{guestname}} ({{mode}})" \
  --protected 1 \
  --exclude-path "/tmp/*,/var/log/*,/var/cache/*" # Spart Platz und Zeit

Backup-Strategien nach Storage-Typ

LVM-Thin Snapshots

LVM-Thin Volumes sind weit verbreitet und bieten eine einfache Snapshot-Funktionalität. Der Trick ist, die Snapshots nur so lange zu behalten, wie ihr sie wirklich braucht – sie können die Performance beeinträchtigen.

# Automatisiertes LVM-Snapshot-Backup mit Fehlerbehandlung
create_lvm_backup() {
    local vmid=$1
    local disk_path="/dev/pve/vm-${vmid}-disk-0"
    local snap_name="vm-${vmid}-snap-$(date +%Y%m%d-%H%M%S)"
    
    echo "Erstelle Backup für VM $vmid..."
    
    # Prüfen ob genug Platz für Snapshot vorhanden ist
    if ! lvcreate --test --snapshot --name $snap_name --size 10G $disk_path; then
        echo "Fehler: Nicht genug Platz für Snapshot!"
        return 1
    fi
    
    # Snapshot erstellen - ist quasi instantan
    lvcreate --snapshot --name $snap_name --size 10G $disk_path
    
    # Backup vom Snapshot mit Fortschrittsanzeige
    dd if=/dev/pve/$snap_name bs=64k status=progress | \
      gzip -c > /backup/vm-${vmid}-$(date +%Y%m%d).img.gz
    
    # Snapshot sofort wieder löschen um Performance zu erhalten
    lvremove -f /dev/pve/$snap_name
    
    echo "Backup für VM $vmid abgeschlossen."
}

# Verwendung für VM 100:
# create_lvm_backup 100

ZFS Snapshots

ZFS ist hier deutlich eleganter – Snapshots kosten praktisch nichts und ihr könnt incremental backups machen. Das spart enorm viel Zeit und Bandbreite, besonders bei großen VMs.

# Intelligente ZFS Incremental-Backup-Strategie
zfs_incremental_backup() {
    local dataset=$1
    local remote_host=$2
    local current_snap="${dataset}@backup-$(date +%Y%m%d-%H%M%S)"
    local last_snap=$(zfs list -t snapshot -o name -s creation | grep ${dataset}@ | tail -1)
    
    echo "Erstelle ZFS Backup für $dataset..."
    
    # Neuen Snapshot erstellen - dauert Millisekunden
    zfs snapshot $current_snap
    
    if [ -n "$last_snap" ]; then
        echo "Sende incremental backup seit $last_snap"
        # Nur die Änderungen übertragen - viel schneller
        zfs send -i $last_snap $current_snap | \
          ssh $remote_host "zfs receive -F backup/${dataset##*/}"
    else
        echo "Sende initial full backup"
        # Erstes Backup ist immer vollständig
        zfs send $current_snap | \
          ssh $remote_host "zfs receive backup/${dataset##*/}"
    fi
    
    # Snapshots aufräumen - behalte nur die letzten 7
    local old_snaps=$(zfs list -t snapshot -o name -s creation | grep ${dataset}@ | head -n -7)
    if [ -n "$old_snaps" ]; then
        echo "Lösche alte Snapshots..."
        echo "$old_snaps" | while read snap; do 
            zfs destroy $snap
        done
    fi
    
    echo "ZFS Backup für $dataset abgeschlossen."
}

# Automatisierung für alle VM-Datasets
zfs_replicate_all() {
    echo "Starte ZFS-Replikation für alle VMs..."
    for dataset in $(zfs list -H -o name | grep "tank/vm-"); do
        zfs_incremental_backup $dataset backup-server.local
    done
    echo "ZFS-Replikation abgeschlossen."
}

Monitoring und Alerting

Backup-Status überwachen

Ein Backup-System ohne Monitoring ist wie ein Rauchmelder ohne Batterien – ihr merkt erst, dass es nicht funktioniert, wenn’s zu spät ist. Deshalb solltet ihr unbedingt automatische Checks einrichten.

# Script für Backup-Status-Überwachung
#!/bin/bash
check_backup_status() {
    echo "Überprüfe Backup-Status..."
    
    # Suche nach fehlgeschlagenen Jobs in den letzten 24h
    local failed_jobs=$(pvesh get /cluster/backup --output-format json | \
      jq -r '.[] | select(.state == "error") | .id')
    
    if [ -n "$failed_jobs" ]; then
        echo "ALARM: Backup-Jobs fehlgeschlagen: $failed_jobs"
        
        # E-Mail senden
        echo "Backup-Jobs $failed_jobs sind fehlgeschlagen. Bitte prüfen!" | \
          mail -s "BACKUP FAILURE ALERT" admin@example.com
        
        # Optional: Alert an Monitoring-System
        curl -X POST "https://monitoring.example.com/alert" \
          -H "Content-Type: application/json" \
          -d "{\"message\":\"Backup failures: $failed_jobs\", \"severity\":\"critical\"}"
        
        return 1
    else
        echo "Alle Backup-Jobs laufen normal."
        return 0
    fi
}

# Als Cron-Job alle 2 Stunden ausführen
# 0 */2 * * * /usr/local/bin/check_backup_status.sh

Proxmox Backup Server Health Check

Regelmäßige Gesundheitschecks helfen euch dabei, Probleme zu erkennen, bevor sie kritisch werden. Speicherplatz, Performance und Service-Status solltet ihr im Auge behalten. Das könnte zB. so aussehen:

# Umfassende PBS Gesundheitsprüfung
pbs_health_check() {
    echo "=== PBS Health Check $(date) ==="
    
    # Datastore Status und Speicherplatz
    echo "--- Datastore Status ---"
    proxmox-backup-manager datastore list
    
    echo "--- Speicherplatz ---"
    df -h | grep -E "(backup|pbs)" | while read line; do
        usage=$(echo $line | awk '{print $5}' | tr -d '%')
        if [ $usage -gt 85 ]; then
            echo "WARNUNG: $line - Speicher fast voll!"
        else
            echo "OK: $line"
        fi
    done
    
    # Laufende Prozesse
    echo "--- Aktive Backup-Prozesse ---"
    local active_jobs=$(ps aux | grep -E "(proxmox-backup|pbs)" | grep -v grep | wc -l)
    echo "Aktive Jobs: $active_jobs"
    
    # Verify Jobs Status
    echo "--- Verify Jobs Status ---"
    pvesh get /admin/verify --output-format json | \
      jq -r '.[] | "Job \(.id): \(.state) (letzte Ausführung: \(.last_run_endtime // "nie"))"'
    
    # Netzwerk-Performance zu Remote-Zielen testen
    echo "--- Netzwerk-Tests ---"
    if command -v iperf3 > /dev/null; then
        echo "Teste Bandbreite zu Backup-Zielen..."
        # iperf3 -c backup-remote.com -t 10 -f M
    fi
    
    echo "=== Health Check Ende ==="
}

Disaster Recovery Planning

Vollständige System-Wiederherstellung

Der Tag wird kommen, an dem ihr euer komplettes System wiederherstellen müsst. Ja, schon klar, das passiert nie – Tja, irgendwann ist immer das erste Mal. Vorbereitung ist hier alles – testet eure Disaster Recovery Pläne regelmäßig in einer isolierten Umgebung.

# Vollständige Cluster-Wiederherstellung nach Totalausfall
restore_cluster() {
    local backup_location=$1
    
    echo "Starte Cluster-Wiederherstellung von $backup_location"
    
    # 1. Neue Proxmox-Installation vorbereiten
    echo "Schritt 1: Basis-System installiert (manueller Schritt)"
    
    # 2. Cluster-Konfiguration wiederherstellen
    echo "Schritt 2: Wiederherstellen der Cluster-Konfiguration..."
    if [ -f "$backup_location/cluster-config.tar.gz" ]; then
        tar -xzf "$backup_location/cluster-config.tar.gz" -C /etc/pve/
        systemctl reload pve-cluster
    fi
    
    # 3. Storage-Konfiguration wiederherstellen
    echo "Schritt 3: Storage-Pools wiederherstellen..."
    # Hier müsst ihr eure spezifische Storage-Konfiguration anpassen
    
    # 4. VMs einzeln wiederherstellen
    echo "Schritt 4: VM-Wiederherstellung..."
    if [ -f "$backup_location/vm-list.txt" ]; then
        while read vmid; do
            echo "Wiederherstellen VM $vmid..."
            local backup_file="$backup_location/vm-${vmid}-latest.vma.gz"
            if [ -f "$backup_file" ]; then
                qmrestore "$backup_file" $vmid --storage local-lvm
                echo "VM $vmid wiederhergestellt"
            else
                echo "WARNUNG: Backup für VM $vmid nicht gefunden!"
            fi
        done < "$backup_location/vm-list.txt"
    fi
    
    echo "Cluster-Wiederherstellung abgeschlossen. Bitte Services prüfen!"
}

Backup-Validierung automatisieren

Hatte ich das heute schon erwähnt? Egal, kann man nicht oft genug sagen: Regelmäßige Tests eurer Backups sind unverzichtbar. Nichts ist frustrierender als ein korruptes Backup erst bei eingetretenem Notfall zu entdecken.

Der PBS validiert zwar für euch auch automatisch, aber sich darauf zu 100% zu verlassen halte ich auch für schwierig. Zumindest solltet Ihr in Erwägung ziehen von Zeit zu Zeit tatsächliche Wiederherstellungen durchzuführen, zB. über eure Test/Staging Umgebung, erst dann lässt sich wirklich ruhig schlafen.

# Automatisierte Backup-Tests mit Test-VM
backup_validation() {
    local test_vmid=9999  # VM-ID für Tests reservieren
    local datastore="backup-storage"
    
    echo "Starte Backup-Validierung..."
    
    # Neuestes Backup finden
    local latest_backup=$(proxmox-backup-client list --repository $datastore | \
      grep "vm/$test_vmid" | sort -r | head -1 | awk '{print $1}')
    
    if [ -z "$latest_backup" ]; then
        echo "Kein Backup für Test-VM gefunden, verwende beliebiges VM-Backup"
        latest_backup=$(proxmox-backup-client list --repository $datastore | \
          grep "vm/" | head -1 | awk '{print $1}')
    fi
    
    if [ -z "$latest_backup" ]; then
        echo "FEHLER: Keine Backups gefunden!"
        return 1
    fi
    
    echo "Teste Backup: $latest_backup"
    
    # Test-Wiederherstellung (ohne Start)
    if qmrestore --archive "$datastore:backup/$latest_backup" $test_vmid --storage local-lvm; then
        echo "Wiederherstellung erfolgreich, teste VM-Start..."
        
        # VM testweise starten
        qm start $test_vmid
        sleep 30
        
        if qm status $test_vmid | grep -q "running"; then
            echo "SUCCESS: Backup-Validierung erfolgreich - VM startet korrekt"
            qm stop $test_vmid
            qm destroy $test_vmid --purge
            return 0
        else
            echo "FEHLER: VM startet nicht nach Wiederherstellung"
            qm destroy $test_vmid --purge
            return 1
        fi
    else
        echo "FEHLER: Wiederherstellung fehlgeschlagen"
        return 1
    fi
}

Performance-Optimierung

Backup-Performance Tuning

Performance-Tuning bei Backups ist oft ein Balanceakt zwischen Geschwindigkeit, System-Load und Netzwerk-Impact. Hier sind bewährte Einstellungen für verschiedene Szenarien.

# Datacenter-weite Backup-Einstellungen optimieren (Homelab)
# /etc/pve/datacenter.cfg
max_workers: 3          # Nicht mehr als 3 parallele Backup-Jobs
bandwidth_limit: 200    # 200MB/s Gesamtbandbreite für alle Jobs
ionice: 7               # Niedrigste I/O-Priorität (0-7)
lockwait: 180           # 3 Minuten auf Locks warten

Diese Einstellungen verhindern, dass eure Backups die Produktivsysteme überlasten. Bei leistungsfähigerer Hardware könnt ihr die Werte entsprechend anpassen, die Daten aus dem Beispiel oben sind ein eher einfaches Homelab-Setup ohne performante Server Hardware. Auf einem relativ aktuellen Server könnte das beispielsweise auch so aussehen:

# Datacenter-weite Backup-Einstellungen optimieren (Server)
# /etc/pve/datacenter.cfg
max_workers: 6          # Nicht mehr als 6 parallele Backup-Jobs
bandwidth_limit: 1500   # 1500MB/s Gesamtbandbreite für alle Jobs (NvME Storage)
ionice: 4               # Mittlere I/O-Priorität (0-7)
lockwait: 60            # 1 Minute auf Locks warten

Storage-spezifische Optimierungen

Verschiedene Storage-Technologien brauchen verschiedene Optimierungen. Was für NVMe-SSDs gut ist, kann bei rotierenden Festplatten kontraproduktiv sein. Auch hier ein paar Beispiele:

# I/O-Scheduler für verschiedene Storage-Typen optimieren

# Für NVMe-SSDs: mq-deadline ist meist optimal
echo mq-deadline > /sys/block/nvme0n1/queue/scheduler

# Für SATA-SSDs: none oder mq-deadline
echo none > /sys/block/sda/queue/scheduler

# Für rotierende Festplatten: bfq oder cfq
echo bfq > /sys/block/sdb/queue/scheduler

# Readahead für große sequentielle Zugriffe optimieren
blockdev --setra 4096 /dev/sda  # 2MB readahead

# Für Backup-Workloads oft hilfreich
echo 32 > /sys/block/sda/queue/nr_requests

Troubleshooting häufiger Probleme

Backup-Jobs hängen

Hängende Backup-Jobs sind ein klassisches Problem. Meist liegt’s an Locks, Netzwerkproblemen oder überlasteten Storage-Systemen.

# Hängende Jobs identifizieren und behandeln
find_hanging_jobs() {
    echo "Suche nach hängenden Backup-Jobs..."
    
    # Lange laufende vzdump-Prozesse finden
    ps aux | grep vzdump | grep -v grep | while read line; do
        pid=$(echo $line | awk '{print $2}')
        runtime=$(ps -o etime= -p $pid | tr -d ' ')
        echo "Job PID $pid läuft seit: $runtime"
        
        # Jobs die länger als 6 Stunden laufen sind verdächtig
        if [[ $runtime =~ ^[0-9][0-9]:[0-9][0-9]:[0-9][0-9]$ ]]; then
            echo "WARNUNG: Job $pid läuft sehr lange!"
        fi
    done
    
    # Lock-Files prüfen
    if [ -f /var/lock/vzdump.lock ]; then
        echo "Vzdump-Lock gefunden, prüfe Prozess..."
        local lock_pid=$(cat /var/lock/vzdump.lock)
        if ! kill -0 $lock_pid 2>/dev/null; then
            echo "Lock-File ist verwaist, lösche es..."
            rm /var/lock/vzdump.lock
        fi
    fi
}

# Notfall-Cleanup für völlig hängende Systeme
emergency_backup_cleanup() {
    echo "NOTFALL: Beende alle Backup-Prozesse!"
    killall -9 vzdump
    killall -9 proxmox-backup-client
    rm -f /var/lock/vzdump.lock
    rm -f /tmp/vzdumptmp*
    echo "Cleanup abgeschlossen - prüft die Logs!"
}

Speicherplatz-Management

Volle Backup-Datastores sind ebenfalls ein häufiges Problem. Garbage Collection und Pruning sollten automatisch laufen, aber manchmal müsst ihr trotzdem noch manuell eingreifen.

# Speicherplatz-Probleme diagnostizieren und beheben
storage_cleanup() {
    local datastore=$1
    
    echo "Speicherplatz-Analyse für $datastore..."
    
    # Aktueller Speicherverbrauch
    df -h $(proxmox-backup-manager datastore list | grep $datastore | awk '{print $3}')
    
    # Größte Backup-Gruppen finden
    echo "Größte Backup-Gruppen:"
    du -sh /backup/$datastore/* | sort -hr | head -10
    
    # Garbage Collection manuell ausführen
    echo "Starte Garbage Collection..."
    proxmox-backup-manager garbage-collect $datastore
    
    # Verwaiste Chunks finden
    echo "Suche verwaiste Chunks..."
    proxmox-backup-manager datastore verify $datastore
    
    # Speicherplatz nach Cleanup
    echo "Speicherplatz nach Cleanup:"
    df -h $(proxmox-backup-manager datastore list | grep $datastore | awk '{print $3}')
    
    # Prune-Jobs manuell ausführen wenn automatisch nicht läuft
    echo "Führe Prune-Jobs aus..."
    proxmox-backup-client prune --repository $datastore \
      --keep-daily 7 --keep-weekly 4 --keep-monthly 12
}

# Speicher-Monitoring mit Alerts
monitor_storage_space() {
    for datastore in $(proxmox-backup-manager datastore list | awk 'NR>1 {print $1}'); do
        local path=$(proxmox-backup-manager datastore list | grep $datastore | awk '{print $3}')
        local usage=$(df "$path" | awk 'NR==2 {print $5}' | tr -d '%')
        
        echo "Datastore $datastore: ${usage}% belegt"
        
        if [ $usage -gt 90 ]; then
            echo "KRITISCH: $datastore über 90% voll!"
            # Hier könntet ihr automatisch alte Backups löschen
        elif [ $usage -gt 80 ]; then
            echo "WARNUNG: $datastore über 80% voll"
        fi
    done
}

Netzwerk-Probleme diagnostizieren

Netzwerkprobleme könnten auch der Grund für langsame oder fehlschlagende Backups sein. Hier sind Tools und Techniken, die euch bei der Diagnose helfen.

# Umfassende Netzwerk-Diagnose für Backup-Verbindungen
network_backup_diagnosis() {
    local target_host=$1
    
    echo "=== Netzwerk-Diagnose für $target_host ==="
    
    # Grundlegende Erreichbarkeit
    echo "--- Ping-Test ---"
    if ping -c 5 $target_host > /dev/null; then
        echo "Host $target_host ist erreichbar"
        ping -c 5 $target_host | tail -1
    else
        echo "FEHLER: Host $target_host nicht erreichbar!"
        return 1
    fi
    
    # Bandbreiten-Test mit iperf3
    echo "--- Bandbreiten-Test ---"
    if command -v iperf3 > /dev/null; then
        echo "Teste Bandbreite zu $target_host..."
        timeout 30s iperf3 -c $target_host -t 20 -f M 2>/dev/null | \
          grep "sender" | awk '{print "Upload: " $7 " " $8}'
        timeout 30s iperf3 -c $target_host -t 20 -f M -R 2>/dev/null | \
          grep "receiver" | awk '{print "Download: " $7 " " $8}'
    else
        echo "iperf3 nicht installiert - installiere mit: apt install iperf3"
    fi
    
    # Latenz-Test
    echo "--- Latenz-Analyse ---"
    local avg_latency=$(ping -c 100 $target_host | tail -1 | awk -F'/' '{print $5}')
    echo "Durchschnittliche Latenz: ${avg_latency}ms"
    
    if (( $(echo "$avg_latency > 100" | bc -l) )); then
        echo "WARNUNG: Hohe Latenz könnte Backup-Performance beeinträchtigen"
    fi
    
    # Port-Verfügbarkeit für PBS
    echo "--- Port-Tests ---"
    for port in 8007 8008; do
        if timeout 5s bash -c "</dev/tcp/$target_host/$port"; then
            echo "Port $port: OFFEN"
        else
            echo "Port $port: GESCHLOSSEN oder gefiltert"
        fi
    done
    
    # MTU-Discovery
    echo "--- MTU-Test ---"
    for size in 1472 1500 9000; do
        if ping -c 1 -M do -s $size $target_host > /dev/null 2>&1; then
            echo "MTU $size: OK"
        else
            echo "MTU $size: Fragmentierung erforderlich"
        fi
    done
}

SSL/TLS Zertifikats-Probleme

PBS nutzt HTTPS für alle Verbindungen. Zertifikats-Probleme sind ein häufiger Stolperstein, besonders bei Self-Signed Certificates.

# SSL-Zertifikat-Diagnose und -Reparatur
check_pbs_certificates() {
    local pbs_host=$1
    
    echo "=== SSL-Zertifikat-Check für $pbs_host ==="
    
    # Zertifikat-Details abrufen
    echo "--- Zertifikat-Informationen ---"
    local cert_info=$(echo | openssl s_client -servername $pbs_host -connect $pbs_host:8007 2>/dev/null | \
      openssl x509 -noout -dates -subject -issuer)
    
    echo "$cert_info"
    
    # Zertifikat-Gültigkeit prüfen
    local expiry_date=$(echo "$cert_info" | grep "notAfter" | cut -d'=' -f2)
    local expiry_seconds=$(date -d "$expiry_date" +%s)
    local now_seconds=$(date +%s)
    local days_until_expiry=$(( (expiry_seconds - now_seconds) / 86400 ))
    
    echo "Zertifikat läuft ab in: $days_until_expiry Tagen"
    
    if [ $days_until_expiry -lt 30 ]; then
        echo "WARNUNG: Zertifikat läuft bald ab!"
    fi
    
    # Fingerprint für Remote-Konfiguration
    echo "--- Fingerprint für Remote-Config ---"
    local fingerprint=$(echo | openssl s_client -servername $pbs_host -connect $pbs_host:8007 2>/dev/null | \
      openssl x509 -noout -fingerprint -sha256 | cut -d'=' -f2)
    echo "Fingerprint: $fingerprint"
}

# Neues Self-Signed Zertifikat generieren
regenerate_pbs_certificate() {
    local pbs_host=$1
    
    echo "Generiere neues Self-Signed Zertifikat für $pbs_host..."
    
    # Backup des alten Zertifikats
    cp /etc/proxmox-backup/proxy.pem /etc/proxmox-backup/proxy.pem.backup.$(date +%Y%m%d)
    
    # Neues Zertifikat erstellen
    openssl req -x509 -newkey rsa:4096 -keyout /tmp/proxy.key -out /tmp/proxy.crt \
      -days 3650 -nodes -subj "/CN=$pbs_host"
    
    # Zertifikat und Key kombinieren
    cat /tmp/proxy.crt /tmp/proxy.key > /etc/proxmox-backup/proxy.pem
    
    # Temporäre Dateien löschen
    rm /tmp/proxy.key /tmp/proxy.crt
    
    # Service neustarten
    systemctl restart proxmox-backup-proxy
    
    echo "Neues Zertifikat installiert. Neuer Fingerprint:"
    check_pbs_certificates $pbs_host | grep "Fingerprint:"
}

Best Practices TL:DR

Das solltet ihr unbedingt beachten

Hier sind die wichtigsten Punkte, die über Erfolg oder Misserfolg eures Backup-Systems entscheiden:

Hardware & Infrastruktur:

  • PBS immer auf separater Hardware – nie auf dem System, das ihr sichert
  • Ausreichend RAM für Deduplication (mindestens 16GB für Produktionsumgebungen)
  • Schnelle SSDs für Metadaten, große HDDs für die Backup-Daten
  • Redundante Netzwerkverbindungen wenn möglich

Konfiguration:

  • Retention Policies von Anfang an richtig konfigurieren – nachträglich ist’s mühsam
  • Bandbreitenbegrenzung aktivieren um Produktivsysteme nicht zu beeinträchtigen
  • Verify-Jobs einrichten – ein ungetestetes Backup ist kein Backup
  • E-Mail-Benachrichtigungen für alle kritischen Events aktivieren

Monitoring:

  • Automatische Health-Checks mindestens täglich
  • Storage-Monitoring mit Alerts bei >80% Belegung
  • Regelmäßige Test-Wiederherstellungen in isolierter Umgebung
  • Log-Files regelmäßig überprüfen – Warnungen ernst nehmen

Sicherheit:

  • Client-seitige Verschlüsselung für sensitive Daten aktivieren
  • Separate Credentials für Backup-User – keine Admin-Rechte
  • Firewall-Regeln nur für notwendige Ports (8007, 8008)
  • Offsite-Backups mit sicherer Ãœbertragung (SSH-Keys statt Passwörter)

Häufige Anfängerfehler vermeiden

Der „Virtualisierte PBS“ Fehler: Nie PBS auf demselben Proxmox-Cluster laufen lassen, den er sichern soll. Das ist wie ein Sicherheitsgurt aus Kaugummi.

Die „Set and Forget“ Mentalität: Backups brauchen regelmäßige Pflege. Prüft mindestens monatlich, ob alles läuft.

Fehlende Bandbreitenbegrenzung: Backup-Jobs ohne Limits können euer Produktionsnetzwerk lahmlegen.

Keine Test-Wiederherstellungen: Ihr wisst erst, ob eure Backups funktionieren, wenn ihr sie testet. Murphy’s Law gilt besonders für Backups. 😉

Unklare Retention-Policies: Definiert von Anfang an, wie lange ihr was behalten wollt. Unendlich wachsende Backup-Archive sind ein Alptraum.

Mit diesen Grundlagen habt ihr ein solides Fundament für euer Proxmox-Backup-System. Investiert die Zeit in eine ordentliche Konfiguration – ich sag mal so, dein Zukunfts-Ich wird es dir danken, entweder durch ruhigen, entspannten Schlaf, oder spätestens wenn der erste Notfall eintritt.

Abschluss und weiterführende Ressourcen

Proxmox ist ein mächtiges Werkzeug, aber mit großer Macht kommt auch große Verantwortung. (zwinker) Die hier gezeigten Best Practices sind das Ergebnis aus Erfahrung in der Praxis. Beginnt mit den Grundlagen und arbeitet euch nach und nach zu den erweiterten Features vor.

Eure nächsten Schritte:

  1. Testing/Staging Umgebung aufbauen: Testet alle Konfigurationen erst in einer separaten Umgebung
  2. Monitoring implementieren: Ãœberwacht euer System von Anfang an
  3. Backup-Strategie testen: Macht regelmäßige Restore-Tests
  4. Community beitreten: Das Proxmox-Forum ist sehr hilfsreich

Denkt also daran: Nehmt euch die Zeit, die Grundlagen zu verstehen, bevor ihr zu komplexeren Setups übergeht. Der Proxmox-Admin-Guide als Webseite den ich im Artikel mehrfach als Referenz verlinkt habe ist auch Gold wert. Schaut euch ruhig im Forum um, wenn Ihr Frage habt. Ansonsten gibt es auch für den Einstieg noch einen Youtube-Channel.

Die restlichen Teile dieser Artikelserie habe ich hier auch noch einmal für euch verlinkt: Teil 1: Netzwerk | Teil 2: Storage | Teil 3: Backup | Teil 4: Sicherheit | Teil 5: Performance

Stephan
|
| | | | | | | | |
nach oben | Startseite | zur Suche