Veeam Hardened Repository: Anforderungen, Einrichtung in Version 13.1 und die Fehler, die es schwächen

Was ein Veeam Hardened Repository in Version 13.1 braucht

Ein Veeam Hardened Repository braucht einen Linux-Server mit Blockspeicher, Backup-Ketten, die eine einmal geschriebene Datei nie wieder umschreiben (Forward Incremental mit periodischen Vollsicherungen), und keinen administrativen Weg zu Root-Rechten auf diesem Server, sobald er Backups enthält. In Veeam Backup & Replication 13.1, der aktuellen Version (Stand Oktober 2026), nennt Veeams Benutzerhandbuch die Veeam Infrastructure Appliance „die empfohlene Option“: ein von Veeam gebautes Linux-Image, auf dem Sie die Rolle Veeam Hardened Repository auswählen; ein so gebautes Repository muss zertifikatsbasierte Authentifizierung verwenden und ist über SSH nicht erreichbar. Für die Dauer des Immutability-Zeitraums, den Sie einstellen, können Backup-Dateien „nicht verschoben, geändert oder gelöscht, aber kopiert werden“.

Version 13.1 ist seit dem 29. Juli 2026 verfügbar. Veeams Download-Seite führt Build 13.1.1.18 vom 8. September 2026 als neuesten Build. Wie die Sperre auf jede Datei gesetzt wird, welche Grenzen für den Zeitraum gelten und was Immutability nicht aufhält, steht in unserem Leitfaden dazu, wovor ein unveränderliches Backup schützt.

Was sich von 12.3 zu 13.0 und 13.1 geändert hat

Bis Version 12.3 war ein Hardened Repository ein Linux-Server, den Sie selbst installierten oder aus Veeams Hardened-Repository-ISO bauten. Veeam stellte seinen Data Mover dort mit Einmal-Zugangsdaten bereit, die nur dieser Bereitstellung dienen. Veeams Sicherheitsleitfaden (Security Best Practice Guide) gibt dem Dienstkonto für diesen Schritt vorübergehend sudo-Rechte und weist den Administrator dann an, „SSH dauerhaft zu deaktivieren und dem Konto veeamsvc das SUDO-Recht zu entziehen“. Version 13.0 brachte die Veeam Infrastructure Appliance, ein bootfähiges „JeOS (Just Enough Operating System) ISO“ mit nur den Diensten, die Veeam-Rollen brauchen.

Veeam Help Center: Benutzerhandbuch zu Backup & Replication 13.1, What’s New in 13.1 (24. Juli und 11. August 2026), archivierte Benutzerhandbücher zu 13.0.2 und 12; Veeam Security Best Practice Guide.

Der Governance-Modus, neu in 13.1, ist für Linux-Repositories gedacht, die in Veeams Worten „die Flexibilität, Backups auf Ebene des Systemadministrators zu löschen“ behalten wollen, und ein Repository in diesem Modus darf Rollen übernehmen, die ein Hardened Repository nicht zulässt. Ein Administrator dieses Linux-Servers kann Backups weiterhin entfernen; wo die Bedrohung ein gestohlenes Administratorkonto ist, ersetzt der Governance-Modus deshalb kein Hardened Repository.

Einrichtung: Appliance, selbst gebauter Linux-Server oder VM

Für die Appliance gibt Veeams Benutzerhandbuch diese Reihenfolge vor:

1. Binden Sie das ISO-Image ein, wählen Sie die Art der Bereitstellung, starten Sie die Installation und akzeptieren Sie die Lizenzvereinbarungen.
2. Wählen Sie im Assistenten Initial Configuration die Rolle Veeam Hardened Repository, legen Sie den Hostnamen fest und prüfen Sie die Netzwerkeinstellungen.
3. Fügen Sie im Schritt Time NTP- oder NTS-Server hinzu, die Sie kontrollieren; voreingestellt ist time.nist.gov, und Veeam weist darauf hin, dass die Serverzeit die Multi-Faktor-Authentifizierung und die Job-Zeitpläne beeinflusst.
4. Richten Sie die Konten des Host-Administrators (veeamadmin) und des Security Officers (veeamso) für zwei verschiedene Personen ein, beide mit MFA.
5. Fügen Sie das Repository in der Backup-Konsole hinzu, legen Sie im Schritt Repository den Pfad und den Immutability-Zeitraum fest und deaktivieren Sie dann die Web UI der Host Management console, wie Veeam nachdrücklich empfiehlt; auf einem Hardened Repository aus der Appliance schaltet sie sich 24 Stunden nach dem Aktivieren selbst ab.

Das Benutzerhandbuch zu 13.1 dokumentiert weiterhin einen Server, den Sie selbst konfigurieren; er muss die Systemanforderungen an Backup-Repositories für Ihren genauen Build erfüllen, prüfen Sie die dortige Liste der Distributionen also vor jedem Upgrade. Veeams Sicherheitsleitfaden, geschrieben für Version 12, nennt für eine manuelle Installation Rocky Linux oder Red Hat, wobei auch Ubuntu oder SUSE möglich sind. Auch ein Linux-basierter Backup-Server kann unveränderliche Backups aufnehmen, doch Veeam warnt, dass dies „die Angriffsfläche Ihrer Backup-Infrastruktur vergrößert“.

Im Handbuch zu Version 12 schrieb Veeam: „Um die Angriffsfläche zu verringern, verwenden Sie eine physische Maschine mit lokalem Speicher.“ Der Hardware-Leitfaden eines Veeam-Produktmanagers, aktualisiert am 25. Februar 2026, empfiehlt einen Server mit internen Platten; damit entfällt das Risiko, dass ein Angreifer alles auf einem Speichersystem löscht. Die Appliance kann als virtuelle Maschine laufen (die Release Notes zu 13.1 führen ein bekanntes Problem bei solchen VMs auf), doch ein solches Repository ist nur so sicher wie die Hypervisor-Konten, die seine Platten löschen können; darum geht es in unserem Leitfaden dazu, wie Sie ESXi und vCenter vor Ransomware schützen.

Platten, RAID und das Dateisystem XFS

Veeams Hardware-Leitfaden verlangt getrennte Platten für Betriebssystem und Daten, SSDs für das Betriebssystem, einen RAID-Controller mit batteriegepuffertem Write-back-Cache sowie redundante Stromversorgung und Netzwerkanbindung. Für die Datenplatten nennt er RAID 6 oder 60 mit mindestens einer Ersatzplatte, nach seinen Angaben die Wahl der meisten Kunden gegenüber RAID 10, und er schließt RAID 5, 50 und andere Layouts mit einfacher Parität aus. Veeams Best-Practice-Leitfaden rät zu Volumes von bis zu 500 TB, die zu höchstens 80 Prozent gefüllt werden.

Derselbe Leitfaden empfiehlt XFS mit einer Blockgröße von 4 KB, weil XFS sowohl Fast Clone als auch Immutability unterstützt. Fast Clone erstellt eine synthetische Vollsicherung, indem es auf vorhandene Datenblöcke verweist, statt sie zu kopieren. Auf XFS stützt es sich auf reflink, das laut der Manpage von mkfs.xfs standardmäßig aktiviert ist und crc=1 voraussetzt, ebenfalls die Voreinstellung. Einem früher oder mit anderen Optionen formatierten Volume kann es fehlen; prüfen Sie deshalb vor dem ersten Backup mit xfs_info auf dem Mountpoint, ob reflink=1 gesetzt ist.

Ein Veeam-Produktmanager erklärte im Januar 2022 in einem Thread der R&D Forums, dass aktive Vollsicherungen Fast Clone nicht nutzen und dass Ketten, die aus einem anderen Repository herüberkopiert wurden, zuerst eine aktive Vollsicherung oder eine Compact-Operation für die Backup-Datei brauchen. Bis dahin werden synthetische Vollsicherungen auf einer migrierten Kette vollständig geschrieben.

Backup-Modi und Job-Einstellungen, die Immutability zulässt

Eine gesperrte Datei lässt sich nicht umschreiben, deshalb akzeptiert Veeam nur Backup-Methoden, die eine Datei nach dem Lauf, der sie geschrieben hat, nie mehr ändern: für Backup-Jobs Forward Incremental mit periodischen synthetischen oder aktiven Vollsicherungen. Forever Forward Incremental führt das älteste Inkrement mit der Vollsicherung zusammen, sobald die Aufbewahrung erreicht ist, und Reverse Incremental schreibt die Vollsicherung bei jedem Lauf um. Ein Beitrag eines Veeam Technical Account Managers im Community Hub (17. Juni 2026) zitiert die Meldung des Assistenten für einen Job mit Forever Forward Incremental: „Immutable backups feature requires the usage of forward incremental backup mode with periodic fulls.“ Planen Sie in den erweiterten Einstellungen des Jobs periodische synthetische Vollsicherungen ein, die auf XFS mit Fast Clone wenig Platz kosten, oder aktive Vollsicherungen. Laut demselben Beitrag lässt sich Reverse Incremental in Version 13 nicht mehr konfigurieren.

Backup-Copy-Jobs laufen standardmäßig als Forever Forward Incremental und melden, wenn sie ohne GFS auf ein Hardened Repository zielen: „Immutable backups feature requires the GFS retention policy enabled in the Backup Copy job settings.“ Seit Version 11 stellt GFS einen Copy-Job auf Forward Incremental mit synthetischen Vollsicherungen um, und ein Veeam-Produktmanager bestätigte in den R&D Forums, dass wöchentliches GFS genügt. Version 13.1 erlaubt außerdem, das Konfigurations-Backup des Backup-Servers auf einem Hardened Repository zu sperren, sodass ein Angreifer, der den Backup-Server übernimmt, das Backup nicht löschen kann, aus dem Sie den Server neu aufbauen würden.

Fehler, die ein Hardened Repository schwächen

Die Sperre ist das Linux-Attribut „immutable“, und die Manpage von chattr sagt, wer es kontrolliert: „Nur der Superuser oder ein Prozess mit der Capability CAP_LINUX_IMMUTABLE kann dieses Attribut setzen oder entfernen.“

Veeam Help Center: Benutzerhandbuch zu 13.1 und What’s New in 13.1; Best-Practice-Leitfäden von Veeam zu Security und zu Backup & Replication; Veeam-Hardware-Leitfaden (aktualisiert am 25. Februar 2026); Manpages chattr(1) und mkfs.xfs(8).

Ein Repository bleibt eine einzige Fehlerdomäne; halten Sie deshalb eine zweite Kopie an einem anderen Ort vor, wie es die 3-2-1-1-0-Backup-Regel beschreibt, und lassen Sie nach dem Aufbau den Security & Compliance Analyzer der Konsole laufen.

Unser Assessment von Security und Backup prüft Infrastruktur, Zugriffe und Backups und endet mit einer Risikokarte und einem priorisierten Maßnahmenplan. Beschreiben Sie im Formular unten, wie Ihr Repository aufgebaut ist und wer es erreichen kann.

Was jemand an der Konsole oder am BMC noch tun kann

Das Attribut „immutable“ ist eine logische Kontrolle innerhalb des Betriebssystems, und Veeams Sicherheitsleitfaden nennt ein unveränderliches Dateisystem „nutzlos“, wenn das System „auf einer tieferen Ebene gelöscht werden kann“. An der Tastatur kann jemand in den Single-User-Modus booten, um eine Root-Shell zu bekommen, weshalb der Leitfaden ein GRUB-Passwort vorschlägt, oder ein anderes Betriebssystem von externen Medien starten und die Platten neu formatieren. Eine Remote-Konsole des BMC mit virtuellen Medien leistet dasselbe von jedem Punkt in dessen Netz aus.

Der Hardware-Leitfaden nutzt den BMC für den Status von Platten und RAID und für E-Mail-Alarme über ausgefallene Platten, erlaubt aber auch, das Kabel vom BMC-Port abzuziehen; die Alarme verschickt dann Software auf dem Betriebssystem. Prüfen Sie auf der Appliance, welche Alarme sie verschicken kann, bevor Sie den BMC vom Netz trennen. Als „Kompromiss“ schlägt der Leitfaden eine Firewall vor dem BMC-Port vor, die nur ausgehenden Verkehr durchlässt. Er ergänzt, dass MFA auf dem BMC genutzt werden sollte, aber nicht vor den Sicherheitsproblemen schützt, die solche Schnittstellen hatten. Der Sicherheitsleitfaden schlägt außerdem vor, das Rack abzuschließen. Das Security-Officer-Konto der Appliance (veeamso) ist in Veeams Worten „eine zusätzliche Sicherheitsebene, die Ihre Infrastruktur vor böswilliger Systemadministration schützt“.

Netzwerksegmentierung, Multi-Faktor-Authentifizierung und Privileged Access Management gehören zu unserer Leistung Cyber-Resilienz. Nennen Sie uns, wo Ihre BMCs und Backup-Server im Netz stehen und wer über ihre Administratorkonten verfügt.

Plattenplatz für die Sperrfrist bemessen

Ein gesperrter Wiederherstellungspunkt bleibt auf der Platte, auch wenn die Aufbewahrung ihn bereits entfernen würde, und Veeam löscht eine Forward-Incremental-Kette erst, wenn auch ihr letztes Inkrement nicht mehr unter die Aufbewahrung fällt. Bei täglichen Läufen und wöchentlichen Vollsicherungen bleibt die älteste Vollsicherung deshalb mindestens für den Immutability-Zeitraum plus die sechs täglichen Inkremente, die ihr folgen.

Nehmen Sie zur Veranschaulichung an, eine Vollsicherungsdatei umfasst 10 TB, die Inkremente betragen 0,5 TB pro Tag, synthetische Vollsicherungen laufen wöchentlich mit Fast Clone, und die Aufbewahrung beträgt 14 Tage. Mit Fast Clone teilen sich die Vollsicherungen Blöcke, die Platte hält also ungefähr eine Vollsicherung plus die Inkremente von etwa 20 Tagen: 10 TB + 20 × 0,5 TB = 20 TB. Ein Immutability-Zeitraum von 30 Tagen hält etwa 36 Tage auf der Platte, rund 28 TB oder 40 Prozent mehr. Folgt man Veeams Rat, ein Volume nicht über 80 Prozent zu füllen, braucht das Volume dann etwa 35 TB. Läuft der Job stattdessen mit wöchentlichen aktiven Vollsicherungen, trägt jede Kette eine eigene Vollsicherung, sodass jede zusätzliche Woche Sperre eine weitere Vollsicherung samt ihren Inkrementen auf der Platte hält, in diesem Beispiel etwa 13 TB. GFS-Punkte kommen mit ihrem eigenen Anteil hinzu, den unser Leitfaden zur Backup-Aufbewahrung durchrechnet.

Was wir tun

Im Rahmen unseres Cyber-Resilienz-Service liefert das Team unseres Engineering-Partners Vixen.UNO Backup auf Veeam-Basis unter einem Vertrag mit Eurokommerz, mit regelmäßigen Testwiederherstellungen zur Prüfung der Backup-Integrität und einem Ausweichstandort in Baltnetas Tier-3-Rechenzentren in Litauen; Ziel-RPO und -RTO sind im SLA fixiert. Das Assessment von Security und Backup, das auch Umgebungen umfasst, die wir nicht gebaut haben, endet mit einer Risikokarte und einem priorisierten Maßnahmenplan; sein Preis steht vor Beginn fest. Änderungen werden Schritt für Schritt in vereinbarten Wartungsfenstern ausgerollt, mit Rollback-Plan.

FAQ