Storage. Backup. Virtualisierung.
Netzwerk / LAN Backup · Version 1.9 · © Stor IT Back 2026
Ein LAN-Backup ist eine zentrale Datensicherung, bei der Server, virtuelle Maschinen,
Clients und Anwendungen ihre Sicherungsdaten über das Netzwerk an einen zentralen Backup-Server oder ein Backup-Repository übertragen.
Backup-Jobs, Aufbewahrung, Monitoring und Wiederherstellung lassen sich dadurch zentral verwalten.
Ein LAN-Backup wird auch als Netzwerk-Backup oder Netzwerksicherung bezeichnet.
Es gehört zu den klassischen Verfahren für die zentrale Datensicherung in Unternehmen und lässt sich mit Festplatten, Deduplizierungs-Appliances,
Object Storage, Cloud-Speicher und Tape kombinieren.
Sollen mehrere Server in einem Unternehmen gesichert werden, könnte grundsätzlich jeder Server ein eigenes Backup-Ziel
oder ein eigenes Bandlaufwerk erhalten. Eine solche dezentrale Lösung wird mit wachsender Anzahl der Systeme jedoch schnell teuer und unübersichtlich.
Bei einer zentralen Netzwerksicherung übertragen die Systeme ihre Daten stattdessen über das LAN an eine gemeinsame Backup-Infrastruktur.
Wichtig: Eine Sicherung ausschließlich auf interne Laufwerke des zu sichernden Servers bietet keinen ausreichenden Schutz.
Fällt das gesamte System aus oder wird es durch Ransomware kompromittiert, können auch die dort gespeicherten Backup-Daten verloren gehen.
Das Backup-Ziel sollte deshalb möglichst unabhängig vom Quellsystem betrieben und zusätzlich durch weitere Kopien abgesichert werden.
Der wesentliche Vorteil eines zentralen LAN-Backups ist die gemeinsame Administration aller Sicherungen.
Backup-Jobs können an einer zentralen Stelle geplant, überwacht und ausgewertet werden. Fehlerhafte oder ausgefallene Sicherungen lassen sich dadurch schneller erkennen.
Auch Wiederherstellungen können zentral gestartet werden. Das reduziert den administrativen Aufwand und erleichtert den Aufbau standardisierter Betriebsprozesse.
Eine professionelle Backup-Lösung sollte den Ablauf weitgehend automatisieren. Sicherungen können beispielsweise
nachts oder am Wochenende durchgeführt werden. Über Monitoring, Benachrichtigungen und zentrale Protokolle lässt sich kontrollieren,
ob alle vorgesehenen Systeme erfolgreich gesichert wurden.
Eine zentrale Backup-Infrastruktur ermöglicht außerdem mehrstufige Backup-Verfahren. Daten können zunächst schnell auf Festplatte geschrieben
und anschließend auf ein weiteres Medium kopiert werden, beispielsweise auf ein Bandlaufwerk,
eine Tape-Library oder in die Cloud.
Dadurch lässt sich das eigentliche Backup-Fenster verkürzen. Die nachgelagerte Kopie auf Tape oder zu einem externen Standort kann unabhängig von den produktiven Systemen erfolgen.
Eine typische zentrale Backup-Architektur besteht aus mehreren Komponenten. Die genaue Aufteilung hängt von Datenvolumen, Anzahl der Systeme, Backup-Fenster, Wiederherstellungszielen und Sicherheitsanforderungen ab.
Für Planung und Fehlersuche ist es sinnvoll, die Datenwege eindeutig zu dokumentieren:
Quelle → Netzwerk → Backup-Server / Proxy → Backup-Repository → zweite Kopie / Offsite / Tape
Bei einer zentralen Netzwerksicherung kommt der Backup-Software eine entscheidende Bedeutung zu.
Dabei wird je nach Produkt zwischen zentralen Backup-Servern, Media-Servern, Proxies, Agents und weiteren Komponenten unterschieden.
Nicht jede Backup-Software unterstützt jedes Betriebssystem, jede Anwendung oder jede Virtualisierungsplattform.
Windows, Linux und verbreitete Hypervisoren werden von vielen Produkten unterstützt.
Bei Datenbanken, Spezialanwendungen, älteren Betriebssystemen oder heterogenen IT-Landschaften sollte jedoch genau geprüft werden,
welche Sicherungsmethoden verfügbar sind.
Ein weiterer wichtiger Punkt ist die Bedienbarkeit. Wichtige Einstellungen, Warnungen und Fehler müssen leicht erkennbar sein.
Eine technisch leistungsfähige Backup-Lösung nützt wenig, wenn fehlerhafte Jobs oder falsch konfigurierte Aufbewahrungsregeln im täglichen Betrieb übersehen werden.
Stor IT Back unterstützt Unternehmen bei der Auswahl und Planung geeigneter Backup-Lösungen.
Sprechen Sie uns an, wenn unterschiedliche Backup-Produkte,
Architekturen oder Hersteller verglichen werden sollen.
Bei einem agentbasierten Backup läuft eine Backup-Komponente direkt auf dem zu sichernden System.
Sie kann Daten, Anwendungen und gegebenenfalls deren Konsistenzzustand erfassen und an den Backup-Server übertragen.
Bei einem agentlosen Backup greift die Backup-Software über vorhandene Schnittstellen auf das System zu.
In Virtualisierungsumgebungen werden dafür häufig die APIs des Hypervisors genutzt.
Agentlose Verfahren reduzieren den Verwaltungsaufwand und eignen sich besonders für viele virtuelle Maschinen.
Für Datenbanken oder spezielle Anwendungen können Agents oder anwendungsspezifische Plugins trotzdem erforderlich
oder sinnvoll sein, damit Transaktionen und Anwendungszustände konsistent gesichert werden.
In kleineren Umgebungen richtet sich die Auswahl der Serverhardware zunächst nach den Anforderungen der verwendeten Backup-Software.
Mit steigendem Datenvolumen werden jedoch CPU-Leistung, Arbeitsspeicher, Netzwerkbandbreite und I/O-Leistung zunehmend wichtig.
Komprimierung, Deduplizierung, Verschlüsselung, synthetische Vollsicherungen oder umfangreiche Katalog-
und Suchfunktionen können zusätzliche CPU-, RAM- und Storage-Ressourcen benötigen.
Über zusätzliche Netzwerkkarten kann ein eigenes Backup-Netz oder ein separates VLAN aufgebaut werden.
SAS- oder Fibre-Channel-Adapter ermöglichen die direkte Anbindung von Tape-Libraries oder Storage-Systemen.
Bei sehr hohen Datenraten und vielen parallelen Backup-Streams können Netzwerk, CPU, Arbeitsspeicher, Storage oder angeschlossene Geräte zum Engpass werden.
Größere Backup-Umgebungen verteilen die Last deshalb häufig auf mehrere Media-Server, Proxies oder Backup-Nodes.
Auch ein Backup-Server kann als virtuelle Maschine betrieben werden. Dabei muss allerdings berücksichtigt werden,
dass zusätzliche Backup-Daten über den Hypervisor und dessen Storage- und Netzwerkpfade transportiert werden.
Eine besondere Herausforderung ist die direkte Anbindung einer Tape-Library.
Tape-Systeme verwenden häufig SAS oder
Fibre Channel.
Soll eine solche Hardware direkt von einer virtuellen Maschine verwendet werden, müssen geeignete Passthrough- oder SAN-Verfahren zur Verfügung stehen.
Alternativ lassen sich Tape-Geräte über entsprechende Bridges oder Router über das Netzwerk bereitstellen.
Die notwendige Bandbreite hängt dabei vom verwendeten Tape-Laufwerk, der Datenrate und der Anzahl paralleler Streams ab.
Für leistungsfähige aktuelle Tape-Laufwerke und mehrere parallele Sicherungen sind 10 GbE oder schnellere Netzwerkverbindungen häufig sinnvoll.
Den passenden Backup-Server für Ihre Anforderungen bestimmen wir auf Basis von Datenvolumen, Backup-Fenster,
Restore-Anforderungen und vorhandener Infrastruktur. Wenden Sie sich an uns.
Festplatten- und Flash-basierte Backup-Repositories ermöglichen hohe Sicherungs- und Wiederherstellungsgeschwindigkeiten. Besonders bei häufigen Restores oder kurzen RTO-Vorgaben sind Disk-basierte Backup-Ziele deshalb weit verbreitet.
Eine Virtual Tape Library (VTL) verwendet Festplatten als Speichermedium,
präsentiert sich gegenüber der Backup-Software jedoch wie eine klassische Tape-Library mit virtuellen Bandlaufwerken und virtuellen Medien.
Dadurch können vorhandene Tape-basierte Backup-Prozesse weiterhin genutzt werden,
während die Daten zunächst auf schnellen Festplatten gespeichert werden. Mehrere virtuelle Laufwerke ermöglichen außerdem parallele Backup-Streams.
Tape eignet sich insbesondere für große Datenmengen, lange Aufbewahrungszeiten und Offline-Kopien.
Ausgelagerte Bänder können physisch vom produktiven Netzwerk getrennt werden und dadurch einen wirksamen Air Gap bilden.
Eine häufig eingesetzte Kombination ist die Sicherung auf Festplatte mit anschließender Kopie auf Tape.
Dieses Verfahren wird als Disk-to-Disk-to-Tape (D2D2T) beziehungsweise Backup-to-Disk-to-Tape (B2D2T) bezeichnet.
Object Storage kann lokal im eigenen Rechenzentrum oder über einen Cloud-Anbieter eingesetzt werden.
Je nach Plattform stehen Funktionen wie Versionierung, Object Lock oder unveränderbare Speicherbereiche zur Verfügung.
Bei Cloud- und Object-Storage-Zielen sollten neben Speicherkosten auch Netzwerkbandbreite, Restore-Dauer,
mögliche Transferkosten und Anforderungen an Datenschutz sowie Datenstandort berücksichtigt werden.
Bei einer Netzwerksicherung müssen die Sicherungsdaten innerhalb des verfügbaren Backup-Fensters
vom Quellsystem zum Backup-Ziel übertragen werden. Die theoretische Geschwindigkeit einer Netzwerkverbindung allein reicht deshalb nicht zur Dimensionierung aus.
Als einfache Grundlage kann zunächst der erforderliche Netto-Durchsatz berechnet werden:
Erforderlicher Netto-Durchsatz = zu sicherndes Datenvolumen / verfügbares Backup-Fenster
In der Praxis müssen zusätzliche Faktoren berücksichtigt werden:
Ein vorhandener 10-, 25- oder 100-GbE-Link bedeutet deshalb nicht automatisch, dass diese Datenrate auch vom Backup erreicht wird. Die gesamte Datenkette muss ausreichend dimensioniert sein.
Werden regelmäßig große Datenmengen innerhalb kurzer Zeit gesichert, können Backup und Restore das produktive Netzwerk belasten.
Ein separates Backup-VLAN oder ein physisch getrenntes Backup-Netz kann diese Datenströme vom normalen Client- und Serververkehr trennen.
Ein VLAN sorgt zunächst für eine logische Trennung. Die physische Bandbreite der verwendeten Switches
und Uplinks wird jedoch weiterhin gemeinsam genutzt. Bei besonders hohen Sicherheits- oder Performance-Anforderungen
kann deshalb ein vollständig separates Netzwerk sinnvoll sein.
Weitere Möglichkeiten zur Steuerung des Datenverkehrs sind Bandbreitenlimits, Traffic-Shaping und Quality of Service (QoS).
Komprimierung reduziert die Größe der übertragenen Daten durch eine effizientere Darstellung. Deduplizierung erkennt identische Datenblöcke und speichert sie nur einmal.
Beide Verfahren können Speicherplatz einsparen. Werden sie bereits auf dem Quellsystem oder einem lokalen Proxy durchgeführt,
kann zusätzlich die über das LAN zu übertragende Datenmenge reduziert werden.
Bei einer Source-side-Deduplizierung wird das Netzwerk entlastet, dafür benötigt das Quellsystem zusätzliche Rechenleistung.
Bei einer Target-side-Deduplizierung erfolgt die Verarbeitung erst am Backup-Ziel.
Dadurch wird das Quellsystem entlastet, die ursprüngliche Datenmenge muss jedoch zunächst durch das Netzwerk übertragen werden.
Ein zentraler Backup-Server ist ein besonders wichtiges Ziel für Angreifer. Wird die Backup-Infrastruktur kompromittiert, können Angreifer versuchen, Sicherungen zu löschen oder zu verschlüsseln. Backup-Systeme sollten deshalb nicht ausschließlich durch dieselben Benutzerkonten und Berechtigungen geschützt werden wie die produktiven Systeme.
Eine verbreitete Erweiterung der klassischen 3-2-1-Backup-Regel ist die 3-2-1-1-0-Regel:
Gerade die letzte „0“ ist entscheidend: Ein erfolgreich abgeschlossener Backup-Job allein beweist noch nicht, dass sich die Daten im Notfall vollständig wiederherstellen lassen.
Die Qualität einer Backup-Lösung sollte nicht ausschließlich danach bewertet werden, wie schnell Daten gesichert werden können. Entscheidend ist, ob die benötigten Systeme und Daten innerhalb der geforderten Zeit wiederhergestellt werden können.
Das Recovery Point Objective (RPO) beschreibt, wie viel Datenverlust im Fehlerfall maximal akzeptiert werden kann. Ein RPO von vier Stunden bedeutet beispielsweise, dass im ungünstigsten Fall Änderungen der vergangenen vier Stunden verloren gehen dürfen.
Das Recovery Time Objective (RTO) beschreibt, wie lange die Wiederherstellung eines Systems oder einer Anwendung maximal dauern darf.
RPO und RTO beeinflussen unmittelbar die Backup-Architektur. Sehr kurze RPO- und RTO-Vorgaben stellen höhere Anforderungen an Sicherungshäufigkeit,
Storage-Performance, Netzwerk und Restore-Verfahren.
Ein Backup ist erst dann zuverlässig, wenn die Wiederherstellung regelmäßig getestet wird. Je nach Bedeutung der Systeme können unterschiedliche Tests sinnvoll sein:
Die Ergebnisse sollten dokumentiert werden. Dadurch lässt sich überprüfen, ob die definierten RPO- und RTO-Ziele tatsächlich erreicht werden.
Bei großen Datenmengen kann das Netzwerk zum Engpass werden. Müssen viele Systeme gleichzeitig gesichert werden,
können Backup-Streams produktive Anwendungen beeinträchtigen oder das verfügbare Backup-Fenster überschreiten.
Durch getrennte Backup-Netze, VLANs, Bandbreitensteuerung, inkrementelle Sicherungen,
Deduplizierung und geeignete Backup-Proxies lässt sich diese Belastung reduzieren.
Bei sehr großen Storage-Infrastrukturen können außerdem Verfahren wie LAN-free Backup
oder andere direkt am Storage arbeitende Backup-Methoden sinnvoll sein.
Möchten Sie Ihre vorhandene Backup-Infrastruktur bewerten oder eine zentrale Netzwerksicherung neu planen? Sprechen Sie uns an.
Ein LAN-Backup ist eine zentrale Datensicherung über das Netzwerk. Server, virtuelle Maschinen, Clients oder Anwendungen übertragen ihre Sicherungsdaten über das LAN an einen Backup-Server, eine Backup-Appliance oder ein zentrales Backup-Repository. Dadurch können Backup-Jobs, Monitoring, Aufbewahrung und Wiederherstellung zentral verwaltet werden.
Eine zentrale Netzwerksicherung reduziert den administrativen Aufwand und ermöglicht ein gemeinsames Monitoring aller Backup-Jobs. Statt für jedes System eine eigene Backup-Infrastruktur zu betreiben, können viele Server und Anwendungen auf gemeinsame Backup-Ressourcen zugreifen. Gleichzeitig lassen sich Aufbewahrung, Reporting und Restore-Verfahren standardisieren.
Ein Backup speichert mehrere Datenstände über einen definierten Zeitraum, während eine Replikation Daten in erster Linie auf ein zweites System kopiert. Werden Dateien versehentlich gelöscht oder durch Ransomware verschlüsselt, können diese Änderungen auch auf ein Replikat übertragen werden. Replikation kann die Verfügbarkeit erhöhen, ersetzt aber keine versionierte Datensicherung.
Typische Komponenten sind Backup-Server oder Backup-Appliance, Backup-Software, Agents oder Proxies sowie ein Backup-Repository. Als Speicherziele können Disk, Deduplizierungs-Storage, Object Storage, Cloud oder Tape eingesetzt werden. Größere Umgebungen verwenden häufig zusätzlich eigene Backup-VLANs, Media-Server und Offsite-Kopien.
Bei einem agentbasierten Backup läuft eine Backup-Komponente direkt auf dem zu sichernden System; bei einem agentlosen Backup erfolgt der Zugriff über vorhandene Schnittstellen. In Virtualisierungsumgebungen können beispielsweise Hypervisor-APIs verwendet werden. Für Datenbanken und spezielle Anwendungen können Agents oder anwendungsspezifische Plugins trotzdem sinnvoll oder erforderlich sein.
Disk-basierte Repositories ermöglichen schnelle Backups und Restores. Tape eignet sich besonders für große Datenmengen, lange Aufbewahrung und physisch getrennte Offline-Kopien. Object Storage lässt sich gut skalieren und kann je nach Plattform Funktionen für unveränderbare Daten bereitstellen. In der Praxis werden häufig mehrere Speicherarten miteinander kombiniert.
Eine Virtual Tape Library (VTL) speichert Daten auf Festplatten oder einem anderen Disk-basierten Storage, präsentiert sich gegenüber der Backup-Software jedoch wie eine klassische Tape-Library. Dadurch können Tape-orientierte Backup-Prozesse weiterverwendet und gleichzeitig schnelle Disk-basierte Sicherungen genutzt werden.
Backup-Zeitfenster und Bandbreite sollten anhand des tatsächlich zu übertragenden Datenvolumens dimensioniert werden. Inkrementelle Sicherungen, Source-side-Deduplizierung, Bandbreitenlimits, eigene Backup-VLANs, Traffic-Shaping und lokale Proxies können das produktive Netzwerk entlasten. Entscheidend ist außerdem, dass Quell-Storage und Backup-Repository die benötigte Datenrate verarbeiten können.
Ein separates Backup-VLAN oder Backup-Netz ist sinnvoll, wenn große Datenmengen innerhalb kurzer Backup-Fenster übertragen werden müssen oder Backup und Restore den produktiven Netzwerkverkehr beeinträchtigen. Ein VLAN bietet eine logische Trennung, während ein physisch separates Netzwerk zusätzlich eigene Bandbreite und eine stärkere Isolation bereitstellen kann.
Komprimierung reduziert die Größe der gespeicherten Daten, während Deduplizierung identische Datenblöcke erkennt und nur einmal speichert. Erfolgt die Deduplizierung bereits an der Quelle, kann zusätzlich der Netzwerkverkehr reduziert werden. Dafür wird auf dem Quellsystem oder Backup-Proxy zusätzliche Rechenleistung benötigt.
Backup-Systeme sollten getrennte Administrationskonten, Multi-Faktor-Authentifizierung und möglichst unveränderbare Backup-Ziele verwenden. Zusätzlich sind Offline- oder Air-Gap-Kopien sinnvoll. Besonders wichtig ist, dass ein kompromittiertes Administratorkonto der Produktionsumgebung nicht automatisch das Löschen sämtlicher Sicherungen ermöglicht.
Die 3-2-1-1-0-Regel empfiehlt drei Kopien der Daten auf mindestens zwei unterschiedlichen Speicherarten. Eine Kopie sollte an einem anderen Standort liegen, eine weitere Kopie offline, air-gapped oder unveränderbar sein. Die Null steht für null ungeprüfte Fehler nach regelmäßigen Backup- und Restore-Tests.
Das Recovery Point Objective (RPO) beschreibt den maximal akzeptierten Datenverlust, während das Recovery Time Objective (RTO) festlegt, innerhalb welcher Zeit ein System oder eine Anwendung wieder verfügbar sein soll. Beide Werte sind wichtige Grundlagen für die Dimensionierung einer Backup- und Recovery-Lösung.
Backups sollten regelmäßig durch echte Wiederherstellungen geprüft werden. Dazu gehören einzelne Dateien ebenso wie komplette virtuelle Maschinen, Server und Anwendungen. Für geschäftskritische Systeme sollten außerdem größere Restore- oder Disaster-Recovery-Tests durchgeführt und die benötigten Wiederherstellungszeiten dokumentiert werden.
Typische Fehler sind zu kleine Backup-Fenster, unzureichende Netzwerkbandbreite, langsame Backup-Repositories, fehlende Überwachung und unklare Verantwortlichkeiten. Ebenfalls kritisch sind Sicherungen, die zwar erfolgreich protokolliert werden, deren Wiederherstellung aber nie getestet wurde. Deshalb sollten Backup und Restore gemeinsam geplant und überwacht werden.
