Windows-Clients automatisch sichern mit UrBackup, ZFS und PXE

Die virtuellen Windows-Maschinen auf dem Cluster landen jede Nacht im Proxmox Backup Server, aber die physischen Rechner im Haus – zwei Desktop-PCs und zwei Notebooks – hatten bisher keine automatische Sicherung. Das Ziel war klar gesteckt: täglich die Benutzerdateien sichern, einmal pro Woche ein komplettes Plattenabbild ziehen, Stände ein halbes Jahr aufbewahren und ein Abbild im Ernstfall per PXE über das Netzwerk zurückspielen. Ende Oktober 2026 stand der UrBackup-Server im LXC-Container zwar an einem Abend, doch bei den ersten großen Abbildern bremsten mich Standby-Einstellungen im Dock, Cloud-Platzhalter und eine wackelige Netzwerkkarte aus.

Warum Disk2vhd, PBS und Veeam ausschieden

Den Anstoß gab am 24. Oktober 2026 ein konkreter Anlass: Auf einem Arbeitsplatz-PC mit Windows 10 22H2 (480-GB-SSD, davon 133 GB belegt) stand ein Hardware-Umzug auf einen neuen Rechner mit Windows 11 an. Um vorab eine vollständige Sicherung als Rückfall zu haben, habe ich mit Disk2vhd ein Abbild direkt auf die Samba-Freigabe images geschrieben. Interaktiv in einer angemeldeten Sitzung war das nach rund 30 Minuten erledigt.

Für regelmäßige Hintergrundläufe taugt dieser Weg allerdings nicht. Sobald ich denselben Aufruf als geplante Aufgabe unter dem Konto SYSTEM ohne aktive Benutzersitzung gestartet habe, blieb Disk2vhd unsichtbar hängen, und kurz darauf reagierte auf dem PC auch WinRM nicht mehr. Ich brauchte also einen Dienst, der Datei- und Block-Abbilder zentral plant, ohne Benutzereingriff durchläuft und normalen Benutzern im Haushalt erlaubt, versehentlich gelöschte Dateien selbst zurückzuholen.

Werkzeug	Vorteile im Homelab	Ausschlussgrund / Haken
Proxmox Backup Server (PBS)	Im Cluster bereits vorhanden, starke Deduplizierung	Kein offizieller Windows-Client (nur WSL-Umwege oder Drittanbieter-Betas), kein Block-Abbild, kein PXE-Restore
Veeam Backup & Replication CE / Agent Free	Bis zu 10 Workloads kostenlos, ausgereifter Windows-Agent	Zentraler Server braucht eine eigene Windows-VM samt Lizenz und Pflege; Agent Free allein plant nur lokal je PC; WinPE-PXE über wimboot aufwendiger
UrBackup (Server + Client 2.5.32)	Schlanker Linux-Server im LXC, plant Dateien und UEFI-Abbilder zentral, Live-ISO bootet per PXE, Selbstbedienung per Tray-Icon und Web-GUI	Spricht LDAP nur ohne TLS (braucht lokalen stunnel für LDAPS); abgebrochene Block-Abbilder lassen sich nicht fortsetzen

Die Wahl fiel auf UrBackup. Der Client-Agent lässt sich still mit dem Parameter /S oder per Gruppenrichtlinie aus dem lokalen Softwarearchiv verteilen, sichert bei UEFI-Systemen die EFI- und Systempartition automatisch mit und bringt ein eigenes Linux-Live-Medium mit, das der vorhandene PXE-Container direkt über das Netzwerk starten kann.

Server im LXC und ein eigener ZFS-Pool statt SnapRAID

Im ersten Moment lag es nahe, die Client-Sicherungen einfach auf dem vorhandenen Daten-Server abzulegen. Dort laufen sieben 4-TB-Platten mit zusammen 26 TB unter mergerfs und SnapRAID auf ext4, wovon erst 134 GB belegt waren. Für UrBackup ist so ein Pool aber eine schlechte Wahl: Auf ext4 legt UrBackup Plattenabbilder als VHD- oder VHDZ-Dateien an und verknüpft unveränderte Dateien zwischen den täglichen Ständen über tausende Hardlinks. Bei vielen kleinen, sich ständig ändernden Dateien muss jeder snapraid sync-Lauf sämtliche Änderungen neu berechnen.

Auf btrfs oder ZFS nutzt UrBackup stattdessen Copy-on-Write-Snapshots und spart gerade bei wöchentlichen Abbildern deutlich Platz. Bei den Rechnern mit geschätzt zusammen 0,5 bis 1 TB belegter Datenmenge rechnen sich 26 Wochenabbilder und tägliche Dateistände auf etwa 1 bis 3 TB.

Ich habe deshalb in Knoten 3 eine einzelne 10-TB-Festplatte (8,97 TB nutzbar) als eigenen ZFS-Pool urbackup-pool ohne Spiegel eingerichtet. Fällt diese Platte aus, fange ich auf einer vorhandenen Reserveplatte neu an. Ein lokaler RAID-Spiegel ist hier verzichtbar, weil die Originaldaten weiter auf den Clients liegen und die gesamte Ablage zusätzlich per restic (AES-256) im Wechsel auf zwei 5-TB-USB-Platten außer Haus kopiert werden soll; das ist noch offen.

Der UrBackup-Server selbst läuft als LXC-Container auf Knoten 3 mit 2 Kernen, 2 GB RAM und 32 GB Systemlaufwerk auf NVMe-Speicher. Der ZFS-Pool ist direkt in den Container eingehängt; der Proxmox Backup Server sichert nachts nur das schlanke Container-System ohne die Sicherungsablage. Beim Einrichten am Abend des 24. Oktober 2026 fielen gleich zwei Dinge auf, die man vor dem ersten produktiven Lauf glattziehen sollte:

• Der neue Container lief zunächst in der Zeitzone UTC statt Europe/Berlin. Daran hängen aber sämtliche Zeitfenster und der Wake-on-LAN-Wecker des Servers. Wer Einstellungen direkt in der SQLite-Datenbank /var/urbackup/backup_server_settings.db anpasst, muss vorher zwingend den Dienst urbackupsrv stoppen und eine Kopie der Datei anlegen, weil der laufende Prozess Änderungen sonst wieder überschreibt.
• Die Weboberfläche unter https://backup.example.lan (abgesichert mit einem Zertifikat der internen CA) sollte neben einem lokalen Notfallkonto die Anmeldung über das Active Directory erlauben. UrBackup unterstützt LDAP allerdings nur unverschlüsselt ohne TLS. Damit keine Klartext-Anmeldungen über das Netz gehen, nimmt im Container ein lokaler stunnel-Dienst Verbindungen auf 127.0.0.1:3268 an und leitet sie per LDAPS an die Domänencontroller weiter.

# /etc/stunnel/ldaps-ad.conf im UrBackup-Container
[ldaps-ad]
client = yes
accept = 127.0.0.1:3268
connect = dc01.example.lan:636
connect = dc02.example.lan:636
CAfile = /etc/ssl/certs/example-ca.pem
verifyChain = yes

Fällt der Tunnel oder das Active Directory einmal aus, funktioniert weiterhin das in der Passwortverwaltung hinterlegte lokale Notfallkonto.

Dateisicherung im Leerlauf, OneDrive-Falle und Zeitplan

Als ersten Testkandidaten habe ich am selben Abend ein Notebook mit dem Client 2.5.32 verbunden. Kaum war der Agent installiert, legte UrBackup von sich aus los und startete eine volle Dateisicherung mit der Standard-Pfadliste des Clients – also einmal komplett über C:\, während ein Benutzer angemeldet war. Wer den Agenten im Netz ausrollt, sollte die serverseitige Automatik und die Pfadlisten daher vor dem ersten Client-Kontakt einstellen.

Dabei zeigte sich auf dem Test-Notebook direkt die nächste Falle: Das Benutzerprofil meldete 207 GB an Daten im OneDrive-Ordner, die lokal aber nur als Online-Platzhalter (Files On-Demand) existierten. Wenn ein Backup-Agent solche Verzeichnisse liest, zwingt Windows den Cloud-Client dazu, sämtliche Dateien im Hintergrund aus dem Internet herunterzuladen. Der OneDrive-Pfad ist deshalb zusammen mit Temp-Ordnern, Browser-Caches und unfertigen Downloads fest von der Dateisicherung ausgenommen.

Auch beim Zeitplan für die Dateisicherung habe ich die Standardsteuerung von UrBackup umgedreht. Die Rechner sind nicht rund um die Uhr eingeschaltet, und tagsüber soll kein Backup-Lauf die Arbeit ausbremsen. Auf dem Server ist das automatische Anstoßen von Dateisicherungen deshalb deaktiviert. Stattdessen läuft auf den Clients eine geplante Aufgabe, die zwischen 08:00 und 22:00 Uhr aktiv wird, sobald der Rechner am Netzteil hängt und im Leerlauf ist. Ein kleines Skript ruft dann das Kommandozeilenwerkzeug des Agenten auf und sorgt über einen Zeitstempel dafür, dass höchstens alle 20 Stunden ein Lauf startet:

# Schematisch: Aufruf durch die geplante Leerlauf-Aufgabe auf dem Client (08:00 bis 22:00 Uhr)
UrBackupClient_cmd.exe start ...

Die Aufbewahrung ist für ein halbes Jahr ausgelegt: Bei den Dateien behält der Server 14 tägliche und 26 wöchentliche Stände. Die Block-Abbilder laufen samstags um 03:00 Uhr morgens (der Server weckt die Desktop-PCs um 02:55 Uhr per Wake-on-LAN) und werden 26 Wochen lang aufgehoben, wobei alle vier Wochen ein Vollabbild und dazwischen inkrementelle Abbilder geschrieben werden. Der Termin am Samstag um 03:00 Uhr fällt zwar in das allgemeine Backup-Fenster von 02:00 bis 04:00 Uhr, in dem auch der PBS arbeitet, belastet Knoten 3 aber nur einmal pro Woche.

Drei Abbruchfallen bei den ersten Plattenabbildern

Bei Dateisicherungen sind Unterbrechungen harmlos, weil bereits übertragene Dateien beim nächsten Lauf übersprungen werden. Bei Block-Abbildern gilt in UrBackup dagegen eine harte Grenze: Ein abgebrochenes Abbild lässt sich nicht fortsetzen. Bricht die Verbindung kurz vor Schluss weg, verwirft der Server den unvollständigen Stand (in der Datenbank bleibt complete=0), und der nächste Versuch beginnt wieder bei null. Zwischen dem 24. und 26. Oktober 2026 bin ich dabei nacheinander in drei Fallen gelaufen.

1. Deckel-Standby am Notebook im Dock

Das erste Vollabbild des Test-Notebooks startete am Abend des 24. Oktober über WLAN und sollte gegen 06:00 Uhr morgens fertig sein. Der Lauf blieb aber schon um 22:06 Uhr bei 11,7 GB stehen, weil das Notebook offline ging. Auch am Kabel im Dock brach der nächste Anlauf ab: Das Gerät lag mit geschlossenem Deckel auf dem Tisch, und Windows schickte es trotz aktiver Festplatten- und Netzwerklast des Backup-Dienstes in den Standby. Erst als das Begleitskript für die Dauer eines Abbildlaufs am Netzteil eine explizite Schlafsperre gesetzt hat, wurde sowohl das Abbild des Test-Notebooks als auch am 26. Oktober das des zweiten Notebooks (256 GB auf C:\) fertig.

2. USB-Netzwerkkarte auf dem Server-Knoten verliert alle 34 Minuten den Link

Am Abend des 26. Oktober lief das erste Vollabbild des großen Arbeitsplatz-PCs an. Um 19:54:30 Uhr, bei rund 80 Prozent Fortschritt, brach die Übertragung plötzlich ab. Die Ursache lag diesmal bei Knoten 3 selbst: Die dort genutzte USB-Netzwerkkarte mit r8152-Treiber verliert im Abstand von etwa 34 Minuten kurz den Link. Bei kurzen Dateisicherungen oder normalem Webzugriff geht so ein kurzer Aussetzer im TCP-Retransmit unter; ein mehrstündiges Vollabbild reißt er zuverlässig ab.

3. Leerer Prozessstatus, doppelte Vollabbilder und wechselnde Dock-IP

Direkt nach so einem kurzen Link-Ausfall zeigt die Prozessabfrage auf dem Client zunächst keinen laufenden Sicherungsauftrag mehr an. Das heißt aber noch nicht, dass der Server den Lauf bereits aufgegeben hat. Als ich beim ersten Notebook nach einer Unterbrechung einen weiteren Startbefehl hinterhergeschickt habe, hat UrBackup den zweiten Befehl in die Warteschlange eingereiht und direkt nach dem ersten Vollabbild ungefragt ein zweites komplettes Vollabbild auf den Pool geschrieben. Nach einer kurzen Trennung wartet man also erst die Server-Wartezeit ab und stößt den Lauf nur dann genau einmal neu an, wenn er wirklich stehen bleibt.

Dazu kam am Schreibtisch ein Nebeneffekt der Dockingstation: Weil die Netzwerkschnittstelle im Dock sitzt, wanderte dieselbe IP-Adresse (z. B. 192.0.2.216) beim Umstecken zwischen den beiden Notebooks hin und her. Wer per Skript nach IP-Adresse auf einen vermeintlich bekannten Rechner zugreift, landet schnell auf dem falschen Gerät. Die MAC-Adresse des Docks hat inzwischen eine eigene feste DHCP-Reservierung (192.0.2.69) bekommen, und Skripte prüfen vorab immer den Computernamen.

PXE-Wiederherstellung, Checkmk und offene Punkte

Für die Wiederherstellung einzelner Dateien sollen die Benutzer am PC keine Hilfe brauchen: Über das UrBackup-Symbol in der Taskleiste sollen sie ohne eigenes Passwort an ihre Stände kommen, alternativ über die Weboberfläche mit ihrer normalen Domänen-Anmeldung und Rechten nur auf den eigenen Rechner. Das ist geplant und noch nicht eingerichtet. Für den Ausfall einer ganzen SSD ist das UrBackup-Live-Medium bereits als Menüpunkt „UrBackup-Wiederherstellung“ im iPXE-Menü des lokalen PXE-Containers eingetragen; ein zweites Skript bereitet denselben Start auf einem USB-Stick für den Notfallordner vor.

In Checkmk ist der UrBackup-Server als eigener Host aufgenommen und meldet das Sicherungsalter je Client. Bei den stationären PCs schlägt die Prüfung auf Warnung, sobald die letzte Dateisicherung älter als 2 Tage oder das letzte Abbild älter als 9 Tage ist; für die Notebooks gelten großzügigere Schwellwerte. Eine anfangs im Serverprotokoll auftauchende Meldung Syncing … Operation not permitted im LXC-Container auf ZFS ließ sich als harmlos abhaken.

Mit Stand vom 26. Oktober 2026 sind noch fünf konkrete Baustellen übrig:

• An Knoten 3 muss zuerst die USB-Netzwerkkarte mit dem r8152-Aussetzer alle 34 Minuten getauscht oder umgehängt werden; direkt danach steht der neue Anlauf für das bei 80 Prozent abgebrochene Vollabbild des Arbeitsplatz-PCs an.
• Auf dem Test-Notebook lief das Leerlauf-Skript bisher nur im Trockentest um 01:20 Uhr nachts; der erste echte Lauf im Tagesfenster zwischen 08:00 und 22:00 Uhr steht noch aus.
• Für die automatische Verteilung des Agenten per Gruppenrichtlinie (Organisationseinheit „Clients-Sicherung“) brauchen die Computerkonten noch Leserecht auf das Softwarearchiv, und für den großen Arbeitsplatz-PC ist noch zu entscheiden, ob neben C:\ auch die weiteren Laufwerke D:, F: und H: gesichert werden.
• Das vorbereitete Skript für den PXE-Wiederherstellungstest muss noch einmal komplett gegen eine Test-VM laufen – erst wenn ein Abbild über das Netzwerk zurückgespielt wurde und sauber bootet, gilt der Weg als abgenommen (danach halbjährlich auf Wiedervorlage).
• Das manuelle Disk2vhd-Abbild vom 24. Oktober und die temporäre Samba-Freigabe images bleiben so lange als Rückfall bestehen, bis der zweite Desktop-PC sein geprüftes UrBackup-Abbild hat; ebenso wartet die verschlüsselte restic-Kopie der ZFS-Ablage noch auf die Einrichtung der beiden 5-TB-Wechselplatten für die Sicherung außer Haus.