🚨 Mittlerweile ist die in diesem Artikel eingesetzte Veeam Backup for Microsoft 365 Version nicht mehr aktuell. Der Vorgang innerhalb des KB Artikels unterscheidet sich allerdings nicht für Version 8.1 und ist immer noch gültig! Das Einbinden neuer Repositories sieht allerdings seit Version 8 etwas anders aus.
Einer meiner langjährigen Kunden sichert seit rund zwei Jahren seine Microsoft 365 Daten mit Veeam Backup for Microsoft 365 (VBO365). Initial ist er mit einer Konfiguration auf Basis von Local Storage (basierend auf einem Jet-base Repository) gestartet. Die gesamte VBO365 Konfiguration besteht bei diesem Kunden aus einer einzelnen VM, somit ist die Intelligenz, die Proxy-Rolle und auch das Repository selbst, in dieser VM gehostet.
Immer wieder wurde die Kapazität für das Repository innerhalb der VM erweitert, mittlerweile fasst die VMDK rund 8 TB an Daten. Nun muss man dazu sagen, dass diese VM auf NetApp Storage (mirrored / 2-sites / somit nicht unbedingt günstig) liegt und wiederrum täglich im regulären Infrastruktur Backup via VBR enthalten ist. Bislang alles kein Problem, die Kapazität und Ressourcen waren vorhanden – perspektivisch wird das Ganze Konstrukt auf Dauer allerdings relativ teuer.
In absehbarer Zeit wandert die gesamte Infrastruktur zu einem Managed Service Provider, hauptsächlicher Kostentreiber ist hier unter anderem auch die SAN Kapazität.
Um das ganze nun zu optimieren, hatte ich den Vorschlag unterbreitet, die VBO365 Repository Daten zu Wasabi zu migrieren. Ein Wechsel von VBO365 zur Veeam Data Cloud ist aktuell für den Kunden noch kein Thema. Somit würde dann nur noch die Intelligenz und Proxy Rolle auf Kundenseite (bzw. dann MSP Seite) liegen und belegt eine überschaubare Kapazität auf dem SAN.
Glücklicherweise gibt es hierzu bereits einen Migrationsweg, der unter https://www.veeam.com/kb3067 einzusehen ist. Ich liste hier nun die einzelnen Schritte, die für diese Umsetzung angewandt wurden. In diesem Szenario wird die PowerShell-based Migration verwendet.
Versions-Check
KB4106: Build Numbers and Versions of Veeam Backup for Microsoft 365. Der Kunde setzt bereits Version 7.1.0.2031 (vom 24. April 2024) ein und ist somit up2date. Die neuste Version ist hierbei nicht zwingend erforderlich, sollte es allerdings bei der Migration Probleme geben, ist sowohl der Support als auch ich happy eine aktuelle Version im Zugriff zu haben.
Wasabi
Im Vorfeld hat der Kunde bereits einen Wasabi Account zur Verfügung gestellt, allerdings fand in der Wasabi Console noch keine Konfiguration statt. Es handelt sich somit um eine neuen Wasabi Account. Unter https://console.wasabisys.com/ erfolgt der Login in das Dashboard.
Wasabi – Buckets
In der Console wird unter dem Punkt Buckets via Create Bucket ein neues Bucket (ähnlich eines Containers) erstellt.
Ein Wizard leitet nun durch 6 unterschiedliche Menüpunkte. Bucket Name, auf diesem Screenshot zu sehen und zum Schutz der Kundendaten wurde hier der Name angepasst zu uniquename-xyz123. Die Bucket-Namen müssen eindeutig sein und dürfen somit nicht doppelt verwendet werden, dies gilt auch über Mandanten hinweg! Der Kunde wünscht die Platzierung seiner Daten in der Region Frankfurt eu-central-2.
Direkt hier zu sehen, die später nochmal in VBO365 benötigte Service URL s3.eu-central-2.wasabisys.com. Mit Next geht es weiter zu Set Properties.
Set Properties. Hier erwähnenswert, in der aktuellen VBO365 Version 7.x können Backups noch nicht direkt Immutable abgelegt werden (in der kommenden Version 8 wird dies erstmalig möglich sein)! Somit belasse ich die Default Einstellungen und bestätige mit Next.
Unter dem Link Backup to Wasabi on Veeam Backup for Microsoft 365 v7 findet Ihr eine Step-by-Step Anleitung wie ein Wasabi Bucket in VBO365 eingebunden wird. Ich liste diese Steps weiter unten noch in diesem Blogpost, möchte allerdings auf zwei Besonderheiten für das Anlegen des Buckets hinweisen, bzw. den Auszug daraus listen:
Veeam Backup for M365 supports immutability only for backup copies. Refer to Backup Copy for Veeam Microsoft 365 v7 article for more detail.
If you are going to leverage immutable Veeam backups, follow the steps in Object Lock: Enabling. Enabling bucket versioning only is not a proper configuration for immutable Veeam backups and can cause problems. If you are simply going to use regular Veeam backups with Wasabi buckets, bucket versioning is not required.
Aktuell möchte der Kunde seine Backup-Daten erst mal nur zu Wasabi migrieren um OnPrem Kapazität zu reduzieren. Wünschenswert ist eine weitere Backup-Copy, diese dann Immutable, bereitzustellen – hierfür wird ein separates Bucket mit aktiviertem Object Lock und Versionierung benötigt. Wenn gewünscht, kann ich die Steps für diese Konfiguration gerne in einem weiteren Blogpost beleuchten.
Logging und Replication. Sowohl die Funktion Logging als auch Object Replication in ein weiteres Bucket kommt bei diesem Kunden nicht zum Einsatz, ich lasse diese Einstellungen ebenfalls auf Default. Tipp: bevor man mit dem Gedanken spielt, ein Bucket für VBO365 zu replizieren, würde ich die Built-In Funktion Backup Copy in VBO365 empfehlen. Hierbei kann dann u.a. auch Immutability genutzt werden und Veeam sorgt für die Konsistenz der Daten im Backup Copy – im Falle der Bucket Replication weiß weder Veeam etwas von diesen Daten, noch Wasabi etwas von den Informationen seitens Veeam. Somit bleiben auch diese beiden Menüpunkte auf dem Default, erneut geht es mit Next weiter zum nächsten Punkt.
Tags und Review. Im Menüpunkt Tags besteht die Option diesem Bucket unterschiedliche Tags zuweisen zu können. Dies wäre hilfreich, wenn man mehrere Buckets im Einsatz hat, Filteroptionen benötigt oder das Finden von Objekten vereinfachen möchte (was hier nicht der Fall ist). Abschließend erhält man unter dem Punkt Review eine Übersicht der gesetzten Optionen. Mit der Auswahl Create Bucket wird dieses nun erstellt.
Anschließend erfolgt eine Bestätigung und das erste Bucket ist vorhanden:
Wasabi – Policies
Im nächsten Schritt wird eine Custom Policy erzeugt. In der Console wird im Menüpunkt Policies via Create Policy die entsprechende Option selektiert.
Mit Policies besteht die Möglichkeit, bestimmte Aktionen zu definieren, die ein Benutzer/eine Gruppe ausführen darf/oder auch nicht darf. Die entsprechende Policy für Veeam for Microsoft 365 findet sich unter KB4046.
Als Name verwende ich in diesem Szenario Veeam_VBO_365_IAM (IAM steht übrigens für Identity & Access Management).
Im Policy Editor fügen wir den Code aus dem oben gelisteten Veeam KB4046 Artikel ein. Wichtig: der Name des Buckets in Zeile 21 und 37 muss mit dem oben erzeugten Bucketnamen übereinstimmen, hier also uniquename-xyz123, am Ende bestätige ich via Create Policy.
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:ListAllMyBuckets", "s3:GetBucketLocation" ], "Resource": "arn:aws:s3:::*" }, { "Effect": "Allow", "Action": [ "s3:ListBucket", "s3:ListBucketMultipartUploads", "s3:GetBucketObjectLockConfiguration", "s3:GetBucketVersioning", "s3:ListBucketVersions" ], "Resource": "arn:aws:s3:::uniquename-xyz123" }, { "Effect": "Allow", "Action": [ "s3:PutObject", "s3:GetObject", "s3:DeleteObject", "s3:AbortMultipartUpload", "s3:ListMultipartUploadParts", "s3:RestoreObject", "s3:GetObjectVersion", "s3:GetObjectRetention", "s3:PutObjectRetention", "s3:DeleteObjectVersion" ], "Resource": "arn:aws:s3:::uniquename-xyz123/*" } ] }
Wasabi – Users
In Wasabi fehlt nun noch ein Benutzer der Zugriff auf dieses Bucket bekommt, mit der hierfür eigens erstellten Policy. Ich möchte aus Sicherheitsgründen nicht den Wasabi-Admin-Account bei der Kopplung zwischen Veeam und Object-Storage verwenden.
Erneut in der Console, nun unter dem Punkt Users, wird via Create User der Assistent zum Erstellen des entsprechenden Benutzers geöffnet.
Hier im Menüpunkt Details zu sehen, der Username john.wick und der gewählte Type of Access Programmatic (create API key).
Via Next gelange ich zur Auswahl Groups, hier besteht die Option den User in eine bestehende Gruppe hinzuzufügen, oder direkt mit in eine neu erstellte Gruppe mit aufzunehmen. Hier in aktuellem Szenario nicht benötigt. Erneut geht’s via Next weiter.
Die im Vorfeld erstellte Policy Veeam_VBO_365_IAM wähle ich nun aus und weise diese somit dem Benutzer zu, mit Next gehts weiter zum abschließenden Review.
Unter Review werden noch einmal alle gesetzten Optionen aufgelistet. Mit Create User wird der Vorgang abgeschlossen.
Direkt im Anschluss wird für den eben erzeugten Benutzer der Access Key angezeigt und die Option den Secret Key anzuzeigen, in die Zwischenablage zu kopieren oder diese Informationen in einer CSV herunterzuladen. Ich habe mich in diesem Beispiel für Download CSV entschieden. Keine Sorge, die hier auf dem Screenshot gezeigten Informationen, entsprechen nicht der Realität 😋
Das war es innerhalb von Wasabi. Tatsächlich dauert das Schreiben darüber länger als das eigentliche Einrichten. Und keine Sorge, der Account bekommt noch eine zusätzliche Absicherung via MFA 😉
Veeam Backup for Microsoft 365
Weiter gehts in Veeam Backup for Microsft 365, endlich. Wie Anfangs erwähnt, hat der Kunde bereits eine lauffähige VBO365 Konfiguration, allerdings bis jetzt noch keine Anbindung an ein Object Storage Repository, darum kümmere ich mich jetzt.
Veeam Backup for Microsoft 365 – Object Storage
Innerhalb VBO365 wird das Menü Backup Infrastructure ausgewählt, die Option Object Storage selektiert und entweder via Kontextmenü oder Auswahl im Ribbon die Option Add Object Storage gewählt.
Man wird nun durch den Add Object Storage Wizard geleitet, im ersten Schritt vergebe ich den Namen Wasabi Cloud Storage. In größeren Umgebungen macht es sicherlich Sinn, einen aussagekräftigen Namen zu verwenden, den Namen des Buckets, oder ähnliches. Auch hier eignet sich das Feld Description für weitere Informationen.
Mit Next geht’s weiter und die Wahl fällt in diesem Szenario natürlich auf Wasabi Cloud Storage, erneut geht es mit Next weiter.
Wie weiter oben erwähnt, benötigen wir noch mal die Service Point URL und den Namen der Data center region. Diese kann in der Wasabi Console nachgeschaut werden oder z.B. auch unter folgendem Link: Service URLs for Wasabi’s Storage Regions. Im Screenshot zu sehen, handelt es sich hier um die Daten für s3.eu-central-2.wasabisys.com bzw. eu-central-2 (Frankfurt).
Noch liegen keine Zugangsdaten für dieses Bucket in VBO365 vor, dies wird nun via Add… nachgeholt. Der entsprechende Access key und Secret key wird hinterlegt (siehe Download CSV, weiter oben), als Description bietet sich hier ein aussagekräftiger Hinweis an. Mit OK wird dieser Eintrag gespeichert und auch direkt ausgewählt.
Somit geht es mit Next weiter zur Auswahl des entsprechenden Buckets.
Ausgewählt hier im Beispiel, das Bucket uniquename-xyz123. Allerdings ist hier noch kein Ordner vorhanden, dieser muss somit erst erstellt werden.
Via Browse… öffnet sich die Auswahl der entsprechenden Ordner.
via Option New Folder, habe ich den Ordner backup erstellt und diesen anschließend mit OK bestätigt.
Wie zu Beginn erwähnt, wird dieses neue Repository für die primären Backup-Daten verwendet (nach erfolgreicher Migration), somit steht aktuell noch keine Immutable Option zur Verfügung, ebenfalls benötigen wir die unter Advanced verfügbare Option für ein Soft-Limit / Quota in diesem Szenario nicht. Der Vorgang wird mit Finish bestätigt.
Wie im Screenshot zu sehen, verfügt der Kunde nun über ein eingebundes Object Storage.
Veeam Backup for Microsoft 365 – Backup Repositories
Damit das ganze nun auch konsumiert werden kann, muss dieses noch als Backup Repository hinzugefügt werden. Die Wahl fällt also auf den Bereich Backup Repositories, gefolgt von der Option Add Repository. Ich verwende auch hier den Namen Wasabi Cloud Storage (siehe Anmerkung oben, bzgl. aussagekräftigen Namen). Mit Next geht’s wie immer weiter.
Die Wahl der Target location fällt in diesem Fall nun auf Backup to object storage, mit Next geht’s weiter zur Backup proxy und cache location.
Ich behalte den aktuellen Proxy bei, muss allerdings via Browse… noch einen Cache Folder definieren, hierfür habe ich den Ordner VeeamCache erstellt und entsprechend ausgewählt. Für Informationen zum Cache und Sizing dessen, empfehle ich die folgenden Artikel, Cache – Veeam Backup for Microsoft 365 Guide und Object Storage | Veeam Backup for Microsoft 365 Best Practices.
Cache Repository
When you’re using an Object Storage repository, you need to configure a local cache folder. This cache folder is used to store temporary meta data to reduce the amount of storage transaction targeting your Object Storage. Provide disk space for ~1% of your source data size as local cache with a maximum of 100GB.** In case of restores this local cached meta data reduces the need for 90% of the required API calls to the object storage (which might increase cost on public cloud). Read more detailed information in the sizing section for Object Storage.
Im nächsten Fenster wähle ich den vorhin hinzugefügten Object Storage Wasabi Cloud Storage aus und aktiviere die Option Encrypt data uploaded to object storage. Da es hierfür noch kein Passwort gibt, muss dies erst via Add… hinzugefügt werden. Via Passwortmanager wurde ein generiertes Kennwort erzeugt und im Passwortsafe eingepflegt. Mit OK wird die Aktion bestätigt.
Nachdem das Encryption Kennwort hinterlegt wurde, kann erneut mit Next zum nächsten Schritt gesprungen werden.
Hier wird nun die gewünschte Retention policy selektiert, bei diesem Kunden ist dies Keep forever und die Snapshot-based retention Variante. Beide Werte sind hier entsprechend dem aktuellen Repository (Local Storage) identisch konfiguriert worden.
Mit Finish ist die Konfiguration abgeschlossen. Der Kunde verfügt nun über zwei Repositories, das bereits vorhandene Local Storage Repository und das neu hinzugefügte Object Storage Repository.
Nun kann es an die eigentliche Migration der Daten gehen.
Veeam Backup for Microsoft 365 – Migration via PowerShell Script
Wie zu Beginn des Artikels erwähnt, gibt es im KB3067 die unterschiedlichen Migrationswege. Ich habe mich für den Weg via bereitgestelltem PowerShell Migrationsskript entschieden. Das Skript kann im KB Artikel heruntergeladen werden.
Sobald das Skript aufgerufen wird, wird der entsprechende Tenant ausgewählt – die meisten Abfragen sind hier sehr einfach, da dieses VBO365 System nur einen Tenant, einen Proxy und nur ein Quell-Repository hat.
Die entsprechenden Optionen werden in diesem Beispiel jeweils mit 0 ausgewählt. Lediglich bei der Abfrage zum Target repository, muss hier natürlich das neu erstellte Wasabi Cloud Storage Repository ausgewählt werden, hier in diesem Fall 1.
Anschließend startet die Migration der Daten. Innerhalb der PowerShell ISE sieht man die einzelnen Accounts die in der Verarbeitung sind.
Ebenfalls ist die Migration auch im VBO365 selbst einzusehen:
Und natürlich merkt man die ganze Aktion auch an der Auslastung im System, siehe Task-Manager:
Ich schreibe an diesem Artikel nun schon mehrere Stunden, mittlerweile sind die ersten Workloads erfolgreich migriert, siehe Screenshot:
Abschließend kann man sagen, das Ganze funktioniert straightforward. Die Kosten für Wasabi in dieser Größenordnung, stehen in keinem Verhältnis zu den Anschaffungskosten für ein OnPrem Speichersystem wie es der Kunde aktuell nutzt und von den zukünftigen Kosten pro TB beim neuen Managed Service Provider möchte ich gar nicht erst sprechen.
Solltet ihr ebenfalls diesen Migrationsweg in Erwägung ziehen, bitte Aufmerksam den verlinkten KB3067 Artikel lesen, nur ein kleines Beispiel, was es zu beachten gibt – wenn das Skript z.B. nicht genutzt wird:
The Move-VBOEntityData cmdlet will not reconfigure backup jobs to change the repository they use. The jobs must be reconfigured manually or by using additional PowerShell cmdlets (as is done in the script example found in this article).
Bei Fragen oder Anregungen, bitte gerne auf mich zukommen.