Kontakt

Blog

Backup

Veeam

Veeam Backup & Replication – Immutable Backup mit Veeam Hardened Repository

Lesedauer 8 Minuten

Mit Version 11 hat Veeam den Schutz von Backups durch äußere Angriffe in seiner Backup & Replication Suite weiter verbessert: „Hardened Repository“ heißt das Feature, welches Backups unveränderlich im jeweiligen Backup Ziel, dem Repository, ablegt.

Schema zum Testaufbau

Was bedeutet eigentlich “Immutable”, also “unveränderliches, Backup?

Per Definition erfüllen unveränderliche Backups unter anderem den Zweck, nicht gelöscht oder verschlüsselt werden zu können. Das Löschen kann zum einen versehentlich oder willkürlich passieren, eine Verschlüsselung aber auch durch einen Angriff von außen über eine Ransomware-Infektion. Diverse Konfigurationsparameter bestimmen dabei, wie lange die Backups nicht verändert werden können.

Allgemeine Voraussetzungen

  • Veeam Backup & Replication 11 oder neuer
  • Linux-Server für das Repository (Physisches Deployment empfohlen, Abbildung als VM möglich)
    – z.B. mit lokalen Festplatten für die Backup Daten
    – Wichtig: Darf nur Repository, nicht Proxy sein!
  • Eine unterstützte 64-Bit Linux-Distribution (eine generelle Empfehlung des Herstellers gibt es derzeit nicht)
    – z.B. Ubuntu Server 20.04 LTS (langfristige Updates bis 2025)
    – Unterstützung für chattr und setfattr-Kommandos
  • Nutzung des XFS-Filesystems für das Laufwerks des Repositories mit aktiviertem reflink für FastClone
  • Einen passenden Backup Typ:
    – Backup: “Forward incremental” mit regemäßigen Full-Backups (aktiv oder synthetisch)
    – “Backup Copy”: mit GFS (“Grandfather-Father-Son“) konfiguriert

Limitierungen

  • Das “Hardened Repository” kann nicht mit anderen Veeam Backup & Replication Servern geteilt werden
  • “Reverse” oder “forever forward incremental”-Backups sind nicht möglich, wenn die Backup-Archive unveränderlich abgelegt werden sollen
  • NFS-Shares könne nicht genutzt werden
  • Es gibt verschiedene Ausnahmen für Scale-Out Backup-Repositories. Diese betreffen unter anderem das Verhalten von Performance- oder Capacity-Tiers sowie die Möglichkeiten der Evakuierung
  • Backups lassen sich nicht händisch vom Repository entfernen
  • Immutability kann nicht für NAS oder Transaktionsbackups, RMAN/SAP HANA/ SAP on Oracle Backups genutzt werden
  • Der Linux-Server darf, wie bereits erwähnt, nicht gleichzeitig Hardened Repository und Veeam Backup Proxy sein

Was gibt es sonst zu beachten?

  • Bei der Aktivierung der Immutability Option im Repository überschreibt die Aufbewahrungsrichtlinie des Repositories die des Jobs, wenn diese kürzer ist
  • Metadaten Files werden nicht unveränderlich abgelegt, da Sie bei jedem Job aktualisiert werden.
  • Der Einsatz von Immutability ist nicht für Nutanix Mine-Infrastrukturen empfohlen
  • Der Einsatz von Single Use-Credentials ist empfohlen
  • Der Zeitraum der Immutablity kann von mindestens sieben bis max. 9999 Tage gesetzt werden. Nach Ablauf können die Backups wieder gelöscht werden
  • Die Zeitperiode für das Immutable Backup zählt ab dem Erstellen des letzten Wiederherstellungspunktes in der aktiven Backup Kette.
    – Wenn z.B. am 01.01. ein Full Backup erstellt wurde, am 02.01 ein inkrementelles und am 03.01 das letzte inkrementelle Backup erstellt wurde, wird ab dem 03.01. losgezählt. Bei einer Aufbewahrungszeit von zehn Tagen wäre das Backup also bis einschließlich zum 13.01. nicht veränderbar

Schritte zur Einrichtung von Veeam Immutable Backup mit Veeam Hardened Repositories

  • Konfiguration der BIOS Optionen (Workload Profile etc.) des Servers
  • RAID-Konfiguration des Controllers
  • Installation des Linux Servers
  • Konfiguration des Linux Servers

Bei der Konfiguration des Servers gibt es einiges zu beachten. So ist es ratsam, zunächst auch einen eigenen User für den Zugriff von Veeam auf den Server lokal anzulegen und auch nur diesen zum Zugriff auf das Repository zu berechtigen. Das Repository benötigt zur Nutzung des Fast Clone-Features vor allem ein unterstütztes Filesystem (z.B. XFS) aber auch diverse Parameter wie CRC und reflink aktiviert.

Im Anschluss an die passende Konfiguration des Linux Servers erfolgt nun das Anbinden an die Veeam-Infrastruktur.

Hierzu wird der Server zunächst als Linux Server der Backup Infrastructure hinzugefügt. Es ist empfohlen, hier Single Use-Credentials zu verwenden, da diese nicht von Veeam in der Backup-Infrastruktur gespeichert werden.

Single Use Credentials

Zum initialen Deployment ist es notwendig, dass der Veeam User auch die Berechtigung hat, die Rechte passend zu erhöhen. Diese temporäre Anpassung sollte nachträglich wieder entfernt werden.

Credential Optionen

Unter der Option “Advanced” können dann noch die Ports angepasst werden. Standardmäßig nutzt Veeam hierbei für die Kommunikation mit dem Repository Port 6162 und für die Übertragung von Daten Port 2500 bis 3300. Hier können die Ports Problemlos beschränkt werden. Pro Task wird ein Port benötigt.

Mit dem Fertigstellen des Wizards wird das Repository nun final hinzugefügt und der Veeam Transportdienst installiert.
Das Anheben von Rechten ist danach für Backup- und Restore-Tasks nicht mehr notwendig, der genutzte lokale User des Linux Servers kann nun wieder in seinen Rechten erneut eingeschränkt werden. Lediglich für ein erneutes Update des Transportdienstes müssen die Rechte wieder temporär erhöht werden.

Damit das Repository auch für einen Backupjob zur Verfügung steht, wird es nun in der Backup Infrastructure unter Backup Repositories hinzugefügt. Hierzu wird im Wizard Direct attached storage ausgewählt und der vorhin angelegte Linux-Server verwendet.
Hierbei ist es wichtig, den passenden Pfad zu verwenden und FastClone sowie die Immutable Funktion zu aktiveren.

Neues Veeam Backup Repository

Je nach Backup-Infrastruktur kann es hier auch Sinn machen, Optionen wie per-VM Backup-Files zu aktivieren.
Die weiteren Schritte sind analog zu einem normalen Backup Repository und können daher wie notwendig passend gesetzt werden.

Nach erfolgtem Hinzufügen, erscheint des Repository nun in der Übersicht.

Nun geht es weiter an das Abschotten des Systems, um die Angriffsvektoren möglichst gering zu halten. Hierbei empfiehlt es sich folgende Einstellungen vorzunehmen:

  • Beschränken der Netzwerkzugänge
  • Verwenden Komplexer Passwörter sowie deaktivieren nicht benötigter Benutzer
  • Deaktivieren nicht benötigter Dienste
  • Härtung der Systemzugänge

Um die Zeit immer aktuell zu halten, ist auch der Einsatz eines gesicherten, vertrauenswürdigen NTP-Servers ratsam. Gleichzeitig kann dies aber auch gegen den Server verwendet werden, sofern der NTP-Server kompromittiert wird. Der gezielte Einsatz eines solchen ist daher vorab und aufgrund individueller Konfigurationen zu prüfen. Alternativ kann der Server selbstverständlich auch die lokal eingestellt Systemzeit verwenden.

Im Anschluss kann nun ein Backupjob konfiguriert werden. Hierbei ist es wichtig, sich an die oben bereits erwähnten Empfehlungen und Limits zu halten.
Es ist unter anderem möglich, primäre VM-Backupjobs oder auch Backup Copy-Jobs anzulegen. Welche Methode für Ihre Backupkonzept am besten geeignet ist, richtet sich hier nach Ihrer Infrastruktur und den Vorgaben Ihres Unternehmens.

Nachdem der erste Backupjob auf mit dem Repository als Ziel erfolgreich gelaufen ist, können wir nun prüfen, ob es das gewünschte Ergebnis liefert. Am einfachsten ist es, einmal aus der GUI heraus eine VM aus dem Job zu entfernen. Sofern alles richtig konfiguriert worden ist, sollte das wie folgt aussehen:

Löschen schlägt fehl. Erster Erfolg

Und wie sieht es auf dem Repository aus?
Dazu können wir uns dann, nach Verschaffen des Zugriffs auf die Konsole (z.B. auch vor Ort) einmal die Attribute der einzelnen Backup-Files anschauen:

Das “i”-Attribut bedeutet in dem Fall, dass das “immutable”-Flag gesetzt ist. So sollte es aussehen.

Wie oben erwähnt, sind die Metadaten (.vbm) nicht immutable, da diese bei jedem Backupjob verändert werden. Sofern dieses Metadaten-File entfernt wird, kann es, z.B. durch ein erneutes, manuelles Importieren der Backup Kette, neu erstellt werden. Es ist daher möglich, auch ohne das Metadaten-File die Backups grundsätzlich wiederherzustellen.

Zu guter Letzt versuchen wir nun noch eine Datei aus dem Backupverzeichnis über die Konsole zu löschen. Auch das schlägt glücklicherweise fehl, sofern wir im Vorfeld alles richtig konfiguriert und überflüssige Rechte eingeschränkt haben.

Löschen per Konsole schlägt fehl. Zweiter Erfolg

Wir stehen Ihnen für Fragen zur Verfügung!

Sie haben Fragen zu Themen rund um Veeam Backup & Replication oder benötigen Unterstützung bei der Einrichtung von Immutable Backup? Kommen Sie bei Bedarf auf uns zu, wir unterstützen Sie gerne!

Weitere Beiträge

Alle Artikel ansehen

Alle Artikel ansehen
Sprechen Sie jetzt mit einem Experten!

Als netgo group bringen wir Menschen und Technologien erfolgreich zusammen. Dabei denken wir ganzheitlich, verstehen das Geschäft unserer Kunden und ebnen den Weg für eine smarte und intelligente Digitalisierung.

Mehr erfahren