Jump to content

Relaunch 2018: Willkommen im neuen Forum - Das MCSEboard.de wurde runderneuert. Wir wünschen Euch viel Spaß an Board.

Empfohlene Beiträge

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.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

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.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

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.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

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.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

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.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

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.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Erstelle ein Benutzerkonto oder melde dich an, um zu kommentieren

Du musst ein Benutzerkonto haben, um einen Kommentar verfassen zu können

Benutzerkonto erstellen

Neues Benutzerkonto für unsere Community erstellen. Es ist einfach!

Neues Benutzerkonto erstellen

Anmelden

Du hast bereits ein Benutzerkonto? Melde dich hier an.

Jetzt anmelden

×