[Sammelthread] Proxmox Stammtisch

Die VM, würde ich aktuell sogar vernachlässigen - klar, wenn ich sie wieder herstellen kann ists nice
Aber am Ende wäre es nur eine Debian VM inkl. Docker.

Wichtiger sind mir vor allem die Daten
Von daher daher war meine Überlegung, dieses über ein eigenes ZVOL in die VM einzubinden und das entsprechend per Replikation zu sichern.
Wenn ich eine andere VM hochfahre, müsste ich das ZVOL ja einbinden und die Daten lesen können - oder hab ich hier grad nen Denkfehler? :)
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Ein ZFS zvol ist ein Blockdevice, quasi wie eine Festplatte die man einer VM zuweisen kann.
 
Daher auch meine Überlegung, allerdings alles in der Theorie, hab noch kein ZFS am laufen
System1: ZFS ZVOL in meiner VM für Docker -> alle Docker relevanten Daten liegen auf diesem ZVOL

Mittels ZFS Snapshot + Replikation wird das ZVOL auf ein zweites System gesichert um im Notfall ein Backup zu haben

Oder spricht hier was gegen meinen Ansatz?
 
Wenn man für Docker z.B. ein Ubuntu virtualisiert und da eventuell weitere virtuelle Platten benutzt, so sollten alle zvols dieser Ubuntu VM z.B. mit der id 100 per ZFS Replikation gesichert werden, dazu die Konfigurationsdaten dieser VM z.B. /etc/pve/qemu-server/100.conf.

Zum Wiederherstellen/Importieren dieser VM, die zvols bereitstellen (gleicher Ort pool/dataset/zvol) und dazu die /etc/pve/qemu-server/100.conf. Ändert sich der Ort, dann die 100.conf editieren.
 
Danke dir für deine Erklärungen Gea - soweit hab ichs, glaub ich :) verstanden
Mit dem Ansatz könnte ich die gesamte VM wieder herstellen

Falls ich die 100.conf nicht hätte, aber die ZVOLs repliziert habe - kann ich diese als weitere HDD in eine andere VM (200) einbinden und auf die Daten zugreifen?
 
Ja, wenn es einfache Daten sind. Dann reicht es die Platte einfach irgendwo bereit zu stellen. Ist es eine Bootplatte einer VM, so könnte man eine neue VM erstellen und der kuckucksartig die zvol unterschieben. Damit könnte man eine VM auch ohne die alte .conf händisch wiederherstellen.
 
Wenn Video-Encode und Nvidia, nimm auf alle Fälle minimum eine 4000er, da die AV1-Encode in Hardware kann. die 3000er nicht! Ab den xx70TI sind zwei Hardwareencoder verfügbar. 4060/5060 und 4070/5070 ohne TI nur einer.

Wenn Du ne aktuelle Nvidia willst, würde ich zur Eile raten da mit Preissteigerungen zu rechnen ist.
Also ich habe mich jetzt soweit es meine Kenntnisse bzgl. Codes und Videobearbeitung mit den Thema beschäftigt. Intel ist wegen dem hohen Stromverbrauch raus.
Dann ist für Videoschnitt insbesondere mit Davinci Resolve Studio der VRAM sehr wichtig. Hier sollten 12 GB das Minimum sein.
Wichtig ist mir ein "halbwegs" flüssiges Arbeiten in der Timeline mit 4K Material. Wie lange dann das Rendern für die Ausgabe dauert ist mir nicht so wichtig.
Ist dann für mich das AV1-Encoding der 4000er nicht so wichtig und ich kann auch zur 3000er bzw. 2000er Serie greifen, wenn die Karte genug VRAM hat oder mache ich hier einen Denkfehler?
 
Wie handhabt ihr das mit den Proxmox Backups?
Ich habe aktuell eine Proxmox Maschine und eine TrueNAS Maschine (die täglich Offsite gesichert wird).
Aber noch keine Proxmox Backups eingerichtet :fresse:

Habt ihr auf der Proxmox Maschine einen PBS eingerichtet der auf das NAS sichert?
Oder habt ihr den PBS aufm dem NAS eingerichtet.
Oder nutzt ihr ein komplett anderes System?
 
Habt ihr auf der Proxmox Maschine einen PBS eingerichtet der auf das NAS sichert?
So.
Oder habt ihr den PBS aufm dem NAS eingerichtet.
Und so auch. :sneaky:

Zwei PVE, einer ist das NAS. Der bekommt die Backups von dem andern PVE/PBS.
Und der NAS-PVE-PBS sichert zunächst auf sich selbst, sozusagen, weil der andere nicht immer läuft. Aber wenn der andere läuft, dann synct der die Eigensicherung von dem einen zu sich rüber.
Sounds complicated. :rolleyes2:
Aber das funktioniert ganz gut. Es entsteht natürlich eine Lücke in der Zeit, wo der andere nicht läuft. Ja nu.
Die PBS sind in LXC installiert.
 
Kannst du nicht auf dem TrueNAS eine PBS-VM aufsetzen.
Mache ich ungern, das Ding soll nur doof Speicher sein.
Mich nervt ja schon das Wechseln von dem TrueNAS Conteiner System von Docker zu Kubernetes und jetzt wieder zu Docker.

Und der NAS-PVE-PBS sichert zunächst auf sich selbst, sozusagen, weil der andere nicht immer läuft. Aber wenn der andere läuft, dann synct der die Eigensicherung von dem einen zu sich rüber.
Sounds complicated. :rolleyes2:
Die PBS sind in LXC installiert.
An LXC habe ich auch schon gedacht, da eine VM zu viel RAM fressen würde.
Ich habe auf dem PVE leider nur sehr begrenzt Speicherplatz und würde daher ggf. direkt mit dem dort laufenden PBS über ein Netzwerkshare auf das TrueNAS sichern. Wahrscheinlich NFS? Das NAS läuft sowieso 24/7.

Oder ist das eine schlechte Idee?
 
Zuletzt bearbeitet:
Oder ist das eine schlechte Idee?
Die PBS erzeugen Millionen von Dateien. Anfangs hatt ich es auch so, Datastore auf NFS. Später hab ich es dann umgedreht, PBS auf der andern Seite mit Datastore als Bind Mount. War mir, hm, sympathischer.

Ein Grund war glaub ich auch, weil der eine PVE ja nicht immer da ist. Da wäre dann ein (NFS)-Datastore offline. So wie jetzt ist es einfacher, weil der PBS nun, wenn der online geht, die Backups abholt.

Wenn das NAS nicht so viel Power hat und Du da auch gar keinen PBS drauf laufen haben möchtest, ist es ja eh klar, mit NFS also.
 
@Luckysh0t
Cloud Services möchte ich nicht nutzen. Ich versuche alles Lokal laufen zu haben.
Daher würde ich auch gerne die Backups Lokal laufen lassen.
Beitrag automatisch zusammengeführt:

Die PBS erzeugen Millionen von Dateien. Anfangs hatt ich es auch so, Datastore auf NFS. Später hab ich es dann umgedreht, PBS auf der andern Seite mit Datastore als Bind Mount. War mir, hm, sympathischer.
Wie meinst du das mit dem Bind Mount?
Wenn ich jetzt den PBS auf dem TrueNAS installieren würde?
 
So zum Thema NFS einbinden auf dem Proxmox Host,. das klappt wohl soweit. Nur verstehe ich zwei Optionen nicht.

1. "Content:" Was muss ich da auswählen, wenn ich das einfach als Speicher nutzen möchte. Z.B. um diesen in einem LXC zu mounten per bind?
2. "Preallocation:" Für was ist diese Funktion?

Entweder bin ich zu blöd, oder es steht einfach nix brauchbares dazu in der Doku
 
Als Content müsste „rootdir“ das richtige sein, um den Storage weiter in einen LXC Container zu geben, zumindest wenn man das über die GUI als MountPoint nutzt.

Preallocation definiert, ob die angegebene Größe direkt belegt wird, oder ob nur real benutzter Speicherplatz gebraucht wird.

Details dazu auch in der Doku unter https://pve.proxmox.com/wiki/Storage
 
Als Content müsste „rootdir“ das richtige sein
Den Habe ich nicht zur Auswahl. Ist aber erstmal nicht schlimm.
Den NFS Ordner habe ich jetzt einfach direkt gemountet, da ich PBS nun als VM laufen habe.
Dann kann ich später die VM selbst auch noch mal sichern (manuell) und diese auf dem NAS ablegen.

Vorteil ist, wenn mir der PVE abraucht, kaufe ich nen neuen Rechner, istalliere Proxmox, lade die PBS VM drauf und kann darüber alles über diese wiederherstellen.

Nachteil, läuft eben ne VM mehr auf dem PVE
 
@toscdesign Als VM hätte es mehr Sinn auf dem NAS gemacht. PBS kannst Du auch neben PVE installieren, da braucht es weder nen LXC noch eine VM für.
 
@BobbyD
Ich will nichts auf dem NAS installieren. Wie schon geschrieben, soll das nur dummer Netzwerkspeicher sein.
Beitrag automatisch zusammengeführt:

PBS kannst Du auch neben PVE installieren, da braucht es weder nen LXC noch eine VM für.
Davon raten die Proxmox Entwickler explizit von ab.
 
Zuletzt bearbeitet:
PBS kannst Du auch neben PVE installieren, da braucht es weder nen LXC noch eine VM für.
Ich würde die PVE Installation so clean wie möglich halten. Das erleichtert es deutlich, wenn der Host mal neu aufgesetzt werden muss, und alles was dazu installiert wird, birgt das Risiko das es mit den PVE Komponenten zu Problemen kommt. Am saubersten ist eine eigene PBS VM mit durchgereichtem Datenträger, also z.B. SSD als raw device eingebunden.
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh