Proxmox Backup Lösungen

[maxprox]

Für ein Backup auf Datei Ebene sei unbedingt BackupPC erwähnt:
Ein geniales Tool das dateibassiert Linuxsysteme agentenlos über ssh (keys) und rsync sichert. Der Clou hier ist das holen der Backups vom BackupPC Server aus, ohne das umgekehrt irgenwelche Rechte oder Zugriffe nötig sind. Daher per se hohe Sicherheit vor Schädlingsübergriffe von zB Windows auf die Backups. Vom gesicherten System existieren keine Zugriffsrechte auf die Backups bzw. Backuplaufwerke. Aufgrund von Hardlinks und Delta Backups sehr schnell und effizient. Windowse können per smb oder - so machen wir das - nach Installation eines rsync Dienstes (wir verwenden dazu DeltaCopy) geht das mit Windows ebenso effizient und schnell. siehe:
http://backuppc.sourceforge.net/
https://sourceforge.net/projects/backuppc/files/backuppc/
https://backuppc.github.io/backuppc/BackupPC.html
BackupPC-4-from-tarball-or-git-on Debian or Ubuntu
Die in den Repositories enthaltene 3er Version läuft stabil und gut, trotzdem installiere ich hier und da bereits die aktuelle 4er, weil sie mit erweitertem Delta Backup noch effizienter ist als die 3er. Ich hoffe die 4er Version ist im nächsten LTS Ubuntu oder Debian enthalten.
Grüße,
maxprox

 

[hec]

Security ist die Frage der Sichtweise. Soviel ich das sehe verbindet sich die Software mit root auf die jeweiligen Server. Das ganze in Verbindung mit passwordless SHS Keys ist ein Supergau wenn der Backup Server nicht entsprechend gesichert ist. Da ist 2FA nur ein Anfang. Wenn ich den Backup Server unter Kontrolle bekomme kann ich somit sämtliche konfigurierten Server verändern. Löschen wäre ja noch lustig das würde man merken aber so ein paar veränderte Files ist viel lustiger.

Das Problem ist ich will weiters oft unterschiedliche Firewall Konfigurationen für SSH und Backup haben. Wenn beide am gleichen Port laufen kann ich es in der Firewall nicht unterscheiden.

 

[maxprox]

Security ist die Frage der Sichtweise. Soviel ich das sehe verbindet sich die Software mit root auf die jeweiligen Server. Das ganze in Verbindung mit passwordless SHS Keys ist ein Supergau wenn der Backup Server nicht entsprechend gesichert ist. Da ist 2FA nur ein Anfang. Wenn ich den Backup Server unter Kontrolle bekomme kann ich somit sämtliche konfigurierten Server verändern. Löschen wäre ja noch lustig das würde man merken aber so ein paar veränderte Files ist viel lustiger.
Das Problem ist ich will weiters oft unterschiedliche Firewall Konfigurationen für SSH und Backup haben. Wenn beide am gleichen Port laufen kann ich es in der Firewall nicht unterscheiden.

Hallo hec,

Na ja, wir sprechen von einem Linux auf dem kein weiterer Dienst läuft, als BackupPC keine Freigaben, kein Samba usw. Die gesicherten Systeme sehen ja diesen BackupPC per se nicht mal. Da ist es doch warscheinlicher dass die Produktivsysteme befallen werden, auf denen die user all zu oft einladen. Und wie du schon schreibst kann ich den Zugriff darauf weiter absichern, zB per 2FA, fail2ban usw.
von den Backupsfiles werden checksummen gebildet damit BackupPC weiss was zu tun ist. wenn du da was ändern würdest, naja, soweit lassen wir es mal gar nicht erst kommen und da der eh nur Backup zieht, hättest du doch auf dem Teil Kontrolle wenn du nur hier den ssh Port ändern würdest ...

Grüße,
maxprox

 

[hec]

Port ändern bringt mir nichts ich müsste mehr oder weniger 2 SSH Daemons laufen lassen. Einen für Administration und einen für Backup. Das wäre dann in der Firewall trennbar.

Ja mag sein er zieht nur Backups aber mit dem root kann ich eben alles machen. Ich kenne auch Unternehmen da gibt es die Policy Login mit root muss deaktiviert werden.

Du sprichst hier die Wahrscheinlichkeit an welches System welches Risiko bietet - dem muss ich eindeutig widersprechen.
Alleine wenn ich an die Berechtigung denke - wie willst du diese lösen? Jeder der Zugriff auf den Backupserver hat bekommt damit auch root Zugriff auf alle gesicherten Server. Die Backup Admins haben aber meistens nichts auf Produktivsystemen verloren.

Bei einem einzigen Admin sind solche Lösungen nett aber wenn es ganze Abteilungen für so etwas gibt schaut die Situation anders aus.

Ich will die Software nicht schlecht machen ich möchte nur diverse Sicherheitsaspekte aufzeigen.

 

[crmspezi]

@
LnxBil
Das glaube ich so nicht. Die "schlechten" Raten habe ich auf verschiedenen (8x !) Testservern und Produktiv Kundenservern mit v5.4, 6.0 und 6.1. Das Problem sind die "leeren" Container (4TB, mit 300-800GB gefüllt in qcow2 Dateien auf Shared Storage 2x10GBit/s). ZFS direkt ist technisch nicht möglich, ZFS over iSCSI ist super langsam im Vergleich, CIFS ist viel schneller als NFS, deshalb qcow2 auf Shared Storage (RAID10 mit XFS). ALLES in 6 Monaten unter viel LEID erfahren, aber im Vergleich mit Hyper-V gut, sehr gut (Performance, nicht Backup!)

Lasse das Backup mit vzdump laufen, es zeigt Dir 130/110 MByte/s und unterscheidet NICHT nach belegten Clustern die wirklich gesichert werden müssen. Damit dauert der Sicherungsprozess x-mal länger und wird deshalb nur alle 2 Wochen von "Außen" von mir zusätzlich aktiv.

Hier aktuell:


"Naja, es benutzen Abertausende von Personen und die haben keine Problem. "
Das möchte ich bei dieser Konfiguration wie von mir beschrieben gern glauben. Aber die Erfahrungen widerlegen dies, denn ich habe viele verschiedene PVE's evaluiert, Systeme bis 384GByte RAM und 4 CPU's, mit 88 Kernen in der Grundkonfiguration mit qcow2 Anbindung. ZFS nativ ist auch nur 20% fixer mit vzdump.

Das macht nachdenklich!

VG

 

[fireon]

Außerdem hätte ich gerne Dedup und Compression am Storage System und will damit nicht die Hosts belasten.

Ja, haben wir doch, nennt sich ZFS

Zu BackupPC: Das verwenden wir auch schon Ewigkeiten. Gibt es übrigens auch fertige Pakete auf unserem Repo für Ubuntu 18.04. @hec Man darf natürlich auch mal gern das Handbuch lesen und danach sollte man wissen was man tut. Und ja man verwendet natürlich nicht den Rootuser dafür Für das gibt es doch ein zentrales AD/LDAP wo es einen User gibt der die Backups holt und wieder zurückspielen darf, sprich der User darf nur rsync als Root ausführen. Außerdem ist der Passwortlogin deaktiviert und die Berechtigungen richtig gesetzt. Somit ist es klar das dies eines der einfachsten und sichersten Sicherungsmethoden für Files darstellt.

 

[LnxBil]

Lasse das Backup mit vzdump laufen, es zeigt Dir 130/110 MByte/s und unterscheidet NICHT nach belegten Clustern die wirklich gesichert werden müssen.

Das ist richtig, daher TRIM aktivieren (Falls das Backend-Storage das kann) oder den freien Speicher mit 0en überschreiben.

Ich habe selbst ein FC-SAN mit den gleichen Probleme und wenn ich den freien Speicher mit 0en überschreibe und die VM entsprechend optimieren
- keine gezippte Rotation von Logdateien, nur Namensänderung um keine Rewrites zu haben
- Dateilöschen durch überschreiben mit 0en

dann klappt es auch prima mit dem Backup, denn der wirklich leere Speicher wird schön übersprungen. Dann noch ein gescheites Backup-System hintendran mit ZFS und man kann auf engem Platz enorm viele PVE Backups aufheben, mit inkrementeller off-site-Übertragung.

Das ist aber kein alleiniges Proxmox VE Problem, sondern hab ich exakt so schon bei VMware, XEN und Hyper-V gesehen. So lange das Backend-Storage es kann und die VM dies auch weiß ist alles prima, aber sonst geht es tierisch in die Hose mit der Menge der Daten.

 

[crmspezi]

Da höre ich doch gespannt zu, schöpfe Hoffnung und möchte das gern testen. Aber wie soll die VM was davon wissen? Oder meinst Du den Host? Das dies nichts mit Proxmox zu tun hat ist mir klar, wohl aber mit der Methode. Hyper-V mit Altaro scheint dies aber gut zu verstehen. Hier habe ich kurze Sicherungszeiten bei 4TB und geringer Platten-Auslastung.

VG

 

[LnxBil]

Hyper-V mit Altaro scheint dies aber gut zu verstehen. Hier habe ich kurze Sicherungszeiten bei 4TB und geringer Platten-Auslastung.

Jede Differentielle-Backuplösung des Hypervisors arbeitet eigentlich gleich: Jeden Block durchgehen ob er sich gegenüber der bereits gespeicherten Lösung geändert hat und falls ja überträgt er ihn (+ bissel snapshotting drumherum, damit der Vorgang so atomar wie möglich ist).
PVE macht nur Vollbackups. Es gibt/gab mal eine Lösung mit differentiellen Backups, die können aber sehr langsam sein.
An sich ist so eine Software zu schreiben, die ein intelligentes, differentielles Backup macht nicht so schwer ... es muss halt nur einer machen. Wie bei allen Lösungen kann das aber nicht der Hypervisor selbst machen, sondern sollte immer extern gelagert sein. Fraglich ob die kommerziellen Anbieter hier mal PVE unterstützen oder nicht.

Aber wie soll die VM was davon wissen? Oder meinst Du den Host?

Die verlinkte Backup-Lösung im Vortrag setzt ja auf die Proxmox-Voll-Backups und Differentialisiert über ZFS im Nachgang. Das ist einzig alleine nur für die Verwaltung von sehr vielen Backups auf kleinstem Raum.

 

[hec]

Die einen mögen ZFS die anderen WAFL. Solange man eine gute SnapShot basierte Sicherung hat ist ja alles ok.

Die Frage ob ein Snapshot ein Full oder Diff Backup ist kommt drauf an von welcher Seite man das sieht. Für das Storage System ist es ein Diff Backup aus Sicht des Servers ein Full.

Bei einer NetApp habe ich mehrere Technologien um die Effizienz extrem zu steigern.
Dazu zählen Deduplication, Compression und auch Compaction - das ganze noch inline. FC SAN Anbindung habe ich nicht getestet das müsste ich noch machen. Aber ansonsten sehe ich diese Probleme eigentlich nicht.

 

[LnxBil]

Bei einer NetApp habe ich mehrere Technologien um die Effizienz extrem zu steigern.
Dazu zählen Deduplication, Compression und auch Compaction - das ganze noch inline. FC SAN Anbindung habe ich nicht getestet das müsste ich noch machen. Aber ansonsten sehe ich diese Probleme eigentlich nicht.

Dazu gibts ein Plugin für PVE, sodass du das pro VM machen kannst? Falls ja, dann ist das sehr schick. Das würde ich auch ZFS vorziehen, da es dann ja clusterfähig ist. Hat man dann auch gleich Multipath dabei? Das war ja die Ganze Zeit das Problem von dem qemu-basierten iscsi initiator.

 

[LnxBil]

FC SAN Anbindung habe ich nicht getestet das müsste ich noch machen.

Ich habe bisher nur mit dummen FC-SANs gearbeitet, da diese immer jede Netapp - egal wieviele Millionen die gekostet haben soll - in Performance um Längen geschlagen hat. Das war immer so lustig ... da kommt man zum Kunden und die sind mächtig stolz auf deren NetApp und dann kommt die böse Ernüchterung wenn ich das Teil benchmarke (fio) und meine, dass das ja nicht so wirklich dolle ist. Klar hat man all' die Features nicht, die brauch man bei Datenbanken aber auch nicht, da die Technik der Datenbank eine komplett andere ist.

 

[fireon]

Ich habe bisher nur mit dummen FC-SANs gearbeitet, da diese immer jede Netapp - egal wieviele Millionen die gekostet haben soll - in Performance um Längen geschlagen hat. Das war immer so lustig ... da kommt man zum Kunden und die sind mächtig stolz auf deren NetApp und dann kommt die böse Ernüchterung wenn ich das Teil benchmarke (fio) und meine, dass das ja nicht so wirklich dolle ist. Klar hat man all' die Features nicht, die brauch man bei Datenbanken aber auch nicht, da die Technik der Datenbank eine komplett andere ist.

Wie geil...

 

[grefabu]

Moin,

ich schmeiße mal etwas in den Ring:
Ende letzten Jahres habe ich mich mal an einer Trial von bacula (enterprise) versucht. Leider habe ich es nicht geschaft (teilweise Zeit, teilweise Komplexität) den Server nebs proxmox Plugin zum Laufen zu bringen.

Diese Woche habe ich aber jemanden von bareos auf der opsi conf auf das Thema angesprochen. bareos ist ja ein Fork von Bacula.
Aktuell hat bareos ein plugin für oVirt, das wird aber noch ausgebaut.

Ich habe den Kontakt bei bareos schon angeschrieben und werde auch noch mal mich mit Ihm austauschen.

Mein Ziel wäre, eine ähnliche Lösung wie z.B. VMWare/Hyper-V mit veeam zu haben, blockbasiertes inkrementelles Backup.
Mal sehen was sich da machen lässt. Es ist letztendlich auch eine Frage des Geldes.

Das Thema ist sicher recht komplex, gerade wenn von seiten der virtualisierung verschiedene Storages im Spiel sind? Obwohl, es ist doch sicher letztendlich alles Blockbasiert,...

Andersherum, wenn sich genügend zusammentun,...

 

[fireon]

Ja mit Bareos hatte mich auch schon einige Zeit beschäftigt, war davon ziemlich begeistert. Nur leider nahm die dann immer mehr und mehr ab. Die Komplexität ist nicht schön. Ohne bei denen mal ein Studium zu vollziehen, wird das glaub ich nix. Na jedenfalls hier mein Artikel darüber.

 

[hec]

Ich habe bisher nur mit dummen FC-SANs gearbeitet, da diese immer jede Netapp - egal wieviele Millionen die gekostet haben soll - in Performance um Längen geschlagen hat. Das war immer so lustig ... da kommt man zum Kunden und die sind mächtig stolz auf deren NetApp und dann kommt die böse Ernüchterung wenn ich das Teil benchmarke (fio) und meine, dass das ja nicht so wirklich dolle ist. Klar hat man all' die Features nicht, die brauch man bei Datenbanken aber auch nicht, da die Technik der Datenbank eine komplett andere ist.

Die Aussage du hast mit einem dummen SAN immer bessere Werte als eine NetApp ist mit Sicherheit falsch.

Wenn dann hat der NetApp Partner diese wohl nicht richtig konfiguriert oder die Hosts. Ich kann die NetApp auch mit SAN ansprechen also FC/iSCSI wenn ich will. Das ist ja genau der Vorteil einer NetApp. Egal in welche Richtig ich wachsen will ich habe alle Protokolle.

Welche Werte erreicht denn dein dummes FC-SAN? Vor allem interessiert mich Latency und Durchsatz und die Konfiguration dazu.

 

[sunghost]

An veeam stört mich, dass ich dafür nen Win10 oder WinServer installieren/lizensieren muss. Bareos habe ich schon länger auf dem Zettel und behalte es mal im Auge, hoffe da kommt was für Proxmox.

 

[LnxBil]

Welche Werte erreicht denn dein dummes FC-SAN? Vor allem interessiert mich Latency und Durchsatz und die Konfiguration dazu.

Das letzte, richtig schnelle FC-SAN (nur SAS-basiere SSD, 14 TB netto) hat 70k gekostet und liefert 164k IOPS (4K randread, 16 numjobs, qd32) und 3,19 GB/sec bei multipath+alua 2x16 GBit DA FC (8k seq read, 16 numjobs, qd32). Zugriffszeit von 300 us. Neben den eher künstlichen Zahlen von fio, haben wir natürlich auch andere Zahlen, wie z.B. die Instanzanlage einer Datenbank, bei der man auch sehr deutlich gesehen hat, dass die Performance nicht gestimmt hat bei den NetApp-Kunden.

Wenn dann hat der NetApp Partner diese wohl nicht richtig konfiguriert oder die Hosts.

Genau das ist die Antwort, die ich auch immer bekomme. Bestimmt gibt es auch schnelle, nur hat wohl kein Kunde von uns so eine. Ein dummes SAN muss man auch nicht groß konfigurieren. Wide-Stripe-Volume anlegen damit ALUA geht und schon ist man fertig.

Die Aussage du hast mit einem dummen SAN immer bessere Werte als eine NetApp ist mit Sicherheit falsch.

Ja stimmt, ich war zu unpräzise. Klar ist ein 10 Euro-SAN von ebay von vor 20 Jahren nicht schneller als irgend eine NetApp. Wenn wir die Kosten pro IOPS betrachten sieht das aber anders auch. Die ganzen, oft nicht abwählbaren Software-Features und die astronomischen Supportkosten nach 4+ Jahren machen die NetApp einfach nicht attraktiv für Workloads, bei denen man keine Software-Features benötigt.

Ich freue mich auch immer auf jede NetApp, die ein Kunde hat - in der Hoffnung, dass sich mein Eindruck mal ändert. Ganz ernsthaft! Irgendwo müssen ja die schnellen Systeme sein, von denen man immer zu lesen bekommt.