Ja und das Sekundärbackup deines Masters würde ich halt eher auf einen eigenen Server packen, ich bezog mich auf folgenden Teil:
Ich finde es wenig schlüssig im Master extra viel Platz als Sekundärbackup vorzuhalten, wenn man für den...
Was für ein Backup meinst du?
Wenn du ein Backup einer VM machst kannst du das auf jedem beliebigen Hypervisor mit jeder beliebigen Version einspielen.
Bei LXC Containern sieht das etwas anders aus, da der LXC den Hostkernel benutzt. Da kann man...
Da hast du aber irgendein richtiges Problem.
Selbst die PBS mit vielen langsamen HDDs und 200TB+ Daten drauf brauchen maximal eine halbe Stunde für den Prune. GC dann gern mal 4-18 Stunden. Und das ist schon das langsamste Setup was ich betreue...
Da die NIC up ist, sollte der Server erreichbar sein. Kannst du die IP anpingen? Mal versucht per ssh zu verbinden?
Sonst aus der VM mal etwas externes anpingen.
P.S. dein /20 Subnetz ist schon relativ groß für eine Spielwiese.
Du kannst auch ZFS auf einem HW RAID Volume betreiben.
Dann sollte der ZFS Pool immer Single bleiben und niemals ein zweites vdev dem Pool hinzufügen. Dann läuft das stabil und ohne Probleme.
Natürlich kann man dann Features wie Self Healing...
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...