Hyper V Best Practice

[felkr 11]

Entschuldigt bitte aber ich hätte prüfen sollen was mir der Upload Rechner da ausrechnet und dann wäre mir der Fehler aufgefallen :-)
Habe nicht mit absicht falsche Zahlen gerechnet.

 

Ich kann nur aus unserer Erfahrung sagen das wir Kunden haben die wir erfolgreich in der Cloud sichern. Da bis Größen von 2TB.

Das geht auch mit VDSL 50. Aber immer nur als Offsite Copy.

[testperson 1.675]

Und wie kommen die Daten im Worst-Case aus der Cloud zurück? ;)

[mwiederkehr 373]

Aha,

war das mit den 100 GB Änderung pro Tag mal so ins Blaue geschossen!? Wir haben bei einem täglichen Backup schon deutlich mehr Änderungsvolumen. Und das trotz Deduplication. 

Und selbst bei 'nur' 100GB brauchst Du mit  den genannten 10 MBit/s fast 23 Stunden (Im idealen Fall)!

Das war grob geschätzt. Habe mal nachgeschaut: Firma in Konstruktions- und Produktionsbranche, 15 Mitarbeiter, Terminalserver: 1.6 TB, tägliche Änderung ca. 30 GB, nach Kompression 15 GB. Aber die haben Office 365. Du hast schon Recht, würde da ein Exchange laufen, sähe es ganz anders aus.

 

Und wenn wir z.B. mal bei Veeam bleiben. Ein Forever-Incremental bläht sich auf Dauer immer mehr auf! Von daher sollte man ruhig man alle paar Monate ein Active Full machen. Ist schon Wahnsinn, was ein Regelmäßiges Active Full wieder an Platz auf dem Repository einspart!

Also alle paar Monate ein neues Vollbackup an den DL schicken?

Veeam kann in neueren Versionen die Backupdatei "defragmentieren". Bei Veeam Cloud Connect läuft das auf dem Server beim Dienstleister. (Ist ja nicht so, dass man einfach einen SMB-Share als Repository anhängt über VPN.)

 

Und wie kommen die Daten im Worst-Case aus der Cloud zurück? ;)

Der Kunde wollte Backup, von Restore hat niemand was gesagt. :) Ist aber natürlich ein wichtiger Punkt. Kenne da mehrere Möglichkeiten: Daten auf Festplatte abholen (langsam, da zwei Kopiervorgänge), Server temporär auf Infrastruktur von Dienstleister im RZ laufen lassen, Ersatzhardware ins RZ fahren und Restore direkt darauf... Kommt ganz auf den Dienstleister an, bedeutet aber auf jeden Fall mehr Aufwand als "mal kurz in Azure zusammenklicken". Wobei ich externe Sicherungen nur für den Worst Case (Brand etc.), für "Server defekt" oder "Datei gelöscht" habe ich immer eine lokale Sicherung.

[djmaker 95]

Und wie kommen die Daten im Worst-Case aus der Cloud zurück? ;)

 

Einige Anbieter für Cloud-Dienste bieten gegen Entgelt den Versand de Daten per USB-HDD oder Leih-Storage an (MS auf jeden Fall). Ich würde dann aber das Backup in die Cloud machen und dort bei einem Ausfall des eigenen RZ die Server hochfahren (VPN-Tunnel und Routing müssen natürlich passen) und parallel die gesicherten Daten zu mir senden lassen. Dann ein Resync zurück in das eigene RZ und Umschalten. Fertig.

 

Die Materie ist natürlich etwas komplexer aber das wäre der grobe Plan.

[testperson 1.675]

Einige Anbieter für Cloud-Dienste bieten gegen Entgelt den Versand de Daten per USB-HDD oder Leih-Storage an (MS auf jeden Fall). Ich würde dann aber das Backup in die Cloud machen und dort bei einem Ausfall des eigenen RZ die Server hochfahren (VPN-Tunnel und Routing müssen natürlich passen) und parallel die gesicherten Daten zu mir senden lassen. Dann ein Resync zurück in das eigene RZ und Umschalten. Fertig.

 

Die Materie ist natürlich etwas komplexer aber das wäre der grobe Plan.

 

Das wäre also deine Theorie? Hast du das auch schon mal in der Praxis umgesetzt? ;)

 

Ich habe halt schon öfters in große Augen bei Kunden geguckt, die total stolz auf Ihr Cloud Backup waren, als diese Punkte angesprochen wurden. Ebenfalls habe ich schon einmal ganz traurige Augen gesehen, als "mal eben schnell" ein Restore aus einem Cloud Backup gebraucht wurde.

[djmaker 95]

Cloud Backup hat primär nichts mit schnellem Restore zu tun (es sei denn, man kann die Backups direkt in der Cloud starten). Sollte ein Start der Server in der Cloud nicht möglich sein bzw. nicht gewollt dann ist es nur die sekundäre backup site (welche das primäre backup nicht ersetzt.

[magheinz 110]

aber wozu ein sekundäres backup an welches man im Fall der Fälle nicht schnell genug herankommt? Das dient doch nur dem theoretischen Nutzen um irgendwelche Vorgaben zu erfüllen. Einen praktischen Nutzen hat man doch nicht.