Empfehlungen für eine effiziente Offsite-Remote-Backup-Lösung von VMs

Ich suche nach Empfehlungen zum Sichern meiner aktuellen 6-VMS (und bald auf bis zu 20). Zur Zeit führe ich einen Zwei-Knoten-Proxmox-Cluster aus (bei dem es sich um eine Debian-Basis handelt, die KVM für die Virtualisierung mit einem benutzerdefinierten Web-Front-End zur Verwaltung verwendet). Ich habe zwei fast identische boxen mit amd phenom ii x4 und asus motherboards. Jedes hat 4 500 GB sata2-Festplatten, 1 für das Betriebssystem und andere Daten für die Installation von proxmox und 3 für die gemeinsame Nutzung der 1,5 TB Speicher zwischen den beiden Computern mit mdadm + drbd + lvm. Ich mounte lvm-Images für alle virtuellen Maschinen in kvm. Derzeit kann ich in der Regel innerhalb von Sekunden eine Live-Übertragung von einem Computer auf den anderen durchführen (auf dem größten virtuellen Computer, auf dem win2008 mit m $ sql-Server ausgeführt wird, dauert es ungefähr 2 Minuten). Ich verwende das in proxmox integrierte vzdump-Dienstprogramm, um Schnappschüsse von der vm 'zu machen. s und speichern Sie diese auf einer externen Festplatte im Netzwerk. Ich habe dann Jungledisk-Dienst (mit Rackspace), um den vzdump-Ordner für die Remote-Offsite-Sicherung zu synchronisieren.

Das ist alles in Ordnung und gut, aber nicht sehr skalierbar. Zum einen können die Backups selbst jede Nacht einige Stunden dauern. Bei inkrementellen Übertragungen auf Blockebene von Jungledisk wird bei der Synchronisierung nur ein kleiner Teil der Daten außerhalb des Standorts übertragen, dies dauert jedoch mindestens eine halbe Stunde.

Die viel bessere Lösung wäre natürlich etwas, das es mir ermöglicht, die Differenz von zwei Zeitpunkten (sagen wir, was von 6 Uhr morgens bis 7 Uhr morgens geschrieben wurde) sofort zu erfassen, sie zu komprimieren und dann diese Differenzdatei an den Backup-Server zu senden, der sie sofort auf den Server überträgt Remotespeicher auf dem Rack. Ich habe ein wenig in zfs geschaut und es ist die Fähigkeit zu senden / empfangen. Das gepaart mit einer Pipe der Daten in bzip oder so scheint perfekt. Es scheint jedoch, dass die Implementierung eines Nexenta-Servers mit ZFS im Wesentlichen mindestens einen oder zwei weitere dedizierte Speicherserver erfordert, um iSCSI-Block-Volumes (über ZVOLs ???) an die Proxmox-Server zu liefern. Ich würde es vorziehen, das Setup so gering wie möglich zu halten (dh KEINE separaten Speicherserver zu haben), wenn dies überhaupt möglich ist.

Ich habe auch kurz zumastor gelesen. Es sieht so aus, als könnte es auch tun, was ich will, aber es scheint die Entwicklung im Jahr 2008 gestoppt zu haben.

Also, zfs, zumastor oder sonstiges?

In Ihrer Situation ist dies möglicherweise nicht möglich, daher hoffe ich, dass ich in diesem Fall nicht herabgestimmt werde. Es ist jedoch möglicherweise effizienter, Ihre Sicherungsstrategie zu ändern. Wenn Sie bestimmte Daten anstelle von VM-Snapshots sichern, werden Ihre Backups viel schneller ausgeführt und es ist einfacher, Änderungen zu erfassen.

Abhängig von Ihren VMs und dem Zweck, für den sie verwendet werden, können Sie sie einfach dazu bringen, Daten täglich an dem Ort zu sichern, an dem Sie die Snapshots jetzt speichern (oder nach welchem ​​Zeitplan auch immer), und JungleDisk kann dann nur die Daten sichern. Dadurch würden geänderte Dateien effizienter übertragen und der für Sicherungen erforderliche Speicherplatz sowie die benötigte Zeit verringert. Darüber hinaus können Sie noch Schnappschüsse aufnehmen, um diese zu speichern, und dies viel seltener (z. B. wöchentlich).

In diesem Fall können Sie jederzeit eine neue VM aufrufen und Daten wiederherstellen oder einen älteren Snapshot verwenden, um die VM wiederherzustellen. Anschließend können Sie die Datensicherung verwenden, um den neuesten Stand wiederherzustellen.

Wenn ich Offsite-Backups machen würde, würde ich die folgenden Optionen wählen:

(a) Shell-Skript, mit dem SCP auf den Remote-Server kopiert. Auf diese Weise können Sie einen Cron-Job hinzufügen, der automatisch das Skript ausführt, mit dem die Sicherung erstellt wird. Außerdem können Sie festlegen, dass vor dem eigentlichen Übertragen der Dateien eine temporäre Archivdatei erstellt wird, wodurch Bandbreite gespart wird, indem beim Sill-Gziping keine Übertragung erfolgt.

oder

(b) Installieren Sie ein Server-Management-Tool wie Webmin, und führen Sie damit automatisierte Sicherungen durch. Ich singe dies momentan ohne Probleme auf meinen Produktionsservern. Es funktioniert einfach einwandfrei. Ich würde auch cloudmin (kostenpflichtig) für die Verwaltung vieler VMs empfehlen, da es eine All-in-One-Lösung bietet.

Einige zusätzliche Links:

http://www.debianhelp.co.uk/backup.htm

http://ubuntuforums.org/showthread.php?t=35087

Hoffe das hilft, RayQuang

Vielleicht möchten Sie einen Blick auf backuppc werfen.

backuppc kann mit rsync arbeiten, das inkrementelle Kopien erstellt.

Außerdem können Sie ganz einfach eine schwarze Liste von Ordnern erstellen, die nicht gesichert werden müssen. Zum Beispiel: temp / / tmp .garbages / ...

http://backuppc.sourceforge.net/

backuppc verfügt über eine übersichtliche Weboberfläche, über die Sie einige Teile eines Backups direkt als ZIP-Datei herunterladen können. Es kann von Nagios mit check_backuppc überwacht werden.

Ich bin mir nicht sicher, wie viele architektonische Änderungen Sie vornehmen wollten, um Ihre Skalierbarkeit zu verbessern. Wenn Sie jedoch bereit wären, die VM-Plattform zu wechseln, können Sie sich VMWare ansehen.

Es gibt viele gute VMWare-Backup-Lösungen, ich persönlich habe VzionCore verwendet. Sie können dann mit Snapshots und Zeitpunkt-Wiederherstellung einige raffinierte Aufgaben ausführen. Es besteht sogar die Möglichkeit, ein Failover auf einen Remotestandort durchzuführen.

zfs macht es großartig, Sie haben bereits erwähnt, dass dies jedoch der Nachteil ist, dass es auf der 2-Server-Skala nicht gut funktioniert. Es gibt Ihnen auch kein DRDB-Failover, dh Nexenta ist eine einzige Fehlerquelle.

Sie können versuchen, VirtualBox auf OpenSolaris oder NexentaCore zu installieren, aber nicht so einfach wie ProxMox + DRDB, damit Sie Ihre vorhandenen Maschinen wiederverwenden können.

Wenn Sie Ihre Änderungen messen und sie niedrig genug finden, können Sie DRDB mit einem dritten Spiegel außerhalb des Standorts testen. Dies funktioniert nur, wenn die Anzahl der Schreibvorgänge auf Ihren VMs extrem niedrig ist.

Steve Radich - Windows-Hosting und SQL-Leistung seit 1995 - http://www.BitShop.com/Blogs.aspx

Ich führe einen großen Proxmox-Cluster aus und muss vorschlagen, dass Sie Ihre Sicherungsstrategie ändern, anstatt die in vzdump-Snapshots integrierten Sicherungen zu verwenden, die ewig dauern, immer voll und daher groß sind und die Wiederherstellung einzelner Dateien extrem langwierig machen.

Stellen Sie sich eine Backup-Lösung vor, von der es viele gibt. Backuppc, Urbackup, Bacula, Amanda etc ...

Es wird viel schneller sein, viel weniger Platz verbrauchen und es wird viel einfacher sein, bestimmte Dateien wiederherzustellen.

Ich glaube, ich habe die ultimative Antwort auf meine Frage gefunden:

BUP https://github.com/bup/bup

Eigenschaften:

• Es verwendet einen rollierenden Prüfsummenalgorithmus (ähnlich wie rsync), um große Dateien in Blöcke aufzuteilen. Das nützlichste Ergebnis ist, dass Sie große VM-Images, -Datenbanken und XML-Dateien inkrementell sichern können, auch wenn sie normalerweise alle in einer großen Datei enthalten sind und nicht Tonnen von Speicherplatz für mehrere Versionen benötigen.

  Es verwendet das Packfile-Format von git (dem Open Source-Versionskontrollsystem), sodass Sie auf die gespeicherten Daten zugreifen können, auch wenn Sie die Benutzeroberfläche von bup nicht mögen.

  Im Gegensatz zu git werden Packfiles direkt geschrieben (anstatt eine separate Garbage Collection / Repacking-Phase zu haben), so dass es auch mit unglaublich großen Datenmengen schnell geht. Mit den verbesserten Indexformaten von bup können Sie auch weit mehr Dateinamen als git (Millionen) und weit mehr Objekte (Hunderte oder Tausende von Gigabyte) verfolgen.

  Daten werden "automatisch" zwischen inkrementellen Sicherungen geteilt, ohne dass bekannt sein muss, welche Sicherung auf welcher anderen basiert - auch wenn die Sicherungen von zwei verschiedenen Computern erstellt werden, die sich nicht einmal kennen. Sie müssen bup nur anweisen, die Daten zu sichern, und es wird nur die minimale Datenmenge gespeichert, die benötigt wird.

  Sie können direkt auf einem Remote-Bup-Server sichern, ohne dass Tonnen temporären Speicherplatzes auf dem zu sichernden Computer erforderlich sind. Und wenn Ihre Sicherung zur Hälfte unterbrochen wird, setzt der nächste Lauf an der Stelle an, an der Sie aufgehört haben. Und es ist ganz einfach, einen BUP-Server einzurichten: Installieren Sie BUP einfach auf jedem Computer, auf den Sie SSH-Zugriff haben.

  Bup kann "par2" -Redundanz verwenden, um beschädigte Backups wiederherzustellen, selbst wenn Ihre Festplatte fehlerhafte Sektoren nicht erkannt hat.

  Selbst wenn ein Backup inkrementell ist, müssen Sie sich nicht um das Wiederherstellen des vollständigen Backups kümmern. Ein inkrementelles Backup verhält sich so, als wäre es ein vollständiges Backup, es nimmt nur weniger Speicherplatz in Anspruch.

  Sie können Ihr bup-Repository als FUSE-Dateisystem bereitstellen und auf diese Weise auf den Inhalt zugreifen und ihn sogar über Samba exportieren.

Edit: (19. August 2015) Und noch eine weitere großartige Lösung, die noch besser ist: https://github.com/datto/dattobd

Es ermöglicht Live-Snapshots und bietet COW-ähnliche Funktionen für jedes normale alte Dateisystem unter Linux.

Edit: (15. Juli 2016) Und noch eine großartige Lösung, die das Wasser in die Luft jagt: https://github.com/borgbackup/borg

Es ist besonders besser als Bup beim Beschneiden. Es scheint eine hervorragende Unterstützung für Komprimierung, Verschlüsselung und effiziente Deduplizierung zu bieten. dattobd + borg ftw !!!