Proxmox Backups müssen nicht frustrieren: Ein Skript für Synology iSCSI

Proxmox Backup Server kann Speicherplatz nutzen, der über eine Synology iSCSI LUN bereitgestellt wird, und ein Community-Skript versucht, die anfängliche Verbindung und das Setup deutlich zu vereinfachen. Es reduziert repetitive Konfigurationsarbeiten im Alltag spürbar, ersetzt jedoch weder einen verbindlichen Wiederherstellungstest noch eine grundlegende architektonische Entscheidung über Speicher-Ausfalldomänen.

Das veröffentlichte Projekt pbs-synology-iscsi beschreibt eine menügeführte iSCSI- und CHAP-Konfiguration. Die Diskussion darum drehte sich jedoch weniger um die reine Lauffähigkeit des Skripts als vielmehr um die grundlegendere Frage, ob NFS, lokaler PBS-Speicher oder iSCSI langfristig die einfachere und robustere Architektur darstellt.

Warum Synology iSCSI für Proxmox Backup Server nutzen?

Synology iSCSI kann einem dedizierten PBS-Host reinen Block-Storage bereitstellen und umgeht so einige der typischen Dateifreigabe-Berechtigungsprobleme, die dieses Setup in der Praxis oft erschweren.

Der Entwickler, der unter dem Namen MorphyDK auftritt, beschrieb wiederkehrenden Frust bei der Nutzung von NFS für den PBS-Speicher auf Synology-Systemen. Es handelte sich dabei nicht um einen spektakulären Hardware-Ausfall oder um plötzlich verschwundene Backups; es war vielmehr das kleinere, zermürbende Problem mit Dateiberechtigungen und Zugriffsrechten, das jede Neuinstallation unnötig mühsam machte. Jeder, der ein Homelab betreibt, kennt diese Art von Reibungsverlusten aus eigener Erfahrung: Ein Dienst funktioniert zwar irgendwann, aber wenn man Monate später zu dieser Konfiguration zurückkehrt, muss man längst vergessene Entscheidungen mühsam rekonstruieren. Das Backup-System beginnt sich wie ein weiteres System anzufühlen, das ständige Zuwendung und Rettung verlangt. Das ist eine besonders frustrierende Situation, wenn der eigentliche Zweck dieser Infrastruktur doch darin besteht, Notfälle und Wiederherstellungen einfacher zu machen.

Bevor Sie sich endgültig für ein bestimmtes Zielprotokoll entscheiden, sollten Sie eine umfassendere Proxmox Backup Strategie prüfen, die auch Off-Host-Kopien und gezielte Restore-Szenarien berücksichtigt.

Der entscheidende Impuls war die Entdeckung von Derek Seamans Ansatz, eine iSCSI LUN direkt an einen Proxmox Backup Server Host anzubinden. MorphyDK testete diesen Pfad und stellte fest, dass er auf Anhieb funktionierte. Diese Differenzierung ist wichtig: Die Idee, iSCSI zu verwenden, wurde keineswegs als bahnbrechende Neuerfindung präsentiert. Der Entwickler nannte Dereks Vorarbeit offen als tragendes Fundament und konzentrierte sich darauf, den eigentlichen Ablauf wesentlich benutzerfreundlicher und zugänglicher zu gestalten. Statt jedes Mal durch eine verstreute Sammlung von Terminal-Befehlen und Notizen navigieren zu müssen, war das Ziel ein geführtes Setup mit Menüs, farbigen Ausgaben, automatischer Erkennung und verständlichen Abfragen. Das gelöste Problem war ebenso sehr die Vermeidung fehleranfälliger Wiederholungen wie die Speicheranbindung selbst: Weniger Detektivarbeit, weniger vergessene Konfigurationsschritte und eine Einrichtung, an die sich auch andere Homelab-Betreiber ohne Bauchschmerzen herantrauen können.

Hinter dieser Diskussion steht ein handfester technischer Unterschied. NFS stellt eine Netzwerk-Dateifreigabe bereit, wodurch Eigentumsrechte, Dateiattribute und Berechtigungen direkt in die Beziehung zwischen PBS und dem NAS hineinspielen. iSCSI hingegen stellt dem PBS-Host reinen Block-Speicher zur Verfügung, auf dem ein passendes Linux-Dateisystem den eigentlichen Datastore beherbergen kann. Das offizielle PBS-Speicherhandbuch beschreibt Datastores als normale Verzeichnisse auf Unix-Dateisystemen wie ext4, XFS oder ZFS. Das macht iSCSI nicht automatisch in jeder Hinsicht überlegen, und es schließt keineswegs jede denkbare Fehlerquelle aus. Es verlagert jedoch den Ort, an dem das Dateisystem verwaltet wird, vollständig auf das Betriebssystem des Backup-Servers. Genau das ist der Grund, warum Administratoren, die von NFS-Berechtigungskonflikten zermürbt sind, diesen alternativen Pfad als große Erleichterung empfinden. Die praktische Frage lautet letztlich, ob dieser Kompromiss den Betrieb in der konkreten Umgebung tatsächlich stabiler und einfacher macht.

Was automatisiert das PBS Synology iSCSI Skript?

Das Repository beschreibt einen geführten Workflow zur Konfiguration des iSCSI-Ziels und der Authentifizierung, anstatt manuelle Schritte einzeln im Terminal ausführen zu müssen.

Das veröffentlichte Projekt bietet deutlich mehr als nur eine bunte Menüführung im Terminal. Das Repository dokumentiert die geführte iSCSI-Target-Konfiguration samt CHAP-Authentifizierung, eine vorherige Datenträgerprüfung vor jeglichen Modifikationen und die Fähigkeit, einen bereits vorhandenen PBS-Datastore auf dem Speicher zu erkennen und erneut einzubinden, anstatt ihn ungefragt zu überschreiben. Darüber hinaus übernimmt das Skript nachgelagerte Aufgaben wie die Anpassung von Paket-Repositories, Systemaktualisierungen, die Überwachung der Mount-Wiederherstellung nach Reboots und automatisierte TRIM-Zeitpläne. Dabei handelt es sich um die vom Autor dokumentierten Funktionsmerkmale, nicht um eine Garantie dafür, dass jeder Pfad auf jedem beliebigen System auf Anhieb reibungslos durchläuft. Die Zielsetzung ist dennoch eindeutig: Das Skript versucht, eine leicht vergessene Abfolge von Speicher- und Betriebssystembefehlen in ein verlässliches, wiederholbares Verfahren zu überführen. Für jeden Administrator, der dasselbe Setup bereits mehrfach von Hand aufsetzen musste, ist das ein absolut verständliches Anliegen.

Ein besonders kritisches Versprechen betrifft den Umgang mit bereits vorhandenen Datenbeständen. Backup-Speicher ist einer der denkbar schlechtesten Orte, an denen ein Skript fehlerhafte Annahmen treffen darf. Das Repository betont, dass das Setup vorhandene Festplatten prüft und gezielt versucht, einen bestehenden Datastore zu erhalten und wieder einzubinden, wenn ein solcher gefunden wird. Dieser Punkt verdient Beachtung, denn ein gut geschriebener Installer muss vor allem erkennen können, wann Nichtstun die einzig korrekte Handlungsweise darstellt. Allerdings ist eine Beschreibung in einer Projekt-README kein Ersatz dafür, den Quellcode selbst genau zu prüfen und potenziell destruktive Zweige in einer sicheren Umgebung zu testen. Das Projekt bietet zudem einen direkten Shell-Befehl an, der das Skript direkt herunterlädt und ausführt. Ist das bequem? Zweifellos. Ist es etwas, das man ungeprüft auf dem einzigen Speicherort unersetzlicher Backups ausführen sollte? Das lässt sich weitaus schwerer rechtfertigen.

Der Entwickler räumte außerdem offen ein, bei der Erstellung erhebliche Unterstützung von Claude AI erhalten zu haben. Dieses Eingeständnis macht den Quellcode nicht automatisch fehlerhaft, genauso wie das Schreiben jeder einzelnen Zeile von Hand ihn nicht automatisch sicher machen würde. Es wirft jedoch berechtigte Fragen hinsichtlich eingehender Code-Reviews und praktischer Tests auf, insbesondere wenn es um Festplattenpartitionierung, Mount-Pfade, System-Upgrades und Authentifizierung geht. In diesem Fall bot die menschliche Interaktion in den Diskussionsbeiträgen ein sehr ermutigendes Gegengewicht: Derek Seaman selbst meldete sich zu Wort und bot an, die Neuerungen über einen Pull Request in sein eigenes Vorhaben zu integrieren. MorphyDK nahm den Austausch direkt auf. Ein Werkzeug, das aus einem persönlichen Ärgernis heraus entstanden war, hatte die Aufmerksamkeit des ursprünglichen Autors geweckt. Auf genau diese Weise können kleine Infrastruktur-Skripte für eine breitere Community nützlich werden, sofern Pflege, Wartung und kritische Code-Reviews mit der Benutzerfreundlichkeit Schritt halten.

Ist NFS oder iSCSI einfacher für Proxmox Backups?

Weder NFS noch iSCSI ist in jedem Szenario die absolut einfachere Lösung; die richtige Wahl hängt davon ab, wie der Datastore verwaltet, gemountet, überwacht und im Ernstfall wiederhergestellt wird.

Nicht jeder Diskussionsteilnehmer wünschte sich einen noch ausgefeilteren iSCSI-Installer. Ein Teilnehmer beschrieb, dass er PBS direkt auf dem Speicherserver selbst installiert habe, wodurch die Notwendigkeit entfällt, den Speicher überhaupt über NFS, iSCSI oder SMB anzubinden. Ein anderer verwies auf eine Anleitung, Proxmox Backup Server als virtuelle Maschine direkt auf dem Synology NAS zu betreiben. Auch über Erfahrungen mit älterer Synology-Hardware wurde intensiv berichtet: Eine Synology DS1815+ wurde als absolut zuverlässig für PBS in Erinnerung gerufen, während ein Nutzer einer RS820 berichtete, dass sein Setup vollkommen stabil laufe, auch wenn es keine Geschwindigkeitsrekorde aufstelle. Diese letzte Beobachtung ist vielleicht der pragmatischste Maßstab der gesamten Debatte: Wenn die Kernaufgabe im Schutz der eigenen Systeme liegt, wiegen berechenbare und zuverlässige Backups deutlich schwerer als beeindruckende Durchsatz-Diagramme.

Die tieferliegenden Vor- und Nachteile der verschiedenen Speichertechnologien werden in unserem Vergleich von ZFS, Ceph, LVM Thin und RAID ausführlich analysiert.

Ein weiterer Kommentator vereinfachte die Ausgangslage noch radikaler: Er schlug vor, PBS einfach in einem Docker-Container auf einem leistungsfähigen NAS zu betreiben. Dies wurde als schnelle, unkomplizierte Lösung mit geringem Speicherbedarf präsentiert, allerdings basierte die Speicherabschätzung eher auf individuellen Behauptungen als auf systematisch getesteten Mindestanforderungen über verschiedene NAS-Modellreihen hinweg. Container können äußerst attraktiv sein, wenn sie zu vorhandenen Gewohnheiten und bestehender Hardware passen. Gleichzeitig verlagern sie Fragen zu Kompatibilität, Datenpersistenz und Notfallwiederherstellung auf eine zusätzliche Abstraktionsebene. Die verschiedenen Alternativen sind keineswegs beliebig austauschbar, und die Diskussion zeigte dies sehr deutlich. Manche Administratoren bevorzugen einen dedizierten PBS-Server mit getrenntem Netzwerkspeicher; andere möchten den Backup-Dienst direkt auf der eigentlichen Speicher-Hardware betreiben. Beide Ansätze können in sich absolut schlüssig sein, verlangen vom Administrator jedoch Vertrauen an völlig unterschiedlichen Stellen des Stacks.

Schließlich tauchte ein Vorschlag auf, der das ursprüngliche Skript fast schon bescheiden wirken ließ: die Integration von iSCSI Multipathing. Ein Nutzer teilte ein rudimentäres Shell-Beispiel und plädierte dafür, mehrere Pfade zwischen dem PBS-Initiator und dem Storage-System einzurichten. Der Autor signalisierte Interesse, während ein anderer Leser nachfragte, ob dies mehrere separate Speichersitzungen bedeuten würde. Multipathing kann durchaus sinnvoll sein, wenn tatsächlich redundante Netzwerkpfade existieren; das in der Diskussion gezeigte Fragment war jedoch weit davon entfernt, eine gründlich geprüfte, produktionsreife Erweiterung des Projekts darzustellen. Vor allem verdeutlicht es die endlose Versuchung im Homelab-Bereich: Jedes Mal, wenn jemand eine lästige Konfigurationshürde beseitigt, entdeckt ein anderer ein weiteres Ausfallsicherheits-Feature, das man unbedingt ergänzen könnte. Auf diese Weise läuft ein Skript, das ursprünglich gebaut wurde, um zeitraubende Fummelei zu vermeiden, schnell Gefahr, eine beachtliche eigene Komplexität mit vielen beweglichen Teilen anzuhäufen.

Wie sollten Sie ein PBS-Speicher-Setup beurteilen?

Beurteilen Sie ein Speicherdesign immer anhand erfolgreicher Wiederherstellungstests und eines berechenbaren Verhaltens im Fehlerfall, nicht daran, wie reibungslos der anfängliche Installationsassistent durchgelaufen ist.

Bei der Meinungsverschiedenheit geht es im Kern gar nicht darum, ob NFS oder iSCSI die schönere Trophäe verdient. Es geht darum, an welcher Stelle im Gesamtsystem Sie die Komplexität ansiedeln möchten. Eine dedizierte PBS-Instanz mit einer Synology iSCSI LUN trennt den Dienst sauber von seinen Nutzdaten, erfordert jedoch eine solide Konfiguration des Netzwerkspeichers. Ein PBS, der direkt auf dem NAS läuft, erspart diese Netzwerkverbindung, platziert jedoch die Backup-Software und die gesicherten Daten auf ein und demselben physischen Gerät. Ein containerbasiertes Deployment wirkt extrem leichtgewichtig, bringt jedoch eigene Anforderungen an Support und langfristige Wartung mit sich. Multipathing erhöht die Ausfallsicherheit in passenden Netzwerkarchitekturen, steigert jedoch den Konfigurationsaufwand erheblich. Keiner dieser Kompromisse lässt sich allein dadurch auflösen, wie ansprechend ein Installationsmenü auf dem Bildschirm wirkt. Die richtige Wahl richtet sich danach, welche Hardware bereits vorhanden ist und gegen welche konkreten Ausfallszenarien Sie sich absichern möchten.

Zudem besteht ein fundamentaler Unterschied zwischen einer stabilen Speicherverbindung und einem verlässlichen Notfall-Wiederherstellungsplan. Eine erfolgreich gemountete LUN ist noch lange kein Beweis dafür, dass sich eine beschädigte virtuelle Maschine im Ernstfall auch fehlerfrei rekonstruieren lässt. Ein Skript, das einen bestehenden Datastore automatisch erkennt, garantiert keineswegs, dass die darin gespeicherten Datenblöcke tatsächlich integer und konsistent sind. Die Community-Diskussion liefert viele positive Erfahrungsberichte und nützliche Denkanstöße, enthält jedoch weder systematische Leistungsvergleiche noch langfristige Belege für erfolgreiche Wiederherstellungen mit MorphyDKs neuem Werkzeug. Diesen Umstand muss man offen und ehrlich benennen. Ein umsichtiger Administrator wird den Skriptcode vorab genau analysieren, ihn zunächst auf Test-Datenträgern erproben, exakt nachvollziehen, welche Befehle Änderungen an Partitionstabellen vornehmen, und vor allem praktisch verifizieren, dass ein Restore im Ernstfall funktioniert. Diese Kontrollen sind zweifellos weniger aufregend als ein vollautomatisches Setup, aber sie bilden genau die Trennlinie zwischen beruhigender Backup-Aktivität und echten, wiederherstellbaren Unternehmensdaten.

Der vielleicht sympathischste Aspekt dieser Entwicklung liegt in ihrem pragmatischen Ursprung. Jemand stand vor einem wiederkehrenden, nervigen Problem, griff auf bestehende Lösungsansätze zurück und entwickelte ein Werkzeug, um anderen wertvolle Zeit zu sparen. Der ursprüngliche Ideengeber zeigte sich offen für eine echte Zusammenarbeit. Andere Homelab-Enthusiasten steuerten alternative Architekturideen und Vorschläge für ausfallsicherere Verbindungen bei. Niemand hat dabei die eine allgemeingültige Universallösung erfunden, und das neue Skript muss eine solche auch gar nicht sein, um nützlich zu sein. Sein tatsächlicher Wert entscheidet sich daran, ob es die Ersteinrichtung von PBS spürbar vereinfacht, ohne gleichzeitig das Vertrauen in die Datensicherheit zu untergraben. Denn ein Backup-System, das sich zwar wunderbar installieren lässt, im Moment der Wiederherstellung jedoch versagt, hat den wirklich frustrierenden Teil der Aufgabe letztlich nicht gelöst.

Wählen Sie in der Praxis stets das Speicherprotokoll, das Sie im Notfall sicher überwachen, verwalten und wiederherstellen können, und führen Sie vor dem produktiven Einsatz einen vollständigen Restore-Test durch. Wenn ein direkter PBS-Datastore auf lokalem Speicher in Ihrer Umgebung einfacher und zuverlässiger zu betreiben ist, lohnt es sich oft nicht, die zusätzliche Komplexität einer iSCSI-Schicht einzuführen.