[SOLVED] PVE > PBS - Snapshot Problem mit VSS Win2025Std

[LachCraft]

Offline kannst du machen, aber ist der Verfügbarkeit nicht so zuträglich.
Die Defaulteinstellung ist, dass Windows ein Flush auf die Disks macht.

Meine Doku ist nicht so Massentauglich, aber eventuell reicht dir schon mal mein Teil zum Einstellen des SQL Verhaltens:

Implementation, put the desired backup type number inside Regkey value
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\QEMU Guest Agent VSS
Provider\VssOption, so that the program can query the desired backup type.

VSS backup types:
number   type
1        VSS_BT_FULL
2        VSS_BT_INCREMENTAL
3        VSS_BT_DIFFERENTIAL
4        VSS_BT_LOG
5        VSS_BT_COPY

Kann man, der Paranoia in mir zuliebe, IRGENDWIE griffig festhalten, dass das durchgeführt wurde?
Crashstate ist klar, bei Snapshot, nur ich würde gerne irgendwo heraus lesen können, dass der Buffer auf wirklich geschrieben wurde.

 

[Falk R.]

Hi, kenne keinen Event, den Windows da protokolliert. Du solltest aber ein Start des VSS (Schattenkopie) sehen.

 

[LachCraft]

Hi, kenne keinen Event, den Windows da protokolliert. Du solltest aber ein Start des VSS (Schattenkopie) sehen.

Und wo? Im Eventlog seh ich nur Errors, wenn sie auftreten, eine Info, dass er das tüddelt nicht.

 

[Falk R.]

Beim Backup im PVE zeigt er bei mir:


Zu der Zeit sehe ich im Windows aber auch nur:

 

[LachCraft]

Ja, das kenne ich auch.
Das sagt ja auch nur dass PVE seinen Job macht, aber Windows ist schwer zu packen. (Hat schon Gründe, warum ich Windows allgemein einem anderen Team um die Ohren geworfen habe ^^)

 

[Falk R.]

Ja, das kenne ich auch.
Das sagt ja auch nur dass PVE seinen Job macht, aber Windows ist schwer zu packen. (Hat schon Gründe, warum ich Windows allgemein einem anderen Team um die Ohren geworfen habe ^^)

Vertrauen zu deinem genutzten OS gehört einfach dazu. Wenn Windows einen VSS Snapshot macht, spammt er dich nicht unnütz voll, aber wenn er den VSS Snap nicht machen konnte oder ein Flush nicht funktioniert, hagelt es Fehlermeldungen im Eventlog. Habe ich früher (etwa 15 Jahre) öfters mal gesehen, vor allem im Zusammenspiel mit Backupexec 11 und 12. Heutzutage mit moderner Backupsoftware sehe ich extrem selten Fehler.

 

[LachCraft]

Okay, dann vertrauen wir bei fehlender Meldung, dass alles getan wurde, damit der Snapshot zumindest in der Hinsicht valide ist.
In dem Sinne ist die Maschine eine Spur "sauberer" mit ihrem Crash-State als wenn klassisch der Strom weg wäre.

Wir wollen nur sichergehen, dass wir so sicher wie möglich OHNE alles runterzufahren insb. Datenbank- und Fileserver im Backup besitzen. Dass die Systeme beim Booten rummaulen ist ja logisch, aber sonst kein Beinbruch.

 

[Falk R.]

Okay, dann vertrauen wir bei fehlender Meldung, dass alles getan wurde, damit der Snapshot zumindest in der Hinsicht valide ist.
In dem Sinne ist die Maschine eine Spur "sauberer" mit ihrem Crash-State als wenn klassisch der Strom weg wäre.

Wir wollen nur sichergehen, dass wir so sicher wie möglich OHNE alles runterzufahren insb. Datenbank- und Fileserver im Backup besitzen. Dass die Systeme beim Booten rummaulen ist ja logisch, aber sonst kein Beinbruch.

Das machen fast alle Unternehmen schon ganz viele Jahre so. Das ein Flush nicht funktioniert, kenne ich eigentlich nicht, nur das wenn ein flush durchgeführt wird und ich habe eine DB auf mehrere Disks in verschiedene Datenbankteile geteilt, hast du manchmal Aussetzer, weil die DB erst wieder reagiert, wenn der Flush auf allen Disks durch ist.

 

[LachCraft]

Ich betreibe das auch auf vielen Ecken so, nur in einem Fall ist uns (auch in Wechselwirkungen mit anderen Problemen) Das Backup um die Ohren geflogen, also kaufen wir das nochmal ganz genau durch.

Das mit der DB ist ein guter Hinweis, aber auch nachvollziehbar.

 

[Falk R.]

Was ist denn da genau passiert? Lief der qemu-agent während des Backups? Wenn da Dateibasierte Anwendungen laufen und verschiedene Disks nutzen, diese aber immer konsistent zueinander sein müssen, dann kann das Probleme geben. Der Flush wird auf allen Disks nacheinander ausgeführt, wenn die Anwendung keinen VSS Provider hat, bekommt die auch nix davon mit und die Datenstände können bis zu mehreren Sekunden unterschied aufweisen.

 

[LachCraft]

Was ist denn da genau passiert? Lief der qemu-agent während des Backups? Wenn da Dateibasierte Anwendungen laufen und verschiedene Disks nutzen, diese aber immer konsistent zueinander sein müssen, dann kann das Probleme geben. Der Flush wird auf allen Disks nacheinander ausgeführt, wenn die Anwendung keinen VSS Provider hat, bekommt die auch nix davon mit und die Datenstände können bis zu mehreren Sekunden unterschied aufweisen.

Also final schiefgelaufen ist was ganz anderes.
Der PBS war zu alt geworden und hatte nicht mehr schnell genug schreiben können.
VM lief weiter und Liveänderungen wurden am Schluss gedroppt, VM war im Eimer. Praktischerweise der Exchange mit seiner Datenbank.
Das wurde schon lange gelöst und wie gesagt, sind wir dabei alles nochmal im Detail durchzugehen und alle möglichen Fehler im Team bekannt zu machen, wie eben das VSS Thema und seinen Logs.

Wenn man mit seinem Panzer gegen die Wand geknallt ist, schaut man generell nochmal alles an :-D

 

[Falk R.]

Dafür gibt es ja zum Glück das Seeding. Da musst du Delays von über 60 Sekunden gehabt haben und im Eventlog müssen ganz viele Disk Warnungen aufgetaucht sein. Bis ein Windows dropt dauert schon ewig. Schlimmer ist es wenn Windows die Daten im RAM Cache hat und einfach ausgeht.

 

[LachCraft]

Dafür gibt es ja zum Glück das Seeding. Da musst du Delays von über 60 Sekunden gehabt haben und im Eventlog müssen ganz viele Disk Warnungen aufgetaucht sein. Bis ein Windows dropt dauert schon ewig. Schlimmer ist es wenn Windows die Daten im RAM Cache hat und einfach ausgeht.

Ja das war auch so. Da haben auch einige Stellen wie Monitoring und Personal gefailt, aber dann macht man es in Zukunft einfach besser. Wir hatten dann richtig Löcher in den Disken, da kannst die Datenbank auch direkt in Müll werfen.

Wir haben einfach zugesehen, dass wir die Hardware den aktuellen Anforderungen anpassen, Seeding hin oder her.

 

[Falk R.]

Ein vernünftiger Backupserver ist immer eine gute Idee, aber viele Daten gehen bei soetwas nicht verloren. Ich habe einige Syteme mit ähnlichen Problemen gerettet, da waren in der Regel nur einige KB-MB defekt und verloren. Auch eine Exchange DB mit kleinen Verlusten kann man noch Readonly nutzen um die Postfächer zu extrahieren, bis auf das oder die betroffenen Postfächer mit den kaputten Daten.