Hi, warum so kompliziert?

Die Datenbank hat keine Probleme auch wenn die älter ist, dass einzige Problem besteht, wenn während des Ausfalls ein Job lief. Dann bleiben eventuell Snapshots über.

In der Regel fällt so ein virtueller Veeam Server extremst selten aus und dafür eine Replikation ist etwas too much. Mach einfach ein Backup und im Worst Case musst du über das einfache Recovery Tool einen Full Restore von deinem Veeam Server machen. 
 

Wenn deine Umgebung komplett tot ist, stört die Recovery Zeit nicht, da du eh erst einmal neue Hardware beschaffen musst. Wenn du einen DR Cluster hast, läuft der Veeam ja eh da. Ist nur die VM defekt, dann hast du auch kein Zeitdruck und machst deinen Full Restore.

Du solltest auf jeden Fall Backups der Veeam datenbank (Configuration backup) anlegen und auf einem externen Storagespeichern, damit du den VeeamServer sicher wieder herstellen kannst.

Du schreibst, dass du auf deinem Repository Server zusätzlich Hyper-V fährst. Das bedeutet also, dass es ein Windows Host ist und du kein Hardened Repository einsetzt. Bei der Entwicklung der Bedrohung durch Ransomware wäre ein immutable Repository sehr anzuraten.

Danke euch bis hier hin!

@JMeixner: Config Backup ist vorhanden und 99% meiner Kunden setzen das Hardened Repo zusätzlich zum Windows Repo auf und arbeiten mit Backup Copy. Die Immutability ist also vorhanden.

@Falk: Es geht hier tatsächlich um Szenarien, wo die RTO sehr gering sein sollte. Wir gehen hier mal nicht vom Hardwareausfall oder von einem erfolgreichen Ransomware-Szenario aus, sondern z.B. von einem Config-Fehler, der zu einem Ausfall von Storage oder SAN führt, Stromausfall o.ä.

Betiteln wir es als Szenarien, wo die grundsätzliche Hardware wieder lauffähig gemacht werden kann, dennoch beispielsweise ein DC per Instant Recovery wiederhergestellt werden muss, um DNS-Abhängigkeiten zu gewährleisten.

Klingt aber erstmal so, als spräche explizit erst einmal nichts dagegen. Wie gesagt, die allermeisten solcher Kunden haben keine DR-Infrastruktur, daher die Idee / das Vorgehen mit der Replika auf unabhängige Datastores (Windows Repo oder ESXi Host mit lokalem Speicher).

Also hackersicher ist das nicht. Bei einem mir bekanntem Vorfall wurde der ESX Host kompromittiert und alle VMs wurden verschlüsselt….es spricht vieles dafür einen ggf. preiswerten gesonderten Server als Backupserver zu nehmen.

Deshalb vom virtuellen Veeam immer ein Backup vorhalten, natürlich auf dem Hardened Repository.

@RaLu Da widerspreche ich dir, da ich ja hier nicht die gesamte Infrastruktur beschreibe.

Die Backupdaten liegen auf dem Repo, welches hier natürlich physikalisch ist und außerdem netzwerkseitig segmentiert, etc.

Dann werden die Daten beispielsweise auf ein Hardened Repo und / oder ein Immutable S3 Repo (Cloud o.ä., wenn die RTO es zulässt) kopiert, somit hat man die Immutability in einem zweiten Tier.

Wenn auf einem physikalischen Server (geht ja nicht auf dem Hardened Repo) der Backup Server mit läuft, dann würde ein Hardwareausfall dieses Servers bedeuten, dass ich zwar noch weitere Tiers habe, jedoch mit den Daten nicht arbeiten kann, weil ich kein Veeam (keine Installation etc.) mehr habe. Daher virtualisiere ich den Backupserver und lagere das Repo und ggf. den Proxy auf Physik aus (Veeam Advanced Deployment). Somit löse ich mich vom Single Point of Failure.

Da viele Kunden kein DR-Cluster haben (Deutscher Mittelstand), weiche ich hier mit Netzsegmentierung bzw. VLAN-Design z.B. auf der Prod-Cluster aus und arbeite mit Replikation - was widerum meine ursprüngliche Frage darstellt. 

Die große Frage ist, wie ist die Segmentierung ausgeführt? Da ist oft die größte Schwachstelle.

Ein Configbackup auf dem LHR reicht eigentlich vollkommen aus, manche machen auch vom physikalischen Veeam ein Agentbackup. 
Ich mag lieber physikalische Backupserver, beim Ransomwareangriff bei einem Kunden, sind die Hacker auch nicht auf den physikalischen Veeam Server drauf gekommen, da das Windows vernünftig gehärtet war. Wir brauchten somit nicht einmal die Hardened Backupkopie sondern konnten direkt das letzte Backup restoren, damit die Forensiker loslegen konnten.

Genau das versuche ich auch zu erreichen und das ist auch der beste Weg! Nur ich hab leider oft erlebt, dass die Kunden eine Standalone-installation haben und dann alles weg war, auch wenn noch ein NAS o.ä. Backupdaten getragen hat - daher die Idee der Virtualisierung.

Da wir Veeam mit Advanced Deployment, diversen Firewallregeln, Windows-Hardening, Netzsegmentierung und vor allem auch Serviceaccounting aufsetzen, ist es schon etwas aufwendiger geworden, “mal eben” einen neuen Server mit Veeam bereitzustellen, weil wir nicht mehr einfach auf “weiter-weiter-fertigstellen” klicken.

Aber das ist letztlich Kundenentscheidung und meiner Ansicht nach alles eine Frage der RTO.

Sobald du eine VM hast, ist die viel einfacher übernommen. Netzwerksegmentierung über die Perimeter Firewall ist auch nur halb gut. Leider haben die wenigsten eine extra Datacenter Firewall. Viele routen ihre VLANs noch über die Coreswitches, da hat man gar nichts gewonnen.

Jetzt muss ich leider anmerken: Das hat nichts mit meiner initialen Frage zutun 

Bin absolut bei dir, aber da ich selbst DR-Consultant bin, ist mir das durchaus bewusst. Dennoch virtualisiere ich seit Jahren Veeam (Advanced Deployment) und suche hier Erfahrungswerte für neue Ansätze, da ich eben das Maximum herausholen möchte.

Hier geht es explizit um Kunden, die eine geringe RTO und HA im Bereich Veeam benötigen, aber beispielsweise nur zwei physikalische Server hierfür nutzen (Windows Repo und Linux Hardened Repo).

Hallo Lukas,

hm, meines Wissens nach ist es nicht wirklich empfohlen den VBR-Server selbst mit Veeam zu sichern oder zu replizieren.

Das ist meiner Meinung nach auch nicht unbedingt nötig, solange Du ein Backup der Konfig-DB hast ist der VBR-Server ziemlich schnell wieder verfügbar: Windows installieren, VBR-Installation starten und dabei direkt die Konfig-DB wieder einlesen, dann sieht alles wieder so aus wie vorher.

Das vorab, ansonsten ist es grundsätzlich eine gute Idee den VBR-Server zu virtualisieren, das läuft bei uns genauso weil wir zwei Datacenter haben die einen VMWare-Cluster bilden und der VBR-Server somit auch hochverfügbar ist.

Wenn man den VBR-Server entsprechend absichert (RDP abschalten, als Standalone ohne AD aufsetzen, MFA aktivieren, etc.) ist das IMO auch ziemlich sicher, vorausgesetzt man verwendet (wie Du) externe Repos mit Immutability, am besten Linux-basiert um auch einen gewissen Medienbruch zu gewährleisten.

Noch eine Anmerkung zu den Hardened Repos, das sollten natürlich physikalische Linux-Server mit Direct Attached Storage sein bei denen außer Veeam keine anderen Dienste wie ssh etc. laufen, und ich würde auch empfehlen das Remote-Management (IMM, iLO, DRAC etc.) abzuklemmen damit auch darüber kein Zugriff erfolgen kann.

Das bedeutet zwar dass man ins Datacenter fahren muss wenn sich irgendwas verklemmt, aber das ist immer noch besser als ein verschlüsseltes oder nicht mehr zugreifbares Repo.

HTH + schöne Grüße aus Dortmund,

Harald

@HaraldH Danke für das Feedback, die Punkte setzen wir genau so um, bin völlig bei dir.

Einzig das Hardening und die VBR-Installation sind - zumindest für Laien - nicht mal eben so gemacht. Mittlerweile gehen wir hin und machen im Windows ein Hardening (Security-Policy, RDP aus, lokale Account, etc.), arbeiten vor allem mit Serviceaccounting.

Viele Kunden sind damit etwas überfordert und wollen das Ganze demnach einfacher haben, daher unser Ansatz.

Ich denke, ich baue das mal im Lab nach und werde versuchen, Erfahrungswerte zu generieren.