Hallo zusammen!
Im kleineren bis mittleren Mittelstand in Deutschland ist oft das Budget knapp, das ist bekannt. Viele Unternehmen nutzen berechtigterweise Veeam und möchte das Maximum aus der Umgebung herausholen - Stichwort “Preis-Leistung”.
Im Rahmen vieler vergangener Projekte haben wir für unsere Kunden eine Blaupause entwickelt, in der wir den Veeam Backup Server virtualisieren (z.B. vSphere oder Hyper-V), entweder im Produktivcluster oder in einem DR-Cluster, was jedoch sehr wenige Kunden haben. Es geht hier vor allem um VLAN-Segmentierung, um netzunabhängig und sicher aufgestellt zu sein, daher liegt die VM immer in einem separaten VLAN.
Physikalisch wird hier dann auf direct attached storage gesetzt (HDD oder SSD), d.h. mind. 1 physikalischer Server übernimmt die Rolle von Repository und Proxy (falls SAN-Integration vorhanden).
Die Idee ist nun, sich von Ausfällen des Produktivclusters zu schützen und den virtuellen Veeam Backup Server hochverfügbar zu machen. Heißt in dem Fall folgende Überlegung:
Die Veeam-VM kann per Veeam Replication auf ein weiteres Ziel repliziert werden, das dann in einem Abstand von 15 bis maximal 30 Minuten. Entweder wird auf einen der phys. Repos repliziert (beispielsweise mit Hyper-V Rolle drauf) oder auf die local Datastores von ESXi-Servern (mind. 1 pro RZ).
Im Fehlerfall wird die Replika-VM dann nicht über Veeam gestartet (da Veeam ja mit ausfallen würde, wenn es z.B. auf dem Produktivstorage liegt), sondern “hart” über den Hypervisor. Man fährt also einfach die VM hoch und verzichtet in dem Moment auf den nicht mehr möglichen Delta-Sync.
Folgende Fragen dazu, vielleicht hat hier jemand Erfahrungswerte und ggf. sogar Verbesserungsvorschläge:
- Wie kommt die Veeam-DB (gehen wir von Postgres aus) damit klar, aus einem 15min alten Replica gestartet zu werden? Kann es da Fehler geben und wie ist das Risiko einzuschätzen?
- Ist es von Veeam supported, “sich selbst” zu replizieren?
- Sollte man AAP für die VM aktivieren? Ich bin mir nicht sicher, wie sensibel die DB dann darauf reagiert.
In den Szenarien ist davon auszugehen, dass permanent Jobs laufen, die Transaction Logs sichern. Wir arbeiten hier oft mit SLA-basierten Ansätzen, sodass viele Hintergrundtasks laufen.
Besten Dank vorab!
Viele Grüße aus NRW
Lukas