Question

Backup Strategien mit Veeam für kleine vSphere-Umgebungen


Userlevel 3

Liebe Leute,

bei vorgestellten Beispielen für sinnvolle Backup-Szenarien wird typischerweise eine große Infrastruktur vorausgesetzt die so in der alltäglichen österreichischen KMU-Welt eigentlich nicht gegeben ist. Ich wäre sehr interessiert wie man kleine vSphere-basierende Umgebungen (Vsphere-Essentials Plus Umgebung) mit Veeam B&R schlüssig sichert und wiederherstellt. Im genannten Umfeld gibt es ja maximal 3 vSphere Hosts - typischerweise kein SAN sondern mit Storage an den Hostservern selbst.
Hat wer in der Community ebenfalls eine solche Umgebung? Was für eine Strategie wird verwendet und wie wird sie implementiert um z.B. eine GVS umzusetzen und gegen Ransomware und Co abgesichert zu sein?
Rudolf


25 comments

Userlevel 7
Badge +3

Hallo Rudi!

VBR kommt ja aus dem Klein-Kunden Segment. Daher kann man in dem Bereich auch sehr flexible Lösungen bauen. Zum Beispiel könnte der VBR Server virtuell laufen und auf ein SMB/NAS/iSCSI Gerät sichern. Nach Bedarf natürlich auch Copy auf weiteres Device. Wenn kein shared Storage vorhanden ist, werden hier VMs mittels NBD Transport Mode abgesaugt. Da Backup-Performance in der Größenordnung ohnehin selten eine große Rolle, wird das kein Problem sein. Natürlich ist auch denkbar, wichtige VMs mittels Replication zwischen den Hosts mit lokalen Disken zu duplizieren. Replication ist ja in jeder Veeam Edition inklusive! Soll auf Tape gesichert werden, ist definitiv ein physischer Windows-Host erforderlich. Wenn ein paar prinzipielle Sicherheitsregeln befolgt werden (keine Komponente in die Domäne, sichere und eigene Passwörter, …) ist auch ein gewisser Ransomware Schutz gegeben.

Was meinst du mit GVS? Da stehe ich gerade auf der Leitung.

 

Userlevel 6
Badge +1

Aus GVS hätte ich GFS abgeleitet; liege ich da richtig?

Auch im KMU Umfeld setzen wir meist auf einen kleinen dedizierten Backupserver mit einem einzelnen Band Laufwerk. Durch die Band-Rotation lässt sich eine Langzeitaufbewahrung erreichen; z.b. 5 Tage, 4 Wochen und 12 Monate. Wichtig ist in einer solchen Umgebung, meiner Meinung nach, der tägliche Wechsel der Bänder zum Schutz vor Ransomware/Sabotage.

Ohne shared-storage würde ich eine Replication zwischen den Hosts einrichten um die Ausfallsicherheit zu erhöhen oder bei Wartungsarbeiten migrieren zu können.

Fehlt das Budget für einen Backupserver könnte dieser, wie Wolfgang schreibt, virtuell abgebildet werden. Als Sicherungsziel dann aber ein externes Storage wie ein NAS per iSCSI. Und mangels Tape dann eine Cloud Kopie, wenn die Bandbreite dafür reicht.

Userlevel 7
Badge +1

Wir haben unter anderem eine solche Klein-Umgebung mit drei ESX Hosts.

Dort haben wir einen virtuellen VBR Server implementiert und die Backup Daten gehen auf ein QNAP NAS. Die Datenmenge im NAS Repository ist insgesamt ca. 15 TB.

Funktioniert soweit alles gut. Ganz glücklich bin ich nicht damit wegen der fehlenden Redundanz der Backups. Hier könnte man noch eine kleine Tape Lösung dazu nehmen. Das ist mit einem virtuellen Server nicht ideal. Wolfgangs Vorschlag des kleinen physischen Servers mit einem Bandlaufwerk ist hier wohl praktikabler, wenn man Taoe haben möchte. Wahrscheinlich wäre ein Cloud Object Storage das Einfachste. Aber der der Kunde wollte nicht mehr Geld ausgeben. Zumindest solange noch nichts passiert ist…. 😄 

Userlevel 3

Hallo Regnor, Wolfgang:

GVS ist die eingedeutschte Variante von GFS: Großvater, Vater, Sohn = Grandfather, Father, Son :-)

Userlevel 3

Ich verwende bei einem Kunden mit besagter Essential Plus-Umgebung 3 vSphere Host Server wobei jene VM die sehr zeitkritisch bei der Wiederherstellung wären jeweils als Replication Job auf einen anderen vSpherehost ein Replikat anlegen. Die Backup-Jobs selbst sind mit GVS aka GFS eingestellt. Wie würdet Ihr das GFS selbst konkret einstellen bezüglich der Aufbewahrungseinstellungen (Tage, Woche, Jahr)?

Userlevel 3

@JMeixner : Ja, ein latentes Problem das kleine Betriebe immer erst dann bereit sind in die Tasche zu greifen wenn es bereits einen Gau gegeben hat :-( .
Als Cloud-Speicher könnte man auch Wasabi verwenden? Da gibt es ja eine Zusammenarbeit mit Veeam. Jedenfalls werde ich das mittelfristig mal einbeziehen und testen weil das ein sehr günstiger s3-kompatibler Anbieter ist.

Userlevel 3

Wir haben unter anderem eine solche Klein-Umgebung mit drei ESX Hosts.

Dort haben wir einen virtuellen VBR Server implementiert und die Backup Daten gehen auf ein QNAP NAS. Die Datenmenge im NAS Repository ist insgesamt ca. 15 TB.

Funktioniert soweit alles gut. Ganz glücklich bin ich nicht damit wegen der fehlenden Redundanz der Backups. Hier könnte man noch eine kleine Tape Library dazu nehmen, das ist aber wegen der Fiber Channel Verbindung mit dem virtuellen Server nicht ideal, hier ist Wolfgangs Vorschlag des kleinen physischen Servers mit einem Bandlaufwerk praktikabler. Wahrscheinlich wäre ein Cloud Object Storage das Beste. Aber der der Kunde wollte nicht mehr Geld ausgeben. Zumindest solange noch nichts passiert ist…. 😄 

Genau so läuft das bei besagtem Kunden bei mir auch :-)

Userlevel 7
Badge +1

@JMeixner: Ja, ein latentes Problem das kleine Betriebe immer erst dann bereit sind in die Tasche zu greifen wenn es bereits einen Gau gegeben hat :-( .
Als Cloud-Speicher könnte man auch Wasabi verwenden? Da gibt es ja eine Zusammenarbeit mit Veeam. Jedenfalls werde ich das mittelfristig mal einbeziehen und testen weil das ein sehr günstiger s3-kompatibler Anbieter ist.


Mit Wasabi habe ich bisher keine praktischen Erfahrungen. Muss ich mir bei Gelegenheit mal anschauen.

Userlevel 3

Kann man das “Best answer” irgendwie rückgängig machen? Bin irgendwie drauf gekommen… :-)

Userlevel 7
Badge +1

Mhh, ich glaube, selber kann man das nicht zurücksetzen.

Hello @Kseniya , is it possible to reset a Best answer selection? @Rudolfo has selsted it unintentionally...

Userlevel 7
Badge +1

It’s fixed, @JMeixner 😌

Userlevel 3

@Kseniya@JMeixner , thank you both for correcting it, because this topic could bring up some more examples :thumbsup:

Userlevel 6
Badge +1

Hallo Regnor, Wolfgang:

GVS ist die eingedeutschte Variante von GFS: Großvater, Vater, Sohn = Grandfather, Father, Son :-)

Dann passts ja :)

Wie würdet Ihr das GFS selbst konkret einstellen bezüglich der Aufbewahrungseinstellungen (Tage, Woche, Jahr)?

Pauschal kann man das schlecht sagen, da es sehr von den Kundenanforderungen abhängt. Wenn es gar keine Anforderung gibt empfehle ich meist 14 Tage, 4 Wochen, 12 Monate und dann X Jahre.  Wobei die 14 Tage sowohl auf dem primären als auch sekundären Storage sind, alles ältere dann nur noch auf dem Sekundären. ReFS/XFS zusammen mit GFS habe ich bisher eher selten eingesetzt.

 

 

Userlevel 4
Badge +1

Though the post is in German, I translated into English and enjoyed it thoroughly. 

Userlevel 3

@regnor - Danke für Dein Beispiel! Was ist Dein Motiv für gerade 14 Tage?
Ein längerer Zeitrahmen für die schnelle Wiederherstellbarkeit von zeitnahen Sicherungen?
Wäre eine vollständige Objekt-Abdeckung nicht schon auch nach 7 Tagen gegeben?
Es geht ja auch um eine effiziente Speicherplatzbenutzung - oder überwiegt der Vorteil der mehr zeitnahen Wiederherstellungspunkte den erhöhten Speicherbedarf bei 14 Tagen?

Userlevel 3

Though the post is in German, I translated into English and enjoyed it thoroughly. 

Joy is one of the best goals to reach …. :-)

Userlevel 7
Badge +3

Würde nicht unter 14 Tage für tägliches Backup gehen. Es gibt Ransomware (oä.) die sich im System einnistet und erst nach Tagen oder Wochen aktiv wird. Somit könnte es ein, dass bereits alle täglichen Backups “befallen” sind, wenn die Anzahl der Restore-Points zu gering ausfällt. Wenn möglich, würde ich einen Zeitraum von ca. 30 Tagen anpeilen.

Userlevel 7
Badge +1

Wieviele VMs mit was für einer Gesamt Datenmenge habt ihr denn? Bei 30 Versionen für alles würden mir bei vielen Kunden alle Storages platzen…

Macht ihr wöchentliche synthtic Fulls oder incremental forever?

Userlevel 7
Badge +3

Wieviele VMs mit was für einer Gesamt Datenmenge habt ihr denn? Bei 30 Versionen für alles würden mir bei vielen Kunden alle Storages platzen…

Macht ihr wöchentliche synthtic Fulls oder incremental forever?

Da hast du natürlich recht! Wäre eher ein Wunsch. Alternativ kann GFS am primären Job konfiguriert werden. Also zB: 14xtäglich, 4xwöchentlich. Wenn die böse Software drei Wochen wartet, bevor sie loslegt, wäre der Datenverlust damit größer.

Userlevel 3

@vNote42 : Also wenn ich das richtig verstehe: Bezüglich Absicherung gegen “schlafende Ransom-Software” müsste man den verfügbaren Backupspeicher voll ausreizen - je mehr Tage desto gut. Weil wenn sich jetzt in der Praxis z.B. das mit 14 Tagen als gängige Praxis etabliert ist es ja nur eine Frage der Zeit bis Bösewichte auf eine solche gängige Praxis reagieren.
Das heißt es gibt also prinzipiell immer das Restrisiko dass eine “Schläfer-Software” einfach nur lange genug “schlafen” muss bevor sie aktiv wird.
Fazit für mich: Ausreizen der Zeitspanne der täglich behaltenen Backups so wie es der dafür vorgesehene Speicherplatz hergibt der einem vom Kunden vegönnt wird + Information an den Kunden über diesen Zusammenhang. 100% Sicherheit gibt es nicht wir können uns nur sehr nahe an 100% annähern wenn wir mehr Speicherplatz für diese Zwecke zugestanden/genehmigt bekommen.

Da fällt mir dann immer der Spruch ein: “Wenn Du willst dass etwas sicher ist dann darf es nicht funktionieren/funktional sein!” :-)

 

Userlevel 7
Badge +3

@vNote42: Also wenn ich das richtig verstehe: Bezüglich Absicherung gegen “schlafende Ransom-Software” müsste man den verfügbaren Backupspeicher voll ausreizen - je mehr Tage desto gut. Weil wenn sich jetzt in der Praxis z.B. das mit 14 Tagen als gängige Praxis etabliert ist es ja nur eine Frage der Zeit bis Bösewichte auf eine solche gängige Praxis reagieren.
Das heißt es gibt also prinzipiell immer das Restrisiko dass eine “Schläfer-Software” einfach nur lange genug “schlafen” muss bevor sie aktiv wird.
Fazit für mich: Ausreizen der Zeitspanne der täglich behaltenen Backups so wie es der dafür vorgesehene Speicherplatz hergibt der einem vom Kunden vegönnt wird + Information an den Kunden über diesen Zusammenhang. 100% Sicherheit gibt es nicht wir können uns nur sehr nahe an 100% annähern wenn wir mehr Speicherplatz für diese Zwecke zugestanden/genehmigt bekommen.

Da fällt mir dann immer der Spruch ein: “Wenn Du willst dass etwas sicher ist dann darf es nicht funktionieren/funktional sein!” :-)

 

Schön zusammengefasst! 30 Tage, denke ich, ist ein guter Wert! Natürlich hast du recht, ist nur eine Frage der Zeit, bis sie 40 Tage wartet, bevor sie zum Verschlüsseln/Löschen beginnt. Wobei das dann wieder egal wäre, ob ich nun 30 Tage oder nur 14 Tage tägliches Backup hätte. Da geht es eher um 2-4 Wochen Schlummer-Zeit – GFS im Job vorausgesetzt.

Nachdem du mit der 100%ige Sicherheit 100% recht hast, können wir nur versuchen, es den Bösen so schwer wie möglich zu machen!

Userlevel 6
Badge +1

Die 14 Tage haben sich so ergeben, dass die meisten Restores aus diesem Zeitraum passieren. Dadurch erspart man sich häufige Wartezeiten beim Restore von z.B. Band. Mit ReFS sollte der zusätzliche Speicherbedarf sich in Grenzen halten; da könnten auch 21 oder 30 Tage möglich sein.

Bei Ransomware ist GFS nur ein Teil der ganzen Lösung. Wichtig ist da dann die Auslagerung auf ein sicheres Medium; der primäre Backupserver könnte beim Angriff auch verloren gehen. Wie ihr auch schreibt eine 100% Sicherheit gibt es nicht.

Userlevel 6
Badge +1

Wieviele VMs mit was für einer Gesamt Datenmenge habt ihr denn? Bei 30 Versionen für alles würden mir bei vielen Kunden alle Storages platzen…

Macht ihr wöchentliche synthtic Fulls oder incremental forever?

Wenn du ReFS nutzt und die Änderungen der VMs sich in Grenzen halten, könntest du prüfen ob eine höhere Aufbewahrung möglich ist.

Userlevel 3

Das Grundproblem “schlafender Befall” und Du weißt nichts davon, ist Der Knackpunkt an der ganzen Sache.
Also wenn dieser Fall eintritt würde ich einem Kunden raten (nachdem man das erkannt hat) sofort damit zu beginnen ein paralleles, unabhängiges Produktivsystem in unabhängiger Netzwerkinfrastruktur (VLAN/oder überhaupt eigene Switches) hochzuziehen und in dieses nur mehr verifizierte, geprüfte Daten zurückzuspielen. Die alten VM-Backup-Images wegwerfen bzw. Last Known Good - Versionen von den VM immuteable archivieren.
Das ist der steinige, teure Weg aber wahrscheinlich langfristig der bessere und unterm Strich günstigere Weg. Zumindest würde ich das so machen wollen - der Kunde müsste aber natürlich auch davon überzeugt sein - ist ja dann letztlich auch meine Aufgabe dass schlüssig zu argumentieren und zu “verkaufen”.
Wie würdet Ihr vorgehen wenn dieses Szenario eintritt dass ihr kein verlässliches Backup mehr habt oder davon ausgehen müsst?

Userlevel 6
Badge +1

Es hängt natürlich von der Art des Befalls ab. Bei einfachen Cryptotrojanern, also eher solchen die auf Privatanwender abzielen, ist der Restore nicht ganz so dramatisch. Bei komplexen Befällen oder Angriffen wird man wahrscheinlich den, von dir beschriebenen, Weg gehen müssen. Wenn sich das Event zeitlich nicht mehr sicher eingrenzen lässt, müssten alle Systeme neuinstalliert und nur die Nutzdaten, nach Prüfung, zurückgespielt werden. Das kann in kleinen Umgebungen vll noch einfacher gehen aber in größeren Infrastrukturen wird das keinen Spaß machen...zum Glück habe ich so einen Fall noch nicht mitgemacht.

Comment