Netzwerk / LAN Backup V1.8 (c) Stor IT Back 2026
Sollen mehrere Server in einem Unternehmen
gesichert werden, so benötigt entweder jeder Server sein eigenes Backup-Ziel oder Bandlaufwerk (lokale Datensicherung),
oder alle werden zentral über einen Backupserver gesichert. Ein Bandlaufwerk bzw. ein Backup-Storage für jeden Server wird
sicherlich sehr schnell viel zu teuer und zu unübersichtlich. Scheidet also in den meisten Fällen aus.
Hinweis: Die Sicherung eines jeden Servers auf interne Platten des eigenen Servers ist nicht sinnvoll, da bei
Ausfall des Gesamtsystems auch die Backup-Daten verloren sind. Das Backup-Ziel muss möglichst unabhängig vom Quell-System sein.
Diese Methode mit der zentralen Sicherung über das Netzwerk wird Netzwerk Backup oder LAN Sicherung genannt,
die am häufigsten in Unternehmen verwendete Datensicherung. Vorteil dieses Verfahrens sind nicht
nur die eingesparten Bandlaufwerke, sondern vielmehr der Gewinn durch
zusätzliche Sicherheit und Einsparung an Administrationskosten (Automatisierung) beim Backup.
Alle Server werden zentral verwaltet, ein fehlendes Backup wird leichter festgestellt
und ein Restore kann zentral durchgeführt werden. Dies schlägt sich auch im
Arbeitsaufwand der Administratoren nieder.
Bei einem zentralen Netzwerkbackup (LAN Backup) sollte eine Automatisierung des Ablaufes
vorgenommen werden. Es wird weniger Personal für das Handling benötigt und die
Vorgänge können in der Nacht oder am Wochenende durchgeführt werden.
Der allgemeine Aufbau eines Netzwerkbackup ist aus der Skizze
ersichtlich.
Neben der Einsparung an Ressourcen sind auch ganz neue Möglichkeiten zur
Sicherung gegeben. So kann zum Beispiel zuerst auf die Festplatte des Backup-Servers
gesichert werden, später dann von dieser Festplatte auf das angeschlossene
Bandlaufwerk oder in die Cloud. Damit kann die Datensicherung wesentlich schneller durchgeführt
werden, das kostbare Backupfenster wird geschont, da der Transfer auf eine Platte
meist sehr viel performanter ist.
Weiterhin kann der Backup-Server in einem zweiten Brandabschnitt oder Standort
aufgestellt werden. Ist die Sicherung auf dem Backupserver angekommen (egal
ob auf Festplatte, Cloud oder Bandlaufwerk), so ist die erste Vorsorge für den
Katastrophen-Fall getroffen.
Eine wichtige Bedeutung
kommt beim Netzwerkbackup der Backupsoftware zu. Hierbei wird zwischen der Server-Software
und den Backupclients unterschieden.
Nicht jede Software unterstützt jedes Betriebssystem. Windows, Linux und VMware sind meist kein Problem.
Es gibt hier besonders Einschränkungen und Voraussetzungen bei der Backup-Server-Software, aber auch bei
Clients wird nicht jedes Betriebssystem und jeder Anwendung unterstützt. In heterogenen IT-Landschaften
sollte deshalb immer auf die namhaften Hersteller mit großer Unterstützung zurückgegriffen
werden, man weiß ja nie, welches Betriebssystem noch ins Haus kommt. Wir zeigen
Ihnen die Unterschiede der einzelnen Hersteller auf und beraten Sie zur Auswahl des geeigneten
Produktes.
Auch die Bedienung der Software ist sehr wichtig, je einfacher und
übersichtlicher, desto sicherer ist der Betrieb zu gewährleisten. Stehen wichtige Einstellung in nicht direkt sichtbaren Tabs, so können
die schnell vergessen werden. Das führt im Zweifelsfalle zu fehlerhaften Sicherungen, die nicht sofort erkannt werden.
In
kleineren Umgebungen ist die Auswahl der Serverhardware primär vom
Betriebssystem abhängig. Jedoch wird bei steigendem Datenvolumen auch
Prozessorleistung und Memory immer wichtiger. Müssen die Daten
komprimiert oder umfangreiche Suchfunktionen durchgeführt werden, so
steigen die Anforderungen immer weiter.
Zusätzliche Aufrüstungen können durch Netzwerkkarten und SAS-Adapter vorgenommen werden. Es kann zum
Beispiel ein eigenes LAN für Backupfunktionen aufgebaut werden, um die Clients nicht während Sicherungen oder Restores zu behindern. Für eine
zusätzliche Tape-Library oder ein Sicherungs-Platten-Storage nutzt man dann die SAS Adapter. Ab einem bestimmten
Transfervolumen wird aber ein PCIe-Bus nicht mehr ausreichen, es muss ein weiterer
Server angeschafft werden, um z.B. einzelne Funktionen auszulagern.
Eine Besonderheit sind virtuelle Backup-Server, also der Server der das Backup durchführt ist eine virtuelle Maschine. Ein klar ersichtlicher Nachteil
ist die zusätzliche IO-Belastung durch die Backup-Daten. Im schlimmsten Fall gehen doppelt so viele Daten durch den Hypervisor und das auch noch
zur gleichen Zeit. Was auch zu beachten ist: Wie bekommt man die Tape-Library an die virtuelle
Maschine angeschlossen? Die Tape-Library hat SAS oder
Fibre Channel Schnittstellen und diese müssen direkt in die VM geleitet werden (als RAW Device).
Das ist meist nicht so einfach (wenn überhaupt) möglich. Alternativ kann auch iSCSI eingesetzt werden, jedoch
benötigt die Library dann einen iSCSI auf SAS Router und unter 10 Gbit/s LAN ist es nicht möglich.
Den richtigen Server für Ihre Anforderungen
bestimmen wir durch eine IST-Analyse, wenden Sie sich an uns.
Die Tape-Library muss dem
Daten- und Transfervolumen angepasst werden. Diese Größen richten sich nach dem
Volumen Ihrer aktiven Daten und dem Backupfenster. Hieraus lassen sich mit Hilfe
Ihrer aktuellen Anforderungen und einer Hochrechnung über Statistiken die Basisdaten
errechnen und die passende Hardware auswählen.
Aber eine klassische Tape-Library
ist nicht die einzige Sicherungshardware. Auch Festplatten sind beim Disk-to-Disk-Backup
eine nutzbare Backup-Hardware. Eine Erweiterung sind Libraries, die statt auf
Bänder auf Festplatten sichern. Von außen, für die Backupsoftware,
wie eine klassische Tape-Library und gesichert wird auf schnelle Festplatten.
Der große Vorteil sind viele Laufwerke (und damit viele Backup-Streams
parallel), bei geringen Kosten.
Eine ideale Kombination zur Tape-Library sind Festplatten
zur schnellen Sicherung und das Band für große Datenmengen und externe
Auslagerungen. Diese zweistufigen Prozesse (B2D2T, Backup to Disk to Tape) erhöhen Performance und Sicherheit.
Der wichtigste Vorteil ist die zentrale
Datensicherung (LAN Backup) aller Server eines Unternehmens. Hiermit wird die Überwachung und
Administration des Backup-Vorganges erleichtert. Es sind zentrale Logs und
Auswertungsmöglichkeiten vorhanden, so dass fehlerhafte Vorgänge sofort erkannt
werden können. Auch ist mit dieser Funktion (der Backup-Admin) eine "Gewaltenteilung" in der
Datenhaltung möglich. Ist System- und Backupadministrator nicht die gleiche
Person, so können rechtliche Vorgaben verbessert eingehalten werden.
Die Nachteile kommen erst bei großen Datenmengen zum Vorschein. Da alle Daten
über das LAN transportiert werden müssen, können die Antwortzeiten für Anwender
während der Backupzeiten stark ansteigen. Es kann sogar zu Abbrüchen in Transaktionen
kommen. Das LAN wird dann zum Nadelöhr und das Backupfenster reicht nicht
mehr aus. Lösungsmöglichkeiten sind LANfree
und Serverless Backup.
Möchten Sie weiter zu den Vor- und Nachteilen der einzelnen Backupverfahren informiert werden, so wenden Sie sich an uns.
Was bedeutet Backup über das LAN und warum ist es im Unternehmen so verbreitet?
Backup über das LAN heißt: Server, Clients oder Anwendungen senden ihre Sicherungsdaten über das Unternehmensnetzwerk an ein zentrales Backup-Ziel (z.B. Backup-Server, Storage-System, Backup-Appliance). Das ist verbreitet, weil es zentral administrierbar ist und keine separaten Backup-Netze zwingend nötig sind. Im Rechenzentrum lässt sich so eine einheitliche Sicherungsplattform aufbauen, die mehrere Standorte oder VLANs bedienen kann. Für Entscheider ist wichtig: Zentralisierung vereinfacht Prozesse, kann aber das LAN belasten, wenn Planung und Zeitfenster fehlen.
Wie unterscheidet sich Backup von Replikation und wann brauche ich was?
Backup ist eine Versionierung: Es speichert mehrere Stände über die Zeit, sodass man auch von gestern oder vor dem Angriff zurück kann.
Replikation kopiert Daten oft nahezu in Echtzeit auf ein zweites System, schützt aber nicht automatisch vor logischen Fehlern
(z.B. verschlüsselte oder gelöschte Daten werden mit repliziert). Für hohe Verfügbarkeit kann Replikation sinnvoll sein,
aber sie ersetzt kein Backup.
Praxisbeispiel: Bei Ransomware ist ein unveränderbares (immutable) Backup häufig der Rettungsanker, während Replikate ebenfalls betroffen sein können.
Welche Komponenten gehören typischerweise zu einer zentralen Backup-Lösung über das LAN?
Üblich sind ein Backup-Server oder eine Backup-Appliance, Backup-Software, ein Backup-Repository (Storage: Disk, Dedupe-Storage, Object Storage)
und Agents/Connectoren auf den zu sichernden Systemen. Im Rechenzentrum kommen oft zusätzliche Bausteine dazu: separate Backup-Netzsegmente/VLANs,
Proxy-Systeme für Virtualisierung und ggf. ein Offsite-Ziel (zweites RZ oder Cloud).
Entscheider sollten auf ein klares Rollenmodell achten: Wer steuert den Job? Wo liegen die Daten? Wo werden sie aufbewahrt?
Tipp: Dokumentieren Sie die Datenflüsse (Quelle → Transport → Ziel), damit Performance- und Sicherheitsfragen sauber beantwortet werden können.
Was ist der Unterschied zwischen agentbasiertem Backup und agentlos und was ist wann empfehlenswert?
Agentbasiert heißt: Ein kleines Programm auf dem System sammelt Daten konsistent ein (inkl. Applikationszustand) und sendet sie ins Backup.
Agentlos bedeutet oft: Die Backup-Software greift über Schnittstellen (z. B. Hypervisor-APIs) zu, ohne auf jedem System einen Agent zu installieren.
Agentlos ist administrativ oft einfacher, kann aber bei speziellen Anwendungen (Datenbanken, bestimmte Dienste) weniger fein steuerbar sein.
Empfehlung: In Virtualisierungsumgebungen ist agentlos häufig ein guter Standard, für geschäftskritische Datenbanken sind applikationsnahe Methoden
(oft agentbasiert oder mit DB-Plugins) meist zuverlässiger.
Welche Backup-Ziele sind sinnvoll: Disk, Tape, Object Storage und wie entscheidet man?
Disk-basierte Repositories sind schnell für Backups und vor allem Restores, daher sind sie im Alltag meist erste Wahl.
Tape ist weiterhin attraktiv für sehr lange Aufbewahrung und Air Gap (physische Trennung), braucht aber Prozesse und Handling.
Object Storage (on-prem oder Cloud) eignet sich gut für Skalierung und Unveränderbarkeit (je nach System),
kann aber Restore-Zeiten beeinflussen und benötigt saubere Kostenkontrolle.
Praxisstrategie: Disk für schnelle Wiederherstellung + zweite Kopie auf Tape oder Object Storage für Langzeit/Offsite ist häufig robust.
Wie verhindere ich, dass Backups das Unternehmensnetzwerk ausbremsen?
Planen Sie Bandbreite und Zeitfenster bewusst: Backups sollten möglichst in Zeiten niedriger Last laufen oder priorisiert/limitiert werden.
Technische Mittel sind z.B. Bandbreitenbegrenzung pro Job, getrennte VLANs, Traffic-Shaping/QoS (Quality of Service) und lokale
Proxy-Systeme nahe am Storage. Auch die Backup-Methode hilft: Inkrementelle Sicherungen und Deduplizierung reduzieren Datenvolumen, das durchs LAN muss.
Konkreter Tipp: Messen Sie reale Durchsätze pro Segment und rechnen Sie rückwärts, ob Ihr Backup-Fenster realistisch ist (statt nur 10G ist vorhanden anzunehmen).
Was bringen Deduplizierung und Komprimierung und wo sollte das passieren?
Komprimierung reduziert Daten durch Zusammenpressen, Deduplizierung entfernt doppelte Datenblöcke (z. B. bei vielen ähnlichen VMs).
Beides spart Speicher und oft auch Netzwerkverkehr. aber es kostet CPU, je nachdem, wo es passiert. Source-side (an der Quelle) spart LAN-Bandbreite,
belastet aber die Quellsysteme. Target-side entlastet die Quelle, spart aber weniger Netzwerk.
Praxisbeispiel: Viele Außenstellen profitieren stark von Source-side-Dedupe, während ein Rechenzentrum mit starkem Backbone eher Target-side-Dedupe bevorzugen kann.
Wie schütze ich LAN-Backups vor Ransomware und Insider-Risiken?
Wichtig sind getrennte Berechtigungen (Backup-Admins ≠ Domain-Admins), starke Authentifizierung (MFA) und möglichst ein Backup-Ziel, das nicht einfach löschbar ist.
Immutable Backups (unveränderbare Sicherungen für eine definierte Zeit) sind ein zentraler Baustein,
ebenso wie Offline- oder Air-Gap-Kopien (z.B. Tape oder isolierte Storage-Tiers). Zusätzlich sollten Backup-Server und Repositories gehärtet werden
(Patch-Management, eingeschränkte Admin-Zugriffe, separate Management-Netze).
Konkreter Tipp: Simulieren Sie einen Ransomware-Fall als Übung: Welche Credentials wären kompromittiert, und was bleibt dann noch sicher?
Wie stelle ich sicher, dass Backups auch wirklich wiederherstellbar sind?
Ein Backup ist erst gut, wenn der Restore regelmäßig getestet wurde. Das umfasst Stichproben (Dateien),
komplette VM-/Server-Restores und anwendungsnahe Tests (z.B. Datenbank-Consistency). Sinnvoll ist ein wiederkehrender Testplan:
monatlich kleine Restores, quartalsweise größere Szenarien, jährlich ein Notfalltest mit Zeitmessung (RTO).
Tipp: Dokumentieren Sie Restore-Schritte so, dass auch ein Vertretungsteam sie ausführen kann, im Krisenfall fehlt oft genau die Person, die alles weiß und kann.
Welche typischen Fehler passieren bei Backup über das LAN und wie vermeide ich sie?
Häufige Fehler sind zu kleine Backup-Fenster, fehlende Segmentierung (Backups laufen durchs gleiche Netz wie produktive Spitzenlast)
und ein Repository, das beim Restore zu langsam ist. Ebenfalls kritisch: unklare Verantwortlichkeiten (wer reagiert auf Fehler?),
zu viele Ausnahmen (dieser Server ist special) und fehlendes Monitoring. Vermeidung heißt: Kapazitätsplanung (Datenwachstum),
klare Betriebsprozesse (Alarmierung, Eskalation), und ein Architektur-Design, das Restore priorisiert.
Merksatz: Backups sind wichtig, aber Restores sind entscheidend.
Wann lohnt sich ein separates Backup-Netz oder ein eigenes VLAN?
Wenn Backups regelmäßig das produktive Netz spürbar beeinflussen oder wenn viele Daten über kurze Zeitfenster bewegt werden müssen,
ist ein eigenes VLAN oder ein separates Backup-Netz oft sinnvoll. Es erhöht Planbarkeit und reduziert das Risiko,
dass ein Restore nebenbei das Tagesgeschäft stört. In großen Umgebungen kann auch ein separates Management-Netz für Backup-Komponenten
Sicherheit und Stabilität verbessern.
Tipp: Starten Sie pragmatisch mit VLAN-Trennung und Bandbreitenlimits; ein komplett physisch getrenntes Netz ist nicht immer nötig,
aber in sehr kritischen Umgebungen ein starkes Argument.
