Jump to content

Auslagerung von Veeam Backups


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

Hallo,

da die Einschläge ständig nächer kommen, möchte ich unsere Veeam Backups auf exterene Festplatten auslagern.

 

Hier mal kurz unsere vorhandene Umgebung und verfügbare Komponenten:

3x esxi mit ca. 40 VM`s

1x dedizierter esxi auf dem ein Weindows Server 2016 mit Veeam B&R 11 für Windows Enterprise läuft

1x Datadomain DD6300 mit ausreichend Speicher

 

1x QNAPTS673-8G Nettokapazität 30TB Anbindung 10 GiB

 

Wie unser externer Dienstleister sich das vorstellt:

mit "Backup Copy Job" die Backups auf die QNAP transferieren und von dort ziehen wir dann die Backup Files auf externe Platten ab.

Das haben wir nun mal getestet und das System aktualisert dann die Daten auf der QNAP laufend und mein Zeitfenster für das Wegkopieren wird zu knapp.

 

Was ich gerade mal getestet habe:

im Veeam über "Export Backup" eine VM zu VeeamZIP exportiert und anschließend über "Restore VM Files" die exportierte VM auf die QNAP geschrieben. Das geht relativ zügig und ich habe die VM`s im "Klartext" vorliegen.

Diese kann ich dann nach Belieben auf externe Platten abziehen.

In m.A. könnte ich so wöchentlich komplette VM`s exportieren und habe diese dann auch eigenständig lauffähig ohne erst über Veeam die VBK und VIB Files zu verarbeiten.

Über einen "Backup Copy Job" könnte ich zur Sicherheit auf eine 2. noch vorhandene QNAP parallel auslagern.

 

Aber:

Mir ist allerdings das manuelle anstoßen der Exporte zu Ressourcengebunden (manuelles Eingreifen). Kann man da etwas scripten, oder hat jemand eventuell eine bessere Idee?

In unserer alten infrastruktur hatten wir die Backups mit vRanger gemacht und da konnte ich die VM`s wöchentlich auf eine QNAP sichern und von dort abziehen.

 

Hat eventuell jemand einen Tip für mich, wie ich das am sinnvollsten realisieren könnte?

 

Danke und viele Grüße

Thorsten

bearbeitet von hologram
Link zu diesem Kommentar

Ich sehe folgende Möglichkeiten für "Schutz vor Elementarereignissen und Malware":

 

Externer Speicher (S3) oder Veeam Cloud Connect. Zur Unveränderbarkeit gibt es bei S3 den Object Lock und bei Cloud Connect die "Insider Protection". Dabei werden gelöschte Sicherungen noch während x Tagen beim Provider aufbewahrt. Es schützt also sogar vor böswilligen Mitarbeitern mit allen Zugangsdaten. S3 habe ich in der Grössenordnung noch nicht verwendet. Cloud Connect würde sicher gehen, auch effizient (WAN Accelerator), aber nicht ganz günstig.

 

Wenn es nicht unbedingt ausserhalb des Gebäudes sein muss, könntest Du den Backupserver und den Speicher auch in ein separates Netzwerk nehmen. Veeam muss die ESXi erreichen können, aber nicht umgekehrt. Evtl. noch in Kombination mit einem Hardened Repository in einem anderen Netzwerk.

Link zu diesem Kommentar

hi, unsere Firmenphilosophie sieht eine Verwendung von jeglichem externen Cloudgedöns leider nicht vor.

einige unserer Kunden versagen uns dies sogar.

Das mit dem Hardened Repository werde ich mir noch mal etwas genauer anschauen.

 

gegen Umwelteinflüsse sind wir eigentlich sehr gut aufgestellt.

haben 3 RZ auf dem Campus

2 für den VMWare Cluster und 1 für das Backup.

 

Vielen Dank.

 

Link zu diesem Kommentar

Veeam sichert auf eine QNAP NAS und eine zweite steht zur Verfügung. Die zweite QNAP steht (hoffentlich) in einem anderen Brandabschnitt.

 

QNAPs können untereinander automatisiert mittels rsync Daten synchronisieren. Was ich im Moment nicht parat habe ist, ob die zweite den Sync-Prozess auslösen kann, die Zugangsdaten wären dann auf der ersten QNAP nicht bekannt (bei 2 x TrueNAS geht es).

 

Veeam ist es ziemlich egal wie die Backup Jobs gestaltet sind, wird eine oder mehrere VM(s) einzeln benötigt kann man einen extra Job aufsetzen.

bearbeitet von muenster
Link zu diesem Kommentar

Bei dieser Ausgangslage würde ich mich auf die Separierung der Backupinfrastruktur vom produktiven Netzwerk konzentrieren und evtl. SureBackup anschauen. Das hilft, besonders fiese Malware zu entdecken, welche die Daten transparent verschlüsselt und erst später den Schlüssel verwirft. SureBackup kann regelmässig die Backups auf Malware prüfen, Prüfsummen von Dateien in Backups vergleichen und VMs aus dem Backup isoliert starten und prüfen, ob sie funktionieren.

Link zu diesem Kommentar

Hallo,

das verwendete Backup Repository ist aktuell keine QNAP sondern eine Dell Datadomain DD6300 mit 34TB Nettokapazität.

Diese unterstützt Deduplizierung und Komprimierung.

Das hat unter anderem in Kombination mit Veeam den Vorteil dass ich sehr viele Wiederherstellungspunkte ablegen kann.

Und genau diese will ich ja wegspeichern und auslagern. Mir würden wie eingangs beschrieben auch wöchentliche Auslagerungen der kompletten VM`s schon genügen.

 

Ich sehe schon, sehr komplexes Thema.

 

Link zu diesem Kommentar
  • 2 Wochen später...

Schon ne Woche her aber Thema ist ja überall aktuell ;)

Bin auch noch an einem neuen Standardverfahren am austüpfteln für kleinere Umgebungen. Gar nicht so easy wenn man auf Cloud verzichten möchte und den Faktor Mensch bezüglich Zuverlässigkeit auch möglichst dezimieren möchte.

 

Ein paar Vorschläge, evtl. auch kombiniert:

- Das bereits genannte Hardened Repository auf einer Linux-Kiste für das Repo (Scheint ziemlich gut zu sein, zumindest bis jemand das Linux knackt)

- LTO-Tapes --> Evtl. mit nem Loader und einem Band pro Tag (Sind die Daten wirklich geschützt? Könnten ja theoretisch auch gelöscht werden wenn man zugriff auf die Kiste hat)

- LTO-Tapes mit WORM --> Vermutlich der sicherste weg, aber ein (sehr) teurer Spass wenn man immer neue Tapes braucht. =)

- Kleine SAN mit Snapshots als Backup-Rep --> ziemlich sicher aber auch ziemlich teuer. Man kann Snapshots ziehen, sollte das Rep unbrauchbar werden, kann ein snapshot wiederhergestellt werden --> Volume läuft bei Ransomware evtl. rasch voll, snapshot nicht konsistent

- Windows mit NFS als Backupvolume (statt SMB), alles per interner oder separater Firewall blockieren ausser eben NFS. Mit eigenem oder keinem AD. VSS-Snapshots die man z.Bsp. nach Abschluss der Backups konsinstent oder auch inkonistent ziehen und nochmals wegkopieren kann, intern und/oder separte Maschine. Man hat aktuelle Versionsstände und ist theoretisch nicht anfällig auf gängige Windows-Sicherheitslücken. Dafür hat man aber den Komfort bezüglich Verwaltung, Tape-Anbindung, RAID-Controller, Storage-Spaces etc. Nur mit dem NFS-Protokoll/Port Windows an sich anzugreifen dürfte vermutlich schwierig sein. Dürfte für alle Nicht-Linuxer eventuell ein ganz guter und auch eher kostengünstiger Weg sein. Dahinter könnte man dann z.Bsp. eine kleine Testinfrastruktur/Virtual Lab haben wo man Kopien/Snapshots anstartet.

Vielleicht ein Handy-LAN-Adapter für den Remotezugriff den man per Hardwareschalter zu oder abschaltet für ein Fernwartungstool.

Link zu diesem Kommentar
vor 53 Minuten schrieb Weingeist:

- LTO-Tapes --> Evtl. mit nem Loader und einem Band pro Tag (Sind die Daten wirklich geschützt? Könnten ja theoretisch auch gelöscht werden wenn man zugriff auf die Kiste hat)

 

Naja es könnte auch einer alle Rechenzentren anzünden. :) Also wenn jemand an das Band (physikalisch) rankommt, kann er es auch einfach plattmachen (physikalisch). Das sollten die Prozesse schon hergeben, dass da nur befugte Personen rankommen. Ansonsten ist mir zumindest bisher noch keine Malware bekannt, die Tapedrives gezielt attackiert, ich persönlich würde das also immer noch als sicheres Medium ansehen, weil man es eben relativ einfach zwischen den RZs (oder sogar noch ganz woanders hin) auslagern kann. Preislich ist das in meinen Augen auch interessant, weil da TB gar kein Problem darstellen. Einfach nur den Wechsler groß genug wählen. ;)

 

LTO-WORM sind in meinen Augen dazu der falsche Ansatz, denn die verfolgen ja den Ansatz die Daten unveränderbar auch Band haben zu müssen. Das dürfte bei "normalen" Backups selten bis nie der Fall sein.

 

Bye

Norbert

Link zu diesem Kommentar

HI,

bin aktuell dran, dass mit "Export Backup" in das VeeamZIP zu exportieren und von dort über "VM Restore" dann auf die QNAP zu transferieren.

Der Vorteil ist, dass ich auf der QNAP dann die VM`s im Klartext habe.

 

Manuell funktioniert das einwandfrei und hat auch eine saubere Prozessgeschwindigkeit.

 

Ich werde mich am Montag mal dransetzen, dass per Powershellscript entsprechend zu automatisieren.

 

So habe ich auf jeden Fall ein brauchbares Ergebnis, obwohl etwas umständlich.

 

Ich werde weiter berichten.

VG

Thorsten

Link zu diesem Kommentar
vor 2 Stunden schrieb Weingeist:

Windows mit NFS als Backupvolume (statt SMB)

Man kann den Backupserver auch ganz abschotten: er bekommt Zugriff auf die Hosts, aber die Hosts nicht auf ihn. Also separates VLAN oder zweites Interface an der Firewall. (Oder allenfalls Windows Firewall in kleinen Umgebungen.) Zugriff auf den Backupserver nur per RDP, TeamViewer oder Guacamole und nur vom Admin-Netzwerk aus.

Link zu diesem Kommentar

@NorbertFe Bezüglich Tape attackieren: Naja, ich meine jetzt weniger die Tapes die nicht mehr im Wechsler sind, sondern jene die noch drinn sind. Ist ja mühsam das Zeug jeden Tag aus dem Loader zu nehmen. Lässt man sie drinn, können die Tapes ja theoretisch geleert werden. Es werden ja bereits Veeam-Repos automatisiert geleert... Die Linux-Hardened Repos bis dato noch nicht.

 

@mwiederkehr Das meine ich ja, möglichst komplett abschotten. Ist halt wirklich die Frage ob ein Backupserver wirklich per SMB komplett abgeschottet werden kann. Irgendwie müssen ja die Daten geschrieben werden. Keine Ahnung ob das ohne Hin und her Kommunikation möglich ist. Zudem spricht ESXi NFS und NFS ist tendenziell dümmer als SMB. Sonst kann ja theoretisch ein Löschvorgang passieren sobald ein Host kompromitiert wurde.

Link zu diesem Kommentar
vor 8 Minuten schrieb Weingeist:

Naja, ich meine jetzt weniger die Tapes die nicht mehr im Wechsler sind, sondern jene die noch drinn sind. Ist ja mühsam das Zeug jeden Tag aus dem Loader zu nehmen. Lässt man sie drinn, können die Tapes ja theoretisch geleert werden. Es werden ja bereits Veeam-Repos automatisiert geleert... Die Linux-Hardened Repos bis dato noch nicht.

 

Ja natürlich ginge das. Aber ich würde stark behaupten, dass sowas 1. selten ist und 2. natürlich aus dem Wechsler trotzdem physisch ausgelagert werden muss. Wie oft und wieviel muss halt das Backup und Recovery Konzept festschreiben.

Link zu diesem Kommentar

Naja, die Zahlen gehen ja stark in die Höhe und die Angriffe werden immer ausgefeilter/automatisierter.

Ich kenn das halt von früher. Das mit dem Tape-Wechseln ist einfach ka**e wenn das nicht ein Admin macht und der ist im kleinen nunmal selten vor Ort.

 

Bezüglich Worm: Ich stellte mir halt etwas "Halb-Wormiges" vor. Also ein Änderungs und Lösschutz auf Hardwareebene aber ohne Neuschreibschutz auf leerem Platz. Weiss nicht wie das aktuell gehandhabt wird wenn das normale Band gelockt wird. Habe schon länger keine Bänder mehr im Einsatz, aber aus aktuellem Anlass halt wieder in den Vordergrund gerückt.

 

Wäre total easy so Full + Increments vorzuhalten bzw. am liebsten nur jeweils ein aktuelles Delta zum Full. Quasi perfekt für kleine Umgebungen 8er oder 24er loader, 1-2 Tapes pro Wochentag und gut ist. Nach dem Patchday oder wenn viele Daten geändert werden halt nen neues Full auf neue Sätze.

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...