Recent content by Falk R.

Ich verstehe die Aussage auch nicht, Backup soll man immer machen und beim Backup knallt gar nichts, denn da wird ja nur gelesen. Schreiben macht die QLC SSDs schnell kaputt, aber niemals ein Backup.

Bei LXC kannst du kein Discard setzen, das geht nur bei VMs. LXC nutzen ja nur einen Mountpoint und daher muss der Container auch nichts machen.

Das liegt niemals an der Option host. Host bedeutet ja nur, dass alle Features der CPU weiter gereicht werden, so wie bei ESXi oder HyperV per default. Ich nutze seit vielen Jahren nur host bei meinen Kunden und bis auf das nested virt. Flag bei 2025 gab es noch nie Probleme damit. Wenn es...

Ich habe zwar Kunden mit Eternus im Backend, aber die nutzen keine LXC, sondern nur VMs, damit man die im Cluster Live migrieren kann. Da gibt es keine Probleme. Warum genau nutzt du LXC auf einem shared Storage?

Warum? Was soll dann besser sein? Was ist den Verboten? Ich glaube nicht das irgend jemand auf dieser Welt einen RDP Server mit Domänen Controller Rolle betreibt. Falls doch, haben wir die Ursache gefunden. Auf einem DC wir das Diskcaching abgeschaltet und immer Write Thru genutzt, was zu...

Vermutlich hast du mal updates auf deinem Host gemacht und da die LXC den Kernel des Hosts mitnutzen, empfiehlt sich auch direkt Updates in den LXC zu installieren, wenn du Kernelupdates auf dem Host machst. Das hilft zu 99% und alles andere findest du nur heraus wenn du in die Logs schaust.

Mindestens 2 SSDs als Special Device. Wenn das Special Device weg ist, sind alle Daten futsch. Deshalb immer mindestens ein Mirror machen

Aus diesem Grund nimmt man immer einen Server mit mehr Slots als man derzeit benötigt. Server mit HDDs gibts viele mit 12 Slots auf 2HE und wenns mehr sein soll auch gern ein Gehäuse mit 36HDDs auf 4HE. Ich bin der Freund von NVMe und nehme gerne ein günstiges 20Slot 2HE Gerät. Da machst du...

Beantworte erst mal die Frage von Dominik. Ja die backups sind defekt, aber retten kann man eventuell die Daten. Wenn die defekten Chunks noch auf der Quellseite (PVE) vorhanden sind und die noch einmal gesichert werden können, ist es eventuell möglich die alten Restorepunkte zu retten. Aber...

Ich glaube dein Hauptproblem ist tatsächlich Kopfsache. Wenn Speicher knapp wird, stecke einfach eine oder mehrere Disks nach. Getrennt sichern, erhöht die Komplexität, aber diese gefühlte Sicherheit ist keine, denn wenn ein Backup kaputt geht, dann nach Murphys Law immer das, was du gerade...

Das ist ein Blockspeicher, da ist das Dateisystem immer noch lokal. Aber bitte kein NAS mit iSCSI nutzen. Da hat man im NAS ein Dateisystem und legt da eine große Datei drauf, die als iSCSI LUN weiter gereicht wird. Das ist immer per Design langsam. Dürfte stabiler laufen als NFS, aber trotzdem...

Wenn du auf verschiedene Datastores sicherst, gibts kein Dedup. Sind es verschiedene Namespaces im Datastore, gibts Dedup. Du solltest eh immer eine Backupkopie machen. Es gibt die Simple 3-2-1 Regel. 3 Datenkopien - Produktiv, Backup, SekundärBackup 2 Medien - Medienbruch ( Nicht klar...

Die 2 DFS Server sollten natürlich getrennt liegen, aber im Backup Datastore würden die dedupliziert werden, solange da keine Microsoft Deduplizierung aktiv ist. Das mit dem Verify wunder mich nicht wirklich. Veeam empfiehlt auch seit Jahren, keine NAS zu nutzen, denn laut deren Support sind 90%...

Beim PBS braucht man kein ZFS mit HW Raid, macht nur Sinn wenn ich Replikation im PVE nutzen möchte. Dann ein Single vDev vom HW Raid Volume und niemals den Pool erweitern, Mirror oder Special Device hinzufügen.

HyperV braucht das, VBS (virtualization based security) oder wenn man Terminalserver benutzt, will man eventuell gesandboxte Browser haben, das sind auch mini HyperV Container.