Was? Das prunen geht eigentlich recht schnell. Die garbage-collection oder verify-Job werden bei hdds aber immer lange dauern, weil beim PBS der Datenbestand in zig kleine Dateien ( Chunks ) aufgeteilt wird und jeder (!) chunk dafür eingelesen...
Nein, er nimmt in der Regel das, was eingestellt war. Bei vSphere ist das oft Standard, weil die schon 13x die Art wie man es einstellt geändert haben.
P.S. bei 12 vCPUs muss das schon eine Dicke DB VM sein. Gern mal beim migrieren überprüfen ob...
Das ist jetzt nicht dein Ernst?
Ganz Grundsätzlich könnest du ja mal schauen, wenn du morgens um 4 Uhr die Kiste anschaust, welcher Container / VM den die Last erzeugt - die haben ja alle eine Anzeige für Auslastung in der GUI.
Also Lösung wäre...
Dein Setup bringt Sicherheitstechnisch nix.
Wenn du einen zweiten PBS für die HDDs nimmst und den zusätzlichen absicherst, dann bringt das eine Menge und ist genau so wie ich das regelmäßig bei Kunden mache.
Ja außer die Fallstricke. Wenn ich die richtige Disk auswähle gibt es keinen Fallstrick.
Das schlimmste was passieren kann, dass es nachher nicht schneller als vorher ist.
Ich habe noch einmal den Ursprungspost gelesen.
Vermutlich hast du auch einen Denkfehler. Du machst irgendwann ein Full Backup, danach wird immer nur inkrementell die Änderung gespeichert.
Auch wenn du deine Wochen und Monatsbackups kopierst...
Als sekundär PBS wo die Restoreperformance egal ist, nutze ich auf öfters große HDDs. Sonst immer brav auf SSDs. Aber zum testen reichen ja erst einmal HDDs.
Ich bin da nicht so tief in der Materie, aber das soll wohl über irgendwelche IDs der Cores gehen bei MS SQL.
Soll ja auch bei HyperV funktionieren, wo man gar nichts tunen kann. ;)
Wenn da steht: Executing script "/usr/share/lxc/hooks/lxc-pve-prestart-hook" for container "200",
Dann vermute ich mal /usr/share/lxc/hooks/lxc-pve-prestart-hook
Hast Recht, die Volumegroup bleibt ja die von der OS Disk.
Ich hätte das eh nicht so gebaut. Ich erstelle im Smart Array inner eine kleine vDisk für das OS und den Rest dann als große Disk für den Rest.
Dann kann man da viel fexibler arbeiten...
Wenn du irgendwelche Scripte ausführst ohne zu wissen was da passiert, bist du immer erst einmal selbst schuld.
Proxmox rollt Updates aus die sauber getestet sind, aber natürlich nicht mit irgendwelchen Scripten von irgendwelchen Personen.
Dann...
Das macht doch gar keinen Sinn, außer die Daten werden täglich wieder überschrieben, aber da stellt sich eh die Frage der Sinnhaftigkeit von Monatsbackups.
Wenn man täglich synchronisiert ist die änderungsrate bei normalen Servern deutlich...
Das ist nicht de Anspruch vom PBS und wird er nie können. Ich nutze weiterhin Veeam für Application Aware, aber nur noch per Agent auf den paar Servern wo es benötigt wird. Der Agent läuft 1000x stabiler als die derzeitige PVE Integration.
Hi die 1029 Sekunden sind normal. Das ist scheinbar default.
bei mir ist lastrx immer kleiner als der Intervall.
Du kannst in der chrony.conf hinter iburst minpoll und maxpoll einfügen.
z.B.
....iburst minpoll 6 maxpoll 7 wäre dann zwischen 64...
Hi, lösche einfach den LVM-Thinpool auf deiner OS Disk, am besten gleich die Root Partition vergrößern:
lvremove /dev/pve/data
lvresize -l +100%FREE /dev/pve/root
resize2fs /dev/mapper/pve-root
Danach den anderen Thinpool löschen und mit dem...
Ich habe mir alles noch einmal durchgelesen. Ist deine Anwendung in der großen VM die über 2 NUMA Nodes geht auch NUMA Aware?
Wenn du NUMA aktivierst, wird die Information über die NUMA Nodes an die VM weiter gegeben und die Applikation muss...