VMware wechsel zu Proxmox

[Sinux]

Hallo zusammen,

ich habe ein paar Fragen zu euren Erfahrungen, nicht wie ich was machen muss da suche ich mir selber raus aber ich benötige bitte euer Feedback.
Da VMware gerade seine Firmenpolitik geändert hat sichte ich Proxmox (wieder einmal).
Ich habe einen Proxmox auf einen DELL EMC PowerEdge R650 RAID 10 SSD installiert und mehrere Testklone (vom ESXi via qm-import raw) migriert.
Was mich zuerst interessiert ist ein normales Backup ohne den PBS da dieser in den Empfehlungen SSD's und zfs möchte und das fällt weg.
Habe eine ganz normalen HP 380 G9 im RAID 5 HDD mit NFS laufen. Auf diesen sichert der ESXi via vghetto script ganz normal schon Jahre lang.
Was beim Proxmox schon nicht funktioniert ist eine normales Backup ohne Komprimierung.
Bekomme dort irgendwann ein Time Out Problem und der Gast ist irgendwann auch nicht mehr erreichbar. Schalte ich zst Komprimierung ein funktioniert es.
Und da sind dir schon beim nächste Problem, vma und zstd, wenn ich mal schnell an eine Datei möchte mounte ich aktuell eine vmdk auf dem nfs share und habe die dann Griffbereit. Das funktioniert ja nicht beim Proxmox da ich da erst einmal zst und danach vma extrahieren muss. Das bedeutet 2 mal entpacken um überhaupt etwas machen zu können ganz zu schweigen von dem Platzverbrauch. Wie habt ihr das ohne PBS gelöst wenn man mal schnell an eine RAW ran möchte? Oder brauche ich eine komplett andere Backup Strategie?
Ich kann aber keine neuen Server anschaffen (RAID Controller weg, HBA und SSD's herzaubern)
So ich hoffe das war nicht zu unverständlich und bin gespannt auf eure Meinung und Ratschläge.

 

[CH.illig]

ich habe in einem kleinsetup auf dem PVE ebenfalls PBS installiert (Erlaubt und supported)
dieser PBS hat dann den storage eingebunden und nimmt die backups entgegen via localhost

damit hast du ein schnelleres backup, und auch noch die file restore option...

alternativ was spricht dagegen auf dem HP PBS zu installieren?

 

[Falk R.]

ich habe ein paar Fragen zu euren Erfahrungen, nicht wie ich was machen muss da suche ich mir selber raus aber ich benötige bitte euer Feedback.

Gern.

Da VMware gerade seine Firmenpolitik geändert hat sichte ich Proxmox (wieder einmal).
Ich habe einen Proxmox auf einen DELL EMC PowerEdge R650 RAID 10 SSD installiert und mehrere Testklone (vom ESXi via qm-import raw) migriert.
Was mich zuerst interessiert ist ein normales Backup ohne den PBS da dieser in den Empfehlungen SSD's und zfs möchte und das fällt weg.

Das sind nur Emfehlungen und kein Zwang.
Was für HDDs hast du und hat dein Raidcontroller vernünftig Cache? (BBWC)
Ich habe auch bei Kunden, alte Server (Gen9 und Gen10) mit 10k HDDs als PBS am laufen.
Ein Kunde hat 24 10k HDDs im ZFS RaidZ2, läuft für die 15 VMs und 3TB Daten immer schnell genug.
Alternativ habe ich auch SmartArray Raid6 auf HDDs im PBS als XFS eingebunden und rennt auch wunderbar bei den 30VMs, in dem Setup.
Bei neuen Servern nutze ich natürlich nur noch SSDs.
Der PBS spart dir auch extrem viel Volumen durch das Dedup, weshalb man ja nicht so viele SSDs benötigt.

Gerade beim Verify, was bei den HDDs sonst tödlich ist, geht das dank Controllercache schon deutlich entspannter und beim Backup hilft es extrem, wenn man den Writecache recht hoch eingestellt lässt.
Mit PBS wirst du viel schneller glücklich.

 

[Sinux]

Herzlichen Dank CH.illig und Falk R !!!

alternativ was spricht dagegen auf dem HP PBS zu installieren?

ganz einfach das Proxmox SSD's auf seinen Backupsystemen nicht empfiehlt.

Danke dir CH.illig!

Das sind nur Emfehlungen und kein Zwang.

Ja das ist richtig und deshalb frage ich ja nach euren Erfahrungen, damit meine ich Kollegen die wirklich fundiertes Wissen UND Erfahrung in dieser Richtung haben, danke nochmals dafür!!!

Was für HDDs hast du und hat dein Raidcontroller vernünftig Cache? (BBWC)

10k haben die beim Controller muss ich nach sehen wie der eingestellt ist. Mit BBWC meinst du Batteriebackup und writecache ja? Das wäre an.

Ein Kunde hat 24 10k HDDs im ZFS RaidZ2, läuft für die 15 VMs und 3TB Daten immer schnell genug.

Das fällt bei mir aus kein ZFS auf RAID Controllern, egal wie durch geschliffen (JBOD oder einzeln als Raid Volumes, ZFS empfiehlt das nachdrücklich nicht)

Alternativ habe ich auch SmartArray Raid6 auf HDDs im PBS als XFS eingebunden und rennt auch wunderbar bei den 30VMs, in dem Setup.

Das klingt schon interessanter obwohl ich mit xfs keine Erfahrungen habe (immer ext4 Systeme)
Wie ist das die Performance für VM's mit 600-800 GB VM Disk? Und mit am wichtigsten Snapshots auf SQL Servern, das lief in meinen Test ja nicht wegen dem angebrochenen Backups. Einmal musste ich den Host komplett durch starten was am Tag natürlich nie geht.

Der PBS spart dir auch extrem viel Volumen durch das Dedup, weshalb man ja nicht so viele SSDs benötigt.

Über dedub habe ich nicht nur gute Dinge gehört aber lasse mich gerne belehren.

Gerade beim Verify, was bei den HDDs sonst tödlich ist, geht das dank Controllercache schon deutlich entspannter und beim Backup hilft es extrem, wenn man den Writecache recht hoch eingestellt lässt.
Mit PBS wirst du viel schneller glücklich.

Könntest du mir das bitte erklären? Im RAID Controller den Writecache erhöhen? Welche Werte hast du da so im Sinn?
Ja der PBS macht es einem sehr einfach das ist richtig habe ich ja schon mal probiert, File restore, alles mal angesehen aber was mir noch einfällt was ist mit einer außer Haus Sicherung? Ich mache diese immer noch auf RDX Medien. Das geht ja alles nicht mit dem PBS!
Mein Setup ist vmdk wtl, Files tgl über Urbackup und das alles auf RDX verschlüsselt noch mit außer Haus. Und bitte jetzt keine Tipps zweiten PBS irgendwo anders hin. Richtiges Cold Backup eben.

Also Herzlichen Dank nochmals an euch beide, hoffe es posten noch mehr ihre Erfahrungen.

 

[Falk R.]

10k haben die beim Controller muss ich nach sehen wie der eingestellt ist. Mit BBWC meinst du Batteriebackup und writecache ja? Das wäre an.

Ja genau.

Das fällt bei mir aus kein ZFS auf RAID Controllern, egal wie durch geschliffen (JBOD oder einzeln als Raid Volumes, ZFS empfiehlt das nachdrücklich nicht)

Beim Gen9 kannst du die Controller in einen echten HBA Modus versetzen. Dann ist der Raidchip aus und nicht nutzbar.
Alternativ kannst du dir einen HBA kaufen, aber der macht nix anders.
Bei Gen10 Smart Array sieht das wieder anders aus, da ist das kein echter HBA Mode, aber für viele Systeme Supportet, die ebenfalls kein Raid haben dürfen. Auch bei Gen10 ist die Disk inkl. SMART im OS sichtbar, aber HPE sortiert da unsupportete Disks weiterhin aus.

Was du niemals tun solltest, bei mach alten Raid Controllern wurde statt HBA Modus, einfach viele Raid 0 gebaut, vor allem bei den DELL Controllern. Das ist echt Böse.

Das klingt schon interessanter obwohl ich mit xfs keine Erfahrungen habe (immer ext4 Systeme)
Wie ist das die Performance für VM's mit 600-800 GB VM Disk? Und mit am wichtigsten Snapshots auf SQL Servern, das lief in meinen Test ja nicht wegen dem angebrochenen Backups. Einmal musste ich den Host komplett durch starten was am Tag natürlich nie geht.

XFS ist ein wenig schneller als EXT4 und ich habe damit bisher bei größeren Datastores bessere Erfahrungen.
Mein größtes XFS Volume ist 600TB und damit hatte ich noch nie Probleme.
Ich habe bei einem Kunden nur die Test und Dev Umgebung bisher auf proxmox migriert, aber da ist ein 8TB SQL Server, der maximal am WE mal neu gestartet werden darf. Den sichern wir tatsächlich auch nur einmal am Wochenende, da er täglich ca. 2Tb Änderungen hat. Das ist zu viel für die HDDs. Alle anderen VMs bis ca. 2TB und normalen Änderungsraten gibts überhaupt keine Probleme.
Wenn da mal irgendwann SSDs abfallen, wird es auch für die dicke Kiste mehr Backups geben.

Über dedub habe ich nicht nur gute Dinge gehört aber lasse mich gerne belehren.

Dedup bringt immer ein Risiko mit sich. Wenn die Metadaten weg sind, hast du nur noch Datenmüll. Wenn man aber mit einem Dedupfähigen System vernünftig umgeht, hast du keine Probleme. Alle PBS die ich bei Kunden betreue, laufen seit dem ersten Tag perfekt.

Könntest du mir das bitte erklären? Im RAID Controller den Writecache erhöhen? Welche Werte hast du da so im Sinn?

Für beste Backupperformance 90% Write und 10% Read. Wenn die Verify's zu lange dauern mal 75/25% testen.

Ja der PBS macht es einem sehr einfach das ist richtig habe ich ja schon mal probiert, File restore, alles mal angesehen aber was mir noch einfällt was ist mit einer außer Haus Sicherung? Ich mache diese immer noch auf RDX Medien. Das geht ja alles nicht mit dem PBS!

Ich mache das lieber mit einem zweiten PBS (oft noch langsamere HDDs ) der per Pull regelmäßig die Backups holt. Damit hat man die Hauptfehlerquelle "Mensch" ausgeschlossen und hat einen super Ransomwareschutz wenn man beim zweiten PBS eingehend alle Verbindungen verbietet.

Mein Setup ist vmdk wtl, Files tgl über Urbackup und das alles auf RDX verschlüsselt noch mit außer Haus. Und bitte jetzt keine Tipps zweiten PBS irgendwo anders hin. Richtiges Cold Backup eben.

So argumentieren auch immer alle Tape Verfechter mit mir. Beim zweiten PBS sind die Daten viel schneller weg und ich habe auch einen PBS bei einem Hoster für einen Kunden eingerichtet. Da kommt nur ein Rechner mit einer bestimmten IP an das DIng von außen dran. In dem RZ beim Hoster ist das mindestens so sicher wie im Tresor, nur das man nix manuell machen muss und die Backups direkt richtig Geografisch getrennt liegen.

Da spielt auch immer etwas Geschmack mit, aber ich bin der Freund von Automatismen um Layer8 Fehler zu vermeiden und man hat mit nur ein paar Inkrements übertragen viel schneller einen Ransomwareschutz.

 

[t.lamprecht]

Über dedub habe ich nicht nur gute Dinge gehört aber lasse mich gerne belehren.

PBS benutzt keinen Storage spezifische deduplication die viel CPU brauch und wenig bringt, sondern verwendet zum Speichern der Backup daten einen Storage-Agnostischen sog. "Content Addressable Storage" Chunk Store.
D.h. es kann sehr effizient nur neue daten gespeichert werden, also Inkrementell, und trotzdem jedes Backup eigenständig bleiben.

 

[Sinux]

So argumentieren auch immer alle Tape Verfechter mit mir. Beim zweiten PBS sind die Daten viel schneller weg und ich habe auch einen PBS bei einem Hoster für einen Kunden eingerichtet. Da kommt nur ein Rechner mit einer bestimmten IP an das DIng von außen dran. In dem RZ beim Hoster ist das mindestens so sicher wie im Tresor, nur das man nix manuell machen muss und die Backups direkt richtig Geografisch getrennt liegen.

Und noch mal Herzlichen Dank Falk R., dann anders, sagen wir mal ich habe einfach keine Möglichkeit draußen noch einen PBS hinzustellen und das habe ich wirklich nicht! Ich könnte ja dann zusätzlich auf ein RDX die WE Sicherungen direkt vom PVE nehmen, habe in der Testumgebung auch mal cryptsetup installiert, beißt sich das evtl. mit dem PVE Kernel?

XFS ist ein wenig schneller als EXT4 und ich habe damit bisher bei größeren Datastores bessere Erfahrungen.
Mein größtes XFS Volume ist 600TB und damit hatte ich noch nie Probleme.
Ich habe bei einem Kunden nur die Test und Dev Umgebung bisher auf proxmox migriert, aber da ist ein 8TB SQL Server, der maximal am WE mal neu gestartet werden darf. Den sichern wir tatsächlich auch nur einmal am Wochenende, da er täglich ca. 2Tb Änderungen hat. Das ist zu viel für die HDDs. Alle anderen VMs bis ca. 2TB und normalen Änderungsraten gibts überhaupt keine Probleme.

Riesen danke schön, also keine Problem mit Snapshots, da muss ich mal weiter testen.

Beim Gen9 kannst du die Controller in einen echten HBA Modus versetzen. Dann ist der Raidchip aus und nicht nutzbar.

danke, ok wusste ich so nicht dachte kommt auf den verbauten Controller an.

Was du niemals tun solltest, bei mach alten Raid Controllern wurde statt HBA Modus, einfach viele Raid 0 gebaut, vor allem bei den DELL Controllern. Das ist echt Böse.

das meinte ich

Riesen Danke Schön nochmals, ich muss dann weiter grübeln wie ich eine perfekte Mischung daraus mache.

PBS benutzt keinen Storage spezifische deduplication die viel CPU brauch und wenig bringt, sondern verwendet zum Speichern der Backup daten einen Storage-Agnostischen sog. "Content Addressable Storage" Chunk Store.
D.h. es kann sehr effizient nur neue daten gespeichert werden, also Inkrementell, und trotzdem jedes Backup eigenständig bleiben.

Herzlichen Dank t.lamprecht, stimmt den Chunk Store hatte ich mir mal angesehen waren so gefühlt Millionen kleiner einzelner Dateien und das schreckt mich auch immer ab weil das Dateisystem ja dann einen brutal erhöhten Verwaltungsaufwand hat.
Aber Danke für die Erklärung!!!

 

[JensF]

Ich könnte ja dann zusätzlich auf ein RDX die WE Sicherungen direkt vom PVE nehmen...

Das funktioniert auch, nur macht es dann die Funktion des dirty-bitmaps zunichte. Er würde dann beim nächsten PBS-Backup ein neues dirty-bitmap erstellen und somit alle Daten einlesen müssen. Übertragen werden trotzdem nur die Änderungen, aber das Backup wird länger dauern.

 

[Falk R.]

Was genau möchtest du mit den RDX erreichen? Welchen Restorefall willst du damit abdecken?

 

[Sinux]

Das funktioniert auch, nur macht es dann die Funktion des dirty-bitmaps zunichte. Er würde dann beim nächsten PBS-Backup ein neues dirty-bitmap erstellen und somit alle Daten einlesen müssen. Übertragen werden trotzdem nur die Änderungen, aber das Backup wird länger dauern.

Herzlichen Dank JensF,

damit meinst du wenn ich ein einfaches wtl Backup über PVE selber mache "merkt" das der PBS und muss "voll" neu sichern?

 

[Falk R.]

Er muss voll lesen, schreibt aber trotzdem nur inkrementell.

 

[Sinux]

Was genau möchtest du mit den RDX erreichen? Welchen Restorefall willst du damit abdecken?

Herzlichen Dank Falk R.

Im Falle aller Fälle wenn VM Host und Backupserver dahin sind, die "vmdk's" nehmen und an einen neuen Host hängen oder auf einer Linux Maschine mounten um an Daten ran zukommen. Übrigens habe ich heute fast einen ganzen Tag verbracht einen Test PBS auf einem HP 380 G7 zu installieren aber immer einen schwarzen Screen nach dem Installationsmenü bekommen. Die Tipps nomodeset, gfxpayload usw. haben nicht geholfen. Mit einer einfachen debian 12 net iso war sofort eine ganz normale Debian Installation möglich. Schon fader Beigeschmack wenn das schon so los geht.

 

[Falk R.]

Bei so alter Hardware kann das schon mal vorkommen. Sowas testet ja niemand mehr.
Außerdem würde ich das alte Ding nicht einschalten. Für den Strimverbrauch kannst du dir nach einem Jahr neue Hardware kaufen.

 

[Sinux]

Stimmt, ist ja nur eine Test Server Installation (da der echte Backupserver im Gebrauch ist!
ABER eine Debian normal Installation funktioniert ja auch also hinkt der Vergleich Altsystem dann ein bisschen.
Danke Falk .R. das du nicht genervt bist von mir!

 

[Falk R.]

Der Installer vin PVE ist etwas anders. Auf den alten Kisten läuft der TUI (Text UI) Installer meist besser.
Alternativ kannst du ja Debian12 installieren und PVE dann nachinstallieren.

 

[Dunuin]

Herzlichen Dank t.lamprecht, stimmt den Chunk Store hatte ich mir mal angesehen waren so gefühlt Millionen kleiner einzelner Dateien und das schreckt mich auch immer ab weil das Dateisystem ja dann einen brutal erhöhten Verwaltungsaufwand hat.

Nicht nur gefühlt. Aber dann siehst du ja woher unter anderem die Empfehlung für SSDs kommt. Bei snapshot-mode Backups wäre es auch noch wichtig zu wissen, dass da aktuell die Writes der VM während des Backups sowohl auf den PBS als auch auf die virtuelle Disk geschrieben werden müssen und erst wenn beide ein ACK geben ist der Write durch. Langsamer PBS Datastore oder hohe Latenz zum PBS kann dir also mit Pech die VMs ausbremsen. Und für Live Restore (VM nutzen während sie noch am Restoren ist) bräuchte man auch eine gewisse Storage-Performance, damit das gut nutzbar ist.

 

[Sinux]

Der Installer vin PVE ist etwas anders. Auf den alten Kisten läuft der TUI (Text UI) Installer meist besser.
Alternativ kannst du ja Debian12 installieren und PVE dann nachinstallieren.

Ich installiere immer nur via TUI/Console finde geht schneller. Ja und dann so den PBS installieren stand in den Tipps zu dem Installer black screen Bug auch so drin.
Danke Falk .R.

 

[Sinux]

Nicht nur gefühlt. Aber dann siehst du ja woher unter anderem die Empfehlung für SSDs kommt. Bei snapshot-mode Backups wäre es auch noch wichtig zu wissen, dass da aktuell die Writes der VM während des Backups sowohl auf den PBS als auch auf die virtuelle Disk geschrieben werden müssen und erst wenn beide ein ACK geben ist der Write durch. Langsamer PBS Datastore oder hohe Latenz zum PBS kann dir also mit Pech die VMs ausbremsen. Und für Live Restore (VM nutzen während sie noch am Restoren ist) bräuchte man auch eine gewisse Storage-Performance, damit das gut nutzbar ist.

Ah, wieder was gelernt! Ja mit den SSD's meinte ich ja genau deswegen. Und wo die Preise z.Z. für normale HDD's so günstig bieten die sich eben für Backup Server an und die SSD's eben für V Host's Ich habe ja nur 12 VM's, Win SRV mit SQL DC und so mehr ich das lese werde ich wohl eine 2. Option testen, KVM mit qcow2 und vielleicht mal das virtnbdbackup. Das der PBS den PVE im Backup dann auch so beeinflussen kann ist eigentich logisch. Ich finde das mit den Chunks und zfs so wieso doppelt gemoppelt, den zfs beherrscht ja Snapshots aber es wird über die chanks realisiert aber vielleicht irre ich mich auch.
Danke Dunuin

​

 

[Dunuin]

Ja. Wenn PBS mit ZFS direkt arbeiten würde, wäre man aber auch auf ZFS beschänkt und könnte kein ext4,zfs,NFS,SMB,btrfs oder sonst was nutzen. Außer man würde für jedes Dateisystem immer alles erneut programmieren. Und Deduplikation über ZFS willst du vermutlich auch nicht, weil du dann ja wieder 5GB RAM mehr je 1TB Backupstorage benötigen würdest. Und wenn man dann doch wieder Millionen von Chunks für softwareseitige Deduplikation braucht, dann bist du wieder bei SSDs.

 

[Falk R.]

Und wo die Preise z.Z. für normale HDD's so günstig bieten die sich eben für Backup Server an und die SSD's eben für V Host's Ich habe ja nur 12 VM's, Win SRV mit SQL DC und so mehr ich das lese werde ich wohl eine 2. Option testen, KVM mit qcow2 und vielleicht mal das virtnbdbackup. Das der PBS den PVE im Backup dann auch so beeinflussen kann ist eigentich logisch.

Wenn du klassische Backuplösungen vergleichst, benötigst du nur HDDs, aber viel mehr Kapazität. Mit dem PBS brauchst du dank Dedup weniger Kapazität und dann ist das am Ende auch nicht viel teurer als vorher mit den HDDs.
Viele andere Backuplösungen können nur mit qcow2 umgehen, die Storageunabhängige Implementation vom PBS finde ich daher genial.