Kein Unternehmens-PC darf ohne ein durchdachtes Backupkonzept in Betrieb gehen. Obwohl sich so langsam auch in kleineren und mittelgroßen Unternehmen cloudbasierte Ansätze etablieren, arbeiten zahlreiche Anwender nach wie vor mit lokalen Daten. Während große Unternehmen auf zentrales, netzwerkbasiertes Backup mit kommerzieller Sicherungssoftware setzen, arbeiten kleinere Umgebungen gerne mit "Hausmitteln". Dabei muss dann oft eine USB-Platte und das Windows-eigene Sicherungstool oder ein PowerShell-Skript mit "robocopy" genügen.

Prinzipiell ist am Hausmittel-Software-Ansatz gar nichts auszusetzen, aber das Sicherungsmedium USB-Platte taugt wenig. Doch hier kann der Administrator mit einem simplen Backupserver Marke Eigenbau und dem iSCSI-Protokoll helfen.

Das LAN-Konzept ist natürlich alt und wird seit vielen Jahren mit simplen NAS-Boxen umgesetzt – doch kommt hier das SMB-Protokoll zum Einsatz, das die Daten der Windows-Arbeitsstationen sichert. Warum sollten Administratoren also das iSCSI-Protokoll statt SMB verwenden? Für iSCSI als Backupprotokoll sprechen eine ganze Reihe von Gründen. Allen voran steht dabei das Dateisystem: SMB als Netzwerkdateisystem fehlen gegenüber einem lokalen Dateisystem wie NTFS einige Funktionen. Dazu zählen erweiterte Dateiattribute und Features wie der Volume Shadow Copy Service.

SMB als Shared-Netzwerkdateisystem darf zudem keinen Write-Cache verwenden, was Schreibvorgänge insbesondere mit vielen kleinen Dateien extrem verlangsamt. Und das SMB-Dateisystem läuft auf dem Backupserver selbst, was diesem bei mehreren parallelen Zugriffen ebenfalls Geschwindigkeit nimmt. Eingerichtet als Shared-Filesystem, erlaubt ein großes Backupverzeichnis auf einem NAS zudem, dass alle Arbeitsstationen die Backups der anderen Rechner einsehen – es sei denn, der Administrator konfiguriert individuelle Zugriffsrechte.

iSCSI arbeitet als sehr simples, blockbasiertes Netzwerkprotokoll. Das Dateisystem muss der Client selbst stemmen. Aus Sicht des Betriebssystems erscheint das Backuplaufwerk wie eine lokale Platte. Daher greifen auch Schreib-Cache und Funktionen wie Snapshots. Der Administrator weist jedem PC sein eigenes Laufwerk über iSCSI zu, sodass die Arbeitsstationen jeweils nur auf ihr eigenes Laufwerk zugreifen können. Einen iSCSI-Client bringen Betriebssysteme wie Windows oder Linux mit, für macOS gibt es verschiedene kommerzielle und freie Tools.

Setzt der Backupserver ausreichend schnelle Platten ein, liefert iSCSI zudem eine bessere Performance als SMB-Freigaben, insbesondere bei kleinen IOPs. Eine einzelne iSCSI-Verbindung schafft bei einem herkömmlichen 1-GBit/s-Netzwerk bis zu 120 MByte/s Durchsatz. Mehrere Clients müssen sich dabei natürlich die Leitung teilen, aber auch hier bietet iSCSI gegenüber SMB-Freigaben Vorteile. ISCSI kann Verbindungen über mehrere physische Interfaces verwalten. Mit dem so genannten Multipathing wird dabei zwar keine einzelne Client-Server-Verbindung schneller als 120 MByte/s, aber mehrere simultan arbeitende Clients kommen sich so weniger in die Quere. Zudem kann Multipathing den Ausfall einer Leitung oder eines LAN-Adapters kompensieren.

Das "Small Computer Systems Interface" (SCSI) besteht eigentlich aus zwei Komponenten: Der physischen Verbindung auf der einen und dem Speicherprotokoll auf der anderen Seite. Heute nutzen Server vor allem das Serial Attached SCSI (SAS), schnelle Speichernetzwerke setzen auf Fibre Channel oder auch Infiniband als physischen Layer – aber alle diese Implementierungen verwenden das gleiche Speicherprotokoll. Bei iSCSI kommt als Transportmedium ein herkömmliches LAN zum Einsatz, das das SCSI-Speicherprotokoll in IP-Frames packt. Im Unterschied zu Fibre Channel, das mit geringer Latenz und ohne Paketverluste arbeitet, können in einem IP-Lan jedoch Frames verloren gehen. Das ist im iSCSI-Protokoll zwar berücksichtigt, dennoch hat die LAN-Architektur einen sehr entscheidenden Einfluss auf die iSCSI-Performance. Dazu ein paar Tipps:

- Zwischen dem iSCSI-Server (Target) und den angebundenen Clients (Initiator) sollten so wenige Switche wie möglich liegen. Jeder Switch verzögert die Paketzustellung (höhere Latenz durch Store-and-Forward). Da ein IP-LAN jedes zugestellte IP-Paket erst einmal von der Gegenstelle quittieren lässt (Acknowledge), bevor es das nächste sendet, verzögert jeder Schritt zwischen Initiator und Target die Performance spürbar.

- Als Storage-Protokoll schickt iSCSI größere Datenmengen über das LAN. Wenn das IP-Protokoll dabei große Pakete nutzen kann, verbessert sich der Durchsatz. Sofern Ihre Netzwerkinfrastruktur Jumbo-Frames unterstützt, sollten Sie diese auch nutzen.

- Beim intensiven Einsatz von iSCSI auch für primäre Disks sollten Sie über ein physisch separiertes zweites Netzwerk nachdenken, das ausschließlich dem Storage-Traffic dient.

Diese Tipps sind für unser Backupszenario nicht ganz so wichtig, da es hier nicht auf das letzte Quäntchen Performance ankommt. Aber vielleicht möchten Sie iSCSI auch für Performance-relevante Funktionen nutzen.

Ein iSCSI-Server wird als "Target" bezeichnet, obwohl das genau genommen nicht exakt stimmt. Das Target ist im Grunde genommen der virtuelle SCSI-Host-Adapter, auf den ein Client – der Initiator – zugreift. Jedes Target verwaltet mehrere LUNs, die eigentlichen virtuellen Platten. Ein Storage-Server kann mehrere Targets parallel betreiben und jedes benötigt dabei mindestens ein "Portal" bestehend aus einer IP-Adresse und einer Port-Nummer (standardmäßig 3260). Mehrere Targets können gemeinsam auf einem Portal arbeiten, können aber auch mehrere Portale verwenden. Nutzt der Initiator ebenfalls mehr als einen IP-Adapter, offeriert iSCSI das sogenannte Multipathing. Es verteilt den Datenverkehr zwischen Ziel und Initiator auf mehrere Adapter und Leitungen. Das verbessert die Performance und sorgt für Ausfallsicherheit.

Ein Backupserver erhält von seinen Clients sehr viele redundante Daten. Daher funktioniert die Deduplikation hier besonders effizient. Im Februar 2020 [1] haben wir die Open-Source-Deduplikationslösung "VDO" für Linux ausführlich vorgestellt. Verfügt Ihr Backupserver über ausreichend CPU-Power und RAM, sollten Sie VDO "unterhalb" des iSCSI-Targets verwenden, um Plattenplatz einzusparen. Die hier beschriebenen Methoden für iSCSI-Targets mit BlockIO oder FileIO funktionieren dabei auf regulären Platten und Disk-Arrays ebenso wie auf deduplizierten VDO-Devices und -Volumes. Je nach den verwendeten Laufwerken und der Performance des Backup-PCs kann die Deduplikation dabei die iSCSI-Performance beeinträchtigen. Das ist allerdings zu verschmerzen, da das Backup in der Regel im Hintergrund des PCs arbeitet und es daher weniger darauf ankommt, ob die Sicherung 20 oder 30 Minuten läuft.

Als Serverhardware für diesen Workshop nutzen wir für den Small-Office-Einsatz einen HP-Microserver der Generation 8, mit vier 2-TByte-S-ATA-Laufwerken im Software-RAID, einer Celeron-CPU und 12 GByte RAM. Eine moderne Variante dieses Setups dürfte um die 700 Euro kosten.

Auf dem Backuprechner läuft das iSCSI-Target, das den angeschlossenen Arbeitsstationen die Platten zur Verfügung stellt. Das Open-Source-Target "LIO" gibt es für jede Linux-Distribution, alternativ existiert mit "TGT" eine weitere iSCSI-Implementierung. TGT verwaltet sich jedoch deutlich schwieriger als LIO. Dieses verwendet als Quellen ganze Platten, Partitionen oder Logical Volumes (BlockIO) beziehungsweise stellt es iSCSI-Disks als Dateien in einem bestehenden Server-Dateisystem dar (FileIO). Zudem erlaubt LIO, bestehende SCSI-Geräte direkt als iSCSI-Devices durchzureichen (RawIO). Der letztere Modus kommt besonders dann zum Einsatz, wenn Unternehmen bestehende SCSI-Tape-Autoloader mit einem alten UW-SCSI-Interface netzwerkfähig machen wollen. Neben iSCSI kann LIO auch als Target für FC-, FCoE oder Storage via Infiniband auftreten. Diese Betriebsmodi behandeln wir in diesem Artikel jedoch nicht.

Block-IO oder File-IO haben beide sowohl Vor- als auch Nachteile. In der Theorie ist BlockIO schneller und benötigt weniger Ressourcen, da es zwischen den iSCSI-Client und den Disks des Servers kein weiteres Dateisystem schaltet wie FileIO. Allerdings fällt die Verwaltung der Backend-LUNs komplexer aus, da der Verwalter hier in der Regel den LVM (Logical Volume Manager) nutzen muss. Die Performance des Targets limitiert auch eher die LAN-Anbindung als das Storage-Backend.

Schauen wir uns zunächst ein Beispiel-Setup für Block-IO von Grund auf an und nehmen dabei an, dass der iSCSI-Server vier 2-TByte-S-ATA-Platten ohne Raid-Controller einsetzt. Alle vier Disks erhalten eine Partition mit dem Typ "fd" für Linux-RAID. Der Multi-Disk-Administrator "mdadm" fügt diese vier Partitionen dann zu einem großen Software-RAID-5 zusammen:

Auf dieses 6 TByte große Device packt VDO jetzt die virtuelle 10-TByte-Disk mit Deduplikation (wie Sie VDO einrichten, beschreibt [1] ausführlich):

Das Dedup-Gerät übergeben Sie dann an den Logical Volume Manager:

Der Volume Group spendieren Sie einen großen Thin-Pool, der die komplette Kapazität nutzen kann:

Innerhalb dieses Thin-Pools erstellen Sie dann die Logical Volumes, die später als iSCSI-LUNs für die Clients dienen:

Das Thin-Provisioning funktioniert in Verbindung mit dem iSCSI-Target nur in Richtung "Wachsen". Selbst wenn das Clientdateisystem das iSCSI-Volume "trimmt". also als gelöscht markierte Blöcke über die SCSI-"Discard"-Funktion zur endgültigen Löschung an das Block-Device übergibt, schrumpft die Backend-LUN nicht. In seiner aktuellen Version unterstützt das LIO-Target leider kein Discard, weder beim File- noch beim Block-IO-Backend.

Beim FileIO-Backend legen Sie auf dem iSCSI-Server zunächst ein großes Dateisystem an. Die Schritte ab "mdadm" bleiben bis einschließlich des VDO-Setups identisch. Danach kommt jedoch ein Dateisystem mit XFS oder BTRFS auf den VDO-Datenträger:

Dieses Volume mounten Sie in ein Verzeichnis Ihrer Wahl, beispielsweise "/var/storage". Dort erstellen Sie dann Image-Dateien, die Sie später via iSCSI als LUNs an die Clients freigeben. Eine Image-Datei für ein 1-TByte-iSCSI-Volume legen Sie so an:

Das dd-Kommando kopiert dabei lediglich einen einzelnen 1-GByte-Block gefüllt mit Nullen in die Datei. Der Parameter "seek" definiert die maximale Anzahl an Blöcken des Images. So wird das Image-File thin provisioned, wächst also erst in dem Moment, in dem der iSCSI-Client tatsächlich Daten schreibt. Daher listet der Befehl ls lun0.bin -lh die Datei "lun0.bin" mit der virtuellen Größe von 1,1 TByte, während das Kommando du -h lun0.bin die tatsächlich belegte Größe von 1 GByte zeigt.

Das FileIO-Backend vereinfacht den Umgang mit den virtuellen Disks gegenüber dem LVM des BlockIO erheblich. Zudem lässt sich das VDO-Laufwerk parallel auch als Datenträger für File-Services oder andere Daten ohne eigene LV-Zuweisungen nutzen.

Komplette Disk-Abbilder lassen sich zudem mit einfachen Dateikommandos verwalten. Wollen Sie beispielsweise Ihren iSCSI-Server auf neue Hardware migrieren, können Sie bestehende LUN-Abbilder einfach per scp- oder rsync-Kommando auf ein neues System übertragen. Zudem bietet sich die Snapshot-Funktion des darunter liegenden XFS- oder BTRFS-Dateisystems an, um alle iSCSI-Disks regelmäßig zu sichern. So etwas geht zwar auch mit Logical Volumes, jedoch sind die Prozeduren und Tools hier komplizierter.

Auf dem Backupserver, der in unserem Fall auf Fedora 33 arbeitet, installieren Sie das LIO-Target via

Dann aktivieren Sie den Target-Dienst:

Außerdem müssen Sie an der Firewall des iSCSI-Servers den iSCSI-Port 3260 öffnen:

Wollen Sie mehrere Targets auf unterschiedlichen Ports betreiben, müssen Sie die entsprechenden Ports ebenfalls öffnen. Da Fedora, CentOS und Co mit aktiviertem SELinux arbeiten, geben Sie alternative Ports auch dort frei, beispielsweise für Port 3261 mit:

Arbeiten Sie mit Ubuntu oder Debian, richten Sie die Pakete über den apt-Paketmanager ein. Ab Debian 9 hat sich dabei aber der Name des targetcli-Pakets ("targetcli-fb") geändert. Auch der Name des Target-Dienstes und das zugehörige Konfigurationsverzeichnis lauten hier anders.

Für die Konfiguration des Targets offeriert LIO mit "targetcli" ein sehr simples Managementtool. Es stellt die Konfiguration wie einen Dateisystembaum dar, durch den Sie mit cd navigieren und via ls die Inhalte der jeweiligen Abschnitte auflisten. Starten Sie das targetcli-Tool und geben sie einfach nur cd ein. Im oberen Abschnitt sehen Sie die "Backstores" wie "block" oder "fileio".

Je nach gewähltem Backend wechseln sie über cd /backstores/block oder cd /backstores/fileio in das gewünschte Backend oder wählen es mit den Pfeiltasten aus der cd-Ansicht aus. Das targetcli-Werkzeug zeigt Ihnen über die Kommandovervollständigung die möglichen Kommandos oder die dazu passenden Parameter an, wenn Sie die Tab-Taste drücken.

Ein Block-Device erstellen sie im Bereich "Block" über:

Ganz ähnlich verfahren Sie beim FileIO-Backend:

Sie müssen nicht gleich am Anfang die vollständige Konfiguration einrichten, denn targetcli erlaubt, neue LUNs im laufenden Betrieb hinzuzufügen.

Das erste iSCSI-Target legen Sie im Unterbaum "iscsi" an. Dazu genügt das cre-ate-Kommando ohne weitere Parameter. LIO erstellt dann ein Target mit dem vorgegebenen "World Wide Name" (WWN) und das Standardportal auf Port 3260, das für alle IP-Adressen des Hosts gilt. Die Namensgebung von iSCSI-Targets und Initiatoren folgt nach einem festen Schema: Alle WWNs beginnen mit "iqn.", gefolgt vom Monat der Domain-Registrierung und dem umgekehrten Domänennamen. Das LIO-Target verwendet per Vorgabe das Präfix "iqn.2003-01.org.linux-iscsi:", während Windows-Systeme mit "iqn.1991-05.com.microsoft:" als Namen beginnen. Nach dem Präfix folgt der Name des Systems und alternativ weitere Informationen wie eine Seriennummer oder eine eindeutige ID.

Es steht Ihnen frei, hier eigene Namen einzusetzen, solange sie sich an das Schema des Prefix bis zum ":" halten. Sie können das Target beispielsweise auch so anlegen:

Legen Sie pro iSCSI-Client jeweils ein Target an. Auch Windows- und Linux-Initiatoren erlauben, die Namen der Clients anzupassen. Der WWN wird später auch dazu verwendet, um den Zugang von Initiatoren zu LUNs einzuschränken. Alternativ gibt es eine Authentisierung via Chap mit Benutzernamen und Passwort. Für simple Setups reicht die WWN-Autorisierung meistens aus.

Unter dem neu erstellten Target erscheint nun die Default-Target-Portal-Group "tpg1". Darunter wiederum stehen drei Unterpunkte: acls, luns und Portals. Letzterer übernimmt die Default-Config 0.0.0.0:3260. Im Verzeichnis "luns" weisen Sie nun dem Portal und damit dem iSCSI-Client eines oder mehrere der zuvor konfigurierten FileIO- oder Block-Devices zu. Für Letzteres per

Oder bei FileIO mit:

Im letzten Schritt konfigurieren Sie in der Abteilung "acls" den Clientzugriff. Dazu brauchen Sie den WWN des gewünschten Clients.

Auf Ihrem Windows-10-Client (oder Windows-Server) tippen Sie in der Suchleiste einfach nur <iscsi> ein. Das Startmenü zeigt daraufhin die App "ISCSI-Initiator", die Sie ausführen. Nun fragt Windows zuerst, ob Sie künftig den bislang abgeschalteten ISCSI-Dienst aktivieren wollen – ohne diesen geht es freilich nicht. Im folgenden Dialog klicken Sie auf den Reiter "Konfiguration" ganz rechts. Dort finden Sie den Initiator-Namen ihres Clients und können ihn auf Wunsch auch ändern.

Zurück im targetcli-Tool des iSCSI-Servers richten Sie nun unter "acls" diesen Initiator als Client ein.

Das Target weist nun automatisch die LUNs diesem Client zu. Sie erscheinen als "mapped_lunX" unterhalb der Client-WWN im targetcli-Tool.

Wiederholen Sie die Schritte für weitere Windows-Clients, so dass am Ende jeder sein eigenes Target und mindestens ein iSCSI-Laufwerk besitzt. An dieser Stelle wäre es ratsam, die aktuelle Konfiguration des Targets zu sichern. Dies erreichen Sie über cd / und anschließend saveconfig. Targetcli sichert Ihre Konfiguration unter "/etc/target" als "saveconfig.json". Bei jeder Konfigurationsänderung legt das Werkzeug zudem eine Kopie der Konfigurationsdatei unter "/etc/target/backup" an, sodass Sie eine Historie der Konfigurationsänderungen erhalten.

Zurück auf Ihrem Windows-System wechseln Sie im iSCSI-Initiator auf den Tab "Suche" und den Button "Portal ermitteln". Dort geben Sie den Namen oder die IP-Adresse Ihres iSCSI-Servers ein. Jetzt erscheinen im Reiter "Ziele" die zuvor angelegten iSCSI-Targets, noch mit dem Status "inaktiv". Klicken Sie bei dem passenden Target auf "Verbinden" und lassen sie die Auswahl "Diese Verbindung der Liste der bevorzugten Ziele hinzufügen" aktiviert. Der Windows-Rechner wird künftig bei jedem Neustart das iSCSI-Volume anbinden. Versuche, sich auf dem Target eines anderen Clients anzumelden, schlagen mit einem Autorisierungsfehler fehl.

Klicken Sie mit der rechten Maustaste auf das Windows-Symbol des Startmenüs und dann auf "Datenträgerverwaltung". Das iSCSI-Laufwerk taucht nun als nicht initialisierte Disk in der Liste auf. Sie können diese Disk wie jedes andere lokale Laufwerk formatieren und anschließend nutzen.

Da der iSCSI-Dienst automatisch startet, stellt der Windows-Client die Verbindung zur Disk her, auch wenn sich kein Nutzer anmeldet. Das vereinfacht automatisierte Backupskripte, die im Hintergrund laufen, gegenüber Lösungen, die SMB als Protokoll verwenden und einen aktiv angemeldeten User brauchen.

Jetzt können Sie die Hausmittel wie das Windows-eigene Sicherungstool einrichten, sodass es regelmäßig im Hintergrund die Daten auf das iSCSI-Laufwerk sichert. Sollte ein gesicherter Win­- dows-Rechner ausfallen, müssen Sie auf dem iSCSI-Target dann nur den WWN des neuen Gerätes anstelle des alten im passenden Target eintragen und der frische PC erhält sofort Zugriff zum iSCSI-Laufwerk seines Vorgängers. Dadurch ist er in der Lage, einzelne Dateien oder auch komplette Verzeichnisse hieraus wiederherzustellen.

Nach der initialen Konfiguration des iSCSI-Servers und der zugehörigen LUNs läuft das Backup der Windows-Systeme unauffällig im Hintergrund, ohne dass der Anwender sich damit auseinandersetzen muss. In praktischen Tests mit mehreren Windows-Systemen und LUNs arbeitete die VDO-Deduplizierung des Backends mit einer Effizienz von stolzen 75 Prozent.

Der Microserver ging im Rahmen unseres Setups etwas in die Knie, schaffte aber weiterhin um die 50 bis 80 MByte/s an Durchsatz auf deduplizierten iSCSI-LUNs mit FileIO-Backend. Das ist immer noch flotter als die meisten USB-Laufwerke. In unseren Versuchen hat sich zudem FileIO als das Backend der Wahl durchgesetzt, weil es simpler und flexibler zu verwalten ist.