Im Rahmen eines Kundenprojektes habe ich ein Veeam Advanced Deployment durchgeführt. Ziel des Projektes war es, die Performance und Sicherheit des Backups zu erhöhen, was durch die Auslagerung von Veeam-Services auf mehrere virtuelle und physikalische Systeme erfolgte.
Bei dem Kunden handelt es sich um ein mittelständisches Unternehmen mit einem Direktvertrieb für Großkunden und einem eigenen Entwicklungs-Team.
Die Umgebung besteht aus Windows- und Linux-Systemen und umfasst etwa 300 VMs mit rund 50TB produktiv genutztem Storage.
Die Ausgangssituation sieht so aus, dass der Kunde einen physikalischen Dell R750 mit lokalen HDDs (10 Stück mit je 20TB brutto) als Standalone-Backupserver betreibt. Der Server ist mit 4x 10Gbit an das bestehende iSCSI-SAN angebunden (bis zu 25Gbit im SAN sind möglich) und erreicht folgende Processing Rate während des Backups:
Was genau kann hier ein Bottleneck bzw. ein Sicherheitsrisiko sein?
- Full Stripe Size des HDD-RAIDs auf dem Backupserver beträgt nicht 1MB (Hersteller- und Veeam Best Practice)
- MPIO ist auf dem Server nicht sauber konfiguriert
- Zusatzsoftware (z.B. zwei Webbrowser etc.) ist auf dem Backupserver installiert
- der Server befindet sich im selben Subnetz / VLAN wie die restliche, produktive Infrastruktur
- es besteht keine Redundanz – fällt der Backupserver aus, gibt es weder Zugriff auf die Daten noch auf die Veeam-Umgebung selbst
- der Kunde nutzt zum Zugriff auf die Veeam-Umgebung ausschließlich den lokalen Administrator des Windows-Servers
- der Server hat vollen Internetzugriff und ist von überall aus (LAN-seitig) erreichbar
Wie sieht die neue Lösung aus?
- eigene VLANs für verschiedene Services
- starke Integration eines Firewall-Regelwerkes
- Abhärtung der Zugriffe durch aktuelle Passwort- und Benutzerrichtlinien
- Berechtigungsvergabe nach dem Minimalprinzip
- Personifizierung von Benutzeraccounts
- Integration des physikalischen Backupservers ins SAN inkl. Umsetzung von Best Practices
- RAID-Design mit Einhaltung des herstellerseitigen Best Practices
- Veeam Advanced Deployment
Installation PostgreSQL 15:
PostgreSQL wurde bei dem Kunden in der aktuellen Version inkl. des ODBC-Treibers installiert und es wurde ein Service Account angelegt, der dediziert für Veeam verwendet wird. Dieser hat folgende Berechtigungen:
Tests in der Vergangenheit haben gezeigt, dass es immer wieder Probleme gibt, wenn der Service Account nicht als Superuser deklariert ist. Dies ist aktuell als temporäre Lösung zu sehen, jedoch führt ein Fehlen der Rolle selbst dazu, dass Veeam keine neue Datenbank anlegen darf, obwohl das „Create databases“-Recht gewährt wird!
Achtung: Bei der Migration von bestehenden MSSQL-Szenarien ist darauf zu achten, dass die Standardeinstellungen weitestgehend beibehalten werden. Gerade der Datenbank-Name (Ziel-Datenbank in Postgres) sollte nicht geändert werden, da es sonst zu Fehlern kommt!
Konfiguration iSCSI auf dem physikalischen Proxy-Server:
Der physikalische Backupserver wurde mit 4x 10Gbit an das vorhandene iSCSI SAN angebunden und auf dem Storage-Cluster als Host angelegt. Der Server sieht von den Storage-Systemen jede LUN (read/write). Gemäß aktuellem Best Practice wurde das Automount im Windows deaktiviert:
Konfiguration VMware Proxy:
Hier wurde der VMware Proxy innerhalb von Veeam konfiguriert. Es handelt sich um einen dedizierten Server (wie in der Beschreibung aufgeführt), der über zwei physikalische CPUs verfügt.
Konfiguration Backup Repository:
Der physikalische Server verfügt über lokale HDDs als primäres Repository für Veeam und agiert somit sowohl als Proxy als auch als Repository.
Anpassung der lokalen Sicherheitsrichlinie:
Es wird hier nach der Logik gearbeitet, dass auf den entsprechenden Windows-Servern, die die Veeam-Infrastruktur bereitstellen mit lokalen Service Accounts gearbeitet wird, die beispielsweise keinerlei Rechte für RDP benötigen. Die folgende Sicherheiteinstellung in der lokalen Sicherheitsrichtlinie wurde gesetzt:
Umgekehrt benötigt ein Service Account natürlich die Berechtigung, Dienste auszuführen, daher wurde folgende Einstellung angewendet:
Da bei Microsoft leider bis zum Windows Server 2022 die lokalen Administratoren standardmäßig RDP verwenden dürfen (falls aktiviert), wurde der RDP-Zugriff auf die lokale Gruppe „Remote Desktop Users“ beschränkt und der lokale Administrator dort hinzugefügt. Folgende Einstellung wurde angewendet (hier wurden die lokalen Administratoren entfernt):
Abbildung RBAC im Veeam:
Die in Veeam konfigurierbaren Berechtigungen wurden als lokale Windows-Gruppen abgebildet:
Im ersten Schritt möchte der Kunde keine MFA aktiviert haben, da sich die Umgebung derzeit in isolierten VLANs befindet und er diesen Schritt in einer weiteren Härtung durchführen möchte.
Konfiguration Agent Backups:
Da der Kunde nur wenige Clients und Server per Agent gesichert haben möchte, wurden die folgenden zwei Protection Groups angelegt:
In diesem Szenario wurden die entsprechenden Backup-Jobs auf mit den Protection Groups erstellt. Die Clients werden vom Kunden manuell den Protection Groups hinzugefügt.
Konfiguration Tape Server:
Passend zur gewünschten Backup-Strategie des Kunden wurden die Media Pools „Daily“ und „Monthly“ für die täglichen und monatlichen Backup-Tapes angelegt. Im Media Pool „Unrecognized“ befinden sich alle Cleaning Tapes:
Gesamtübersicht:
Abschließend wurden sämtliche Jobs sauber angelegt und getestet (Screenshot vor Abschluss aller Tests). Vom Prinzip wurden die Jobs basieren auf vSphere-Tags angelegt. Die Idee ist, dass jede VM nur ein Tag benötigt, um in Veeam sauber zugeordnet werden zu können.
Die Performance hat sich ebenfalls signifikant verbessert:
Priorität von Beschriftungen:
In sämtlichen meiner Installationen lege ich viel Wert auf eine saubere und detaillierte Beschriftung. Dies hat den Hintergrund, dass sowohl Kunde als auch jeder Mitarbeitende eines Dienstleisters relativ schnell einen Überblick erhält, was für den Kunden auch ein schnelleres Troubleshooting und eine bessere Basis für Dokumentationen bietet:
