Veeam Backup – Auslagerung von Backups auf Azure Blob Storage

In diesem Beitrag möchte ich aufzeigen, wie man sein Veeam Backup um eine Sicherung auf Azure Blob Storage erweitert. Ein Vorteil dieser Methode ist, dass die Backup-Daten nach einer gewissen Zeit und/oder nach einem gewissen Füllstand des lokalen Speichers auf den Azure-Speicher ausgelagert werden. Da es sich hierbei um einen Speicher handelt, der nicht lokal steht und z.B. Teil der Active Directory ist, hat man in diesem Fall auch direkt eine (weitere) Absicherung gegen eine lokale Ransomware-Attacke.

Wichtig:

Um diese Art von Backup zu nutzen, sind ein paar Voraussetzungen und Bedingungen zu erfüllen. Zum einen ist ein direktes Backup auf den Azure-Speicher aktuell nicht möglich. Es wird grundsätzlich immer erst ein Backup auf ein “normales” Repository benötigt, die Daten werden erst im zweiten Schritt auf den Cloud-Speicher ausgelagert. Dies bedeutet, dass ein Scale-Out Repository benötigt. Das wiederum bedeutet, dass minimal die Enterprise-Version von Veeam Backup & Replication benötigt wird! Wenn diese Voraussetzungen nicht erfüllt sind, funktioniert die Nutzung nicht.

Die Einrichtung des Storage Accounts in Azure

Wir beginnen mit der Erstellung einer neuen Ressource in Azure. Hierzu loggen wir uns mit unserem Azure Account ein, falls dieser nicht vorhanden ist muss er natürlich noch erzeugt werden.

Hier wechseln wir in den Bereich Storage Accounts und klicken auf Add im oberen Bereich.

Wir wählen die gewünschte Subscription aus und erstellen eine neue Ressource-Gruppe mit einem von uns gewünschten Namen.

Als Location wählen wir eine Region in der Nähe aus, in meinem Fall West Europe. Performance bleibt auf Standard, Replication ist Locally-Redundant und der Access-Tier ist Cool. Diese Einstellungen könnten natürlich auch angepasst werden, dies führt aber zu höheren monatlichen Kosten.

Nach einem Klick auf Weiter können wir einstellen, von wo man auf diesen Storage zugreifen darf. Da dies in meinem Fall von einem beliebigen Veeam-Server in einem lokalen Rechenzentrum ist, wird hier Public Endpoint ausgewählt.

Unter Advanced können drei weitere Einstellungen gesetzt werden, die in unserem Fall alle auf Disabled gesetzt werden.

Danach könnten bei Bedarf noch Tags gesetzt werden, ich lasse diesen Punkt aber für mich frei und fahre mit der Konfiguration fort.

Er erscheint eine Übersicht über die getätigten Einstellungen, wenn alles korrekt ist können wir fortfahren und die neue Ressource erstellen.

Das Anlegen der Ressource dauert einen Moment, ist die Erstellung abgeschlossen wird dies durch eine Benachrichtigung im Azure Portal gemeldet.

Anpassung des Storage Accounts

Nachdem die Ressource angelegt ist, müssen wir in dem gerade erzeugten Account noch einen Container anlegen. Dies geschieht, wie man in dem Screenshot sehen kann, in der Ressource unter Blobs.

Hier sollten wir einen aussagekräftigen Namen für den Container angeben, der Access Level für diese Ressource ist Private. Ist der Container angelegt, können wir uns danach die Zugangsschlüssel für diesen Container anzeigen lassen. Diesen Schlüssel brauchen wir gleich für das neue Repository in Veeam.

Das neue Repository in Veeam für das Config-Backup

Nachdem wir auf unserem Veeam Server die Backup Konsole geöffnet haben, müssen wir im ersten Schritt überprüfen, auf welches Repository das Config-Backup geschrieben wird. Da wir im nächsten Schritt ein neues Scale-Out Repository anlegen, und diese Art von Backup nicht auf ein Scale-Out Repository geschrieben werden kann, müssen wir hier ggf. noch eine kleine Anpassung vornehmen.

Ich habe in meinem Fall auf dem Laufwerk D: (der lokale Backup-Speicher) das normale Backup-Repository. In dieses Repo laufen (vor der Anpassung) sämtliche Backups hinein, inkl. dem Backup der Veeam-Konfiguration. Damit es nun bei der Anpassung nicht zu einer Fehlermeldung kommt, wird ein neues Config-Backup-Repo erzeugt.

Nach der Erstellung können wir das Backup der Konfiguration anpassen und in das neue Repo schreiben lassen.

Nachdem diese Anpassung gemacht wurde, können wir nun mit der eigentlichen Einrichtung von unserem neuen Speicher fortfahren.

Die Einbindung von Azure Blob Storage als Backup-Speicher

Damit der Online-Speicher genutzt werden kann, sind zwei Schritte erforderlich:

  1. Der Azure Blob Storage muss in Veeam hinzugefügt werden
  2. Es muss ein neues Scale-Out Repository erstellt werden, welches aus minimal einem lokalen Repository und einem Cloud-Speicher besteht

Wir starten mit dem hinzufügen von einem neuen Backup Repository. Hier wählen wir die Option Object Storage.

In der Liste der verfügbaren Speicherarten sehen wir hier den Microsoft Azure Blob Storage.

Wir vergeben einen aussagekräftigen Namen und klicken auf Weiter. Nun müssen wir die Zugangsdaten für den Azure Storage angeben. Hierbei handelt es sich um die Daten, die wir im Azure-Portal angezeigt bekommen haben unter Access Keys:

Der Standort bleibt (vermutlich) auf Azure Global, als Gateway-Server wird das lokale System verwendet in meinem Fall. Falls es einen anderen / weiteren Server gibt, der den Upload der Daten übernehmen soll, kann dieser hier alternativ ausgewählt werden. Wird niemand ausgewählt, erfolgt ein Upload der Daten direkt von den Systemen, die den Backup-Speicher bereitstellen. In diesem Fall müssen alle Systeme einen Zugriff auf das Internetz haben.

Werden die Daten übernommen und man klickt auf Weiter, wird die Verbindung überprüft und getestet. Klappt der Zugriff, sehen wir nun den von uns im Azure-Portal angelegten Container. Innerhalb von diesem Container müssen wir nun einen Ordner anlegen, in dem die Backup-Daten gespeichert werden.

Damit haben wir die Erstellung von unserem Backup Repository, basierend auf Microsoft Azure Blob Storage, abgeschlossen. Im nächsten Schritt müssen wir nun das vorhandene Backup-Repo mit dem neuen Azure-Repo verheiraten.

Die Erstellung des Scale-Out Repository

Um die gesamte Konfiguration nun abschließen zu können, müssen wir noch die beiden Repository lokal und Azure in einem Scale-Out Repository verbinden. Dazu erstellen wir ein neues Scale-Out Repository.

Der Performance Tier ist in meinem Fall das lokale Repository auf dem Server selbst. Unter Advanced habe ich keine der Standard-Optionen geändert oder angepasst, diese verbleiben so wie sie sind.

Klickt man nun auf Weiter, erscheint eine Abfrage, ob alle Jobs, die aktuell in das “normale” Repository laufen, automatisch auf das neue Scale-Out Repository umgebogen werden sollen. Dies macht Sinn, damit die Backups weiter nahtlos weiterlaufen und es keine Lücke im Backup gibt.

Die Art der Datenhaltung verbleibt auf Data locality. Dies bewirkt, dass ein volles Backup inkl. der Delta-Dateien immer in einem Repository verbleibt und es so nicht zu einer Fragmentierung der Backup-Ketten kommt. Erst wenn lokal erneut ein volles Backup erstellt wird, werden die älteren Backup-Daten auf den Capacity-Tier verschoben.

Nun können wir unser Azure Blob Storage Repository auswählen. Hier kann eine Dauer angegeben werden, wie lange die Backups auf dem lokalen Speicher vorgehalten werden sollen.

Ganz wichtig ist hier auch die Verschlüsselung der Daten. Da man sich nicht sicher sein kann, wo und wie die Daten genau gespeichert werden, ist eine Verschlüsselung in meinen Augen Pflicht!

Damit sind wir auch schon am Ende der Konfiguration angekommen, sobald wir den Wizard zur Erstellung des Scale-Out Repository abschließen, steht das neue Repo zur Verfügung und kann genutzt werden.

Fazit

Diese Anleitung zeigt, wie man Azure Blob Storage als zweiten Backup-Speicher für Veeam nutzen kann. Der Vorteil liegt hier besonders bei der Tatsache, das die Backup-Daten aus dem Raum / Gebäude / Ort / Land getragen werden und so Unfälle und Attacken überleben. Auch wenn der Speicherplatz, je nach Größe der Backups, nicht ganz günstig ist, so gibt es doch eine super Integration in Veeam und die einfache Einrichtung und Verwaltung sowie das bekannte “klappt halt einfach mit Veeam” sorgen für ruhige Nächte 🙂


Sie benötigten persönliche Unterstützung oder haben nicht die richtige Lösung für Ihr Problem gefunden?

Dieser Blog wird von mir, Jan Kappen, in seiner Freizeit betrieben, hier beschreibe ich Lösungen für Probleme aller Art oder technische Anleitungen mit Lösungsansätzen.

Die berufliche Unabhängigkeit

Ich bin seit Januar 2020 vollständig selbstständig und habe meine eigene Firma gegründet, die Building Networks mit Sitz in Winterberg im schönen Sauerland. Hier stehe ich als Dienstleister gerne für Anfragen, Support oder Projekte zur Verfügung.

Die Firma Building Networks bietet Ihnen:

  • Hilfe und Support per Telefon, Fernwartung oder persönlich vor Ort
  • Projekt-Unterstützung
  • Ausgezeichnete Kompetenz zu den Themen
    • Microsoft Hyper-V
    • Microsoft Failover Clustering & HA
    • Storage Spaces Direct (S2D) & Azure Stack HCI
    • Veeam Backup & Recovery
    • Microsoft Exchange
    • Microsoft Exchange Hybrid Infrastruktur
    • Microsoft Active Directory
    • Microsoft Office 365
    • Ubiquiti
    • 3CX VoIP PBX
    • Fortinet Network Security
    • Baramundi Software
    • ...

Ich freue mich über Ihren Kontakt, weitere Informationen finden Sie auf der Webseite meiner Firma unter Building-Networks.de

Jan

Jan Kappen arbeitet seit 2005 in der IT. Er hat seine Ausbildung 2008 abgeschlossen und war bis 2018 als IT-Consultant im Bereich Hyper-V, Failover Clustering und Software Defined Storage unterwegs. Seit 2015 wurde er jährlich von Microsoft als Most Valuable Professional (MVP) im Bereich "Cloud & Datacenter Management" ausgezeichnet für seine Kenntnisse und die Weitergabe seines Wissens. Jan ist häufig auf Konferenzen als Sprecher zu finden, weiterhin bloggt er viel. Von September 2018 bis Dezember 2019 war Jan als Senior Network- und Systemadministrator bei einem großen mittelständischen Unternehmen im schönen Sauerland angestellt. Im Januar 2020 hat er den Sprung in die Selbstständigkeit gewagt und ist seitdem Geschäftsführer der Firma Building Networks in Winterberg. In seiner Freizeit kümmert er sich um das Freifunk-Netzwerk in Winterberg und Umgebung.

2 Kommentare:

  1. Hallo Jan,vielen Dank für den Bericht, hat super geklappt.
    Nun, wie prüfst du welchen Restore du von dem Blob machst?
    Hast du eine Kontrolle dass der Restore tatsächlich aus der Cloud kommt?
    Weil du ja erst mal das Backup auf das lokale Storage machst und erst (bei mir) nach einem Tag in den Blob.
    der Azure Storage Explorer gibt nicht wirklich eine brauchbare Auskunft, ausser der Datenmenge.
    Gruss Matthias

  2. Hallo Jan,

    wie sieht es denn mit der Einrichtung von einem Azure Blob Storage über einen Private Endpoint aus. Hier werde ich aktuell nicht schlau draus. DNS ist korrekt eingerichtet und wird auch mit der internen IP aufgelöst.

    Gruß
    Marcel

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert