UGREEN NAS DXP4800 Pro als Proxmox Backup Server: Mein Hybrid-Backup mit NVME, HDD und SMB Sicherung

👉 Direkt auf YouTube schauen und abonnieren:
Smart Home & More auf YouTube

Einleitung

Backups sind eines dieser Themen, über die man meistens erst dann wirklich nachdenkt, wenn es zu spät ist. Gerade im HomeLab, bei Proxmox-Installationen, virtuellen Maschinen, Containern und NAS-Systemen sammeln sich mit der Zeit immer mehr Dienste an, die man nicht einfach mal eben neu aufsetzen möchte. Genau deshalb habe ich mir das UGREEN NAS DXP4800 Pro einmal aus einer etwas anderen Perspektive angeschaut.

In diesem Beitrag geht es nicht darum, das UGREEN NAS einfach nur mit dem mitgelieferten Betriebssystem zu nutzen. Das kann man natürlich machen, und dafür gibt es auch viele sinnvolle Anwendungsfälle. Mich hat aber interessiert, wie gut sich die Hardware als nativer Proxmox Backup Server eignet.

Die Idee dahinter ist ziemlich spannend: Das UGREEN NAS DXP4800 Pro bringt schnelle Netzwerkschnittstellen, Platz für HDDs und zusätzlich NVMe-Steckplätze mit. Daraus lässt sich ein Hybrid-Backup-System bauen, das schnelle kurzfristige Backups auf NVMe ermöglicht und gleichzeitig ein größeres Archiv auf klassischen Festplatten bereitstellt.

Genau dieses Konzept habe ich in meinem Video praktisch umgesetzt. Im Blogbeitrag möchte ich dir die Architektur, die wichtigsten Überlegungen und das Grundprinzip erklären. Die komplette Schritt-für-Schritt-Einrichtung mit allen Menüs, Einstellungen und Tests zeige ich ausführlich im Video.


Warum überhaupt ein dedizierter Proxmox Backup Server?

Viele betreiben ihren Proxmox Backup Server zunächst virtuell. Das funktioniert grundsätzlich und ist für den Einstieg oft völlig ausreichend. Trotzdem gibt es einige Gründe, warum ein separater Backup Server interessant sein kann.

Ein Backup-System sollte möglichst unabhängig vom eigentlichen Hypervisor laufen. Wenn der Proxmox-Host selbst ein Problem hat, möchte ich nicht gleichzeitig auch meine Backup-Infrastruktur verlieren. Ein separates Gerät schafft hier eine saubere Trennung.

Dazu kommt die Performance. Gerade bei größeren VMs oder mehreren parallelen Sicherungen merkt man schnell, ob Speicher und Netzwerk mithalten können. Ein System mit 10-Gigabit-Ethernet und schnellen NVMe-Datenträgern ist hier natürlich eine ganz andere Grundlage als eine einfache USB-Platte oder ein langsam angebundenes Netzlaufwerk.

Für mich war deshalb die zentrale Frage: Kann das DXP4800 Pro als kompakter, stromsparender und gleichzeitig leistungsfähiger Proxmox Backup Server dienen?

Meine Antwort nach dem Test ist ziemlich klar: Ja, das kann es. Aber richtig interessant wird es erst durch die Kombination aus schnellem NVMe-Speicher und großem HDD-Archiv.


Die Hardware-Basis: Warum das DXP4800 Pro gut passt

Das UGREEN NAS DXP4800 Pro bringt einige Eigenschaften mit, die für so ein Backup-Szenario besonders interessant sind. Dazu gehören vor allem die vier 3,5-Zoll-Laufwerksschächte, die zwei NVMe-Steckplätze und die Netzwerkanbindung mit 10-Gigabit-Ethernet.

Für ein klassisches NAS ist das schon eine ordentliche Ausstattung. Für einen Proxmox Backup Server wird es aber noch spannender, weil man die unterschiedlichen Speichertypen gezielt einsetzen kann.

Die NVMe-Laufwerke eignen sich hervorragend für schnelle Backups und schnelle Restores. Gerade wenn man kurzfristig eine VM zurückholen muss, möchte man nicht unnötig lange warten. Die HDDs bieten dagegen viel Speicherplatz zu einem deutlich besseren Preis pro Terabyte. Genau daraus entsteht das Hybrid-Konzept.

In meinem Setup nutze ich die NVMe-Laufwerke für kurzfristige, schnelle Backup-Stände. Die HDDs dienen als Archiv für längere Aufbewahrungszeiten. Damit muss ich nicht alle Daten dauerhaft auf teurem NVMe-Speicher halten, habe aber trotzdem schnellen Zugriff auf die letzten Sicherungen.


Das Hybrid-Backup-Konzept

Das eigentliche Konzept besteht aus zwei Datastores im Proxmox Backup Server:

  1. Ein schneller Datastore auf NVMe-Basis
  2. Ein großer Archiv-Datastore auf HDD-Basis

Der schnelle Datastore ist für aktuelle Backups gedacht. Hier landen zum Beispiel die letzten Sicherungen meiner VMs und Container. Die Aufbewahrungszeit ist bewusst kurz gehalten. Mir geht es hier nicht darum, Monate oder Jahre zurückzuspringen, sondern schnell an die letzten funktionierenden Stände zu kommen.

Der Archiv-Datastore auf HDD-Basis übernimmt die langfristige Sicherung. Dort werden die Daten aus dem schnellen Bereich regelmäßig synchronisiert. Die Retention kann hier deutlich großzügiger eingestellt werden, weil mehr Speicherplatz zur Verfügung steht.

Damit entsteht ein sehr praktischer Ablauf:

  • Proxmox sichert zunächst schnell auf NVMe.
  • Der Proxmox Backup Server synchronisiert diese Daten intern auf das HDD-Archiv.
  • Kurzfristige Restores laufen schnell über NVMe.
  • Ältere Stände bleiben im Archiv erhalten.

Das ist aus meiner Sicht ein sehr sinnvoller Kompromiss zwischen Geschwindigkeit, Kosten und Speicherplatz.


Warum NVMe nicht einfach für alles?

Man könnte natürlich fragen: Warum nicht einfach alles auf NVMe speichern?

Technisch wäre das möglich. Praktisch wird es aber schnell teuer. Backups wachsen mit der Zeit. Gerade wenn mehrere VMs, Container oder zusätzliche Datenquellen gesichert werden, ist der Speicherbedarf nicht zu unterschätzen.

NVMe ist schnell, aber pro Terabyte deutlich teurer als klassische Festplatten. Für aktuelle Backups ist die Geschwindigkeit sehr wertvoll. Für ältere Stände, auf die man nur im Notfall zugreift, reicht HDD-Speicher in vielen Fällen völlig aus.

Genau deshalb finde ich dieses zweistufige Modell so interessant. Es nutzt die Stärken beider Speicherarten: NVMe für Geschwindigkeit, HDD für Kapazität.


10-Gigabit-Ethernet als wichtiger Baustein

Ein schneller Speicher allein bringt wenig, wenn das Netzwerk limitiert. Deshalb ist die 10-Gigabit-Schnittstelle des DXP4800 Pro in diesem Setup ein wichtiger Punkt.

In meinem Test konnte ich über die 10-Gigabit-Verbindung sehr gute Durchsatzwerte erzielen. Das ist besonders dann relevant, wenn größere VMs gesichert oder wiederhergestellt werden. Auch wenn Proxmox Backup Server dedupliziert und komprimiert, bleibt die Netzwerkanbindung ein entscheidender Faktor.

Wer bereits ein HomeLab mit 10-Gigabit-Struktur betreibt, kann das DXP4800 Pro hier sehr sinnvoll einbinden. Für kleinere Setups funktioniert das Konzept natürlich auch mit 2,5 Gigabit oder 1 Gigabit, aber dann verschiebt sich der Flaschenhals entsprechend.

Installation: Im Video Schritt für Schritt

Die eigentliche Installation des Proxmox Backup Servers auf dem UGREEN NAS zeige ich im Video ausführlich. Dort gehe ich unter anderem auf die BIOS-Einstellungen, den Bootvorgang über USB und die Auswahl des Installationslaufwerks ein.

Wichtig ist: Wer das originale UGREEN OS behalten möchte, sollte sich vorher Gedanken über ein Backup oder einen Clone machen. Alternativ kann man natürlich auch ein anderes Laufwerk für die Installation verwenden.

Im Video zeige ich außerdem, welche Einstellungen im BIOS sinnvoll sind, damit das System sauber als Backup Server läuft. Dazu gehören unter anderem der Umgang mit dem Watchdog, Wake-on-LAN und das Verhalten nach Stromausfall.

An dieser Stelle möchte ich bewusst nicht jedes Menü und jeden Klick im Blog nachbauen. Genau das ist der Mehrwert des Videos. Der Beitrag soll dir helfen, das Konzept zu verstehen und zu entscheiden, ob dieses Setup auch für dein eigenes HomeLab interessant ist.

ZFS: Mirror für NVMe, RAIDZ1 für HDDs

Bei der Speicherstruktur setze ich auf ZFS. Für die beiden NVMe-Laufwerke bietet sich ein Mirror an. Damit bleibt der schnelle Datastore auch dann verfügbar, wenn eine der beiden NVMe ausfällt.

Bei den vier HDDs nutze ich ein Setup mit einfacher Ausfallsicherheit. Dadurch steht ein großer Archivbereich zur Verfügung, ohne komplett auf Redundanz zu verzichten.

Natürlich muss man sich bewusst sein: RAID oder ZFS ersetzt kein Backup. In diesem Fall ist ZFS aber Teil der Backup-Infrastruktur. Es schützt vor dem Ausfall einzelner Datenträger, ersetzt aber keine zusätzliche externe oder ausgelagerte Sicherung.

Gerade bei wichtigen Daten sollte man immer weiterdenken. Ein lokaler Backup Server ist sehr gut, aber kein Schutz gegen Diebstahl, Brand, Überspannung oder menschliche Fehler, wenn keine zusätzliche Kopie existiert.


Namespaces: Ordnung im Backup Server

Ein Punkt, der gerne unterschätzt wird, sind Namespaces im Proxmox Backup Server.

Wenn man mehrere Proxmox-Hosts, Cluster oder unterschiedliche Backup-Quellen verwendet, kann es schnell unübersichtlich werden. Namespaces helfen dabei, die Daten sauber zu trennen.

In meinem Setup nutze ich Namespaces, um unterschiedliche Quellen besser voneinander zu unterscheiden. Das ist besonders dann wichtig, wenn mehrere Systeme ähnliche VM-IDs verwenden. Ohne klare Struktur kann später Chaos entstehen.

Gerade wenn man langfristig wachsen möchte, lohnt es sich, diese Ordnung direkt von Anfang an sauber aufzubauen.


Retention: Schnell kurz, Archiv lang

Der große Vorteil dieses Setups liegt in den unterschiedlichen Aufbewahrungsregeln.

Auf dem schnellen NVMe-Datastore brauche ich nur wenige aktuelle Stände. Hier geht es um schnelle Wiederherstellung. Deshalb reicht es in vielen Fällen, nur die letzten Sicherungen vorzuhalten.

Auf dem Archiv-Datastore kann die Retention großzügiger ausfallen. Dort können tägliche, wöchentliche oder monatliche Stände länger erhalten bleiben. So bleibt die Möglichkeit bestehen, auch ältere Versionen wiederzufinden.

Das ist besonders hilfreich, wenn ein Fehler nicht sofort auffällt. Manche Probleme merkt man erst Tage oder Wochen später. Dann ist es gut, nicht nur den letzten Stand zu haben.


Interner Sync vom schnellen Speicher ins Archiv

Ein besonders schöner Trick an diesem Setup ist die interne Synchronisation.

Der Proxmox Backup Server kann Datastores synchronisieren. In meinem Fall wird der schnelle NVMe-Datastore als Quelle verwendet und das HDD-Archiv zieht sich die Daten regelmäßig herüber.

Dadurch entsteht ein automatisierter Ablauf, ohne dass der eigentliche Proxmox-Host mehrfach sichern muss. Der Host schreibt schnell auf NVMe, und der Backup Server kümmert sich anschließend selbst um die Archivierung.

Wichtig ist dabei, die Löschlogik bewusst zu konfigurieren. Das Archiv soll nicht einfach alles löschen, nur weil der schnelle Datastore ältere Stände entfernt. Genau hier muss man sauber planen, damit das Archiv wirklich als Langzeitspeicher funktioniert.


Wichtig: Garbage Collection im Proxmox Backup Server einrichten

Ein Punkt, den ich im Video nicht sauber genug gezeigt bzw. teilweise vergessen habe, ist die Garbage Collection im Proxmox Backup Server. Das ist wichtig, weil PBS alte oder nicht mehr referenzierte Datenblöcke nicht sofort physisch vom Datenträger entfernt.

Wenn du also Retention-Regeln einstellst, zum Beispiel „nur die letzten drei Backups behalten“, bedeutet das zunächst nur: Die alten Backup-Snapshots werden aus Sicht von PBS entfernt. Der tatsächlich belegte Speicherplatz wird aber erst durch die Garbage Collection wieder freigegeben.

Gerade bei meinem Hybrid-Setup mit schnellem NVMe-Datastore und großem HDD-Archiv sollte deshalb für beide Datastores ein Garbage-Collection-Job eingerichtet werden.

Meine Empfehlung für dieses Setup

Für den schnellen NVMe-Datastore würde ich die Garbage Collection regelmäßig laufen lassen, zum Beispiel täglich oder alle paar Tage. Dort ist der Speicherplatz begrenzter, und durch die kurze Retention sollen alte Daten auch wirklich wieder freigegeben werden.

Für das HDD-Archiv reicht je nach Datenmenge auch ein etwas entspannterer Rhythmus. Wenn dort viele Daten landen oder viele Backups verschoben und bereinigt werden, kann aber ebenfalls ein täglicher Lauf sinnvoll sein. Wichtig ist nur, dass Garbage Collection nicht zur gleichen Zeit wie große Backup-, Sync- oder Verify-Jobs läuft.

So gehst du vor

Im Proxmox Backup Server gehst du beim jeweiligen Datastore auf:

Datastore → Prune & GC → Garbage Collection Jobs → Add

Dort legst du einen Zeitplan fest. Für mein Setup bietet sich zum Beispiel an:

  • NVMe-Datastore: nach den Backup- und Sync-Jobs
  • HDD-Archiv: zeitversetzt danach oder an einem anderen Zeitpunkt

Wichtig ist die Reihenfolge: Erst sollten die Backups erstellt werden, dann kann der Sync ins Archiv laufen, danach Prune und Garbage Collection. So vermeidest du unnötige Lastspitzen und stellst sicher, dass PBS sauber aufräumt.

Warum das wichtig ist

Ohne Garbage Collection kann es passieren, dass du dich wunderst, warum trotz gelöschter oder ausgelaufener Backups kaum Speicherplatz frei wird. Das ist kein Fehler, sondern Teil des Funktionsprinzips von PBS. Erst die Garbage Collection entfernt nicht mehr benötigte Chunks endgültig aus dem Datastore.

Für ein dauerhaft laufendes Backup-System gehört ein Garbage-Collection-Job deshalb zwingend zur Grundkonfiguration. Das gilt besonders dann, wenn du mit unterschiedlichen Retention-Regeln arbeitest – so wie in diesem Setup mit kurzem NVMe-Speicher und längerem HDD-Archiv.

SMB-Shares zusätzlich sichern

Neben den klassischen Proxmox-Backups wollte ich noch eine weitere Funktion einbauen: die Sicherung von SMB-Freigaben.

Viele haben irgendwo im Netzwerk ein NAS, eine Unraid-Installation, eine Synology, ein TerraMaster oder einfach klassische Freigaben liegen. Dort befinden sich oft wichtige Dateien, Dokumente oder Projektordner.

Mein Ziel war es, diese Freigaben ebenfalls in den Proxmox Backup Server zu bekommen. Der Vorteil: Die Daten werden versioniert, dedupliziert und können über die Oberfläche des Proxmox Backup Servers wiederhergestellt werden.

Dafür habe ich ein eigenes Setup-Script vorbereitet, das die Einrichtung erleichtert. Das Script fragt unter anderem den Datastore, den Namespace, die SMB-Zugangsdaten und die gewünschten Freigaben ab. Anschließend kann es einen automatischen Timer einrichten, der die Sicherung regelmäßig ausführt.

Das ist aus meiner Sicht ein sehr praktisches Zusatzfeature, weil damit nicht nur VMs und Container, sondern auch klassische Dateifreigaben in die Backup-Strategie eingebunden werden können.


Script für SMB-Backups

Das folgende Script ist der einzige Code-Teil in diesem Beitrag. Es ist dafür gedacht, die Einrichtung einer SMB-Sicherung in den Proxmox Backup Server zu vereinfachen.

Wichtig: Bitte prüfe das Script vor dem Einsatz in deiner Umgebung und passe Pfade, Benutzer, Datastores und Freigaben an deine Situation an. Nutze es auf eigene Verantwortung und teste zunächst mit unkritischen Daten.

#!/bin/bash
set -euo pipefail

CONFIG="/etc/unraid-pbs-backup.conf"
SMB_CREDENTIALS="/root/.smb-unraid"
PBS_PASSWORD_FILE="/root/.pbs-unraid-password"
BACKUP_SCRIPT="/usr/local/sbin/backup-unraid-to-pbs.sh"
SYSTEMD_SERVICE="/etc/systemd/system/unraid-pbs-backup.service"
SYSTEMD_TIMER="/etc/systemd/system/unraid-pbs-backup.timer"

echo "============================================================"
echo " Unraid SMB Share Backup -> Proxmox Backup Server Setup"
echo "============================================================"
echo

require_cmd() {
    command -v "$1" >/dev/null 2>&1 || {
        echo "Fehlt: $1"
        echo "Bitte installieren mit:"
        echo "  apt update && apt install -y cifs-utils smbclient python3"
        exit 1
    }
}

ask_default() {
    local prompt="$1"
    local default="$2"
    local value

    read -rp "$prompt [$default]: " value
    echo "${value:-$default}"
}

ask_yes_no() {
    local prompt="$1"
    local default="$2"
    local value

    while true; do
        if [ "$default" = "yes" ]; then
            read -rp "$prompt [J/n]: " value
            value="${value:-j}"
        else
            read -rp "$prompt [j/N]: " value
            value="${value:-n}"
        fi

        case "$value" in
            j|J|y|Y|yes|Yes|YES)
                return 0
                ;;
            n|N|no|No|NO)
                return 1
                ;;
            *)
                echo "Bitte j oder n eingeben."
                ;;
        esac
    done
}

select_from_list() {
    local prompt="$1"
    shift
    local items=("$@")
    local selection
    local index

    if [ "${#items[@]}" -eq 0 ]; then
        return 1
    fi

    echo "$prompt" >&2
    echo "------------------------------------------------------------" >&2

    local i=1
    for item in "${items[@]}"; do
        echo "[$i] $item" >&2
        i=$((i + 1))
    done

    echo "------------------------------------------------------------" >&2
    echo >&2

    while true; do
        read -rp "Auswahl Nummer: " selection >&2

        if [[ "$selection" =~ ^[0-9]+$ ]]; then
            index=$((selection - 1))

            if [ "$index" -ge 0 ] && [ "$index" -lt "${#items[@]}" ]; then
                echo "${items[$index]}"
                return 0
            fi
        fi

        echo "Ungültige Auswahl." >&2
    done
}

safe_shell_value() {
    local value="$1"
    value="${value//\\/\\\\}"
    value="${value//\"/\\\"}"
    echo "$value"
}

get_datastores() {
    proxmox-backup-manager datastore list --output-format json 2>/dev/null | python3 -c '
import sys, json

try:
    data = json.load(sys.stdin)
except Exception:
    sys.exit(0)

if isinstance(data, dict):
    data = data.get("data", [])

for item in data:
    if not isinstance(item, dict):
        continue

    name = item.get("store") or item.get("name") or item.get("datastore")
    if name:
        print(name)
'
}

get_datastore_path() {
    local datastore="$1"

    proxmox-backup-manager datastore list --output-format json 2>/dev/null | python3 -c '
import sys, json

wanted = sys.argv[1]

try:
    data = json.load(sys.stdin)
except Exception:
    sys.exit(0)

if isinstance(data, dict):
    data = data.get("data", [])

for item in data:
    if not isinstance(item, dict):
        continue

    name = item.get("store") or item.get("name") or item.get("datastore")
    path = item.get("path")

    if name == wanted and path:
        print(path)
        sys.exit(0)
' "$datastore"
}

get_namespaces() {
    local datastore="$1"
    local datastore_path=""

    datastore_path="$(get_datastore_path "$datastore" || true)"

    if [ -z "$datastore_path" ]; then
        datastore_path="/mnt/datastore/${datastore}"
    fi

    if [ -d "${datastore_path}/ns" ]; then
        find "${datastore_path}/ns" -mindepth 1 -maxdepth 1 -type d -printf '%f\n' 2>/dev/null || true
    fi
}

require_cmd proxmox-backup-client
require_cmd proxmox-backup-manager
require_cmd mount.cifs
require_cmd smbclient
require_cmd python3

echo "Lese verfügbare PBS Datastores aus..."
echo

mapfile -t DATASTORES < <(get_datastores || true)

if [ "${#DATASTORES[@]}" -eq 0 ]; then
    echo "Konnte keine Datastores automatisch auslesen."
    PBS_DATASTORE="$(ask_default "PBS Datastore manuell eingeben" "ARCHIVE")"
else
    PBS_DATASTORE="$(select_from_list "Verfügbare PBS Datastores:" "${DATASTORES[@]}")"
fi

echo
echo "Gewählter Datastore: $PBS_DATASTORE"
echo

echo "Lese Namespaces für Datastore '$PBS_DATASTORE' aus..."
echo

mapfile -t NAMESPACES < <(get_namespaces "$PBS_DATASTORE" || true)

NAMESPACE_OPTIONS=("[Root Namespace]")

for ns in "${NAMESPACES[@]:-}"; do
    if [ -n "$ns" ]; then
        NAMESPACE_OPTIONS+=("$ns")
    fi
done

PBS_NAMESPACE_SELECTION="$(select_from_list "Verfügbare Namespaces:" "${NAMESPACE_OPTIONS[@]}")"

if [ "$PBS_NAMESPACE_SELECTION" = "[Root Namespace]" ]; then
    PBS_NAMESPACE=""
else
    PBS_NAMESPACE="$PBS_NAMESPACE_SELECTION"
fi

echo

if [ -z "$PBS_NAMESPACE" ]; then
    echo "Gewählter Namespace: Root Namespace"
else
    echo "Gewählter Namespace: $PBS_NAMESPACE"
fi

echo

PBS_AUTH_ID="$(ask_default "PBS Auth-ID" "root@pam")"

read -rsp "PBS Passwort oder Token Secret: " PBS_PASSWORD
echo

if [ -z "$PBS_PASSWORD" ]; then
    echo "PBS Passwort darf nicht leer sein."
    exit 1
fi

echo "$PBS_PASSWORD" > "$PBS_PASSWORD_FILE"
chmod 600 "$PBS_PASSWORD_FILE"

echo
read -rp "Unraid Server IP oder Hostname: " UNRAID_SERVER

if [ -z "$UNRAID_SERVER" ]; then
    echo "Unraid Server darf nicht leer sein."
    exit 1
fi

read -rp "SMB Benutzername: " SMB_USER

if [ -z "$SMB_USER" ]; then
    echo "SMB Benutzer darf nicht leer sein."
    exit 1
fi

read -rsp "SMB Passwort: " SMB_PASS
echo

if [ -z "$SMB_PASS" ]; then
    echo "SMB Passwort darf nicht leer sein."
    exit 1
fi

SMB_DOMAIN="$(ask_default "SMB Domain/Workgroup" "WORKGROUP")"
SMB_VERSION="$(ask_default "SMB Version" "3.0")"
SMB_MOUNT_OPTIONS="$(ask_default "Zusätzliche SMB Mount-Optionen" "ro,noserverino,iocharset=utf8")"

cat > "$SMB_CREDENTIALS" <<EOF_CREDS
username=${SMB_USER}
password=${SMB_PASS}
domain=${SMB_DOMAIN}
EOF_CREDS

chmod 600 "$SMB_CREDENTIALS"

echo
echo "Lese SMB-Freigaben von //${UNRAID_SERVER} aus..."
echo "------------------------------------------------------------"

TMP_SHARES="$(mktemp)"

smbclient -L "//${UNRAID_SERVER}" -A "$SMB_CREDENTIALS" -m SMB3 2>/dev/null \
    | awk '
        $2 == "Disk" {
            print $1
        }
    ' \
    | grep -vE '^\$|^IPC\$|^print\$' \
    > "$TMP_SHARES" || true

if [ ! -s "$TMP_SHARES" ]; then
    echo "Konnte keine SMB-Freigaben automatisch auslesen."
    echo "Du kannst die Freigaben jetzt manuell eingeben."
    echo

    read -rp "Freigaben kommagetrennt eingeben, z. B. Dokumente,Fotos,Clonezilla: " MANUAL_SHARES

    if [ -z "$MANUAL_SHARES" ]; then
        echo "Keine Freigaben angegeben. Abbruch."
        rm -f "$TMP_SHARES"
        exit 1
    fi

    echo "$MANUAL_SHARES" | tr ',' '\n' | sed 's/^ *//;s/ *$//' > "$TMP_SHARES"
fi

mapfile -t AVAILABLE_SHARES < "$TMP_SHARES"
rm -f "$TMP_SHARES"

if [ "${#AVAILABLE_SHARES[@]}" -eq 0 ]; then
    echo "Keine Freigaben gefunden. Abbruch."
    exit 1
fi

echo "Gefundene Freigaben:"
echo "------------------------------------------------------------"

i=1
for share in "${AVAILABLE_SHARES[@]}"; do
    echo "[$i] $share"
    i=$((i + 1))
done

echo "------------------------------------------------------------"
echo

echo "Welche Freigaben sollen gesichert werden?"
echo "Beispiele:"
echo "  1,3,5"
echo "  all"
echo

read -rp "Auswahl [all]: " SHARE_SELECTION
SHARE_SELECTION="${SHARE_SELECTION:-all}"

SELECTED_SHARES=()

if [ "$SHARE_SELECTION" = "all" ]; then
    SELECTED_SHARES=("${AVAILABLE_SHARES[@]}")
else
    IFS=',' read -ra NUMBERS <<< "$SHARE_SELECTION"

    for num in "${NUMBERS[@]}"; do
        num="$(echo "$num" | xargs)"

        if ! [[ "$num" =~ ^[0-9]+$ ]]; then
            echo "Ungültige Auswahl: $num"
            exit 1
        fi

        index=$((num - 1))

        if [ "$index" -lt 0 ] || [ "$index" -ge "${#AVAILABLE_SHARES[@]}" ]; then
            echo "Auswahl außerhalb des Bereichs: $num"
            exit 1
        fi

        SELECTED_SHARES+=("${AVAILABLE_SHARES[$index]}")
    done
fi

if [ "${#SELECTED_SHARES[@]}" -eq 0 ]; then
    echo "Keine Freigaben ausgewählt. Abbruch."
    exit 1
fi

echo
echo "Ausgewählte Freigaben:"
printf ' - %s\n' "${SELECTED_SHARES[@]}"
echo

BACKUP_ID="$(ask_default "Backup-ID im PBS" "unraid")"
BACKUP_TYPE="host"
ARCHIVE_PREFIX="$(ask_default "Archiv-Präfix" "unraid")"
MOUNT_BASE="$(ask_default "Mount-Basisverzeichnis" "/mnt/unraid-backup")"
LOGFILE="$(ask_default "Logfile" "/var/log/backup-unraid-to-pbs.log")"

if ask_yes_no "Leere Freigaben überspringen statt abbrechen?" "no"; then
    SKIP_EMPTY_SHARES="yes"
else
    SKIP_EMPTY_SHARES="no"
fi

if ask_yes_no "Lokale Mountpoints nach Backup wieder aushängen?" "yes"; then
    UNMOUNT_AFTER_BACKUP="yes"
else
    UNMOUNT_AFTER_BACKUP="no"
fi

PBS_REPOSITORY="${PBS_AUTH_ID}@localhost:${PBS_DATASTORE}"

echo
echo "Erstelle Konfiguration: $CONFIG"

{
    echo "# Automatisch erstellt durch setup-unraid-pbs-backup.sh"
    echo
    echo "UNRAID_SERVER=\"$(safe_shell_value "$UNRAID_SERVER")\""
    echo "SMB_CREDENTIALS=\"$(safe_shell_value "$SMB_CREDENTIALS")\""
    echo "SMB_VERSION=\"$(safe_shell_value "$SMB_VERSION")\""
    echo "SMB_MOUNT_OPTIONS=\"$(safe_shell_value "$SMB_MOUNT_OPTIONS")\""
    echo
    echo "PBS_REPOSITORY=\"$(safe_shell_value "$PBS_REPOSITORY")\""
    echo "PBS_NAMESPACE=\"$(safe_shell_value "$PBS_NAMESPACE")\""
    echo "PBS_PASSWORD_FILE=\"$(safe_shell_value "$PBS_PASSWORD_FILE")\""
    echo
    echo "BACKUP_ID=\"$(safe_shell_value "$BACKUP_ID")\""
    echo "BACKUP_TYPE=\"$(safe_shell_value "$BACKUP_TYPE")\""
    echo "ARCHIVE_PREFIX=\"$(safe_shell_value "$ARCHIVE_PREFIX")\""
    echo
    echo "LOGFILE=\"$(safe_shell_value "$LOGFILE")\""
    echo "MOUNT_BASE=\"$(safe_shell_value "$MOUNT_BASE")\""
    echo "SKIP_EMPTY_SHARES=\"$(safe_shell_value "$SKIP_EMPTY_SHARES")\""
    echo "UNMOUNT_AFTER_BACKUP=\"$(safe_shell_value "$UNMOUNT_AFTER_BACKUP")\""
    echo
    echo "SHARES=("

    for share in "${SELECTED_SHARES[@]}"; do
        echo "  \"$(safe_shell_value "$share")\""
    done

    echo ")"
} > "$CONFIG"

chmod 600 "$CONFIG"

echo
echo "Erstelle Backup-Script: $BACKUP_SCRIPT"

cat > "$BACKUP_SCRIPT" <<'EOF_BACKUP'
#!/bin/bash
set -euo pipefail

CONFIG="/etc/unraid-pbs-backup.conf"

[ -f "$CONFIG" ] || {
    echo "Config fehlt: $CONFIG"
    exit 1
}

# shellcheck disable=SC1090
source "$CONFIG"

log() {
    echo "$(date '+%Y-%m-%d %H:%M:%S') - $*" | tee -a "$LOGFILE"
}

fail() {
    log "ERROR: $*"
    exit 1
}

MOUNTED_PATHS=()

cleanup() {
    log "Cleanup gestartet."

    if [ "${UNMOUNT_AFTER_BACKUP:-yes}" = "yes" ]; then
        for mount_path in "${MOUNTED_PATHS[@]:-}"; do
            if mountpoint -q "$mount_path"; then
                umount "$mount_path" || log "WARNUNG: Konnte $mount_path nicht aushängen."
            fi
        done
    else
        log "Mountpoints bleiben eingehängt."
    fi

    log "Cleanup abgeschlossen."
}

safe_archive_name() {
    echo "$1" \
        | tr '[:upper:]' '[:lower:]' \
        | sed 's/ä/ae/g;s/ö/oe/g;s/ü/ue/g;s/ß/ss/g' \
        | tr -c 'a-z0-9_-' '_' \
        | sed 's/_\+/_/g;s/^_//;s/_$//'
}

trap cleanup EXIT

log "------------------------------------------------------------"
log "Starte Unraid SMB Backup nach PBS."

command -v proxmox-backup-client >/dev/null 2>&1 || fail "proxmox-backup-client nicht gefunden."
command -v mount.cifs >/dev/null 2>&1 || fail "mount.cifs nicht gefunden. Bitte installieren: apt install cifs-utils"

[ -f "$SMB_CREDENTIALS" ] || fail "SMB Credentials fehlen: $SMB_CREDENTIALS"
[ -f "$PBS_PASSWORD_FILE" ] || fail "PBS Passwort-Datei fehlt: $PBS_PASSWORD_FILE"

PBS_PASSWORD="$(cat "$PBS_PASSWORD_FILE")"
export PBS_PASSWORD

[ -n "${UNRAID_SERVER:-}" ] || fail "UNRAID_SERVER ist nicht gesetzt."
[ -n "${PBS_REPOSITORY:-}" ] || fail "PBS_REPOSITORY ist nicht gesetzt."
[ -n "${BACKUP_ID:-}" ] || fail "BACKUP_ID ist nicht gesetzt."
[ -n "${BACKUP_TYPE:-}" ] || fail "BACKUP_TYPE ist nicht gesetzt."
[ -n "${ARCHIVE_PREFIX:-}" ] || fail "ARCHIVE_PREFIX ist nicht gesetzt."
[ -n "${MOUNT_BASE:-}" ] || fail "MOUNT_BASE ist nicht gesetzt."
[ -n "${SMB_VERSION:-}" ] || fail "SMB_VERSION ist nicht gesetzt."
[ -n "${SMB_MOUNT_OPTIONS:-}" ] || fail "SMB_MOUNT_OPTIONS ist nicht gesetzt."

mkdir -p "$MOUNT_BASE"

BACKUP_SPECS=()

for share in "${SHARES[@]}"; do
    safe_name="$(safe_archive_name "$share")"

    if [ -z "$safe_name" ]; then
        fail "Ungültiger Share-Name: $share"
    fi

    mount_path="${MOUNT_BASE}/${safe_name}"
    smb_path="//${UNRAID_SERVER}/${share}"

    mkdir -p "$mount_path"

    if mountpoint -q "$mount_path"; then
        log "$mount_path ist bereits gemountet."
    else
        log "Mounte $smb_path nach $mount_path."
        mount -t cifs "$smb_path" "$mount_path" \
            -o "credentials=${SMB_CREDENTIALS},vers=${SMB_VERSION},${SMB_MOUNT_OPTIONS}"
    fi

    mountpoint -q "$mount_path" || fail "$mount_path ist nicht gemountet."

    if [ -z "$(ls -A "$mount_path" 2>/dev/null)" ]; then
        if [ "${SKIP_EMPTY_SHARES:-no}" = "yes" ]; then
            log "WARNUNG: $mount_path ist leer. Share wird übersprungen."
            continue
        else
            fail "$mount_path ist leer. Backup wird abgebrochen."
        fi
    fi

    MOUNTED_PATHS+=("$mount_path")
    BACKUP_SPECS+=("${ARCHIVE_PREFIX}-${safe_name}.pxar:${mount_path}")
done

if [ "${#BACKUP_SPECS[@]}" -eq 0 ]; then
    fail "Keine gültigen Backup-Quellen vorhanden."
fi

log "Folgende Quellen werden gesichert:"
printf '%s\n' "${BACKUP_SPECS[@]}" | tee -a "$LOGFILE"

PBS_NS_ARGS=()

if [ -n "${PBS_NAMESPACE:-}" ]; then
    PBS_NS_ARGS=(--ns "$PBS_NAMESPACE")
    log "PBS Namespace: $PBS_NAMESPACE"
else
    log "PBS Namespace: Root Namespace"
fi

log "PBS Repository: $PBS_REPOSITORY"
log "Backup-ID: $BACKUP_ID"
log "Backup-Typ: $BACKUP_TYPE"
log "Starte proxmox-backup-client."

proxmox-backup-client backup \
    "${BACKUP_SPECS[@]}" \
    --repository "$PBS_REPOSITORY" \
    "${PBS_NS_ARGS[@]}" \
    --backup-type "$BACKUP_TYPE" \
    --backup-id "$BACKUP_ID" \
    2>&1 | tee -a "$LOGFILE"

log "Backup erfolgreich abgeschlossen."
EOF_BACKUP

chmod +x "$BACKUP_SCRIPT"

echo

if ask_yes_no "systemd Timer für automatische Backups erstellen?" "yes"; then
    TIMER_TIME="$(ask_default "Uhrzeit für tägliches Backup" "03:30")"

    cat > "$SYSTEMD_SERVICE" <<EOF_SERVICE
[Unit]
Description=Unraid SMB Share Backup to Proxmox Backup Server
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
ExecStart=$BACKUP_SCRIPT
EOF_SERVICE

    cat > "$SYSTEMD_TIMER" <<EOF_TIMER
[Unit]
Description=Run Unraid SMB Share Backup to PBS daily

[Timer]
OnCalendar=*-*-* $TIMER_TIME:00
Persistent=true
RandomizedDelaySec=300

[Install]
WantedBy=timers.target
EOF_TIMER

    systemctl daemon-reload
    systemctl enable --now unraid-pbs-backup.timer

    echo
    echo "systemd Timer wurde erstellt und aktiviert."
    echo "Timer anzeigen:"
    echo "  systemctl list-timers | grep unraid-pbs"
else
    echo "Kein Timer erstellt."
fi

echo
echo "============================================================"
echo "Setup abgeschlossen."
echo "============================================================"
echo
echo "Config:        $CONFIG"
echo "SMB-Creds:     $SMB_CREDENTIALS"
echo "PBS-Secret:    $PBS_PASSWORD_FILE"
echo "Backup-Script: $BACKUP_SCRIPT"
echo
echo "Test starten mit:"
echo
echo "  $BACKUP_SCRIPT"
echo
echo "Log anzeigen mit:"
echo
echo "  tail -f $LOGFILE"
echo

Warum das Script für mich so spannend ist

Der eigentliche Mehrwert liegt nicht darin, einfach nur Dateien von A nach B zu kopieren. Das könnte man auch mit vielen anderen Werkzeugen machen.

Spannend wird es durch die Kombination mit dem Proxmox Backup Server. Die Daten werden nicht jedes Mal stumpf komplett neu abgelegt, sondern effizient verarbeitet. Wenn sich nichts geändert hat, muss auch nichts neu übertragen werden. Dadurch spart man Speicherplatz und Zeit.

Gleichzeitig bekommt man Versionen. Das ist im Alltag extrem wertvoll. Wenn eine Datei versehentlich geändert oder gelöscht wurde, kann man auf einen älteren Stand zurückgreifen.

Gerade für Dokumente, Projektordner, Konfigurationsdateien oder wichtige NAS-Freigaben ist das eine sehr saubere Lösung.


Performance und Ressourcen

Bei Backups wird oft nur über Speicherplatz gesprochen. Mindestens genauso wichtig sind aber CPU, RAM und Netzwerk.

Der Proxmox Backup Server komprimiert, dedupliziert, verifiziert und führt Garbage Collection durch. Das kostet Ressourcen. Im Test war zu sehen, dass das System durchaus arbeitet, aber insgesamt gut damit zurechtkommt.

Das DXP4800 Pro wird mit 8 GB RAM ausgeliefert. Für einfache Setups kann das reichen. Ich persönlich würde bei einem Proxmox Backup Server aber eher zu 16 GB RAM tendieren, wenn man mehrere Aufgaben parallel laufen lässt oder größere Datenmengen verarbeitet.

Mehr RAM macht das System nicht automatisch magisch schneller, aber es sorgt für mehr Reserven. Gerade wenn Backup-Jobs, Sync-Jobs, Verify-Jobs und Garbage Collection zusammenkommen, ist das sinnvoll.


Für wen lohnt sich dieses Setup?

Dieses Setup ist vor allem dann interessant, wenn du bereits Proxmox nutzt und eine saubere Backup-Lösung aufbauen möchtest.

Besonders spannend finde ich es für:

  • HomeLab-Nutzer mit mehreren VMs und Containern
  • kleinere Unternehmen mit überschaubarer Infrastruktur
  • Nutzer mit 10-Gigabit-Netzwerk
  • alle, die schnelle Restores für aktuelle Backups wollen
  • alle, die zusätzlich NAS-Freigaben versioniert sichern möchten

Weniger sinnvoll ist es, wenn du nur ein sehr kleines Setup mit ein oder zwei unkritischen Systemen betreibst. Dann kann ein einfacheres Backup-Konzept ausreichend sein.

Wenn du aber sowieso ein leistungsfähiges NAS suchst und Proxmox Backup Server ernsthaft einsetzen möchtest, ist das DXP4800 Pro eine sehr spannende Plattform.


Was dieser Beitrag bewusst nicht ersetzt

Ich möchte an dieser Stelle ganz bewusst sagen: Dieser Blogbeitrag ersetzt nicht das Video.

Das Video zeigt die praktische Umsetzung, die Oberfläche, die BIOS-Einstellungen, die Installation, das Anlegen der Datastores, die Netzwerkprüfung, die Sync-Jobs und die SMB-Sicherung im Ablauf.

Der Beitrag erklärt dir dagegen das Warum dahinter. Er soll dir helfen, das Konzept einzuordnen und zu verstehen, warum ich die Hardware so einsetze.

Wenn du das Setup wirklich nachbauen möchtest, solltest du dir das Video anschauen. Dort siehst du die einzelnen Schritte deutlich besser, als man sie in einem Blogbeitrag sinnvoll darstellen könnte.


Mein Fazit

Das UGREEN NAS DXP4800 Pro hat mich in diesem Szenario positiv überrascht. Nicht, weil es einfach nur ein NAS ist, sondern weil die Hardware sehr gut zu einem dedizierten Proxmox Backup Server passt.

Die Kombination aus NVMe, HDD-Bays und 10-Gigabit-Ethernet macht daraus eine flexible Backup-Plattform. Mit dem Hybrid-Konzept bekomme ich schnelle aktuelle Backups und gleichzeitig ein großes Archiv für längere Aufbewahrungszeiten.

Zusätzlich macht die SMB-Sicherung per Script das Ganze noch vielseitiger. Damit lassen sich nicht nur Proxmox-VMs und Container sichern, sondern auch klassische Netzwerkfreigaben.

Für mich ist das ein Setup, das sehr gut in ein modernes HomeLab passt. Es ist nicht die billigste Lösung, aber eine technisch sehr saubere und flexible Variante.

Wenn du bereits mit Proxmox arbeitest und dein Backup-Konzept auf ein neues Level bringen möchtest, solltest du dir dieses Setup auf jeden Fall genauer anschauen.

Nützliche Links zum Setup

Wenn du das Setup aus dem Video bzw. aus diesem Beitrag nachbauen möchtest, findest du hier die wichtigsten Links gesammelt. Ich habe die Liste bewusst thematisch sortiert, damit du nicht lange suchen musst.

UGREEN NAS DXP4800 Pro und NAS-Serie*

Das zentrale Gerät in diesem Setup ist das UGREEN NAS DXP4800 Pro. Über die offizielle Produktseite findest du weitere technische Details, Bilder und Informationen direkt von UGREEN:

👉 UGREEN DXP4800 Pro:
https://nas.de.ugreen.com/WDdI4o

Wenn du dir nicht nur das DXP4800 Pro, sondern auch die anderen Modelle der UGREEN NAS-Serie anschauen möchtest, findest du hier die Übersicht:

👉 UGREEN NAS-Serie / Übersicht:
https://nas.de.ugreen.com/uGqrea

Zusätzlich gibt es die Geräte bzw. die NAS-Serie auch über Amazon:

👉 UGREEN DXP4800 Pro bei Amazon:
https://bit.ly/4u8bjYU

👉 UGREEN NAS-Serie / Übersicht bei Amazon:
https://bit.ly/4dlehSw

Erweiterungen für RAM, NVMe und HDDs

Für den Proxmox Backup Server kann zusätzlicher Arbeitsspeicher sinnvoll sein. Das DXP4800 Pro wird zwar mit 8 GB RAM ausgeliefert, für ein etwas komfortableres PBS-Setup würde ich persönlich aber eher auf 16 GB gehen.

👉 Passender RAM-Riegel für das DXP4800 Pro:
https://amzn.to/4fg4sI6

Für den schnellen Datastore im Proxmox Backup Server sind NVMe-SSDs interessant. Genau dort landen in meinem Konzept die aktuellen Backups, damit Sicherung und Restore möglichst flott laufen.

👉 NVMe SSDs für schnellen PBS-Datastore:
https://amzn.to/3PCF2Ko

Für das größere Backup-Archiv eignen sich klassische HDDs besser, weil sie pro Terabyte deutlich günstiger sind. In meinem Konzept werden die älteren bzw. länger aufzubewahrenden Sicherungen dort abgelegt.

👉 HDDs für Backup-Archiv:
https://amzn.to/4tuWDBM

Remote-Installation und Software

Für die Installation nutze ich im Video eine KVM-over-IP-Lösung. Das ist besonders praktisch, wenn man ein Gerät ohne dauerhaft angeschlossenen Monitor und Tastatur installieren oder administrieren möchte.

👉 KVM over IP / Remote-Installationshilfe:
https://amzn.to/3OZVWm9

Den Proxmox Backup Server selbst findest du direkt bei Proxmox. Dort gibt es auch weitere Informationen zum Produkt und zur offiziellen Dokumentation.

👉 Proxmox Backup Server:
https://www.proxmox.com/de/produkte/proxmox-backup-server/uebersicht

Für die Nacharbeiten nach der Installation nutze ich im Video die bekannten Proxmox Helper Scripts. Diese helfen unter anderem dabei, typische Einstellungen nach der Installation komfortabler vorzunehmen.

👉 Proxmox Helper Scripts:
https://community-scripts.org/categories?category=proxmox-and-virtualization

Ergänzende Inhalte von mir

Wenn dich zusätzlich interessiert, was das originale UGREEN OS kann, findest du mein separates Video zu den Apps und NAS-Funktionen hier:

👉 Mein Video zum UGREEN OS / Apps / NAS-Funktionen:
https://youtu.be/j6az19qcPEA

Hinweis: Einige der Links können Affiliate-Links sein. Wenn du darüber etwas kaufst, unterstützt du meinen Kanal, ohne dass dir dadurch Mehrkosten entstehen.


Transparenzhinweis

Das UGREEN NAS DXP4800 Pro wurde mir von UGREEN für das Video zur Verfügung gestellt. Meine Meinung bleibt davon unabhängig. Gerade in diesem Projekt war mir wichtig, die Hardware nicht nur im Standardbetrieb zu zeigen, sondern bewusst einen alternativen und technisch anspruchsvolleren Anwendungsfall umzusetzen.


Info

Wenn du sehen möchtest, wie ich das komplette Setup Schritt für Schritt aufbaue, schau dir unbedingt das Video dazu an. Dort zeige ich die Installation, die Speicherstruktur, den Sync zwischen NVMe und HDD sowie die SMB-Sicherung mit dem Script im Detail.

Schreib mir gerne in die Youtube Kommentare, ob du deinen Proxmox Backup Server lieber virtuell, auf eigener Hardware oder direkt auf einem NAS betreibst.

Worst-Case-Szenario im HomeLab: Proxmox Backup Server mit ZFS richtig testen

👉 Direkt auf YouTube schauen und abonnieren:
Smart Home & More auf YouTube

Worst-Case-Szenario im HomeLab: Proxmox Backup Server mit ZFS richtig testen

Einleitung

Ich spreche in meinen Videos und Blogbeiträgen oft über Backups, Redundanz und saubere HomeLab-Setups. Aber ganz ehrlich: Backups zu haben bringt nur dann wirklich etwas, wenn man den Worst Case auch einmal realistisch testet. Genau darum geht es in diesem Beitrag.

Was passiert, wenn:

  • die Hardware komplett ausfällt?
  • ein NAS abraucht?
  • ein ZFS-Pool plötzlich nicht mehr verfügbar ist?

Ich zeige hier Schritt für Schritt, wie ich ein solches Worst-Case-Szenario mit einem Proxmox Backup Server (PBS) und ZFS simuliert und erfolgreich wiederhergestellt habe – inklusive Import eines bestehenden ZFS-Pools und dem Austausch einer defekten Festplatte.


Ausgangssituation: Mein HomeLab-Setup

In meinem Setup läuft ein Großteil der Infrastruktur auf einem UGREEN DXP 8800 Plus (8-Bay NAS).

UGREEN NASync DXP8800 Plus 8-Bay Desktop-NAS, Intel i5 1235u 10-Core-CPU, 8 GB DDR5-RAM, eingebaut 128 GB SSD, 2 x 10GbE, 2 x M.2 NVMe-Steckplatz, 8K HDMI, 2 x TBT4 (ohne Festplatte)
  • Zwei 10GbE-Netzwerkanschlüsse: Zwei 10GbE-Hochgeschwindigkeitsnetzwerkanschlüsse, die zu einer Bandbreite von 20 G zusammengefasst werden können, um Downloadgeschwindigkeiten von bis zu 2500 MB/s zu erreichen. Große Dateien lassen sich problemlos übertragen. Die Last zwischen den beiden Portverbindungen kann dynamisch angepasst und ausgeglichen werden, um die Übertragungseffizienz zu verbessern.
  • Beispiellose Verarbeitungsleistung: Mit einem Intel Core i5-Prozessor der 12. Generation mit 10 Kernen und 12 Threads wird die Verarbeitungsleistung im Vergleich zu früheren Prozessoren sprunghaft verbessert.
  • 8-Bay, 272 TB riesiger Datenspeicher: Ausgestattet mit acht SATA- und zwei M.2 NVMe-Laufwerkschächten verfügt das NASync DXP8800 Plus über eine maximale Speicherkapazität von bis zu 272 TB. Speichern Sie Tausende von HD-Filmen, Bildern und Dokumenten und machen Sie NASync zu einer Filmbibliothek, einem Fotoalbum und einem Dateispeicherplatz in einem.
  • Eine umfassende App: Anstatt einzelne Anwendungen für bestimmte Funktionen herunterzuladen, integriert die NAS-App diese Funktionen an einem Ort. Greifen Sie von einem praktischen Ort aus auf Speichermanager, Dateien, Fotos und mehr zu.
  • Professionelle Datensicherheit: Im Vergleich zu Cloud-Laufwerken ermöglicht NASync Benutzern, große Mengen persönlicher Daten auf vertrauenswürdigen lokalen Geräten zu speichern, wodurch Datenverlust und Überwachung weitestgehend verhindert werden. Datenübertragung und Konten können mit professioneller Verschlüsselung und Multi-Faktor-Authentifizierung vollständig geschützt werden.

Darauf befindet sich unter anderem:

  • Proxmox
  • eine virtuelle Maschine mit Proxmox Backup Server
  • zwei per PCI-Passthrough durchgereichte HDDs
  • darauf ein ZFS-Mirror-Pool für die Backups

Zusätzlich habe ich ein zweites System, ein DXP 4800 Plus (4-Bay NAS), das im Ernstfall als Ersatz dienen kann.

UGREEN NASync DXP4800 Plus, 4-Bay Desktop-NAS, Intel Pentium Gold 8505 Prozessor mit 5 Kernen, 8 GB DDR5 RAM, Eingebaute 128GB-SSD, 10GbE & 2.5GbE LAN, 2 × M.2 NVMe-Slots, HDMI 4K (ohne Festplatten)
  • 12. Gen 5-Kern Intel Prozessor: Diese leistungsstarke CPU von Intel bietet ein außergewöhnlich flüssiges Erlebnis und sorgt für einen erheblichen Leistungszuwachs im Vergleich zu früheren Generationen.
  • Benutzerfreundliche App: Verwalte deinen Speicher und greife von all deinen Geräten auf deine Dateien zu, ganz einfach mit unserer maßgeschneiderten Software – und das alles ohne mehrere Tools oder komplizierte Drittanbieter-Software. Verfügbar für Android, iOS, Windows, Mac, Webbrowser und Smart-TVs.
  • Blitzschnelle 10GbE- und 2.5GbE-Netzwerkanschlüsse: Der NASync DXP4800 Plus bietet Datenraten von bis zu beeindruckenden 1250 MB/s über zwei separate Anschlüsse. Ideal für alle, die eine schnelle und reibungslose Übertragung von 4K-Videos und großen Dateien benötigen.
  • 4 Bays und maximal 144TB: Die vier SATA-Bays unterstützen jeweils bis zu 32TB. Zusätzlich können zwei kompakte M.2 NVMe SSDs mit jeweils bis zu 8TB installiert werden (für SSD-Caching oder zusätzlichen schnellen Speicher). Bei vollständiger Ausnutzung aller Steckplätze beträgt die maximale Kapazität beeindruckende 144TB.
  • Professionelle Datensicherheit: Mit sicherer Verschlüsselung sind Benutzerkonten und Daten vollständig geschützt.

Das Ziel dieses Tests:

Was passiert, wenn das 8-Bay-NAS komplett ausfällt – und wie komme ich wieder an meine Backups?


Szenario 1: Totalausfall der Hardware

Annahme

Das komplette Hauptsystem ist defekt. Mainboard, Netzteil – egal. Die Festplatten sind aber noch intakt.

Vorgehen

  1. Ich baue die beiden ZFS-Festplatten aus dem 8-Bay-NAS aus.
  2. Die Platten stecke ich in das 4-Bay-NAS.
  3. Auf dem neuen System installiere ich Proxmox.
  4. Anschließend setze ich einen neuen Proxmox Backup Server als VM auf.

Die ursprüngliche PBS-Konfiguration habe ich bewusst nicht gesichert, um ein realistisches Worst-Case-Szenario zu simulieren.


ZFS-Pool importieren

Nach der frischen Installation des Proxmox Backup Servers sind die Festplatten zwar sichtbar, aber:

  • kein Datastore
  • kein eingebundener ZFS-Pool

ZFS-Pool finden

In der PBS-Shell führe ich folgenden Befehl aus:

zpool import

Damit wird mir der vorhandene ZFS-Pool angezeigt.

Pool importieren

Der Import erfolgt mit:

zpool import -f zfspool

(„zfspool“ natürlich durch den eigenen Poolnamen ersetzen.)

Danach ist der Pool im System verfügbar, aber noch nicht als Datastore eingebunden.


Datastore wiederherstellen

Jetzt kommt der entscheidende Punkt:

  1. In der PBS-Weboberfläche gehe ich auf Add Datastore
  2. Name: identisch zum alten Datastore
  3. Pfad:

/mnt/datastore/zfspool

  1. Unter Advanced aktiviere ich:

Reuse existing datastore

Nach dem Hinzufügen erscheint:

  • der alte Datastore
  • inklusive aller Backups

Die virtuelle Maschine ist sofort wieder verfügbar.

Ergebnis:

➡️ Vollständige Wiederherstellung der Backups – ohne vorherige Konfigurationssicherung.


Szenario 2: Ausfall einer einzelnen Festplatte

Jetzt wird es noch realistischer.

Simulation

  • Eine der beiden ZFS-Platten wird entfernt
  • Der Pool ist anschließend degraded

Der Proxmox Backup Server meldet beim Start:

One or more devices could not be used


Defekte Platte ersetzen

Alte Platte entfernen

Zunächst ermittele ich die ID der Platte, die nicht mehr erreichbar ist.

zpool status -g zfspool

Neue Platte einbinden

  1. Neue HDD physisch einsetzen
  2. Per Passthrough an die PBS-VM durchreichen
  3. Disk-ID ermitteln:

ls -l /dev/disk/by-id/

Pool reparieren

Jetzt ersetze ich die defekte Platte durch die neue:

zpool replace zfspool <alte-disk-id> <neue-disk-id>

Falls auf der neuen Platte noch Daten liegen:

  • entweder per Shell löschen
  • oder komfortabel über die Weboberfläche Wipe Disk

Danach den Befehl erneut ausführen.


Resilvering & Abschluss

Nach kurzer Zeit startet das Resilvering.

Mit:

zpool status zfspool

lässt sich der Fortschritt prüfen.

Nach Abschluss:

  • Pool Status: ONLINE
  • Keine Fehler
  • Alle Backups vollständig vorhanden

Fazit: Warum dieser Test extrem wichtig ist

Dieser Test zeigt sehr deutlich:

  • Backups ohne Wiederherstellungstest sind wertlos
  • ZFS ist extrem robust und flexibel
  • Ein Proxmox Backup Server mit ZFS ist absolut worst-case-tauglich

Selbst bei:

  • kompletter Hardware-Zerstörung
  • Neuinstallation ohne Konfigurationssicherung
  • Ausfall einzelner Festplatten

konnte ich meine Backups vollständig und sauber wiederherstellen.


Meine Empfehlung

Wenn du ein HomeLab betreibst:

  • teste mindestens einmal dein Worst-Case-Szenario
  • simuliere Hardware-Ausfälle
  • überprüfe, ob du wirklich wieder an deine Daten kommst

Denn genau dann, wenn es darauf ankommt, willst du keine Experimente mehr machen.


Wenn du weitere Beiträge rund um Proxmox, ZFS, Backups und saubere HomeLab-Architekturen suchst, schau gern auf meinem YouTube-Kanal Smart Home & More vorbei.

Proxmox Backup Server einrichten – so sichere ich mein komplettes HomeLab ( inkl. ZFS-Mirror, UGREEN NAs & Sync Setup)

👉 Direkt auf YouTube schauen und abonnieren:
Smart Home & More auf YouTube

Proxmox Backup Server Titelbild

In meinem HomeLab spielt der Proxmox Backup Server eine zentrale Rolle. Viele unterschätzen das Thema Backups – aber wenn eine VM plötzlich weg ist oder Hardware ausfällt, sind die Schmerzen groß. Genau deshalb zeige ich dir in diesem Beitrag, wie ich meinen Proxmox Backup Server (PBS) eingerichtet habe: mit ZFS-Mirror, by-id-Passthrough, Backup-Jobs, Remote-Sync und Wiederherstellungsstrategie.

Ich verwende in meinem Setup mehrere UGREEN NAS-Systeme, die hervorragend mit Proxmox harmonieren und gleichzeitig effizient und leise laufen. Meine Geräte:

Dazu habe ich den Speicher erweitert:
48 GB RAM für UGREEN NAS*
👉 https://amzn.to/4nZzEfw


Warum Backups mehr sind als nur eine Kopie

Bevor wir starten, kurz der wichtigste Unterschied:

  • ZFS Mirror → schützt mich vor Plattenausfall
  • Proxmox Backup Server → schützt mich vor Datenverlust
  • Remote Sync → schützt mich vor Brand, Diebstahl, Defekt

Ich erlebe in der Community häufig, dass ein RAID oder ZFS-Mirror als Backup verstanden wird. Das ist aber nur eine Verfügbarkeitsschicht, kein echtes Backup.
Backups entstehen erst, wenn:

  • Daten inkrementell gespeichert werden
  • Versionen existieren
  • sie auf getrennter Hardware liegen

Genau das erfüllt der Proxmox Backup Server im gezeigten Setup.


Mein Setup – Überblick

Ich nutze:

  • Proxmox 9 auf meinem HomeLab
  • UGREEN DXP8800 Plus als Haupt-NAS
  • UGREEN DXP4800 Plus als Backup-NAS
  • Ein weiterer PBS in der Cloud (optional)

Damit kann ich selbst bei einem kompletten Hardware-Schaden alle Backups wiederherstellen.


ZFS Mirror anlegen – die Basis

Zuerst habe ich im UGREEN NAS ein ZFS Mirror aus 2 HDDs angelegt. Das schafft Redundanz und optimale Performance für den PBS-Datastore.

In meinem Fall:

Damit ZFS in der PBS-VM funktioniert, brauche ich die echten Laufwerke – und genau dafür ist Passthrough per /dev/disk/by-id unverzichtbar.


Warum ich /dev/disk/by-id nutze

Wenn du einfach /dev/sda oder /dev/sdb durchreichst, kann die Reihenfolge nach einem Reboot oder Update wechseln.
Das wäre fatal.

Darum nutze ich:

ls -l /dev/disk/by-id

Dort suche ich meine beiden HDDs heraus – in meinem Fall z. B.:

  • ata-ST4000DM004_XXXXXX
  • ata-ST4000DM004_YYYYYY

Diese IDs trage ich später bei der VM als Passthrough ein.

Erste HDD an scsi1:

qm set 126 --scsi1 /dev/disk/by-id/ata-WDC_WD40EFPX-68C6CN0_WD-WX12DC482U93

Zweite HDD an scsi2:

qm set 126 --scsi2 /dev/disk/by-id/ata-WDC_WD40EFPX-68C6CN0_WD-WX22DC4LF10E

Proxmox Backup Server ISO vorbereiten

Ich lade das ISO bei Proxmox herunter und packe es ins in mein Proxmox.

Dann lege ich eine neue VM an:

  • BIOS: UEFI
  • Machine: q35
  • Disk: 64 GB (SSD-Simulation)
  • RAM: 2 GB
  • Cores: 2
  • Netzwerkkarte: VirtIO

Alles sehr genügsam – PBS ist extrem leichtgewichtig.


ZFS Mirror im PBS anlegen

Sobald die VM läuft:

  1. Storage → Disks
  2. Die beiden Passthrough-HDDs auswählen
  3. ZFS → Mirror
  4. Namen vergeben (z. B. zfs-mirror-pbs)
  5. Erstellen

PBS im Proxmox einbinden

Jetzt binde ich den Backup Server in Proxmox ein:

  • Datacenter → Storage → Add → Proxmox Backup Server

Hier brauche ich:

  • IP des PBS
  • Benutzer: root@pam
  • Datastore-Name (z. B. zfsmirrorpbs)
  • Fingerprint aus PBS → Dashboard → „Show Fingerprint“

Nach dem Speichern erscheint der PBS sofort im Storage-Baum.

Backup-Job in Proxmox erstellen

Jetzt richte ich den eigentlichen Backup-Job ein:

  • Datacenter → Backup → Add
  • Schedule: täglich 21:00 Uhr
  • Mode: selected VMs (damit PBS sich nicht selbst sichert)

Optional:

  • Notifications per Mail
  • Compression Zstandard
  • Bandwidth-Limit

Retention – wie viele Backups ich behalte

Hier verwende ich eine Mischung aus kurz und langfristig:

  • Keep Last: 5
  • Keep Daily: 1
  • Keep Weekly: 1
  • Keep Monthly: 2
  • Keep Yearly: 2

Damit habe ich:

  • schnelle Wiederherstellung
  • Schutz vor Ransomware
  • sauberen Versionsverlauf

Backup testen

Ich starte den Job manuell:

Backup → Run now

Wenn die VM danach im Datastore auftaucht, weiß ich:
Das Grundsetup passt.


Mein zweiter PBS – Remote Sync für echte Sicherheit

Jetzt kommt der wichtigste Teil:
Backups müssen extern gespeichert werden.

Ich habe darum ein zweites NAS:

Dort läuft ebenfalls ein Proxmox Backup Server.

Ich richte dann ein:

  • Remote
  • Pull-Job (mein Favorit, weil sicherer)
  • Automatische Synchronisation

Beispiel:

  • Quelle: PBS #1 (Hauptsystem)
  • Ziel: PBS #2 (Backup-NAS)

So habe ich die Daten:

  • vor Ort → schnell wiederherstellbar
  • auf zweiter Hardware → geschützt vor Totalausfall

Option:
Ich betreibe zusätzlich einen PBS in der Hetzner Cloud für maximale Redundanz.


Energieoptimierung – mein Ansatz

Viele fragen mich:

„Kann ich das zweite NAS nicht einfach herunterfahren?“

Ja, kann man:

  • Second-NAS per Sync-Zeitpunkt wecken
  • Nach Sync automatisch herunterfahren
  • ZFS-Spindown aktivieren
  • Nur einmal pro Tag synchronisieren

Dadurch spare ich signifikant Energie.

Ich plane dazu ein eigenes Video & Blogbeitrag. Falls Interesse besteht, bitte in den Kommentaren zum Video einen kleinen Hinweis geben.


Restore – warum PBS hier so stark ist

Was ich am Proxmox Backup Server besonders schätze:

  • Deduplizierung
  • Schnelle inkrementelle Sicherungen
  • Extrem schnelle Wiederherstellung
  • Versioning
  • Bandbreitenlimit
  • Datensparsamkeit

Ich kann:

  • komplette VMs wiederherstellen
  • nur einzelne Dateien mounten
  • Snapshots vergleichen
  • Remote-Backups ziehen

Im Fall eines Hardware-Defekts:

  • ZFS-Mirror in neue Hardware einstecken
  • PBS ISO booten
  • Pool importieren
  • Backups direkt wiederherstellen

Fazit – ein zuverlässiges, effizientes Backup-System

Mit dem Proxmox Backup Server, ZFS-Mirror und einem zweiten NAS habe ich endlich ein Setup, das:

  • sicher,
  • schnell,
  • energieeffizient
  • und absolut robust ist.

Ich kann Hardware austauschen, VMs sofort wiederherstellen und selbst im Worst-Case bleibt mein komplettes HomeLab funktionsfähig.

Wenn du ein UGREEN-NAS einsetzt oder ein kompaktes HomeLab betreiben möchtest, kann ich dir diese Lösungen ehrlich empfehlen:

Wenn du Fragen hast oder dein eigenes Backup-Setup optimieren willst, schreib’s gern in die Kommentare unter dem Video.

Folgende Beiträge zum Themen könnten dich auch interessieren:

Unraid unter Proxmox installieren – Mein komplettes HomeLab-Setup Schritt für Schritt

Ugreen NAS mit TrueNAS – mein Setup unter Proxmox, ZFS & SMB-Freigaben im Praxistest

Ugreen NAS im Test – Mein Setup mit dem DXP8800 Plus & DXP4800 Plus für Smart Home und Proxmox

Proxmox API Home Assistant Backup automatisieren – VMs überwachen & sichern

👉 Direkt auf YouTube schauen und abonnieren:
Smart Home & More auf YouTube

Einleitung

Proxmox API Home Assistant Backup – in diesem Praxis‑Guide lernst du, wie du mithilfe der Proxmox API den Zustand deiner virtuellen Maschinen abfragst, Dashboards in Home Assistant erstellst und Backups automatisierst. Statt auf HACS setzt du dabei auf REST‑Sensoren und API‑Calls, um deine VMs sicher zu überwachen und zu sichern.

Vorbereitung in Proxmox – Benutzer, Token und Rechte einrichten

Bevor du in Home Assistant loslegen kannst, musst du Proxmox entsprechend vorbereiten.

API‑Benutzer und Token anlegen

Erstelle im Proxmox DataCenter einen neuen User (z. B. homeassistant) ohne Passwort, denn wir arbeiten mit API‑Tokens. Wähle als Realm pve und lege anschließend unter API Token einen neuen Token für diesen User an. Achte darauf, Privilege Separation zu deaktivieren. Kopiere dir den Token sofort, da er später nicht mehr angezeigt wird.

Proxmox API Home Assistant Backup - User

Proxmox API Home Assistant Backup - API Token

Rollen konfigurieren

Für den Zugriff auf VM‑Informationen und Backups benötigen wir passende Rollen:

  • Lege eine neue Rolle (z. B. homeassistant-role) mit den Privilegien VM.Audit, Datastore.Audit und Datastore.AllocateSpace, VM.Backup an.
  • Weise diese Rolle dem User auf den benötigten Pfaden zu: dem Node (/nodes/pve-lerch) und den VMs (/vms/*).

Diese granularen Berechtigungen sorgen dafür, dass Home Assistant lediglich die benötigten Daten abrufen und einen Proxmox API Home Assistant Backup auslösen darf.

Proxmox API Home Assistant Backup - Rollen definieren

Home Assistant konfigurieren – REST‑Sensoren anlegen

Im nächsten Schritt richten wir Home Assistant ein. Falls du noch keinen File Editor installiert hast, installiere diesen im Add-on Store von Home Assistant.

Proxmox API Home Assistant Backup - Add-on File Editor

REST‑Sensor für VM‑Informationen

Über den YAML‑Eintrag rest: definieren wir einen Sensor, der regelmäßig einen GET‑Request an die Proxmox API sendet. Die URL lautet beispielsweise:

https://<proxmox-host>/api2/json/nodes/pve-larch/qemu

Als Header gibst du Authorization: PVEAPIToken=<user>@pve!<token-id>=<token> an. Im value_template kannst du die JSON‑Antwort weiterverarbeiten und die Daten in Attributen speichern.

  - resource: https://192.168.101.69:8006/api2/json/nodes/pvelerch/qemu
    method: GET
    headers:
      Authorization: "PVEAPIToken=homeassistant@pve!proxmox=be729a21-e76b-430b-84bf-40d096d035a6"
    verify_ssl: false
    scan_interval: 10
    sensor:
      - name: "PVELerch VM Raw"
        unique_id: pvelerch_vm_raw
        value_template: "OK"
        json_attributes:
          - data

Vergiss nicht, Home Assistant neu zu starten, damit der Sensor angelegt wird. Anschließend siehst du eine Liste aller VMs als JSON‑Attribut, inklusive ihrer Namen, IDs und Status.

REST‑Sensor für LXC‑Container

Für LXC‑Container wiederholst du den Sensor mit dem Endpunkt .../lxc. Denke daran, dass nicht alle API‑Attribute identisch sind – die Belegung des Festplattenspeichers (disk-usage) steht nur bei Containern zur Verfügung.

  - resource: https://192.168.101.69:8006/api2/json/nodes/pvelerch/lxc
    method: GET
    headers:
      Authorization: "PVEAPIToken=homeassistant@pve!proxmox=be729a21-e76b-430b-84bf-40d096d035a6"
    verify_ssl: false
    scan_interval: 10
    sensor:
      - name: "PVELerch LXC Raw"
        unique_id: pvelerch_lxc_raw
        value_template: "OK"
        json_attributes:
          - data

Hier nochmal beide Rest Sensoren für die Configuration.Yaml. Beachte, dass am Anfang einmal „rest:“ stehen muss.

rest:
  - resource: https://192.168.101.69:8006/api2/json/nodes/pvelerch/qemu
    method: GET
    headers:
      Authorization: "PVEAPIToken=homeassistant@pve!proxmox=be729a21-e76b-430b-84bf-40d096d035a6"
    verify_ssl: false
    scan_interval: 10
    sensor:
      - name: "PVELerch VM Raw"
        unique_id: pvelerch_vm_raw
        value_template: "OK"
        json_attributes:
          - data
          
  - resource: https://192.168.101.69:8006/api2/json/nodes/pvelerch/lxc
    method: GET
    headers:
      Authorization: "PVEAPIToken=homeassistant@pve!proxmox=be729a21-e76b-430b-84bf-40d096d035a6"
    verify_ssl: false
    scan_interval: 10
    sensor:
      - name: "PVELerch LXC Raw"
        unique_id: pvelerch_lxc_raw
        value_template: "OK"
        json_attributes:
          - data

Dashboard gestalten – Markdown‑Karte für VM‑Übersicht

Um die Daten ansprechend zu visualisieren, kannst du eine Markdown‑Karte in deinem Home‑Assistant‑Dashboard einfügen. Im Template liest du die Attribute der Sensoren aus und listest jede VM mit Name, Uptime, Status und, bei LXC‑Containern, prozentual belegtem Speicherplatz auf.

Proxmox API Home Assistant Backup - Mark Down Karte
{% set vms = state_attr('sensor.pvelerch_vm_raw', 'data') or [] %}
{% set lxcs = state_attr('sensor.pvelerch_lxc_raw', 'data') or [] %}

## 🖥️ Virtuelle Maschinen (QEMU)

{% for vm in vms | sort(attribute='vmid') %}
  {% set days = vm.uptime // 86400 %}
  {% set hours = (vm.uptime % 86400) // 3600 %}
  {% set minutes = (vm.uptime % 3600) // 60 %}
  {% if days > 0 %}
    {% set uptime_str = days ~ 'd ' ~ hours ~ 'h' %}
  {% else %}
    {% set uptime_str = hours ~ 'h ' ~ minutes ~ 'm' %}
  {% endif %}
- **{{ vm.vmid }}** | {{ vm.name }} | Uptime: {{ uptime_str }} | {{ "🟢" if vm.status == "running" else "🔴" }}
{% endfor %}

## 📦 LXC-Container

{% for lxc in lxcs | sort(attribute='vmid') %}
  {% set days = lxc.uptime // 86400 %}
  {% set hours = (lxc.uptime % 86400) // 3600 %}
  {% set minutes = (lxc.uptime % 3600) // 60 %}
  {% if days > 0 %}
    {% set uptime_str = days ~ 'd ' ~ hours ~ 'h' %}
  {% else %}
    {% set uptime_str = hours ~ 'h ' ~ minutes ~ 'm' %}
  {% endif %}
- **{{ lxc.vmid }}** | {{ lxc.name }} | Disk: {{ ((lxc.disk / lxc.maxdisk) * 100) | round(1) if lxc.maxdisk and lxc.maxdisk > 0 else 'n/a' }} % | Uptime: {{ uptime_str }} | {{ "🟢" if lxc.status == "running" else "🔴" }}
{% endfor %}

So siehst du live, wenn eine VM gestoppt wird oder startet. Über Automationen kannst du sogar Benachrichtigungen verschicken, wenn sich der Status ändert. Achte darauf, dass du die Entitäten auf deine Entitätsnamen anpasst.

sensor.pvelerch_vm_raw

sensor.pvelerch_lxc_raw

Monitoring & Test – Live‑Überwachung von VMs

Teste deine Konfiguration, indem du eine VM in Proxmox stoppst und wieder startest. Die Änderungen sollten in der Markdown‑Karte nach dem nächsten Scan‑Intervall sichtbar sein. Dieses Szenario zeigt, wie zuverlässig die REST‑API im Zusammenspiel mit Home Assistant funktioniert.

Backups per API auslösen

Eines der mächtigsten Features der Proxmox API ist die Möglichkeit, Backups zu starten.

Rollen erweitern

Erweitere deine Rolle um die Berechtigungen VM.Backup und Datastore.AllocateSpace, damit der User Backups auslösen darf ( haben wir schon im ersten Schritt getan ). Vergiss nicht, auch den Storage‑Pfad (/storage) mit dieser Rolle zu verknüpfen.

Proxmox API Home Assistant Backup - User Zugriffsrechte

REST‑Command für VZDump

In Home Assistant legst du unter rest_command: einen neuen Befehl an. Die URL endet diesmal auf /vzdump, die Methode ist POST, und als Payload übergibst du Parameter wie vmid, mode (z. B. snapshot), storage und compress.

rest_command:
  pvelerch_backup:
    url: "https://192.168.101.69:8006/api2/json/nodes/pvelerch/vzdump"
    method: POST
    headers:
      Authorization: "PVEAPIToken=homeassistant@pve!proxmox=be729a21-e76b-430b-84bf-40d096d035a6"
      Content-Type: "application/x-www-form-urlencoded"
    payload: "vmid=100,101,104,106,108,112,113,114,116,119,102,103,105&mode=snapshot&storage=PBS&compress=zstd"
    verify_ssl: false

Ein Aufruf dieses REST‑Commands startet sofort den Backup‑Job in Proxmox. Über die Home‑Assistant‑Entwicklerwerkzeuge kannst du den Befehl testen. In einer Automation oder auf einem Button platziert, kannst du einen Proxmox API Home Assistant Backup sogar zeit‑ oder ereignisgesteuert auslösen.

Fazit & Ausblick

Mit ein wenig Konfigurationsaufwand lässt sich die Proxmox API hervorragend in Home Assistant integrieren. Du kannst den Zustand deiner VMs und LXC‑Container überwachen, in Dashboards visualisieren und sogar Backups per Knopfdruck starten. Nutze diese Lösung als Grundlage für weitere Automatisierungen, zum Beispiel um Benachrichtigungen zu verschicken oder externe Dienste einzubinden.

Wenn du mehr über Energie‑Management erfahren willst, schau dir auch unseren Beitrag zur EVCC‑Einbindung in Home Assistant an. Für Einsteiger in Proxmox empfehlen wir den Artikel Proxmox Grundinstallation Schritt für Schritt.

Link‑Liste

EVCC mit Home Assistant: Smarte Steuerung deiner Geräte per PV-Überschuss

👉 Direkt auf YouTube schauen und abonnieren:
Smart Home & More auf YouTube

EVCC mit Home Assistant ist eine extrem leistungsfähige Kombination für dein Smart Home: Du kannst Geräte wie Smart Plugs, Poolpumpen, Werkzeugakkus oder sogar Backup-Server vollständig automatisiert per PV-Überschuss, Strompreis oder Zeitfenster schalten – auch ganz ohne Elektroauto!

In diesem Beitrag zeige ich dir praxisnah, wie du das Ganze umsetzt, was du dafür brauchst und wie du es für dein Energiemanagement optimal nutzt.

Was ist EVCC mit Home Assistant?

EVCC (Electric Vehicle Charge Controller) ist eine Open-Source-Lösung, mit der ursprünglich PV-Überschussladen von Elektroautos möglich wurde. Dank der neuen Funktion lassen sich jetzt beliebige Home Assistant Schalter als Ladepunkte konfigurieren.

Damit wird EVCC mit Home Assistant zu einem vollwertigen, modularen Energiemanagementsystem – auch ohne E-Auto. Ideal für:

  • Haushalte mit PV-Anlage
  • Smart Home-Enthusiasten
  • Nutzer mit Strompreis-Tarifen wie Tibber

Was du für die Integration brauchst

Voraussetzungen im Überblick:

  • PV-Anlage mit kompatiblem Wechselrichter (z. B. SolarEdge, SMA, Kostal)
  • Home Assistant Installation (z. B. auf Raspberry Pi oder Proxmox)
  • Schaltbare Geräte wie Tuya- oder Shelly-Steckdosen
  • EVCC als Add-on in Home Assistant (kostenlos)

Tipp: Kein Sponsoring oder Premium-Account bei EVCC nötig – funktioniert rein lokal über deine Home Assistant-Instanz, solange du nur mit Home Assistant Schaltern arbeitest oder eine „Open Source / Open Hardware “ Wallbox hast. Allerdings finde ich persönlich, dass es sich lohnt das Projekt aktiv zu unterstützen. Letztlich spare ich damit etwas und unterstütze ein geniales Projekt.


Home Assistant Schalter als Ladepunkt verwenden

Du kannst jetzt jeden beliebigen Home Assistant Schalter wie eine Wallbox in EVCC integrieren. Beispielhafte Konfiguration:

  • Smart Plug 1: Werkzeugakkus
  • Smart Plug 2: Gartenbewässerung
  • Smart Plug 3: NAS-Backup

Einfach als Ladepunkt anlegen, Home Assistant Token einfügen und mit Entity-ID sowie optionaler Leistungsmessung verknüpfen.

EVCC mit Home Assistant – Beispiel für Smart Plug Konfiguration im Dashboard

So funktioniert das PV-Überschuss-Schalten

EVCC mit Home Assistant prüft:

  1. Gibt es aktuell PV-Überschuss?
  2. Ist die definierte Mindestleistung erreicht?
  3. Ist der minimale Strombedarf für das Gerät erfüllt?

Wenn ja, wird geschaltet – sonst bleibt das Gerät aus. Alternativ kannst du zusätzlich mit Strompreis (z. B. Tibber) oder Zeitplänen arbeiten.


Beispiele aus der Praxis

Werkzeugakkus laden

Die Steckdose wird nur eingeschaltet, wenn Überschuss vorhanden ist – ideal für Ladegeräte oder Akku-Werkzeuge.

Poolpumpe

Anstatt starrer Zeitschaltung läuft die Pumpe bei ausreichender Sonneneinstrahlung automatisch.

Proxmox Backup starten

Backups kosten Energie – also automatisiert starten, wenn genug PV-Leistung verfügbar ist.


EVCC mit Home Assistant konfigurieren – Schritt für Schritt

1. File Editor installieren

Unter „Add-ons“ in Home Assistant installieren und starten.

In der File Editor Konfiguration muss jetzt noch Enforce Basepath auf „false“ gesetzt werden.

2. EVCC Add-on hinzufügen

Repository einfügen, EVCC installieren, einmal starten. EVCC legt dabei automatisch ein Verzeichnis an.

3. Konfigurationsdatei anlegen

Im Verzeichnis add-on-config/xyzabsdef_evcc die Datei evcc.yaml anlegen – sonst startet das Add-on nicht korrekt. Die Bezeichnung vor „_evcc“ ist im Verzeichnisnamen Variabel und dient hier nur als Beispiel.

4. EVCC Starten, Schalter anlegen, Token, URL & Entities einfügen

  • EVCC Starten
  • Wallbox hinzufügen und Home Assistant Schalter anlegen
  • Token über Home Assistant Benutzerprofil generieren
  • Entity-ID des Schalters & Leistungssensor eintragen
  • Priorität und Modus definieren

PV-Vorhersage, Strompreise & Prioritäten ( Optional)

PV-Vorhersage

Trage Standort, Ausrichtung & kWp ein – EVCC berücksichtigt dann die Prognose bei der Steuerung.

EVCC mit Home Assistant - PV Vorhersage

Strompreis (z. B. Tibber)

Stelle ein, ab welchem Cent-Betrag ein Gerät schalten darf – ideal für günstige Tariffenster.

EVCC mit Home Assistant - Strompreisvorhersage

Prioritäten

Lege fest, welches Gerät zuerst mit Strom versorgt wird. 10 = höchste Priorität, 0 = niedrigste.

Beispiel:

  • Werkzeugakkus = Priorität 4
  • Poolpumpe = Priorität 5
  • Backup = Priorität 9

Fazit: Warum EVCC mit Home Assistant ein Gamechanger ist

Mit dem neuen Schalter-Feature wird EVCC mit Home Assistant zur echten Steuerzentrale für dein Smart Home:

  • Nutze PV-Überschuss effizient
  • Automatisiere stromhungrige Prozesse
  • Spare Energie & Kosten
  • Auch ohne Elektroauto nutzbar
  • Kombinierbar mit Preis, Prognose & Zeitplan

Fazit: Kein Bastel-YAML mehr nötig – alles bequem über die UI steuerbar! Dadurch konnte ich viele Automatisierungen entfernen und spare dadurch Zeit für Pflege und Wartung. EVCC nimmt mir nun diese Arbeit ab.


Mehr zum Thema Smart Home

👉 Lies auch meinen Beitrag zur Installation von HACS in unter 5 Minuten

👉 Oder schau dir meine EVCC-Playlist auf YouTube an: EVCC Playlist


💬 Hast du Fragen oder Ideen?

Wie nutzt du EVCC mit Home Assistant in deinem Smart Home?
Schreib mir in die Youtube Kommentare – ich freue mich auf dein Feedback!