Unterstützung des Kanals

Hinweis: Der folgende Link ist ein Affiliate-Link.

Die Erstellung meiner Skripte und Videos ist mit einem erheblichen zeitlichen Aufwand verbunden – von der technischen Vorbereitung über intensive Recherche bis hin zu Tests, Aufnahmen und Nachbearbeitung. Alle Inhalte stelle ich dir dennoch vollständig kostenlos zur Verfügung.

Wenn du meine Arbeit unterstützen möchtest, kannst du das ganz einfach tun: Für deine Amazon-Bestellungen nutze gern meinen Partner-Link. Für dich ändert sich am Preis nichts – ich erhalte lediglich eine kleine Provision. Vielen Dank für deinen Support!

Jetzt über Amazon unterstützen

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

14. Mai 202613. Mai 2026 admin

👉 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:

Ein schneller Datastore auf NVMe-Basis
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.

So kühlt es sich mit Home Assistant und IceCube

24. April 202624. April 2026 admin

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

Einleitung

Eine Home Assistant Kühlbox im Wohnwagen ist für mich der nächste logische Schritt gewesen, um mein Setup noch smarter zu machen.

Wir haben uns vor Kurzem einen Dauerstellplatz für unseren Wohnwagen gegönnt. Damit verändert sich natürlich auch die Nutzung: Der Fokus liegt nicht nur auf ständigem Reisen, sondern darauf, den Platz dauerhaft sinnvoll und komfortabel zu nutzen. Gleichzeitig möchte ich aber auf meine Smart-Home-Funktionen nicht verzichten – im Gegenteil.

Ein Thema, das mich direkt beschäftigt hat, war meine Kühlbox. Gerade im Vorzelt ist sie im Sommer unverzichtbar. Aber: Muss sie wirklich immer voll laufen? Was passiert, wenn wir gar nicht vor Ort sind? Und wie kann ich sicherstellen, dass sie effizient arbeitet? Und vor allen Dingen, wie wird sie kühl, bevor wir wieder dort sind ?

Genau daraus ist dieses Projekt entstanden: Ich habe meine Kühlbox in Home Assistant integriert – komplett über Bluetooth und sogar aus der Ferne steuerbar.

In diesem Beitrag zeige ich dir Schritt für Schritt, wie ich das umgesetzt habe und welche Möglichkeiten sich daraus ergeben.

Warum eine Kühlbox smart machen?

Eine Kühlbox im Camper klingt erstmal nach einem simplen Gerät. Ein- und ausschalten, Temperatur einstellen – fertig.

Aber in der Praxis ergeben sich schnell sinnvolle Anwendungsfälle:

Kühlung reduzieren, wenn niemand vor Ort ist
Energie sparen bei leerer Box
Automatisches Abschalten bei niedrigem Batteriestand
Temperaturüberwachung aus der Ferne
Optimierung des Energieverbrauchs

Gerade bei einem Dauerstellplatz, bei dem man nicht ständig vor Ort ist, wird das extrem interessant. Aber auch auf der heimischen Terrasse möchte man eine solche Kühlbox vielleicht in sein smartes Heim integrieren.

Meine Ausgangssituation

Ich nutze eine etwas ältere Kühlbox von Plugin Festivals ( jetze MAENTUM), die bereits über Bluetooth verfügt. Die neueren Boxen nutzen das gleiche Übertragungsprotokoll. Über eine Hersteller-App lassen sich dort:

Temperatur einstellen
Eco- und Max-Modus aktivieren
Statuswerte auslesen
Schwellwerte in drei Stufen für die Spannung bei Batteriebetrieb einstellen

Das Problem: Diese App ist eine klassische Punkt-zu-Punkt-Verbindung. Für Automatisierungen oder Remote-Zugriff ist das völlig ungeeignet*.

PLUG IN FESTIVALS – elektrische Kühlbox – Kompressor Gefrierbox bis -20 Grad – Kühlbox Auto – Camping Kühlschrank – Powerstation zum Kühlen – 12V 230V – 50 Liter

✅ Effiziente Kühlleistung – Die elektrische Kompressor Kühlbox sorgt zuverlässig für Temperaturen von +20 °C bis -20 °C – ideal für lange Reisen, Camping oder Festivals.
✅ Vielseitig einsetzbar – Ob als Auto Kühlbox, mobile Gefrierbox oder Campingkühlschrank: Mit 50 Liter Volumen bietet diese 12V/24V/230V Kühlbox viel Platz für Getränke & Lebensmittel.
✅ Stromsparend dank ÖKO-Modus – für längere Nutzung. Schnelles Herunterkühlen per MAX-Modus – ideal bei akutem Kühlbedarf dank drehzahlgesteuertem Kompressor.
✅ Komfortable App-Steuerung – Steuern Sie die Kühltemperatur bequem per App oder direkt über das LC-Display. Die integrierte LED-Leuchte und der USB-Port für mobile Geräte machen die Nutzung noch komfortabler.
✅ Leise, robust & ideal für Festivals – Dank des qAIR-Systems arbeitet die elektrische Kühlbox besonders leise. Das stabile Metallgehäuse und die hochwertige Isolierung machen sie zum zuverlässigen Begleiter auf Reisen und Festivals.

Also war klar: Das Ganze muss in Home Assistant integriert werden.

Die Lösung: Bluetooth + ESPHome

Der Schlüssel zur Integration ist ein sogenannter Bluetooth Proxy.

Ich habe dafür ein kleines ESP-Gerät verwendet – konkret einen Atom M5 Lite*. Das ist ein kompakter ESP32 mit integriertem Bluetooth.

M5Stack Atom Lite ESP32 IoT Entwicklungsboards und Kits | Development Kit C008

M5Stack SKU: C008
ESP32-basiert, RGB-LED (SK6812)
Eingebaute Infrarot
Erweiterbare Pins & Löcher
Programmierplattform: Arduino, UIFlow

Vorteile dieser Lösung:

Sehr geringer Stromverbrauch
Kompakte Bauweise
Perfekt für den Dauerbetrieb im Wohnwagen
Direkt mit ESPHome nutzbar

🔧 Hardware Setup

Benötigte Komponenten:

ESP32 (z. B. Atom M5)
Kühlbox mit Bluetooth
Home Assistant
ESPHome Integration

Bluetooth-Gerät identifizieren

Der erste Schritt ist, die Kühlbox im Bluetooth-Umfeld zu finden.

In Home Assistant gehst du dazu auf:

Einstellungen → Geräte & Dienste → Bluetooth

Dort werden alle Geräte in der Umgebung angezeigt.

Meine Kühlbox wurde beispielsweise als W1001 erkannt.

👉 Wichtig:
Du musst dir die MAC-Adresse notieren – die brauchst du später für ESPHome.

⚠️ Wichtiger Hinweis

Wenn die Kühlbox mit der Hersteller-App verbunden ist, kannst du sie nicht gleichzeitig in Home Assistant sehen.

Das liegt daran, dass Bluetooth hier als Punkt-zu-Punkt-Verbindung arbeitet.

👉 Lösung:

App trennen
Gerät neu starten
erneut scannen

Hier noch die Dual Box ( die würde ich mir kaufen, wenn meine mal Defekt ist 🙂 )*

PLUG IN FESTIVALS elektrische Kühlbox – 2 Fächer Kompressor Kühlbox 12v 230v – bis -20 Grad & App-Steuerung – Gefrierbox Auto & Camping – DUAL Ice Cube elektrisch (38 Liter)

✅ Leise Kühlung unterwegs & zuhause: Das qAIR-System sorgt für flüsterleisen Betrieb – ideal als Kompressor Kühlbox im Auto, beim Camping oder auf dem Festival.
✅ Zwei Kühlzonen, separat steuerbar: Halte Getränke und Speisen auf zwei individuell einstellbaren Kühlbereichen perfekt temperiert – mit der leistungsstarken Camping Kühlbox.
✅ Von +20 °C bis –20 °C flexibel nutzbar: Der IceCube DUAL Kompressor Kühlschrank passt sich an – egal ob als Gefrierbox fürs Auto oder als Kühlbox für zu Hause oder Outdoor.
✅ Steuerung per App und LC-Display: Die elektrische Kühlbox lässt sich komfortabel per Smartphone oder direkt am Display bedienen – volle Kontrolle über beide Kühlzonen.
✅ Robust, elegant & reisefreundlich: Bruchsichere Glaselemente und Metallkorpus machen diese 40L Kühlbox ideal für Auto, Wohnmobil, Festival oder Campingplatz.

ESPHome Integration

Jetzt kommt der spannende Teil: Die Integration über ESPHome.

Ich habe eine bereits existierende Integration genutzt, die auf Reverse Engineering basiert. Diese ermöglicht die Kommunikation mit der Kühlbox.

💻 [CODE: ESPHome YAML für Bluetooth Integration]

#--------Hier steht der Name, der bei Euch bei der Erstellung vergeben wurde ! ---
esphome:
  name: fuellstand-frischwasser
  friendly_name: Fuellstand_Frischwasser
#--------------------------------------------------------------------------------

external_components:
  - source: github://neftaly/esphome-alpicool

esp32:
  board: m5stack-atom
  framework:
    type: arduino

#----- Dieser Abschnitt wird nicht kopiert ! ------------
logger:

api:
  encryption:
    key: "fmIxjWpGzCmEpjfZ3b0r6l5v0OOAW1FBm4MBLOFBn4U="

ota:
  platform: esphome
  password: "2642bf753f1b8459fd957e65cc1bdfff"

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password
#------------ Abschnitt Ende -------------------------


# Notwendig für Bluetooth-Verbindungen
esp32_ble_tracker:
  scan_parameters:
    interval: 110ms
    window: 110ms
    active: true

#-MAC ADRESSE ANPASSEN
ble_client:
  - mac_address: "CF:0C:FB:60:D0:23" 
    id: alpicool_fridge

alpicool_ble:
  ble_client_id: alpicool_fridge
  id: fridge

sensor:
  - platform: alpicool_ble
    alpicool_ble_id: fridge
    current_temperature:
      name: "Kühlbox Temperatur"
    target_temperature:
      name: "Kühlbox Zieltemperatur"
    battery_voltage:
      name: "Kühlbox Spannung"
    battery_percent:
      name: "Kühlbox Batterie"

climate:
  - platform: alpicool_ble
    alpicool_ble_id: fridge
    name: "Kühlbox Thermostat"

switch:
  - platform: alpicool_ble
    alpicool_ble_id: fridge
    power:
      name: "Kühlbox Power"
    controls_lock:
      name: "Kühlbox Tastensperre"

select:
  - platform: alpicool_ble
    alpicool_ble_id: fridge
    run_mode:
      name: "Kühlbox Modus"
    battery_saver:
      name: "Kühlbox Batterieschutz"

binary_sensor:
  - platform: alpicool_ble
    alpicool_ble_id: fridge
    powered_on:
      name: "Kühlbox Kompressor Status"
    controls_locked:
      name: "Kühlbox Sperre Status"

👉 Wichtig:
Die MAC-Adresse musst du natürlich anpassen.

Integration in Home Assistant

Nach dem Flashen des ESP-Geräts passiert Folgendes:

Gerät erscheint automatisch in Home Assistant
Neue Entitäten werden angelegt
Steuerung wird möglich

Verfügbare Funktionen

Nach der Integration stehen dir mehrere Funktionen zur Verfügung:

Temperatursteuerung

Zieltemperatur setzen
Ist-Temperatur auslesen

Energieüberwachung

Stromverbrauch analysieren ( mit einem Smart Plug z.B. )
Verhalten optimieren

Modi

Eco-Modus
Max-Modus

Dashboard Umsetzung

Ich habe das Ganze in mein bestehendes Camper-Dashboard integriert.

Dort sehe ich:

Temperatur
Strom
aktuelle Einstellungen

Besonders spannend ist der Zusammenhang zwischen Temperatur und Stromverbrauch.

Analyse: Kühlverhalten

Ein interessanter Punkt war für mich das Verhalten der Kühlbox:

Schnelles Runterkühlen
stabile Temperaturhaltung
moderater Energieverbrauch

Für eine 50-Liter-Box ist der Verbrauch absolut in Ordnung.

Automatisierungen

Jetzt kommt der eigentliche Mehrwert.

Beispiele aus meinem Setup:

1. Abwesenheit

Wenn niemand vor Ort ist:

Temperatur erhöhen
oder komplett abschalten

2. Energie sparen

Wenn nur Getränke drin sind:

Eco-Modus aktivieren

3. Sicherheit

Alarm bei zu hoher Temperatur
Push-Benachrichtigung

💡 [HINWEIS]
Hier liegt der größte Mehrwert: Die Kombination aus Daten + Automatisierung.

Remote-Zugriff

Ein entscheidender Punkt war für mich:

👉 Ich wollte das System aus der Ferne steuern.

Das funktioniert bei mir problemlos, da mein Home Assistant bereits remote erreichbar ist.

So kann ich jederzeit:

Temperaturen anpassen
Status prüfen
Automationen kontrollieren

Weitere Smart Camper Features

Neben der Kühlbox habe ich noch weitere Dinge integriert:

Fensterüberwachung
Batteriestatus
Frischwasseranzeige
Gasflaschen-Level
Ausrichtung des Campers
Alarmanlage

Das ergibt zusammen ein sehr rundes System.

Installation des ESP (für Einsteiger)

Falls du noch nie ein ESPHome-Gerät eingerichtet hast:

Schritte:

Firmware erstellen
ESP per USB anschließen
Web Installer nutzen
Firmware flashen
Gerät in Home Assistant hinzufügen

Ich zeige die Schritte am Ende des Videos im Detail.

Hier kommst du zum ESPHome Web Installer

Web – ESPHome

👉 Wichtig:
Achte darauf, dass du die richtige Firmware auswählst und die MAC-Adresse korrekt im Code einträgst.

Fazit

Die Integration der Kühlbox in Home Assistant war für mich ein absolut sinnvoller Schritt.

Ich habe jetzt:

volle Kontrolle über die Kühlung
deutlich bessere Energieeffizienz
Remote-Zugriff von überall
saubere Integration ins Gesamtsystem

Gerade im Camping-Kontext ergibt das extrem viel Sinn. Aber auch auf der Terrasse oder unterwegs bieten sich so tolle Anwendungsmöglichkeiten.

Status: Dual-Zone Unterstützung

Die aktuellen IceCube-Boxen mit zwei Zonen sind in der derzeitigen ESPHome-Implementierung scheinbar noch nicht vollständig umgesetzt. Technisch ist das über das Protokoll (Befehle 0x05 und 0x06) grundsätzlich möglich, erfordert aber eine Erweiterung des C++ Codes, um die zusätzlichen Datenbytes für die zweite Zone zu parsen.

Da ich aktuell selbst nur über die Single-Zone-Variante verfüge, kann ich die Dual-Zone-Logik nicht live am Gerät testen. Sobald ich eine entsprechende Box in die Finger bekomme, werde ich einen Fork der Komponente erstellen und den Code erweitern.

Aufruf an die Community: Falls jemand von euch eine 2-Zonen-Box besitzt und Lust hat, die Unterstützung im Code umzusetzen (oder bereits umgesetzt hat): Schickt mir gerne den Code oder einen Link zum Repository! Ich stelle die Lösung dann hier auf dem Blog der gesamten Community zur Verfügung.

Ausblick

Ich werde das System weiter ausbauen – insbesondere im Bereich:

Automatisierungen
Energieoptimierung
weitere Sensorik

🔗 Interne Links

👉 Victron SmartShunt installieren – Schritt‑für‑Schritt Anleitung für Camper, Auto und Smart‑Home
👉 Wohnwagen ausrichten mit ESP32 – Neigung digital messen
👉 Camper Home Assistant Geolocation & Raspberry Pi Power Solution? | Tutorial 🚐 – smarthome & more

👉🏡 Home Assistant: Egal ob Grill oder Camper, so bekommst du den Füllstand deiner Gasflasche 🔥🚐 – smarthome & more

👉🚀 Enthülle das Geheimnis: Home Assistant + ESPHome für präzise Wassertankmessung im Camper! 💧🌟“ – smarthome & more

Automatisierung des Monats März

26. März 202626. März 2026 admin

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

Home Assistant offene Fenster erkennen – meine beste Automatisierung für mehr Sicherheit

Ich bin nach Hause gekommen und habe etwas gesehen, das eigentlich nicht passieren sollte:
Ein Fenster war offen – im Erdgeschoss. Und niemand war zuhause.

Gerade wenn man sich intensiv mit Smart Home beschäftigt, ist das genau der Moment, in dem man merkt:
Das lässt sich besser lösen.

Genau daraus ist diese Automatisierung entstanden.

In diesem Beitrag zeige ich dir Schritt für Schritt, wie ich in Home Assistant eine Lösung umgesetzt habe, die mich zuverlässig warnt, wenn ich das Haus verlasse und noch Fenster offen sind – und zwar dynamisch, ohne starre Gruppen und ohne Wartungsaufwand.

Warum klassische Lösungen oft nicht funktionieren

Viele setzen Automatisierungen so um:

Fenster einzeln prüfen
mehrere Bedingungen hintereinander
manuelle Pflege bei neuen Geräten

Das Problem dabei:

Das Ganze skaliert nicht.
Jedes neue Gerät bedeutet zusätzliche Arbeit.
Und unterschiedliche Anforderungen lassen sich nur schwer abbilden.

Ich wollte eine Lösung, die automatisch funktioniert, sich selbst erweitert und langfristig wartungsarm bleibt.

Die Lösung: Labels statt Gruppen

Der entscheidende Unterschied in meinem Setup ist der Einsatz von Labels.

Statt feste Gruppen anzulegen, vergebe ich meinen Sensoren einfach ein Label, zum Beispiel:

Fenster

Damit kann ich später alle relevanten Sensoren dynamisch abfragen, ohne sie einzeln definieren zu müssen.

Wichtig:
Der Name muss exakt so auch im Template verwendet werden.

Der Trigger: Haustür als Auslöser

Die Automatisierung startet genau in dem Moment, in dem sie gebraucht wird:

Wenn ich das Haus verlasse.

Das erkenne ich über den Türsensor an der Haustür.

Trigger-Konfiguration

Zustand: geschlossen → geöffnet
Gerät: Haustür

Die zentrale Logik: Dynamisches Template

Jetzt kommt der wichtigste Teil.

Ich prüfe alle Entitäten mit dem Label „Fenster“ automatisch. D.h. , als Bedingung dient, dass tatsächlich auch eines der Fenster geöffnet ist.

{{ expand(label_entities('Fenster'))
   | selectattr('state', 'eq', 'on')
   | list | count > 0 }}

Was passiert hier genau

label_entities(‚Fenster‘) holt alle Sensoren mit diesem Label
expand() erweitert die Liste
selectattr filtert nur geöffnete Fenster
count > 0 stellt sicher, dass nur bei Bedarf ausgelöst wird

Der große Vorteil:
Neue Fenster werden automatisch berücksichtigt, ohne dass du etwas anpassen musst.

Benachrichtigung mit konkreten Fenstern

Ich bekomme nicht nur eine Warnung, sondern direkt eine Liste der offenen Fenster.

{{ expand(label_entities('Fenster'))
   | selectattr('state', 'eq', 'on')
   | map(attribute='name')
   | list | join(', ') }}

alias: "Benachrichtigung: Offene Fenster beim Verlassen"
description: >-
  Sendet eine Push-Nachricht, wenn die Haustür geöffnet wird und noch Fenster
  (Label: Fenster) offen sind.
triggers:
  - trigger: state
    entity_id:
      - binary_sensor.haustur_eg_contact
    to:
      - "on"
    from:
      - "off"
conditions:
  - condition: template
    value_template: |-
      {{ label_entities('Fenster') 
               | expand 
               | selectattr('state', 'eq', 'on') 
               | list | count > 0 }}
actions:
  - action: notify.mobile_app_iphone_tobias
    metadata: {}
    data:
      title: Fenster noch offen!
      message: |-
        Folgende Fenster sind noch auf:         
        {{ 
        label_entities('Fenster') 
        | expand             
        | selectattr('state', 'eq', 'on')             
        | map(attribute='name')             
        | list | join(', ') 
        }}
mode: single

Ergebnis

Die Nachricht enthält konkret die Namen der offenen Fenster, zum Beispiel:

„Folgende Fenster sind noch offen: Küche, Wohnzimmer, Büro“

Companion App einrichten

Für die Benachrichtigung nutze ich die Home Assistant Companion App.

Vorgehen:

App installieren (iOS oder Android)
Mit Home Assistant verbinden
Gerät erscheint automatisch als Ziel für Benachrichtigungen

Alternativ kannst du auch andere Geräte nutzen, zum Beispiel Media Player oder Sprachassistenten.

Testen und Debugging

Ich teste Automatisierungen grundsätzlich vor dem produktiven Einsatz.

Vorgehen

Entwicklerwerkzeuge öffnen
Zustand eines Sensors manuell ändern
Automatisierung auslösen

Warum diese Lösung so gut funktioniert

Diese Automatisierung hat sich bei mir im Alltag absolut bewährt.

Vorteile

dynamisch
wartungsarm
skalierbar
flexibel erweiterbar
sauber strukturiert

Was ich bewusst vermeide

statische Gruppen
harte Verdrahtung einzelner Sensoren
komplexe und unübersichtliche Automationen

Erweiterungsmöglichkeiten

Die Lösung lässt sich leicht ausbauen:

nur prüfen, wenn niemand zuhause ist
Verzögerung einbauen
Integration in Alarmanlage
Sprachausgabe
Anzeige im Dashboard

Mein nächstes Projekt

Mein aktuelles Home Assistant System ist über Jahre gewachsen.

Das führt dazu, dass sich viele Altlasten angesammelt haben:

nicht mehr genutzte Automationen
alte Variablen
unnötige Komplexität

Deshalb plane ich

Ein komplett neues Setup – ohne Backup.

Ziel ist ein sauberer Neustart mit:

klarer Struktur
minimaler Komplexität
besserer Wartbarkeit

Vorgehen

paralleles System aufsetzen
schrittweise Migration
bestehende Geräte weiter nutzen

Wenn dich das interessiert, schreib gerne „#Umzug“ in die Youtube Kommentare.

Smarter Gasleser Home Assistant – mein Langzeittest ohne Cloud

30. Januar 202626. März 2026 admin

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

Ein smarter Gasleser Home Assistant ist für viele Smart-Home-Nutzer der nächste logische Schritt, um den eigenen Gasverbrauch transparent zu erfassen und im Energie-Dashboard auszuwerten.

Ich habe in den letzten Monaten genau so einen smarten Gasleser für Home Assistant im Alltag getestet – als Ersatz für meine bisherige DIY-Lösung mit ESP und improvisierter Befestigung.

In diesem Beitrag teile ich meine Erfahrungen aus dem Langzeittest und zeige, warum ich mich bewusst für eine fertige Lösung entschieden habe. Die komplette Einrichtung und alle Details findet ihr im Video.

Hier bekommst du den Gasleser mit einem extra 10% Rabatt*

Warum ich mein DIY-Projekt ersetzt habe

Wie viele in der Home-Assistant-Community habe auch ich meinen Gaszähler zunächst selbst ausgelesen – mit ESP-Hardware, Sensor und einer provisorischen Halterung.

Das funktionierte grundsätzlich, hatte aber zwei große Nachteile: Die Befestigung war nicht wirklich dauerhaft stabil und kleinere Probleme führten immer wieder zu Nachjustierungen. Mit der Zeit blieb das Projekt liegen, weil andere Smart-Home-Themen wichtiger wurden.

Der smarte Gasleser von Nineti sollte genau dieses Problem lösen: eine kompakte, saubere Lösung ohne Bastelaufwand, aber trotzdem vollständig integrierbar in Home Assistant.

Durchdachtes Montagesystem statt Klebeband

Ein Punkt, der mir direkt positiv aufgefallen ist, ist das Adapter-Konzept. Beim Bestellen wählt man einfach den eigenen Gaszähler-Typ aus und bekommt direkt eine passende Halterung mitgeliefert.

Die Montage ist schnell erledigt, rückbaubar und ohne Bohren oder Kleben möglich. Gerade im Keller oder Hausanschlussraum ist das ein großer Vorteil.

Stromversorgung und WLAN als Voraussetzung

Der Gasleser wird per USB-C mit Strom versorgt und kommuniziert über WLAN. Eine Steckdose in der Nähe sowie eine stabile WLAN-Verbindung sind daher notwendig.

Für den dauerhaften Betrieb ist eine Powerbank aus meiner Sicht keine sinnvolle Alternative.

Schnelle Einrichtung per App

Die Ersteinrichtung erfolgt über die zugehörige App. Nach der Registrierung wird der Gasleser ins WLAN eingebunden, der aktuelle Zählerstand eingetragen und der Impulswert des Gaszählers festgelegt.

Das Ganze ist in wenigen Minuten erledigt und der Verbrauch wird direkt erfasst.

Integration in Home Assistant über MQTT

Für Home-Assistant-Nutzer besonders interessant ist die lokale Einbindung per MQTT. Der Gasleser sendet seine Daten direkt an den MQTT-Broker und erscheint automatisch als Gerät in Home Assistant.

Auch die Einbindung in das Energie-Dashboard funktioniert problemlos.

Betrieb komplett ohne Cloud

Ein wichtiges Feature ist die Möglichkeit, die Cloud-Anbindung vollständig zu deaktivieren. Über das lokale Webinterface lässt sich der Gasleser auf reinen Lokalbetrieb umstellen.

Alle Daten bleiben damit im eigenen Netzwerk. Gerade für Nutzer, die Wert auf Datenschutz und Kontrolle legen, ist das ein großer Pluspunkt.

Wie das genau funktioniert, zeige ich ausführlich im Video.

Erfahrungen aus dem Langzeittest

Nach mehreren Monaten im Einsatz zeigt sich der Gasleser als zuverlässig und stabil. Die Erfassung funktioniert konstant, die Montage sitzt sicher und die Integration in Home Assistant läuft ohne Probleme.

Positiv hervorzuheben ist auch der Support des Herstellers. Kleinere Themen wurden schnell aufgegriffen und per Updates verbessert.

Was man beachten sollte

Nicht jeder Keller oder Technikraum bietet perfekte Voraussetzungen. Wichtig sind eine erreichbare Steckdose und ausreichend WLAN-Empfang. Fehlt eines von beidem, ist diese Lösung eher ungeeignet.

DIY oder fertige Lösung

Ich bin grundsätzlich ein Freund von Eigenbauprojekten. In diesem Fall überwiegen für mich aber klar die Vorteile der fertigen Lösung: weniger Wartung, saubere Montage, Support und die Möglichkeit zum reinen Lokalbetrieb.

Auch wenn die Kosten höher sind als bei einer DIY-Variante, erhält man ein rundes Gesamtpaket.

Weitere Infos und Rabattcode

Der Hersteller stellt aktuell auch einen Rabattcode zur Verfügung*.

Hier bekommst du den Gasleser mit einem extra 10% Rabatt*

Das vollständige Video

In meinem Video zeige ich die komplette Montage, die App-Einrichtung, das MQTT-Setup, die Integration ins Energie-Dashboard sowie den Betrieb ohne Cloud.

Home Assistant Automatisierungen debuggen – wenn Traces nicht mehr reichen

16. Januar 202615. Januar 2026 admin

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

Home Assistant Automatisierungen debuggen: Wenn Automatisierungen versagen, wird es schnell ungemütlich

Wer Home Assistant intensiv nutzt, kennt diese Situationen nur zu gut: Man geht in den Flur – und das Licht bleibt aus. Oder morgens bleiben die Rollläden unten, obwohl sie seit Monaten zuverlässig funktioniert haben. Solche Fehler sind nicht nur technisch ärgerlich, sie sorgen auch im Alltag schnell für Frust. Gerade dann, wenn andere Personen im Haushalt dem Smart Home ohnehin skeptisch gegenüberstehen.

In diesem Beitrag zeige ich keinen neuen Sensor, keine neue Integration und auch keine klassische „Automatisierung des Monats“. Stattdessen geht es um eine Frage, die mir regelmäßig gestellt wird – und die ich mir selbst oft genug stellen muss:

Warum läuft meine Automatisierung nicht, obwohl eigentlich alles richtig aussieht?

Warum die Home-Assistant-Traces oft nicht ausreichen

Home Assistant bringt mit den Traces bereits ein sehr mächtiges Werkzeug zur Fehlersuche mit. Man sieht, welche Trigger ausgelöst wurden, welche Bedingungen geprüft wurden und an welcher Stelle eine Automatisierung eventuell abgebrochen ist.

In der Praxis stoße ich damit aber immer wieder an Grenzen:

Traces werden schnell unübersichtlich
Zustände werden nur punktuell angezeigt
Zusatzinformationen wie „Wann hat sich dieser Zustand zuletzt geändert?“ fehlen
Zusammenhänge zwischen mehreren Entitäten sind schwer zu erkennen

Gerade bei komplexeren Automatisierungen mit Zeitfenstern, Nachtmodi, Helligkeitswerten oder mehreren Bedingungen wird das Debugging schnell zur Fleißarbeit.

An genau dieser Stelle setze ich mit meinem eigenen Ansatz an.

Mein Ansatz: Debug-Snapshots statt Rätselraten

Statt mich ausschließlich auf Traces zu verlassen, arbeite ich mit sogenannten Debug-Snapshots. Die Idee dahinter ist simpel:

Ich speichere mir zu definierten Zeitpunkten innerhalb einer Automatisierung den Zustand relevanter Entitäten – strukturiert, nachvollziehbar und dauerhaft in einer Logdatei.

So sehe ich später ganz in Ruhe:

Welche Entitäten welchen Status hatten
Wann sich ein Zustand zuletzt geändert hat
Ob Bedingungen wirklich erfüllt waren
Wie sich Zustände vor und nach einer Aktion unterscheiden

Das Ganze ist kein Ersatz für Traces, sondern eine Ergänzung – vor allem dann, wenn man systematisch verstehen möchte, warum eine Automatisierung nicht so läuft wie gedacht.

Debug-Snapshots in der Praxis

Ich nutze dafür ein eigenes Skript, das ich an beliebigen Stellen in einer Automatisierung aufrufen kann. Typischerweise setze ich es:

direkt am Start der Automatisierung
vor kritischen Aktionen
nach der eigentlichen Aktion

Jeder Aufruf erzeugt einen Snapshot, der folgende Informationen enthalten kann:

Name der Automatisierung
aktuelle Phase (z. B. Start, Before Action, After Action)
Zeitstempel
Zustände definierter Entitäten
„Last Changed“-Informationen

So entsteht Schritt für Schritt ein klares Bild davon, was in der Automatisierung tatsächlich passiert.

Home Assistant Automatisierungen debuggen

Welche Entitäten sind wirklich relevant?

Ein großer Vorteil dieses Ansatzes ist, dass ich selbst entscheide, was geloggt wird. Typische Kandidaten sind bei mir:

Bewegungsmelder (inkl. last_changed)
Lichtzustände
Helligkeitssensoren
Zeit- oder Datumsbedingungen
Nachtmodus (z. B. über input_boolean)

Gerade der Nachtmodus ist in der Praxis eine häufige Fehlerquelle. Ich hatte schon mehrfach Situationen, in denen eine Automatisierung „nicht funktionierte“, weil schlicht noch der Nachtmodus aktiv war. Im Debug-Log sehe ich das sofort – ohne langes Suchen.

File-Integration: Logdateien direkt in Home Assistant

Damit die Debug-Snapshots nicht irgendwo verschwinden, nutze ich die File-Integration von Home Assistant. Darüber lässt sich ein Notify-Dienst anlegen, der Text direkt in eine Datei schreibt.

Der große Vorteil:

keine externe Infrastruktur
keine zusätzlichen Tools
alles bleibt innerhalb von Home Assistant

Die Logdatei liegt im „www" -Verzeichnis und kann bequem über den File Editor oder per Browser eingesehen werden.

Debug-Log lesen und richtig interpretieren

Ein einzelner Logeintrag besteht aus mehreren Blöcken:

Metainformationen (Zeitpunkt, Phase, Name)
Zustände der Entitäten
Zusatzinformationen wie last_changed

Besonders hilfreich ist der direkte Vergleich zwischen Before Action und After Action. So sehe ich zum Beispiel:

Wurde das Licht wirklich eingeschaltet?
Hat sich der Status geändert?
Wurde eine Bedingung vielleicht doch nicht erfüllt?

Mit diesen Informationen kann ich Automatisierungen gezielt anpassen, statt nur „auf Verdacht“ Werte zu ändern.

Typische Fehlerquellen, die schnell sichtbar werden

Mit Debug-Snapshots lassen sich viele Klassiker schnell entlarven:

Nachtmodus noch aktiv
Helligkeitswert knapp über oder unter dem Grenzwert
Zeitfenster falsch gewählt
Entität war länger unverändert als erwartet

Gerade bei Helligkeitssensoren nutze ich die Logs auch, um über mehrere Tage Daten zu sammeln und Grenzwerte realistisch festzulegen.

Für wen ist dieser Ansatz sinnvoll?

Ganz klar: Das ist kein Einsteiger-Thema.

Wenn du gerade erst mit Home Assistant anfängst, brauchst du dieses Werkzeug vermutlich noch nicht. Aber es ist gut zu wissen, dass es diese Möglichkeit gibt.

Für fortgeschrittene Nutzer, die:

viele Automatisierungen betreiben
komplexe Bedingungen nutzen
nachvollziehbar debuggen möchten

ist dieser Ansatz extrem hilfreich.

Fazit: Debuggen mit System statt Trial-and-Error

Automatisierungen, die nicht funktionieren, gehören leider zum Smart-Home-Alltag dazu. Entscheidend ist, wie man damit umgeht.

Mit Debug-Snapshots habe ich für mich einen Weg gefunden, Probleme systematisch zu analysieren, statt im Nebel zu stochern. In Kombination mit den Home-Assistant-Traces ergibt sich ein sehr mächtiges Werkzeug zur Fehlersuche.

Den kompletten Code für das Debug-Snapshot-Skript stelle ich wie immer in meinem Blog bereit.

alias: debug_snapshot
description: Debug Snapshot (JSONL, dynamisches Ziel)
fields:
  name:
    name: Name
    description: Bezeichnung des Snapshots
    selector:
      text: null
  phase:
    name: Phase
    description: Status oder Phase (z.B. Start, Error, Ende)
    default: info
    selector:
      text: null
  entities:
    name: Entitäten
    description: Liste der zu loggenden Entitäten
    selector:
      entity:
        multiple: true
  zusatzdaten:
    name: Zusatzdaten
    description: Ein Dictionary für extra Infos
    default: {}
    selector:
      object: null
  benachrichtigungsdienst:
    name: Benachrichtigungsdienst
    description: Welcher Dienst soll genutzt werden?
    default: notify.file
    selector:
      text: null
sequence:
  - variables:
      ent_list: >-
        {{ entities if entities is iterable and entities is not string else
        ([entities] if entities else []) }}
      payload: |-
        {% set ns = namespace(snapshot={}) %}
        {% for e in ent_list %}
          {% if states[e] is defined %}
            {% set obj = states[e] %}
            {% set lc = obj.last_changed.astimezone() %}
            {% set ns.snapshot = dict(ns.snapshot, **{e: {
              "state": states(e),
              "last_changed": lc.isoformat(),
              "seconds_since_change": (now() - lc).total_seconds() | int,
              "attributes": obj.attributes
            }}) %}
          {% endif %}
        {% endfor %}
        {{ {
          "ts": now().isoformat(),
          "name": name,
          "phase": (phase | default("info")),
          "extra": (zusatzdaten | default({})),
          "snapshot": ns.snapshot
        } | tojson }}
  - action: notify.send_message
    target:
      entity_id: "{{ benachrichtigungsdienst }}"
    data:
      message: "{{ payload }}"
mode: queued
max: 200

Deine Meinung ist gefragt

Mich interessiert, wie du Automatisierungen debuggt:

Arbeitest du nur mit Traces?
Nutzt du eigene Logs?
Oder ganz andere Ansätze?

Schreib mir das gerne in die Youtube Kommentare.

Und falls du Wünsche für eine kommende Automatisierung des Monats hast – lass es mich wissen.

Hier kommst du übrigens zu meiner letzten Automatisierung des Monats .

Home Assistant Backup richtig umsetzen – Mein vollständiger Rettungsplan für den Worst Case

9. Januar 20269. Januar 2026 admin

Home Assistant Backup ist eines der meist unterschätzten Themen im Smart Home. Erst wenn der Server ausfällt, eine VM beschädigt ist oder eine SD-Karte den Geist aufgibt, zeigt sich, ob das eigene Backup-Konzept wirklich funktioniert.

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

Warum ein Home‑Assistant‑Backup erst im Ernstfall seinen Wert zeigt

Was passiert eigentlich, wenn heute Nacht dein Home‑Assistant‑Server ausfällt? Festplatte defekt, VM gelöscht, SD‑Karte korrupt – und plötzlich ist alles weg. Automationen, Dashboards, Tokens, Integrationen. Genau dieses Szenario ist der Grund, warum ich mich intensiv mit Backups beschäftigt habe.

Viele Nutzer haben irgendwo ein Backup laufen. Aber die entscheidende Frage lautet nicht: Habe ich ein Backup? Sondern: Kann ich es im Worst Case wirklich wiederherstellen?

In diesem Beitrag zeige ich dir mein vollständiges Backup‑Konzept für Home Assistant – inklusive echter Wiederherstellung auf neue Hardware. Kein Theorie‑Artikel, sondern ein praxisnaher Leitfaden, der sich an genau dem orientiert, was im Ernstfall zählt.

Die 3‑2‑1‑Regel – Fundament jedes seriösen Backup‑Konzepts

Bevor wir über Home Assistant sprechen, müssen wir über das Grundprinzip reden. Die 3‑2‑1‑Backup‑Regel ist kein Buzzword, sondern ein bewährter Standard:

3 Kopien deiner Daten
2 unterschiedliche Medien
1 Kopie außerhalb deines Systems

Für Home Assistant bedeutet das konkret:

ein lokales Backup für schnelle Rollbacks
ein Netzwerkspeicher (NAS/SMB) als zweites Medium
ein externes Ziel, z. B. Cloud oder Offsite‑Storage

Alles andere ist kein Backup‑Konzept, sondern Hoffnung.

Ich habe in diesem Beitrag bewusst auf die Nabu Casa Cloud als externes Backup Ziel verzichtet. Für die Cloud ist eine Subscription nötig und mein Ziel war es Möglichkeiten ohne zusätzliche Kosten aufzuzeigen. Dennoch kann ich die Nabu Casa Cloud empfehlen. Man unterstützt damit auch die Weiterentwicklung von Home Assistant.

Home Assistant Backup in der Nabu Casa Cloud

Home Assistant Backups richtig konfigurieren

In Home Assistant selbst stehen dir mittlerweile sehr gute Bordmittel zur Verfügung. Wichtig ist, dass du sie bewusst konfigurierst und nicht einfach auf den Standardwerten stehen lässt.

Automatische Backups

Ich setze auf tägliche automatische Backups, zeitlich so gelegt, dass sie nicht mit anderen Wartungsaufgaben kollidieren. Zusätzlich begrenze ich die Anzahl der Backups pro Ziel, damit Speicher nicht unkontrolliert vollläuft.

Was gehört ins Backup?

Für ein echtes Worst‑Case‑Backup sichere ich:

Konfiguration
Add-ons
Datenbanken
Share‑Ordner

Ja, das Backup wird größer – aber genau das ist der Punkt. Im Ernstfall möchte ich nichts manuell rekonstruieren müssen.

Verschlüsselung: Dein Notfall‑Set ist entscheidend

Sobald Backups außerhalb deines Systems liegen, ist Verschlüsselung Pflicht. In einem Home‑Assistant‑Backup befinden sich unter anderem:

API‑Tokens
Zugangsdaten
Integrations‑Secrets
Informationen über dein Smart Home

Ohne Verschlüsselung liegen diese Daten im Klartext vor.

Das Notfall‑Set

Home Assistant generiert bei der Einrichtung ein Notfall‑Set mit dem Verschlüsselungs‑Key. Dieser Punkt ist kritisch:

Ohne diesen Schlüssel ist ein Restore unmöglich.

Ich speichere das Notfall‑Set:

offline
redundant
getrennt vom System

Home Assistant Backup Verschlüsselungscode

Das ist keine Paranoia, sondern Vorsorge.

Ich nutze dafür eine lokal gehostete Vaultwarden Lösung und speichere dort alle meine Kennwörter und Daten redundant. Der Verschlüsselungscode ist elementar. Ohne sind eure Backups wertlos und ihr könnt diese nicht wiederherstellen.

Backup‑Ziel 1: Lokale Backups

Lokale Backups sind perfekt für:

schnelle Rollbacks
Fehlkonfigurationen
Updates, die schiefgehen

Sie sind kein Schutz vor Hardware‑Ausfall, aber ein wichtiger Baustein. Ich betrachte sie als Komfort‑Backup – nicht als Lebensversicherung.

Backup‑Ziel 2: NAS / SMB‑Freigabe

Als zweites Medium nutze ich eine SMB‑Freigabe auf einem NAS. Das kann ein klassisches NAS sein oder ein Server im Netzwerk.

Wichtig dabei:

eigener Benutzer nur für Backups
klare Freigaberechte
stabiler Netzwerkspeicher

Dieses Ziel deckt bereits viele Ausfallszenarien ab – aber noch nicht alle. In meinem Setup habe ich eine SMB-Freigabe auf einem virtuellen Unraid System im Einsatz. Jede beliebige andere Freigabe , sei es auf einem Synology, QNAP, Terramaster , UGreen – NAS erfüllen aber den gleichen Zweck.

Backup‑Ziel 3: Cloud / WebDAV mit Nextcloud

Für das externe Backup‑Ziel setze ich auf WebDAV, z. B. über Nextcloud. Der große Vorteil: Plattformunabhängig, bewährt und gut integriert.

Zwei‑Faktor‑Authentifizierung richtig lösen

Viele scheitern hier an 2FA. Die Lösung ist kein Abschalten der Sicherheit, sondern:

Nutzung eines App‑Passworts
2FA bleibt aktiv
Zugriff ist sauber begrenzt

So funktioniert Cloud‑Backup ohne Sicherheitskompromisse. Die Nextcloud ist in einem Rechenzentrum gehostet und wird von mir selber verwaltet. Es können aber genauso auch andere Lösungen angewendet werden. Interessant finde ich z.B. auch SFTP Storage, da man sich so schnell einen eigenen günstigen virtuellen Server für kleines Geld bei IONOS, Hetzner etc.. mieten kann und ohne große Infrastruktur und Verwaltungsaufwand nur mit einem SSH Server eine externe Speicherfreigabe hat.

Der entscheidende Test: Restore im Worst Case

Ein Backup ist erst dann ein Backup, wenn es erfolgreich wiederhergestellt wurde.

Ich habe deshalb bewusst den Worst Case simuliert:

bestehende VM außer Betrieb
neues System aufgesetzt
Restore auf komplett andere Architektur (x86 → ARM)

Home Assistant macht das erstaunlich sauber – wenn das Backup korrekt erstellt wurde. Ich habe mich bewusst auch für eine andere Architektur entschieden, um euch im Video direkt zu zeigen, dass ihr selbst vor einem Wechsel , sei es x86 zu ARM oder ARM zu x86 keine Sorge haben müsst, so lange ihr das Home Assistant OS verwendet.

Typische Probleme nach dem Restore – und wie man sie löst

IP‑Adressen

Nach einem Restore ändern sich oft IP‑Adressen. Das betrifft:

MQTT
Integrationen
externe Dienste

Meine Empfehlung: feste IPs oder DHCP‑Reservierungen.

Grundsätzlich würde ich eine DHCP Reservierung im Router per MAC Adresse bevorzugen, da sie hinterher einfacher zu veralten ist. Das unterstützt mittlerweile jeder halbwegs vernünftige Router. Ihr spart euch so später manuelles „Gefrickel“ nach dem Restore.

USB‑Geräte & Device‑by‑ID

USB‑Sticks (Zigbee, Z‑Wave) sollten immer per Device‑by‑ID eingebunden werden. Dann spielt es keine Rolle, an welchem Port sie stecken – auch nach einem Hardware‑Wechsel. Ich habe mich in meinem Beitrag deshalb bewusst entschieden eine USB-ZigBee Verbindung zu verwenden, um euch dieses Szenario ebenfalls direkt zeigen zu können und die Sorge vor einem Wechsel oder einer Wiederherstellung zu nehmen.

Warum dieses Backup‑Konzept bewusst ausführlich ist

Dieses Setup ist kein Minimal‑Guide. Es ist ein Referenz‑Konzept. Ziel ist nicht, möglichst schnell fertig zu sein, sondern:

vorbereitet zu sein
reproduzierbar zu bleiben
im Ernstfall ruhig reagieren zu können

Ein echtes Backup‑Konzept zeigt seinen Wert nicht im Alltag – sondern dann, wenn alles schiefgeht.

Fazit: Backup ist keine Funktion, sondern ein Prozess

Wenn du aus diesem Beitrag nur eines mitnimmst, dann das:

Ein Backup, das du nie getestet hast, ist kein Backup.

Mit der 3‑2‑1‑Regel, Verschlüsselung, mehreren Zielen und einem getesteten Restore bist du auf der sicheren Seite – auch dann, wenn dein Home‑Assistant‑Server plötzlich nicht mehr startet.

Kurzfassung für Eilige (Backup‑Checkliste)

Wenn du Home Assistant ernsthaft betreibst, solltest du mindestens diese Punkte erfüllen:

✔️ Automatische Backups aktiviert
✔️ Backups verschlüsselt
✔️ 3‑2‑1‑Regel umgesetzt (lokal, NAS, extern)
✔️ Externes Ziel unabhängig vom Home‑Assistant‑System
✔️ Notfall‑Set sicher und offline abgelegt
✔️ Restore mindestens einmal getestet (idealerweise auf anderer Hardware)

Wenn einer dieser Punkte fehlt, ist dein Backup‑Konzept unvollständig.

Typische Fehler bei Home‑Assistant‑Backups

Aus Erfahrung scheitern Backups selten an der Technik, sondern an Kleinigkeiten:

Backups werden nie getestet
Verschlüsselungs‑Key geht verloren
Backups liegen nur lokal
Cloud‑Backups ohne Verschlüsselung
USB‑Geräte nicht per Device‑by‑ID eingebunden

Diese Fehler fallen meist erst auf, wenn es zu spät ist.

Interne Empfehlungen

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

19. Dezember 202519. Dezember 2025 admin

👉 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.

Toshiba MG10 Series MG10ACA20TE Festplatte Enterprise 20 TB intern 3.5″ 8.9 cm SATA 6Gb/s 7200 RPM Puffer: 512 MB

Toshiba HD3.5 SA3-Raid 20TB MG10ACA20TE /7.2k/512e

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

Ich baue die beiden ZFS-Festplatten aus dem 8-Bay-NAS aus.
Die Platten stecke ich in das 4-Bay-NAS.
Auf dem neuen System installiere ich Proxmox.
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:

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

/mnt/datastore/zfspool

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

Neue HDD physisch einsetzen
Per Passthrough an die PBS-VM durchreichen
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 Energie sparen: Von 100W auf 39W im Home Lab (Anleitung)

12. Dezember 202512. Dezember 2025 admin

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

Einleitung: Der Kampf gegen den Stromzähler

Kennst du das Gefühl, wenn du auf dein Strommessgerät schaust und dir kurz der Atem stockt? In meinem Fall standen da in Summe über 100 Watt. Dauerhaft. Für ein Home Lab, das zwar leistungsstark sein soll, aber nicht unnötig Energie verbrennen darf.

Mein Ziel war klar: Ich wollte runter von diesem hohen Verbrauch – und zwar drastisch. Das Ergebnis? Ich bin jetzt bei rund 40 Watt.

In diesem Beitrag zeige ich dir genau, wie ich das geschafft habe. Wir schauen uns an, wie wir die „Low Hanging Fruits“ ernten – also die Festplatten (HDDs), die wir schlafen legen, wenn sie nicht gebraucht werden. Außerdem zeige ich dir, wie ich meinen Backup-Server so automatisiere, dass er wirklich nur dann läuft, wenn ein Backup ansteht. Das Wichtigste dabei: Die Dinge, die ich hier zeige, lassen sich auch auf andere Systeme anwenden – du brauchst also nicht zwingend ein Ugreen NAS, um das hier nachzubauen

Lass uns direkt loslegen.

Mein Hardware-Setup: Die Basis

Bevor wir in die Konfiguration gehen, musst du verstehen, wie mein System aufgebaut ist. Das ist wichtig, um die Logik hinter den Skripten später zu verstehen.

Ich nutze aktuell zwei Systeme von Ugreen:

Der Primary*: Ein Ugreen DXP 8800 Plus (8-Bay NAS). Hier läuft mein Hauptsystem mit Proxmox. Bestückt ist es mit 8 Festplatten.

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.

Der Secondary*: Ein Ugreen DXP 4800 Plus (4-Bay NAS). Dies dient als reines Backup-Ziel.

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.

Der Plan ist simpel: Daten werden zwischen dem Primary und dem Secondary synchronisiert. Aber – und das ist der Knackpunkt beim Thema Proxmox Energie sparen – der Secondary muss nicht 24/7 laufen. Er wird nur für das Backup benötigt. Auch auf dem Primary müssen nicht alle 8 Festplatten rund um die Uhr rotieren, wenn ich nur ein- oder zweimal am Tag darauf zugreife.

Als Festplatten setze ich übrigens sehr gerne die Enterprise Platten von Toshiba ein. Alles was wichtig ist, kommt auf diese Platten*. Die haben sich über Jahre als äußerst Robust erwiesen.

Toshiba MG10 Series MG10ACA20TE Festplatte Enterprise 20 TB intern 3.5″ 8.9 cm SATA 6Gb/s 7200 RPM Puffer: 512 MB

Toshiba HD3.5 SA3-Raid 20TB MG10ACA20TE /7.2k/512e

Für Backups greife ich gerne auf die WD-Red Plus Reihe zurück*

WD Red Plus 8 TB NAS Interne Festplatte 3,5 Zoll – 5640 U/Min, SATA 6 Gb/s, CMR, 256MB Cache

Für NAS mit NASware optimiert Die exklusive Western Digital NASware-Technologie optimiert die Festplattenparameter für Workloads von NAS-Systemen, um die Leistung und Zuverlässigkeit zu verbessern.
Für dauerhaften Betrieb entwickelt Ihr NAS-System läuft rund um die Uhr. Ein äußerst zuverlässiger Speicher ist daher unverzichtbar. WD Red Plus-Festplatten sind für Systeme im Dauerbetrieb ausgelegt und geben Anwendern die Gewissheit, dass sie zuverlässig auf ihre Daten zugreifen können.
Auf zuverlässige Kompatibilität getestet Western Digital arbeitet mit vielen verschiedenen Herstellern von NAS-Systemen zusammen, um umfassende Tests durchzuführen und die Kompatibilität mit den meisten NAS-Gehäusen sicherzustellen.
Für niedrigere Gesamtbetriebskosten optimiert WD Red Plus-Festplatten verbrauchen weniger Energie (als frühere Modelle) und laufen kühler, wodurch die Betriebskosten sinken und die Wärme in schwer zu kühlenden NAS-Gehäusen reduziert wird.
Weniger Strombedarf, starke Leistung Obwohl sie weniger Energie verbrauchen, verfügen die Festplatten über eine gewaltige Bandbreite, um die gemischten Leistungsanforderungen von NAS-Systemen mit mehreren Festplatten zu erfüllen.

Schritt 1: Die „Low Hanging Fruits“ – HDDs in den Spindown schicken

Der größte Stromfresser in einem NAS sind oft die mechanischen Festplatten. Wenn diese 24 Stunden am Tag, 7 Tage die Woche drehen, verbrauchen sie unnötig Energie und erzeugen Wärme.

Mein erster Ansatz war also: Wenn ich die Platten nicht brauche, sollen sie schlafen gehen (Spindown).

Szenario A: Festplatten in einer Unraid VM

Einen Teil meiner Festplatten (4 Stück) habe ich direkt an eine virtuelle Maschine (VM) mit Unraid durchgereicht. Hier ist das Stromsparen denkbar einfach.

Hier ist das Stromsparen denkbar einfach.

In Unraid gehst du einfach in die Datenträger Einstellungen und setzt die Ruhezustandsverzögerung (Spindown Delay). Ich habe hier 15 Minuten eingestellt. Sobald 15 Minuten lang kein Zugriff erfolgt, schalten sich die Platten ab.

Achte hierbei nur darauf, dass du den Wert höher stellst, wenn du z.B. häufiger auf das NAS System zugreifst. Jedes An / Ausschalten der Platten erzeugt einen Verschleiß. Wenn deine Platten quasi den gesamten Tag fast durchgängig benötigt werden, dann macht es keinen Sinn an dieser Stelle zu sparen. Nur, wenn die meiste Zeit des Tages tatsächlich keine Daten benötigt werden, solltest du das verwenden.

Wie du Unraid genau installierst und den Controller durchreichst, habe ich bereits in einem anderen Artikel behandelt.

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

Szenario B: Festplatten direkt unter Proxmox (ZFS & Co.)

Jetzt wird es spannender. Die restlichen Platten hängen direkt an Proxmox und werden teilweise für den Proxmox Backup Server (PBS) genutzt. Hier funktioniert der einfache Spindown oft nicht von Haus aus, besonders wenn ZFS im Spiel ist, das die Platten gerne wach hält.

Die Lösung ist ein kleines Tool namens hd-idle.

Installation von hd-idle: Zuerst installieren wir das Tool direkt in der Proxmox-Shell (Konsole):

apt-get install hd-idle

Die richtige Konfiguration: Damit wir nicht versehentlich die falschen Platten schlafen legen (zum Beispiel die Systemplatte, was fatal wäre), müssen wir die Festplatten eindeutig identifizieren. Verlasse dich niemals auf Bezeichnungen wie sda oder sdb, da diese sich nach einem Neustart ändern können. Wir nutzen die eindeutige ID (Serial Number).

Führe folgenden Befehl aus, um deine Disks aufzulisten:

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

Kopiere dir die IDs der Festplatten, die du in den Ruhezustand schicken möchtest (z.B. ata-WDC_WD...).

Nun bearbeiten wir die Konfigurationsdatei von hd-idle. Du findest sie meistens unter /etc/default/hd-idle.

Wichtig sind zwei Dinge:

Setze START_HD_IDLE=true.
Trage deine Platten mit der gewünschten Zeit ein.

Ich empfehle hier einen Wert von 1800 Sekunden (30 Minuten), um die Hardware nicht durch ständiges An- und Ausschalten zu belasten.

# defaults file for hd-idle

# start hd-idle automatically?
START_HD_IDLE=true
HD_IDLE_OPTS="-i 0 \
-a /dev/disk/by-id/ata-WDC_WD40EFPX-68C6CN0_WD-WX12DC482U93 -i 60 \
-a /dev/disk/by-id/ata-WDC_WD40EFPX-68C6CN0_WD-WX22DC4LF10E -i 60 \
-a /dev/disk/by-id/ata-WDC_WD40EFPX-68C6CN0_WD-WX12DC4820ZZ -i 60 \
-a /dev/disk/by-id/ata-WDC_WD40EFPX-68C6CN0_WD-WX22DC4PV4D8 -i 60"

Danach den Dienst einfach neu starten:

systemctl restart hd-idle

Mit diesen Maßnahmen hast du den ersten großen Schritt getan, um mit Proxmox Energie sparen zur Realität zu machen.

Schritt 2: Den Backup-Server bändigen (Primary& Secondary Prinzip)

Jetzt kommen wir zum fortgeschrittenen Teil. Ich nutze den Proxmox Backup Server (PBS), um meine VMs und Container zu sichern. Das Problem: Wenn der PBS als VM auf dem Primary läuft und Zugriff auf den ZFS-Pool hat, hält er die Platten wach. Außerdem: Wozu soll der Secondary -Server (das Backup-Ziel) laufen, wenn gar kein Backup gemacht wird?

Meine Strategie: Ich verlagere die Backups in die Tageszeit, wenn meine PV-Anlage Strom liefert. Den Rest der Zeit sollen der Backup-Server (die VM) und der externe Secondary -Server ausgeschaltet sein.

Das bringt jedoch ein technisches Problem mit sich: Wenn ich die Backup-VM ausschalte oder den Secondary herunterfahre, meckert Proxmox. Der Storage ist nicht mehr erreichbar, und das System schreibt die Logs voll mit Fehlermeldungen („error fetching datatsores“). Das nennt man „Logspam“, und das wollen wir vermeiden.

Die Lösung sind zwei selbstgeschriebene Skripte:

Ein Start-Skript, das alles sauber hochfährt und einbindet.
Ein Stop-Skript, das alles sauber trennt und herunterfährt.

Das Start-Skript

Das Skript erledigt folgende Aufgaben vollautomatisch:

Es sendet ein Wake-on-LAN (WOL) Paket an den Secondary-Server, um ihn zu starten.
Es prüft, ob der Secondary per SSH erreichbar ist.
Es aktiviert den Storage in Proxmox wieder (damit kein Fehler auftaucht).
Es startet die lokale Proxmox Backup Server VM.

Damit das funktioniert, musst du sicherstellen, dass wakeonlan auf deinem Primary installiert ist und im BIOS des Secondary aktiviert wurde.

apt-get install wakeonlan

Das vollständige Skript kannst du dir hier kopieren und an deine IPs und MAC-Adressen, Storage Name und VM ID anpassen:

#!/bin/bash
set -euo pipefail

# --- Konfiguration ---
SLAVE_HOST="192.168.100.3"
SLAVE_MAC="6C:1F:F7:76:53:18"
STORAGE_NAME="PBS_DXP8800Plus"
VM_ID="102"

# KORRIGIERT: Port 8006 für Proxmox VE (PVE).
# Alternativ: Port 22 für SSH (startet oft schneller).
CHECK_PORT=22

log() {
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] $*"
}

log "==== START: Slave-Proxmox Start-Workflow ===="

# 1) Slave per WOL wecken
log "Sende Wake-on-LAN an ${SLAVE_MAC}"
if command -v wakeonlan &> /dev/null; then
    wakeonlan "${SLAVE_MAC}" > /dev/null
else
    log "FEHLER: 'wakeonlan' Befehl nicht gefunden! Bitte installieren (apt install wakeonlan)."
    exit 1
fi

# 2) Auf Erreichbarkeit warten (Ping + Service Check)
log "Warte auf ${SLAVE_HOST} (Max. 5 Minuten)..."
HOST_UP=false

for i in {1..60}; do # 60 Versuche a 5 Sekunden = 5 Minuten
    if ping -c1 -W1 "${SLAVE_HOST}" >/dev/null 2>&1; then

        # ZUSATZ: Port-Check (Dienste wirklich da?)
        if [ -n "$CHECK_PORT" ]; then
             # Versuche, den Port zu erreichen (timeout 2s reicht hier)
             if timeout 2 bash -c "</dev/tcp/${SLAVE_HOST}/${CHECK_PORT}" 2>/dev/null; then
                 log "Host ${SLAVE_HOST} ist pingbar UND Port $CHECK_PORT ist offen."
                 HOST_UP=true
                 break
             else
                 log "Ping OK, aber Port $CHECK_PORT noch nicht erreichbar. Warte..."
             fi
        else
            # Fallback ohne Port-Check
            log "Host pingbar. Warte pauschal 15s auf Dienste..."
            sleep 15
            HOST_UP=true
            break
        fi
    fi
    sleep 5
done

# ABBRUCH, wenn Host nicht kam
if [ "$HOST_UP" = false ]; then
    log "FEHLER: Slave-Host ${SLAVE_HOST} (Port $CHECK_PORT) ist nicht hochgefahren. Abbruch!"
    exit 1
fi

# 3) PBS-Storage aktivieren
# Prüfen, ob Storage schon aktiv ist
if ! /usr/sbin/pvesm status | grep -q "^${STORAGE_NAME}.*active"; then
    log "Aktiviere Storage ${STORAGE_NAME}..."
    /usr/sbin/pvesm set "${STORAGE_NAME}" --disable 0
else
    log "Storage ${STORAGE_NAME} ist bereits aktiv."
fi

# Kurze Pause für den Storage-Mount
sleep 2

# 4) VM starten (nur wenn sie nicht schon läuft)
VM_STATUS=$(/usr/sbin/qm status "${VM_ID}")
if [[ "$VM_STATUS" == *"status: stopped"* ]]; then
    log "Starte VM ${VM_ID}..."
    /usr/sbin/qm start "${VM_ID}"
    log "VM ${VM_ID} Startbefehl gesendet."
else
    log "INFO: VM ${VM_ID} läuft bereits oder Status ist unklar ($VM_STATUS)."
fi

log "==== ENDE: Slave-Proxmox Start-Workflow ===="

Erstelle dir ein Verzeichnis

mkdir /root/automation
nano proxmox-slave-start.sh

Kopiere den Inhalt aus dem Code Block und passe deine Daten an ( IP, Storage, VMID etc.. ) .

Speichere danach die Datei Strg+X und mach sie ausführbar.

chmod +x /root/automation proxmox-slave-start.sh

Dieser Vorgang muss mit dem Stop -Script genauso wiederholt werden. Achtet darauf, dass der Dateiname dann „proxmox-slave-stop.sh“ ist.

Das Stop-Skript

Am Nachmittag, wenn die Sonne weggeht, wollen wir wieder Strom sparen. Das Stop-Skript macht genau das Gegenteil:

Es fährt die lokale Backup-VM herunter.
Es deaktiviert den Storage in Proxmox (verhindert Logspam!).
Es sendet per SSH den Befehl poweroff an den Secondary-Server.

Auch hier müsst ihr wieder eure Daten eintragen ( IP, Storage Name, VM_ID )

  GNU nano 8.4                                                                                                                                                                      proxmox-slave-stop.sh
#!/bin/bash
set -euo pipefail

# Konfiguration
SLAVE_HOST="192.168.100.3"
STORAGE_NAME="PBS_DXP8800Plus"
VM_ID="102"
MAX_WAIT_CYCLES=18  # 18 * 10s = 3 Minuten

log() {
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] $*"
}

log "==== START: Slave-Proxmox Stop-Workflow ===="

# 1) Status prüfen & VM herunterfahren
VM_STATUS=$(/usr/sbin/qm status "${VM_ID}" | awk '{print $2}')

if [[ "${VM_STATUS}" == "running" ]]; then
    log "VM ${VM_ID} läuft. Sende Shutdown-Signal (ACPI)..."
    /usr/sbin/qm shutdown "${VM_ID}" || log "WARNUNG: qm shutdown ${VM_ID} meldete Fehler (evtl. ignoriert)."

    # Wartensschleife
    log "Warte auf Stop der VM ${VM_ID} (Max. 3 Min)..."
    VM_STOPPED=false

    for ((i=1; i<=MAX_WAIT_CYCLES; i++)); do
        CURRENT_STATUS=$(/usr/sbin/qm status "${VM_ID}" | awk '{print $2}')

        if [[ "${CURRENT_STATUS}" == "stopped" ]]; then
            log "Erfolg: VM ${VM_ID} ist gestoppt."
            VM_STOPPED=true
            break
        fi

        # Letzter Versuch: Harter Kill
        if [[ $i -eq $MAX_WAIT_CYCLES ]]; then
            log "TIMEOUT: VM reagiert nicht auf Shutdown. Versuche harten 'qm stop'..."
            /usr/sbin/qm stop "${VM_ID}" || true
            sleep 5 # Kurz warten, damit Proxmox aufräumen kann
        else
            sleep 10
        fi
    done

    # Finaler Check nach Loop
    if [[ "$VM_STOPPED" == "false" ]]; then
         # Checken ob der Hard-Kill oben geklappt hat
         FINAL_STATUS=$(/usr/sbin/qm status "${VM_ID}" | awk '{print $2}')
         if [[ "${FINAL_STATUS}" == "stopped" ]]; then
            log "VM wurde durch harten Stop beendet."
         else
            log "FEHLER: VM ${VM_ID} konnte nicht gestoppt werden! Status: ${FINAL_STATUS}"
            # Wir machen trotzdem weiter, damit der Storage disabled wird!
         fi
    fi

elif [[ "${VM_STATUS}" == "stopped" ]]; then
    log "Info: VM ${VM_ID} ist bereits gestoppt. Keine Aktion nötig."
else
    log "WARNUNG: Unbekannter Status der VM ${VM_ID}: ${VM_STATUS}"
fi

# 3) PBS-Storage deaktivieren (Kritischer Schritt für Host-Performance)
# Wir prüfen vorher kurz, ob er überhaupt aktiv ist, um unnötige Log-Einträge zu meiden,
log "Deaktiviere Storage ${STORAGE_NAME}..."
if /usr/sbin/pvesm set "${STORAGE_NAME}" --disable 1; then
    log "Storage ${STORAGE_NAME} erfolgreich deaktiviert."
else
    log "WARNUNG: Fehler beim Deaktivieren von ${STORAGE_NAME}!"
fi

# 4) Slave-Host herunterfahren
log "Sende Shutdown an Slave-Host ${SLAVE_HOST}..."
# ConnectTimeout verhindert langes Hängen, falls Slave schon weg ist
if ssh -o StrictHostKeyChecking=no -o ConnectTimeout=5 root@"${SLAVE_HOST}" "shutdown -h now" 2>/dev/null; then
    log "Shutdown-Befehl erfolgreich gesendet."
else
    log "HINWEIS: Konnte Shutdown nicht senden (Slave evtl. schon offline oder Netzwerkfehler)."
fi

# 5) Ping-Check (Optional, nur zur Bestätigung)
log "Warte auf Offline-Status des Slaves..."
HOST_IS_DOWN=false
for i in {1..12}; do # 2 Minuten warten
    if ! ping -c1 -W1 "${SLAVE_HOST}" >/dev/null 2>&1; then
        log "Slave-Host ${SLAVE_HOST} ist nun offline."
        HOST_IS_DOWN=true
        break
    fi
    sleep 10
done

if [[ "$HOST_IS_DOWN" == "false" ]]; then
    log "HINWEIS: Slave-Host antwortet noch immer auf Ping (evtl. Updates oder hängt)."
fi

log "==== ENDE: Workflow abgeschlossen ===="

Schritt 3: Der Schlüssel zum Erfolg – SSH ohne Passwort

Damit mein Primary-Server dem Secondary-Server sagen kann „Fahr jetzt runter“, muss er sich per SSH einloggen können – und zwar vollautomatisch ohne Passwort-Eingabe.

Das Lösen wir über SSH-Keys. Das klingt kompliziert, ist aber in einer Minute erledigt.

Key generieren: Logge dich auf der Shell deines Primary ein und gib ein:

ssh-keygen -t ed25519 -C "masterkey"

Bestätige einfach alles mit Enter (kein Passwort/Passphrase setzen!).

Key kopieren: Jetzt müssen wir diesen Schlüssel auf den Secondary übertragen. Dafür gibt es einen genialen Befehl:

ssh-copy-id root@DEINE-SECONDARY-IP

Hier musst du ein letztes Mal das Passwort des Secondary eingeben.

Ab jetzt kann sich dein Primary jederzeit per ssh root@DEINE-SECONDARY-IP auf dem Secondary einloggen, ohne nach einem Passwort zu fragen. Das ist die Grundvoraussetzung, damit unsere Skripte funktionieren.

Schritt 4: Alles automatisieren mit Cronjobs

Wir haben die Hardware optimiert, hd-idle eingerichtet und Skripte geschrieben. Aber wir wollen das ja nicht jeden Tag manuell ausführen. Wir wollen Proxmox Energie sparen, ohne daran denken zu müssen.

Dafür nutzen wir Cronjobs. Tippe in deine Proxmox-Shell:

[Code-Block]

Bash

crontab -e

Hier können wir genau festlegen, wann was passiert. Mein Zeitplan richtet sich nach der Sonne:

Vormittags (z.B. 09:50 Uhr): Das Start-Skript läuft an. Die Sonne kommt raus, wir haben Energie für Backups.
Nachmittags (z.B. 16:02 Uhr): Das Stop-Skript wird ausgeführt. Die Backups sollten durch sein, wir fahren alles runter.

# Zeitzone optional festsetzen (empfohlen)
CRON_TZ=Europe/Berlin

# PATH setzen, damit man nicht immer /usr/bin/ schreiben muss
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

# Secondary-Proxmox + PBS + VM102 morgens starten
50 9 * * * /root/automation/proxmox-slave-start.sh > /var/log/slave-workflow-last.log 2>&1
# VM102 stoppen, PBS deaktivieren und Secondary-Proxmox herunterfahren (z. B. 16:02)
2 16 * * * /root/automation/proxmox-slave-stop.sh >> /var/log/slave-workflow-last.log 2>&1

# Nach Reboot erstmal wieder PBS Storage aktivieren , da PBS VM im Autostart
@reboot /usr/sbin/pvesm set PBS_DXP8800Plus --disable 0 >> /var/log/pbs-storage.log 2>&1

Durch diese Automatisierung läuft mein großes Backup-System nur wenige Stunden am Tag. Die restlichen 18-20 Stunden verbraucht dieser Teil meines Home Labs: 0 Watt.

Schritt 5: Der Feinschliff – CPU Governor anpassen

Zum Schluss noch ein kleiner Tipp für das i-Tüpfelchen. Moderne CPUs bieten verschiedene Energiemodi („Governor“).

Auch das lässt sich per Cronjob steuern:

Nachts (Power-Save): Wenn ich schlafe und das System kaum Last hat, schalte ich die CPU in den powersave-Modus. Sie taktet runter und spart das letzte bisschen Watt.
Morgens (Performance): Wenn mein Home Assistant und andere Dienste aktiv werden, schalte ich zurück auf performance (oder ondemand), damit das System reaktionsschnell bleibt.

Der Befehl dafür sieht in etwa so aus (abhängig von deiner CPU):

cpupower frequency-set -g powersave

Das mag nur ein paar Watt ausmachen, aber beim Thema Proxmox Energie sparen zählt am Ende die Summe aller Maßnahmen.

# NACHT-MODUS (23:00 Uhr): Powersave
0 23 * * * cpupower frequency-set -g powersave

# TAG-MODUS (07:00 Uhr): Performance / maximale CPU Leistung
0 7 * * * cpupower frequency-set -g performance && cpupower frequency-set -u $(cpupower frequency-info -l | tail -1 | awk '{print $2}')

Fazit: Weniger Watt, mehr Freude

Es ist ein komplexes Thema, und ja, man muss sich einmal hinsetzen und die Skripte einrichten. Aber der Aufwand lohnt sich. Ich konnte meinen Verbrauch von konstanten über 100 Watt auf durchschnittlich 39 Watt senken. Auf das Jahr gerechnet ist das eine massive Ersparnis auf der Stromrechnung, die das Hobby „Home Lab“ deutlich familienfreundlicher macht.

Ich hoffe, diese Anleitung hilft dir dabei, dein Setup zu optimieren. Alle Skripte findest du natürlich auch hier zum Kopieren, damit du das Rad nicht neu erfinden musst.

Was ist dein größter Stromfresser im Rack? Schreib es mir gerne in die Kommentare – vielleicht finden wir gemeinsam eine Lösung!

Ugreen NAS mit Proxmox – So baust du dir dein eigenes HomeLab

Home Assistant Weihnachtsbeleuchtung automatisch steuern – Meine Automatisierung des Monats

5. Dezember 202512. Dezember 2025 admin

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

Einleitung

Die Adventszeit ist für viele eine der schönsten Zeiten im Jahr – und gleichzeitig eine der stressigsten. Zwischen Terminen, Familie und Alltag bleibt oft wenig Zeit, sich um die Weihnachtsbeleuchtung zu kümmern. Immer wieder Schalter drücken, Lichterketten einschalten, Außenbeleuchtung aktivieren und am Ende des Tages wieder alles abschalten – das kostet Zeit und Nerven.

Genau deshalb habe ich mir dieses Jahr eine besonders flexible und wiederverwendbare Lösung gebaut: Eine Home Assistant Weihnachtsbeleuchtung, die komplett automatisch funktioniert und sich über Kalender, Label, Zeitpläne und einen Template-Sensor steuern lässt.
Das Ganze ist meine Automatisierung des Monats – und sie lässt sich perfekt auf andere Jahreszeiten oder Anlässe übertragen.

In diesem Beitrag zeige ich Schritt für Schritt, wie ich das Ganze umgesetzt habe, welche Bausteine ich verwende und wie du die Automatisierung für dein eigenes Zuhause anpassen kannst.

Warum eine Home Assistant Weihnachtsbeleuchtung?

Die tägliche Routine rund um die Beleuchtung hat mich jedes Jahr aufs Neue genervt: Schalter drücken, einzelne Lampen aktivieren oder vergessen auszuschalten. Gerade wenn man Home Assistant nutzt, liegt es nahe, diese Abläufe vollständig zu automatisieren.

Wichtig war mir dabei:

Innen- und Außenbeleuchtung getrennt steuern zu können
Bedingungen wie Anwesenheit, Nachtmodus, Sonnenstand und Zeitfenster kombinieren zu können
Eine Lösung zu haben, die jedes Jahr ohne Anpassung funktioniert
Neue Lampen oder Steckdosen ohne Änderungen an der Automatisierung einbinden zu können

Die Grundlage dafür bilden Kalender, Template-Sensor, Labels und Zeitpläne.

Schritt 1: Kalender für die Weihnachtszeit

Damit die Automatisierung jedes Jahr ohne Anpassung funktioniert, lege ich in Home Assistant einen Kalender an. Dort definiere ich den Zeitraum der Weihnachtszeit. Der Kalender steuert später, ob die Automation aktiv ist oder nicht.

Vorgehen:

Die Integration „Kalender“ hinzufügen
Einen Kalender „Automatisierung“ anlegen
Einen Termin „Weihnachtszeit“ erstellen
Jährlich wiederholen aktivieren

Damit weiß Home Assistant jedes Jahr automatisch, ob sich die Weihnachtszeit gerade im aktiven Zeitraum befindet.

Schritt 2: Template-Sensor für den Zustand „Weihnachtszeit“

Aus dem Kalender erstelle ich einen Template-Sensor-Helfer, der lediglich den Zustand „an“ oder „aus“ besitzt. Dieser Sensor ist später eine zentrale Bedingung in der Automatisierung und greift auf den Automatisierungskalender zurück.

Beispielcode:

{{ is_state('calendar.automatisierung', 'on')
and state_attr('calendar.automatisierung', 'message') == 'Weihnachtszeit' }}

Dieser Sensor liefert ein sauberes Boolean-Ergebnis und erleichtert die Logik deutlich.

Schritt 3: Labels für Innen und Außen

Labels sind ein extrem hilfreiches Werkzeug in Home Assistant. Ich nutze zwei Labels:

Weihnachtsbeleuchtung (Innen)
Weihnachtsbeleuchtung (Außen)

Mit Labels kann ich flexibel Lampen hinzufügen oder entfernen, ohne jemals den Automationscode anfassen zu müssen.
Gerade bei saisonaler Deko ist das ideal.

Dann werden alle zu verwendeten Beleuchtungen mit den jeweiligen Labeln versehen.

Schritt 4: Zeitpläne für die Innenbeleuchtung

Die Innenbeleuchtung benötigt andere Regeln als die Außenbeleuchtung. Drinnen möchte ich feste Zeitfenster nutzen, die sich außerdem nach Wochentagen und dem Nachtmodus richten.

Ich arbeite mit einem Zeitplan Helfer

Morgens: 5:00 bis 10:30 (Wochenende ab 6:30)
Nachmittags bis abends: 15:00 bis 24:00

Diese Zeitpläne lassen sich jederzeit anpassen, ohne die Automatisierung zu verändern.

Schritt 5: Außenbeleuchtung mit Sonnenaufgang und Sonnenuntergang

Für die Außenbeleuchtung nutze ich den Sonnenstand:

Einschalten: eine Stunde vor Sonnenuntergang
Ausschalten: bei Sonnenaufgang

Damit läuft die Außenbeleuchtung immer zu den richtigen Zeiten, ohne dass ich eingreifen muss.

Schritt 6: Die Automatisierung – alles zusammengeführt

Die Automatisierung kombiniert:

Kalender
Template-Sensor
Zeitpläne
Nachtmodus
Anwesenheit
Sonnenstand
Labels

Die Automation reagiert auf verschiedene Trigger und führt dann die passenden Aktionen aus.

Beispielsweise:

Wenn die Weihnachtszeit endet, wird jede Beleuchtung deaktiviert.
Wenn morgens der Nachtmodus endet und der Zeitplan aktiv ist, wird innen die Weihnachtsbeleuchtung eingeschaltet.
Wenn jemand nach Hause kommt, wird die Weihnachtsbeleuchtung aktiviert, sofern kein Nachtmodus aktiv ist.
Wenn der Scheduler triggert und jemand zu Hause ist, wird die Weihnachtsbeleuchtung eingeschaltet.
Beim Sonnenuntergang wird die Weihnachtsbeleuchtung-Außen eingeschaltet.
Beim Sonnenaufgang oder bei Ende der Weihnachtszeit wird die Weihnachtsbeleuchtung-Außen ausgeschaltet.

Welche Entitäten musst du für deine eigene Installation anpassen?

Damit die Automatisierung für deine Weihnachtsbeleuchtung korrekt funktioniert, solltest du einige Entitäten an dein eigenes Home-Assistant-Setup anpassen. Im Folgenden findest du alle Stellen, an denen du eigene Namen, Gruppen oder Helper verwenden musst.

Sensoren und Helper

binary_sensor.weihnachtszeit
Dieser Sensor entscheidet, ob gerade „Weihnachtszeit“ ist. Du kannst stattdessen auch einen eigenen Helper oder eine Bedingung verwenden.
input_boolean.notify_night
Der Nachtmodus-Schalter. Falls du einen anderen Boolean für deinen Nachtmodus nutzt, musst du diesen hier ersetzen.
input_select.haus_modus
Der Hausmodus (z. B. „Anwesend“ oder „Abwesend“). Achte darauf, dass deine eigenen Auswahlwerte exakt zu deiner Konfiguration passen.

Zeitplan / Schedule

schedule.zeitplan_weihnachtsdeko
Dies ist der Zeitplan, der festlegt, wann die Weihnachtsbeleuchtung aktiv sein soll. Passe den Namen an deinen eigenen Zeitplan an.

Lichtgruppen oder Labels
Die wichtigste Anpassung betrifft die Zielbeleuchtung. In der Automation werden Labels verwendet, um mehrere Geräte gleichzeitig anzusteuern.

weihnachtsbeleuchtung_innen
Gruppe bzw. Label für alle Innenlichter.
weihnachtsbeleuchtung_aussen
Gruppe bzw. Label für alle Außenlichter.

Wenn du keine Labels verwendest, kannst du stattdessen auch einzelne Licht-Entitäten direkt im Zielbereich der Automation eintragen.

Sonnenuntergang und Sonnenaufgang
Die Automation reagiert zusätzlich mit folgenden Offsets:

Sonnenuntergang: 1 Stunde vorher
Sonnenaufgang: 1 Stunde später
Diese Offsets kannst du bei Bedarf an deine eigenen Lichtverhältnisse anpassen.

Wenn du diese Entitäten im Skript austauschst, kannst du die komplette Automation sofort in deinem eigenen Home Assistant verwenden.

alias: Weihnachtsbeleuchtung
description: ""
triggers:
  - trigger: state
    entity_id:
      - binary_sensor.weihnachtszeit
    to:
      - "off"
    id: id_xmas_end
  - trigger: state
    entity_id:
      - input_boolean.notify_night
    to:
      - "off"
    id: id_night_off
  - trigger: state
    entity_id:
      - input_boolean.notify_night
    to:
      - "on"
    id: id_night_on
  - trigger: state
    entity_id:
      - input_select.haus_modus
    to:
      - Abwesend
    id: id_away
  - trigger: state
    entity_id:
      - input_select.haus_modus
    to:
      - Anwesend
    id: id_home
  - trigger: state
    entity_id:
      - schedule.zeitplan_weihnachtsdeko
    to:
      - "on"
    id: id_sched_on
  - trigger: state
    entity_id:
      - schedule.zeitplan_weihnachtsdeko
    to:
      - "off"
    id: id_sched_off
  - trigger: sun
    event: sunset
    offset: "-01:00:00"
    id: id_sunset
  - trigger: sun
    event: sunrise
    offset: "01:00:00"
    id: id_sunrise
conditions:
  - condition: or
    conditions:
      - condition: state
        entity_id: binary_sensor.weihnachtszeit
        state:
          - "on"
      - condition: trigger
        id:
          - id_xmas_end
actions:
  - alias: Wenn Weihnachtszeit zu Ende
    choose:
      - conditions:
          - condition: trigger
            id:
              - id_xmas_end
        sequence:
          - action: light.turn_off
            metadata: {}
            data: {}
            target:
              label_id:
                - weihnachtsbeleuchtung_innen
                - weihnachtsbeleuchtung_aussen
      - conditions:
          - condition: and
            conditions:
              - condition: trigger
                id:
                  - id_night_off
              - condition: state
                entity_id: schedule.zeitplan_weihnachtsdeko
                state:
                  - "on"
        sequence:
          - action: light.turn_on
            metadata: {}
            data: {}
            target:
              label_id: weihnachtsbeleuchtung_innen
        alias: >-
          Morgens früh, wenn Nachtmodus ausgeschaltet wird,
          Weihnachtsbeleuchtung innen einschalten
      - conditions:
          - condition: and
            conditions:
              - condition: trigger
                id:
                  - id_home
              - condition: state
                entity_id: input_boolean.notify_night
                state:
                  - "off"
              - condition: state
                entity_id: schedule.zeitplan_weihnachtsdeko
                state:
                  - "on"
            alias: Jemand kommt nach Hause
        sequence:
          - action: light.turn_on
            metadata: {}
            data: {}
            target:
              label_id: weihnachtsbeleuchtung_innen
        alias: Jemand kommt nach Hause
      - conditions:
          - condition: and
            conditions:
              - condition: state
                entity_id: input_boolean.notify_night
                state:
                  - "off"
              - condition: state
                entity_id: input_select.haus_modus
                state:
                  - Anwesend
              - condition: trigger
                id:
                  - id_sched_on
        sequence:
          - action: light.turn_on
            metadata: {}
            data: {}
            target:
              label_id: weihnachtsbeleuchtung_innen
        alias: Weihnachtsscheduler On
      - conditions:
          - condition: trigger
            id:
              - id_sunset
        sequence:
          - action: light.turn_on
            metadata: {}
            data:
              rgb_color:
                - 240
                - 5
                - 5
              brightness_pct: 20
            target:
              label_id: weihnachtsbeleuchtung_aussen
        alias: Sonnenuntergang Außenbeleuchtung an
      - conditions:
          - condition: or
            conditions:
              - condition: trigger
                id:
                  - id_away
              - condition: trigger
                id:
                  - id_sched_off
              - condition: trigger
                id:
                  - id_xmas_end
              - condition: trigger
                id:
                  - id_night_on
        sequence:
          - action: light.turn_off
            metadata: {}
            data: {}
            target:
              label_id: weihnachtsbeleuchtung_innen
        alias: Beleuchtung innen aus
      - conditions:
          - condition: or
            conditions:
              - condition: trigger
                id:
                  - id_sunrise
              - condition: trigger
                id:
                  - id_xmas_end
        sequence:
          - action: light.turn_off
            metadata: {}
            data: {}
            target:
              label_id: weihnachtsbeleuchtung_aussen
        alias: Beleuchtung Außen aus
mode: queued
max: 10

Erweiterungsmöglichkeiten

Die Automatisierung ist so aufgebaut, dass ich sie jederzeit für andere Zwecke wiederverwenden kann. Denkbare Erweiterungen:

Halloween
Gartenbeleuchtung
saisonale Outdoor-Deko
Bewässerungssysteme
Ambient-Licht-Szenen

Ich ändere lediglich die Labels oder Zeitpläne – die Grundstruktur bleibt gleich.

Home Assistant Nachtmodus mit Labels – So automatisierst du dein Smart Home einfacher

Fazit

Mit meiner Home Assistant Weihnachtsbeleuchtung habe ich eine Automation umgesetzt, die vollständig automatisch läuft und jedes Jahr ohne Änderungen wiederverwendet werden kann. Durch die Kombination aus Kalender, Template-Sensor, Labeln und Zeitplänen entsteht eine sehr flexible und robuste Lösung, die mir im Alltag Arbeit abnimmt und zuverlässig funktioniert.

Ich hoffe, diese Automatisierung des Monats inspiriert dich zu eigenen Projekten und gibt dir eine klare Struktur, wie du ähnliche Aufgaben in Home Assistant lösen kannst. Wenn du Fragen hast oder deine eigene Version teilen möchtest, freue ich mich über Rückmeldungen auf meinem Youtube Kanal

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

28. November 202527. November 2025 admin

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

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:

UGREEN DXP8800 Plus*
👉 https://amzn.to/4qZ0pn7
UGREEN DXP6800 Plus*
👉 https://amzn.to/48mw9Ke
UGREEN DXP4800 Plus*
👉 https://amzn.to/47WMoxE

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:

2×4 TB HDDs
- 👉 https://amzn.to/3XTRFRO
später erweiterbar
Proxmox VM

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:

Storage → Disks
Die beiden Passthrough-HDDs auswählen
ZFS → Mirror
Namen vergeben (z. B. zfs-mirror-pbs)
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:

UGREEN DXP4800 Plus*
👉 https://amzn.to/47WMoxE

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:

UGREEN DXP8800 Plus* 👉 https://amzn.to/4qZ0pn7
UGREEN DXP6800 Plus* 👉 https://amzn.to/48mw9Ke
UGREEN DXP4800 Plus* 👉 https://amzn.to/47WMoxE
48 GB RAM für UGREEN* 👉 https://amzn.to/4nZzEfw
Verbatim USB-Stick für Unraid* 👉 https://amzn.to/448AfUY

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