Einzelne VM lässt sich nicht sichern

[Peter123]

Aber der PBS produziert einen ganz anderen Workload als ein Veeam Agent Backup. Darüber mal nachgedacht, dass du tausende kleine Dateien schreibst statt einen VBK von Veeam.

Nö, und schon wieder falsch. DU meinst immer noch den durch veeam B&r gemanageten, d.h. nicht-stand-alone, veeam agent (da gibts die großen .vbk pro backup).

Beim veeam standalone agent for win werden auch tausende chunks produziert:



Veeam-Spezialist wirst Du jedenfalls nicht so schnell

Für die Anderen: Veeam bekommt es schon verdammt gut hin, direkt aus der Win-VM auf S3 zu speichern. Die zusätzliche Last ist bei ausreichend performantem Virtualisierungs-host kaum spürbar in einer Win Server VM.

Ich hoffe aber noch, dass Proxmox das auf Dauer ähnlich performant hinbekommt.

Aktuell ist die direkte S3-Speicherung leider nicht produktiv nutzbar.

 

[Falk R.]

Vielen Dank für Eure Unterstützung im Thread!

• Lessons learned: Die direkte Speicherung auf S3 sollte im Regelfall nicht gemacht werden. Offiziell finde ich dazu noch nichts, da kommt bestimmt was in die FAQs.

Ja das kann man so stehen lassen, dass es oft keine gute Idee ist.

• Ich muss gestehen, ich hatte angenommen, dass -- gerade kombiniert mit dem Fleecing-Mechanismus -- die direkte Sicherung auf S3 möglich wäre, ohne dass die Quell-VMs lahmgelegt werden (Beispielszenario: gelegentliche Sicherung einer sehr großen VM ohne den Wunsch nach sehr schnellen Wiederherstellung, und womöglich steht der S3 lokal).

Mit Fleecing hast du ja schon einmal ganz viel richtig gemacht, damit legst du deine VM nicht lahm, aber musst natürlich deutlich mehr Fleecing Speicher einplanen.

• Auf jeden Fall fände ich wünschenswert, dass ein Job nicht durch time-out-Szenarien beim Speicherziel das Webinterface des PBS lahmlegt bzw. den ganzen Prozess zum Anhalten bringt, sodass keine weiteren Backups mehr laufen. Deshalb großen Dank an den Hersteller @Chris , dass er sich so schnell kümmert.

Das hat Chris zum Glück schon gefixt. Danke dafür, dass du mit deinem Thread auf das Problem aufmerksam gemacht hast.

 

[Falk R.]

Nö, und schon wieder falsch. DU meinst immer noch den durch veeam B&r gemanageten, d.h. nicht-stand-alone, veeam agent (da gibts die großen .vbk pro backup).

Beim veeam standalone agent for win werden auch tausende chunks produziert:

View attachment 89799

Ja das sind die Objekte, das liegt aber am Objektspeicher. Was der Client erzeugt und wie die Objekte nachher aussehen, sind schon mal 2 Paar Schuhe.

Veeam-Spezialist wirst Du jedenfalls nicht so schnell

So schnell nicht, ich arbeite mit Veeam erst seit 2008.

Für die Anderen: Veeam bekommt es schon verdammt gut hin, direkt aus der Win-VM auf S3 zu speichern. Die zusätzliche Last ist bei ausreichend performantem Virtualisierungs-host kaum spürbar in einer Win Server VM.

Sicherst du mit einem Standalone Agent etwas VMs von einem HyperV weg?
Veeam hat natürlich schon ganz viel Arbeit in Caching gesteckt, was vermutlich auch dem Standalone Agent zugute kommt.
Da ich normalerweise nur in größeren Umgebungen mit Veeam arbeite, habe ich keine Ahnung welche Features, wie im Standalone Agent umgesetzt wurden.
Du hast Recht, ich werde wohl nie ein Profi werden, was den Standalone Agent angeht.

Ich hoffe aber noch, dass Proxmox das auf Dauer ähnlich performant hinbekommt.

Ob man genau so viel Arbeit wie Veeam ins Thema Objektspeicher Caching steckt wie bei Veeam, das mag ich bezweifeln.

Aktuell ist die direkte S3-Speicherung leider nicht produktiv nutzbar.

Naja, als Backupkopie funktioniert das ganz gut. Damit kann man sein Sekundärbackup wunderbar mit Georedundanz versorgen.