7
Hyper-V Replikat oder Primär-VM sichern?
Hallo,
ich habe einen Hyper-V Host, dessen VMs auf einen zweiten Hyper-V repliziert werden. Und einen Backupserver, auf den die VMs mittels Acronis gesichert werden. Momentan läuft das so, dass ich die Replikate sichere, und nicht die primär laufende VM.
Vorteil:
Nachteil:
Wie macht Ihr das? Würdet Ihr das Replikat oder die primäre VM sichern?
Grüße
lcer
ich habe einen Hyper-V Host, dessen VMs auf einen zweiten Hyper-V repliziert werden. Und einen Backupserver, auf den die VMs mittels Acronis gesichert werden. Momentan läuft das so, dass ich die Replikate sichere, und nicht die primär laufende VM.
Vorteil:
- der Backup-Traffic fällt nicht am Produktionssystem an
- Falls sich irgendwelche Backup-Prüfpunkte mit anderen Prüfpunkten blockieren, betrifft das nicht das Produktionssystem.
Nachteil:
- Wenn die Replaktion versagt, sichere ich nur alte Daten.
- Beim zusammenführen der Replikat-Daten kommt es manchmal zu "Stau" wenn gerade ein Backup-Prüfpunkt der VM erstellt und noch nicht wieder gelöscht wurde.
Wie macht Ihr das? Würdet Ihr das Replikat oder die primäre VM sichern?
Grüße
lcer
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 6475496671
Url: https://administrator.de/contentid/6475496671
Ausgedruckt am: 24.11.2024 um 12:11 Uhr
7 Kommentare
Neuester Kommentar
Moin,
ganz klar das Produktivsystem sichern. Weiß nicht, wie das bei Acronis ist, mit Veeam komplett schmerzfrei.
Die Replikation ist bei uns als schnelle Hilfe für den Komplettausfall des Produktivservers / einzelner VMs vorgesehen, dann zwar nicht mit aktuellen Daten, aber die Leute können weiterarbeiten.
Gruß
ganz klar das Produktivsystem sichern. Weiß nicht, wie das bei Acronis ist, mit Veeam komplett schmerzfrei.
Die Replikation ist bei uns als schnelle Hilfe für den Komplettausfall des Produktivservers / einzelner VMs vorgesehen, dann zwar nicht mit aktuellen Daten, aber die Leute können weiterarbeiten.
Gruß
1
Beim kritischen Sachen z.B. Exchange oder Datenbanken sichere ich beide VMs.
Beim Druckerserver reicht es die sekundäre VM zu sichern, wenn sie überhaupt repliziert wird.
Backup passiert auch immer Nachts, also würde es auch nicht die Benutzer traffictechnisch beeinflussen.
Beim Druckerserver reicht es die sekundäre VM zu sichern, wenn sie überhaupt repliziert wird.
Backup passiert auch immer Nachts, also würde es auch nicht die Benutzer traffictechnisch beeinflussen.
Welcher Backup-Traffic? Einmal die Woche, überwiegend Samstag und Sonntag in der Nacht, wird eine Vollsicherung erstellt und den Rest der Woche inkrementell. Und selbst am Tag eine Vollsicherung verursacht keinen Traffic im Netzwerk (4x 10G) oder auf dem SAN, da der Backup-Server direkt via iSCSI-over-GbE angeschlossen ist.
Hallo,
Grüße
lcer
Zitat von @DerMaddin:
Welcher Backup-Traffic? Einmal die Woche, überwiegend Samstag und Sonntag in der Nacht, wird eine Vollsicherung erstellt und den Rest der Woche inkrementell. Und selbst am Tag eine Vollsicherung verursacht keinen Traffic im Netzwerk (4x 10G) oder auf dem SAN, da der Backup-Server direkt via iSCSI-over-GbE angeschlossen ist.
Vollsicherung aller VMs täglich auf separate Bänder. Ich will keine auf verschiedene Bänder verteilte Backups.Welcher Backup-Traffic? Einmal die Woche, überwiegend Samstag und Sonntag in der Nacht, wird eine Vollsicherung erstellt und den Rest der Woche inkrementell. Und selbst am Tag eine Vollsicherung verursacht keinen Traffic im Netzwerk (4x 10G) oder auf dem SAN, da der Backup-Server direkt via iSCSI-over-GbE angeschlossen ist.
Grüße
lcer
Kann man ja auch machen. Der Weg wäre dann idealerweise erst eine Sicherung auf Blech und im zweiten Schritt, damit keine Engpässe entstehen, auf das Tape. Da kommt dann nichts in die Quere auch wenn es mal länger dauert mit dem Tape. Oder sichert ihr direkt auf Tape?
Nur so aus Neugier, wozu jeden Tag eine Vollsicherung? Man kann das ja so einrichten, dass eine Woche inkl. Inkrementell in einem Tape-Pool liegt.
Nur so aus Neugier, wozu jeden Tag eine Vollsicherung? Man kann das ja so einrichten, dass eine Woche inkl. Inkrementell in einem Tape-Pool liegt.
Hallo,
Grüße
lcer
Zitat von @DerMaddin:
Kann man ja auch machen. Der Weg wäre dann idealerweise erst eine Sicherung auf Blech und im zweiten Schritt, damit keine Engpässe entstehen, auf das Tape. Da kommt dann nichts in die Quere auch wenn es mal länger dauert mit dem Tape. Oder sichert ihr direkt auf Tape?
Direkt.Kann man ja auch machen. Der Weg wäre dann idealerweise erst eine Sicherung auf Blech und im zweiten Schritt, damit keine Engpässe entstehen, auf das Tape. Da kommt dann nichts in die Quere auch wenn es mal länger dauert mit dem Tape. Oder sichert ihr direkt auf Tape?
Nur so aus Neugier, wozu jeden Tag eine Vollsicherung? Man kann das ja so einrichten, dass eine Woche inkl. Inkrementell in einem Tape-Pool liegt.
Die Bänder werden alle außer Haus gelagert. Es sind 2x5 Bänder mit je einem Tape-Pool pro Wochentag. Wenn man da das falsche Band nimmt (z.B. Dienstag 2 statt Dienstag 1) hat man auf und in der nächsten Woche das Band überschreibt. Ist das Backup inkonsistent. Da Menschen im Gegensatz zu Computern Fehler machen, schreiben wir Voll-Backups. Nach dem Motto: wenn ein Backup auf dem Band ist, ist es auch vollständig.Grüße
lcer
Moin.
Wenn du nur die Replikate sicherst, ist das nicht anwendungskonsistent. Sprich: Ein Exchange-Server, von dem nur das Replikat gesichert wird, wird niemals ein Log-Truncating machen usw. Dito für SQL. Wenn das kein Problem für dich darstellt, ist das Konzept ok - die Nachteile hast du ja selbst schon aufgelistet.
Ich sehe aber, ähnlich wie meine Vorredner, kein Problem damit, die Produktivmaschinen per Snapshot zu sichern. Vernünftige Backup-Systeme machen "always inkrementell forever", übertragen also nur ein einziges Mal die komplette Datenmenge und danach nur noch Inkremente. Und da das Backup über die Management-IP des HyperV erfolgt und nicht über den HyperV-Switch, an dem die Clients/Server hängen, stellt das auch im Live-Betrieb eigentlich kein Problem dar.
Cheers,
jsysde
Wenn du nur die Replikate sicherst, ist das nicht anwendungskonsistent. Sprich: Ein Exchange-Server, von dem nur das Replikat gesichert wird, wird niemals ein Log-Truncating machen usw. Dito für SQL. Wenn das kein Problem für dich darstellt, ist das Konzept ok - die Nachteile hast du ja selbst schon aufgelistet.
Ich sehe aber, ähnlich wie meine Vorredner, kein Problem damit, die Produktivmaschinen per Snapshot zu sichern. Vernünftige Backup-Systeme machen "always inkrementell forever", übertragen also nur ein einziges Mal die komplette Datenmenge und danach nur noch Inkremente. Und da das Backup über die Management-IP des HyperV erfolgt und nicht über den HyperV-Switch, an dem die Clients/Server hängen, stellt das auch im Live-Betrieb eigentlich kein Problem dar.
Cheers,
jsysde
