[honx]

mir ist nun zum zweiten mal ein gewisser volsnap-fehler untergekommen:

Die Schattenkopien von Volume "C:" wurden abgebrochen, weil der Schattenkopiespeicher nicht auf ein benutzerdefiniertes Limit vergrößert werden konnte.

hier im detail:

Protokollname: System
Quelle: volsnap
Datum: 14.04.2023 21:58:24
Ereignis-ID: 36
Aufgabenkategorie:Keine
Ebene: Fehler
Schlüsselwörter:Klassisch
Benutzer: Nicht zutreffend
Computer: GameWorkstation
Beschreibung:
Die Schattenkopien von Volume "C:" wurden abgebrochen, weil der Schattenkopiespeicher nicht auf ein benutzerdefiniertes Limit vergrößert werden konnte.
Ereignis-XML:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="volsnap" />
<EventID Qualifiers="49158">36</EventID>
<Level>2</Level>
<Task>0</Task>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2023-04-14T19:58:24.059942800Z" />
<EventRecordID>668043</EventRecordID>
<Channel>System</Channel>
<Computer>GameWorkstation</Computer>
<Security />
</System>
<EventData>
<Data>\Device\HarddiskVolumeShadowCopy44</Data>
<Data>C:</Data>
<Binary>000000000200300000000000240006C00200000000000000030000000000000000000000 00000000</Binary>
</EventData>
</Event>

besagter fehler trat zum ersten mal am 06.11.2022 auf und nun wie gesagt zum zweiten mal.
was ist das für ein fehler und wie kann ich das abstellen?
das ding ist in all den jahren von 2009 ausgehend auch niemals aufgetreten, wie gesagt erst im november zum ersten mal.
hab an den einstellungen bzgl. speicherplatzbelegung im bereich computerschutz auch niemal etwas geändert, steht bei allen partitionen, wo es aktiviert ist, standardmässig auf 1%. zumal die "derzeitige belegung" bei c: gegenwärtig ohnehin bei "0 bytes" steht (screenshot).

und wenn ich in dem reiter computerschutz (screenshot) auf den button "systemwiederherstellung" klicke, steht da "Der Computerschutz ist deaktiviert. Verwenden Sie die Systemwiederherstellung, um ihn zu aktivieren." (screenshot).
dabei ist steht im reiter computerschutz bei sytem (c:) bei schutz ganz klar "ein". oder liegt das daran, dass über all die option "nur vorherige dateiversionen wiederherstellen" aktiviert ist und nicht "systemeinstellungen und vorherige dateiversionen"?

der vollständigkeit halber hier auch noch eine detailkopie des ersten derartigen fehlers vom november 2022:

Protokollname: System
Quelle: volsnap
Datum: 06.11.2022 22:27:27
Ereignis-ID: 36
Aufgabenkategorie:Keine
Ebene: Fehler
Schlüsselwörter:Klassisch
Benutzer: Nicht zutreffend
Computer: GameWorkstation
Beschreibung:
Die Schattenkopien von Volume "C:" wurden abgebrochen, weil der Schattenkopiespeicher nicht auf ein benutzerdefiniertes Limit vergrößert werden konnte.
Ereignis-XML:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="volsnap" />
<EventID Qualifiers="49158">36</EventID>
<Level>2</Level>
<Task>0</Task>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2022-11-06T21:27:27.385859100Z" />
<EventRecordID>648702</EventRecordID>
<Channel>System</Channel>
<Computer>GameWorkstation</Computer>
<Security />
</System>
<EventData>
<Data>\Device\HarddiskVolumeShadowCopy56</Data>
<Data>C:</Data>
<Binary>000000000200300000000000240006C00200000000000000090000000000000000000000 00000000</Binary>
</EventData>
</Event>

[honx]

hab vorübergehend den computerschutz für c: deaktiviert und danach wieder aktiviert und einen systemwiederherstellungspunkt erstellt, welchen ich diesmal sogar erstellen konnte. denn besagte systemwiederherstellung behauptet nun nicht mehr, sie sei deaktiviert, obwohl der computerschutz für c: ohnehin auf "ein" steht.
hab nun bei c: auch gleich umgestellt auf "systemeinstellungen und vorherige dateiversionen", allerdings nur für c:, bei den anderen partitionen hab ich "nur vorherige dateiversionen wiederherstellen" eingestellt gelassen.
nun wird bei "derzeitige belegung" auch nicht mehr "0 bytes" angezeigt, sondern ein tatsächlicher wert, aktuell 112,64 mb (zum zeitpunkt wo ich das gerade poste).
was könnte denn da falschgelaufen sein, dass ich den computerschutz erst deaktivieren und danach wieder aktivieren musste, damit das ding tatsächlich aktiviert ist?

[honx]

heute zum dritten mal aufgetreten, scheint wohl alle vier monate der fall zu sein:

Die Schattenkopien von Volume "C:" wurden abgebrochen, weil der Schattenkopiespeicher nicht auf ein benutzerdefiniertes Limit vergrößert werden konnte.

heute nacht aufgetreten, nachdem dreimal eine "älteste schattenkopie von volume c:" gelöscht wurde.
also zuerst 3 mal informationen zu volsnap, ereignis-id 33:

Die älteste Schattenkopie von Volume "C:" wurde gelöscht, um den Datenträger-Speicherplatz für Schattenkopien auf Volume "C:" unterhalb des benutzerdefinierten Limits zu belassen.

und dann besagter fehler, ereignis-id 36.



also im detail alle vier volsnap-events in der reihenfolge ihres auftretens:
00:33 uhr:

Die älteste Schattenkopie von Volume "C:" wurde gelöscht, um den Datenträger-Speicherplatz für Schattenkopien auf Volume "C:" unterhalb des benutzerdefinierten Limits zu belassen.

Protokollname: SystemQuelle: volsnap
Datum: 10.08.2023 00:33:21
Ereignis-ID: 33
Aufgabenkategorie:Keine
Ebene: Informationen
Schlüsselwörter:Klassisch
Benutzer: Nicht zutreffend
Computer: GameWorkstation
Beschreibung:
Die älteste Schattenkopie von Volume "C:" wurde gelöscht, um den Datenträger-Speicherplatz für Schattenkopien auf Volume "C:" unterhalb des benutzerdefinierten Limits zu belassen.
Ereignis-XML:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="volsnap" />
<EventID Qualifiers="16390">33</EventID>
<Level>4</Level>
<Task>0</Task>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2023-08-09T22:33:21.081171700Z" />
<EventRecordID>686559</EventRecordID>
<Channel>System</Channel>
<Computer>GameWorkstation</Computer>
<Security />
</System>
<EventData>
<Data>\Device\HarddiskVolumeShadowCopy81</Data>
<Data>C:</Data>
<Binary>000000000200300000000000210006400200000000000000110000000000000000000000 00000000</Binary>
</EventData>
</Event>

00:45 uhr:

Die älteste Schattenkopie von Volume "C:" wurde gelöscht, um den Datenträger-Speicherplatz für Schattenkopien auf Volume "C:" unterhalb des benutzerdefinierten Limits zu belassen.

Protokollname: SystemQuelle: volsnap
Datum: 10.08.2023 00:45:25
Ereignis-ID: 33
Aufgabenkategorie:Keine
Ebene: Informationen
Schlüsselwörter:Klassisch
Benutzer: Nicht zutreffend
Computer: GameWorkstation
Beschreibung:
Die älteste Schattenkopie von Volume "C:" wurde gelöscht, um den Datenträger-Speicherplatz für Schattenkopien auf Volume "C:" unterhalb des benutzerdefinierten Limits zu belassen.
Ereignis-XML:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="volsnap" />
<EventID Qualifiers="16390">33</EventID>
<Level>4</Level>
<Task>0</Task>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2023-08-09T22:45:25.608171700Z" />
<EventRecordID>686560</EventRecordID>
<Channel>System</Channel>
<Computer>GameWorkstation</Computer>
<Security />
</System>
<EventData>
<Data>\Device\HarddiskVolumeShadowCopy84</Data>
<Data>C:</Data>
<Binary>000000000200300000000000210006400200000000000000120000000000000000000000 00000000</Binary>
</EventData>
</Event>

00:49 uhr:

Die älteste Schattenkopie von Volume "C:" wurde gelöscht, um den Datenträger-Speicherplatz für Schattenkopien auf Volume "C:" unterhalb des benutzerdefinierten Limits zu belassen.

Protokollname: SystemQuelle: volsnap
Datum: 10.08.2023 00:49:21
Ereignis-ID: 33
Aufgabenkategorie:Keine
Ebene: Informationen
Schlüsselwörter:Klassisch
Benutzer: Nicht zutreffend
Computer: GameWorkstation
Beschreibung:
Die älteste Schattenkopie von Volume "C:" wurde gelöscht, um den Datenträger-Speicherplatz für Schattenkopien auf Volume "C:" unterhalb des benutzerdefinierten Limits zu belassen.
Ereignis-XML:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="volsnap" />
<EventID Qualifiers="16390">33</EventID>
<Level>4</Level>
<Task>0</Task>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2023-08-09T22:49:21.959171700Z" />
<EventRecordID>686561</EventRecordID>
<Channel>System</Channel>
<Computer>GameWorkstation</Computer>
<Security />
</System>
<EventData>
<Data>\Device\HarddiskVolumeShadowCopy87</Data>
<Data>C:</Data>
<Binary>000000000200300000000000210006400200000000000000130000000000000000000000 00000000</Binary>
</EventData>
</Event>

01:00 uhr (fehler):

Die Schattenkopien von Volume "C:" wurden abgebrochen, weil der Schattenkopiespeicher nicht auf ein benutzerdefiniertes Limit vergrößert werden konnte.

Protokollname: SystemQuelle: volsnap
Datum: 10.08.2023 01:00:08
Ereignis-ID: 36
Aufgabenkategorie:Keine
Ebene: Fehler
Schlüsselwörter:Klassisch
Benutzer: Nicht zutreffend
Computer: GameWorkstation
Beschreibung:
Die Schattenkopien von Volume "C:" wurden abgebrochen, weil der Schattenkopiespeicher nicht auf ein benutzerdefiniertes Limit vergrößert werden konnte.
Ereignis-XML:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="volsnap" />
<EventID Qualifiers="49158">36</EventID>
<Level>2</Level>
<Task>0</Task>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2023-08-09T23:00:08.659171700Z" />
<EventRecordID>686562</EventRecordID>
<Channel>System</Channel>
<Computer>GameWorkstation</Computer>
<Security />
</System>
<EventData>
<Data>\Device\HarddiskVolumeShadowCopy90</Data>
<Data>C:</Data>
<Binary>000000000200300000000000240006C00200000000000000140000000000000000000000 00000000</Binary>
</EventData>
</Event>

wie im april musste ich wieder den computerschutz für c: deaktivieren und wieder aktivieren, damit danach wieder was anderes als "0 bytes" angezeigt wird...

gibts denn wirklich keine lösung für den dämlichen bullshit?

einmal kann man so einen fehler ja ignorieren (november 2022). zweimal könnte zufall sein (april 2023) aber bei einem dritten mal (august 2023) kommt allmählich sowas wie panik auf...
ist hier unter umständen eine festplatte am abschmieren? aber wie soll das gehen, beide platten in dem rechner sind 2,5 jahre neu, wurden im märz 2021 beide gewechselt, da beide alten platten 10 jahre alter bereits weit überschritten hatten (gingen auf 13 jahre zu). sowas wäre also eigentlich zu erwarten gewesen, wenn ich immer noch besagte alte platten im rechner hätte, welche nun inzwischen 14 jahre am buckel hätten... aber wie gesagt, sind beide platten mit 2,5 jahren neu!!! also was zum scheiss henker ist hier verdammte scheisse nochmal los?

und da heute der fehler wieder aufgetreten ist, liegt es defintiv NICHT daran dass jene option "nur vorherige dateiversionen wiederherstellen" aktiviert war, denn das hatte ich im april ja umgestellt!

[honx]

heute nacht zum vierten mal aufgetreten, diesmal lagen nicht vier monate zwischen den fehlermeldungen sondern nur 3 tage! was zum henker ist hier los???

Protokollname: SystemQuelle: volsnap
Datum: 13.08.2023 23:28:17
Ereignis-ID: 36
Aufgabenkategorie:Keine
Ebene: Fehler
Schlüsselwörter:Klassisch
Benutzer: Nicht zutreffend
Computer: GameWorkstation
Beschreibung:
Die Schattenkopien von Volume "C:" wurden abgebrochen, weil der Schattenkopiespeicher nicht auf ein benutzerdefiniertes Limit vergrößert werden konnte.
Ereignis-XML:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="volsnap" />
<EventID Qualifiers="49158">36</EventID>
<Level>2</Level>
<Task>0</Task>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2023-08-13T21:28:17.941016600Z" />
<EventRecordID>687027</EventRecordID>
<Channel>System</Channel>
<Computer>GameWorkstation</Computer>
<Security />
</System>
<EventData>
<Data>\Device\HarddiskVolumeShadowCopy96</Data>
<Data>C:</Data>
<Binary>000000000200300000000000240006C00200000000000000170000000000000000000000 00000000</Binary>
</EventData>
</Event>

diesmal wurde eine minute vor dem fehler lediglich einmal eine "älteste schattenkopie gelöscht":

Protokollname: SystemQuelle: volsnap
Datum: 13.08.2023 23:27:26
Ereignis-ID: 33
Aufgabenkategorie:Keine
Ebene: Informationen
Schlüsselwörter:Klassisch
Benutzer: Nicht zutreffend
Computer: GameWorkstation
Beschreibung:
Die älteste Schattenkopie von Volume "C:" wurde gelöscht, um den Datenträger-Speicherplatz für Schattenkopien auf Volume "C:" unterhalb des benutzerdefinierten Limits zu belassen.
Ereignis-XML:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="volsnap" />
<EventID Qualifiers="16390">33</EventID>
<Level>4</Level>
<Task>0</Task>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2023-08-13T21:27:26.830016600Z" />
<EventRecordID>687026</EventRecordID>
<Channel>System</Channel>
<Computer>GameWorkstation</Computer>
<Security />
</System>
<EventData>
<Data>\Device\HarddiskVolumeShadowCopy93</Data>
<Data>C:</Data>
<Binary>000000000200300000000000210006400200000000000000160000000000000000000000 00000000</Binary>
</EventData>
</Event>

allerdings bezweiflich ich ernsthaft, dass jenes eingestellte 1% für eine schattenkopie (für c: wären das etwas über 18gb) nach nur drei tagen bereits vollgelaufen sein soll... zumal bei auftreten besagten fehlers ohnehin die gesamte systemwiederherstellung für c: gewipt wurde und das ding folglich ohnehin wieder bei 0 bytes und ohne irgendwelche systemwiederherstellungspunkte neu anfängt, welche ja wie gesagt durch besagten error allesamt gelöscht wurden...
und es sollte ja eigentlich auch kein "benuzterdefiniertes limit" vergrössert werden, sondern einfach nur wie gehabt älteste schattenkopien gelöscht werden, wenn das ding am volllaufen sein sollte... von daher ist mir gänzlich unverständlich, wie is zu besagtem error überhaupt kommen kann, wenn ja doch nur älteste schattenkopien entfernt werden müssen, um wieder platz zu schaffen...
noch weniger kann ich nachvollziehen, warum das "benutzerdefinierte limit" inzwischen überhaupt ein "problem" darstellen sollte. das war immer schon, seit bestehen des systems, auf 1% eingestellt und das hat in all den jahren immer gereicht! zumal vor zweieinhalb jahren wie gesagt beide festplatten getauscht wurden, und dabei wurde auch gleich deren kapazität verdoppelt, statt ursprünglich zwei 1tb platten sind nun zwei platten mit je 2tb verbaut. für das limit der schattenkopie bedeutet das, dass dessen grösse seit der neuen festplattengrösse ohnehin bereits doppelt so gross ist, als es auf den alten festplatten war! heute beträgt das limit mit 1% etwas über 18gb, auf der alten 1tb platte entsprachen besagte 1% lediglich etwas um 10gb... folglich ist mir völlig UNVERSTÄNDLICH, wie ein DOPPELT SO GROSSES limit inzwischen "zu klein" sein soll, wenn jahrelang bereits die hälfte dessen problemlos ausgereicht hat...

doch so wie es aussieht und gemessen an der tatsache, dass ich seit erstellung des threads einen monolog halte, ist hier wohl ohnehin keine antwort zu erwarten... geschweige denn irgendein lösungsansatz...

[Multithread]

Die meisten "Fehler" in der Ereignisanzeige von Windows kannst du eigentlich Ignorieren.
Da wird ein Fehler geschrieben, wenn etwas beim ersten mal nicht geklappt hat.
Dass es danach nochmals Probiert wurde und erfolgreich durchgeführt, siehst du dort dann nicht mehr.

Was die Geschwindigkeit des füllens angeht:
Wenn jede Version einer Datei gespeichert wird für 90 oder so Tage, dann sind die 18GB sehr schnell voll, denn auch Systemdateien zählen da drunter. Damit kann dir ein einzelnes Windows Update die 18GB locker füllen.

Was du sonst machen kannst: Limit auf 5% vbergrössern, oder ist dein C Laufwerk bereits zu 90% voll?

[honx]

Die meisten "Fehler" in der Ereignisanzeige von Windows kannst du eigentlich Ignorieren.
Da wird ein Fehler geschrieben, wenn etwas beim ersten mal nicht geklappt hat.
Dass es danach nochmals Probiert wurde und erfolgreich durchgeführt, siehst du dort dann nicht mehr.

das problem ist nur, wenn jener fehler auftritt, wird automatisch gleich die gesamte schattenkopie für das laufwerk mit allen bis dahin vorhandenen systemwiederherstellungspunkten gelöscht.
das fängt dann wieder bei 0 bytes an. das kann man denke ich nicht einfach so ignorieren. was ist wenn man mal eine systemwiederherstellung braucht und gerade keine systemwiederherstellungspunkte verfügbar sind, weil gerade der fehler wieder aufgetreten war?

Was die Geschwindigkeit des füllens angeht:
Wenn jede Version einer Datei gespeichert wird für 90 oder so Tage, dann sind die 18GB sehr schnell voll, denn auch Systemdateien zählen da drunter. Damit kann dir ein einzelnes Windows Update die 18GB locker füllen.

bzgl. windows updates finden hier ohnehin nur noch tägliche updates für microsoft security essentials statt... und in dem zusammenhang wird in der regel nur jeden dritten tag ein systemwiederherstellungspunkt erstellt, das geschieht gar nicht täglich, hab ich festgestellt...

Was du sonst machen kannst: Limit auf 5% vergrössern, oder ist dein C Laufwerk bereits zu 90% voll?

auf c: ist sogar noch mehr als die hälfte (1.04tb von 1.81tb) frei.

ich könnte das testweise mal auf 2% vergrössern, doch weiter will ich offen gestanden nicht gehen. denn 5% wären bereits an die 100gb, das ist way too much! auch wenn auf dem volum noch so viel frei ist, speicherplatz zu verschenken hab ich auch nicht!

weiters fehlt mir gänzlich das verständnis, warum ich jetzt, nach 15 jahren betrieb, plötzlich überhaupt das limit vergrössern muss!
das hat doch bislang auch immer gelangt, also warum plötzlich nicht mehr? was ist neu, dass das plötzlich auftritt? zumal windows ja nicht wie im fehler beschrieben, eigentlich gar NICHT irgendein benutzerdefiniertes limit vergrössern sollte, sondern lediglich wie bisher älteste schattenkopien löschen, um wieder platz zu schaffen, wenn platz rar wird...
genau das sollte volsnap normalerweise machen:

Die älteste Schattenkopie von Volume "C:" wurde gelöscht, um den Datenträger-Speicherplatz für Schattenkopien auf Volume "C:" unterhalb des benutzerdefinierten Limits zu belassen.

genau das wäre der job und nichts anderes!
genau das wäre eine normale volsnap-meldung, welche ich im eventlog erwarten würde. genau das sollte gemacht werden und nicht an irgendwelchen "benutzerdefinierten limits" rumpfuschen. das ist nicht der job! also warum versucht volsnap das neuerdings?

zumal besagtes limit wie bereits geschrieben mit der alten festplatte sogar noch kleiner war, denn 1% gemessen an der aktuellen 2tb platte ist entsprechend doppelt so gross als 1% gemessen an der alten 1tb platte...
d.h. aktuell beträgt das limit mit 1% bei meiner 2tb platte 18,63gb, vor dem plattentausch betrug das selbe limit von 1% bei der alten 1tb platte nur etwas um 10gb, also um die hälfte weniger. und das hat immer ausgereicht!
demnach wurde das limit bereits einmal automatisch vergrössert, mit dem einbau der doppelt so grossen festplatten!
das ist es, was ich absolut nicht und ganz und gar nicht nachvollziehen oder irgendwie verstehen kann!

jedenfalls hab ich an dem system seit jahren nichts mehr geändert oder gar irgendwas installiert, was also auch immer jene neue änderung verursacht haben mag, es war keine meiner aktionen...

[jabu]

Diese Speichermethode wird nicht nur für die Systemwiederherstellung und (optional) für Dateiversionen des Benutzers verwendet, sondern auch als Zwischenspeicher zum Konsistenthalten von Backups.

Ein einigermaßen plausibler Fall für dieses Symptom (kein Defekt, kein Dateisystemfehler, kein Bug) wäre, dass bei Backups der Speicherbereich für Schreiboperationen durch Programme, die (zur Konsistenzwahrung) die VSS*-Infrastruktur nutzen, zu knapp ist. Die Formulierung passt trotzdem nicht ganz, aber das kommt bei Windows oft vor.

*VSS: Volume Shadow Copy Service

Da bei einigen Operationen im Voraus unbekannt ist, wieviel noch geschrieben werden wird (man müsste sonst in die Zukunft blicken können), ist dort unbekannt, wieviel Platz benötigt werden wird. Es könnte daher durchaus nötig sein, alte Schattenkopien, eine nach der anderen, zu verwerfen und auf Erfolg zu spekulieren.

Aber das sollte eigentlich keine Entschuldigung dafür sein, dass Microsoft das (wieder mal, darin ist MS meisterhaft) so behämmert miteinander verquirkst hat und dem Benutzer keine Wahl lässt.

Die VSS-Infrastruktur ist so ausgelegt, dass sie von anderen Programmen mitverwendet werden kann. Das wären einerseits Backupprogramme anderer Anbieter und andererseits Programme, bei denen es besonders wichtig ist, dass die von ihnen gespeicherten Daten in einem Backup konsistent sind, auch falls der Schreibvorgang während eines Backups erfolgt. Dazu gehören zum Beispiel Datenbanken und virtuelle Maschinen. Dadurch, dass dort oft große Dateien lange zum Schreiben geöffnet sind, ist das ein Problem, um das man in vielen Fällen nicht mal eben herumzirkeln kann.

Die Idee, dass es an einem Dateisystemfehler oder einem kleinen Defekt an der Datenträgeroberfläche liegen könnte, passt besser zur Fehlermeldung. Aber das muss bei Windows nichts heißen.

Du lässt nicht zufällig in Abständen Backups einer ganzen Partition anlegen? Auch inkrementelle Backups, bei denen nur geänderte Dateien gespeichert werden, würde ich vorsichtshalber mitzählen. Ich würde mich erst mal nicht darauf festlegen wollen, wie etwas im Detail funktioniert, da es zu "Ausschließeritis" führen könnte.

Hinzugefügt:
Hast du damals auf dein neues HDD frisch installiert? Oder ging das über ein "Klonen"? Beim Klonen werden die Sektoren kopiert, sodass Dateisystemfehler erhalten bleiben. So könnten in dem Fall welche mitkopiert worden sein.

Es wäre natürlich mühsam, aber die Aufgabenplanung nach zeitlich passenden Jobs zu durchsuchen, wäre auch ein Ansatz. Dabei wäre zu beachten, dass Jobs aufgeschoben worden sein könnten, weswegen man das Zeitraster nicht zu eng stecken sollte.

[honx]

der festplattentausch fand im märz 2021 statt, der inhalt beider platten wurde geklont und partitionen entsprechend vergrössert (wie gesagt sind beide neue platten mit je 2tb doppelt so gross wie beide alten platten mit je 1tb).
seit märz 2021 finden mittels veeam agent auch wöchentliche backups statt, und zwar auf einer externen 4tb festplatte, welche mittels usb angeschlossen ist. in der regel läuft das so ab, dass eines der backups im monat ein vollständiges "full" backup ist und die restlichen in dem jeweiligen monat sind inkrementell. ob voll oder inkrementell entscheidet veeam selbstständig.

der erste derartige volsnap-fehler ist jedoch erst am 06. november 2022 aufgetreten, also anderthalb jahre NACH dem klonen. davor hat der volsnap-job ordnungsgemäss funktioniert, auch nach dem festplattentausch.
bis zum bösen 06.11.2022, als der fehler erstmals im eventviewer auftrat, gab es von volsnap immer nur jenes ordnungsgemässe informations-event, welches man normalerweise erwarten würde:

Die älteste Schattenkopie von Volume "C:" wurde gelöscht, um den Datenträger-Speicherplatz für Schattenkopien auf Volume "C:" unterhalb des benutzerdefinierten Limits zu belassen.

erst am 06.11.2022 wurde erstmals versucht, an irgendeinem "benutzerdefinierten limit" herumzupfuschen, was dann in dem fehler-event resultierte:

Die Schattenkopien von Volume "C:" wurden abgebrochen, weil der Schattenkopiespeicher nicht auf ein benutzerdefiniertes Limit vergrößert werden konnte.

erstmals am 06.11.2022, das zweite mal 5 monate später am 14.04.2023, das dritte mal 4 monate nach dem zweiten mal am 10.08.2013 und das vierte mal diesmal lediglich 3 TAGE nach dem dritten mal, am 13.08.2023...
das ganze problem nahm seinen anfang also erst am 06.11.2023, somit wie gesagt, anderthalb jahre NACH dem klonen.
daher würde ich mal definitiv ausschliessen, dass ein "alter" dateisystemfehler mitgeklont worden sein könnte. denn andernfalls hätte das problem ja bereits wesentlich früher seinen anfang nehmen müssen, unter umständen bereits vor dem festplattentausch im märz 2021...
falls also tatsächlich irgendein dateisystemfehler vorliegen sollte, dann muss das folglich ein neuer fehler sein, aufgetreten auf einer der neuen 2tb platten.

da volsnap scheinbar keinerlei zeitliche vorgaben zu haben scheint und einfach irgendwann aktiv wird, lässt sich schwer feststellen, mit welchen diensten da zufällig kollidiert worden sein könnte. der 06.11.2022 (als der fehler um 22:27 uhr erstmals auftrat) war ein sonntag. der 14.04.2023 (fehler nr. 2 um 21:58 uhr) war ein freitag. 10.08.2023 (fehler nr. 3 um 01:00 uhr) war ein donnerstag. und der 13.08.2023 (fehler nr. 4 um 23:28 uhr) war wiedermal ein sonntag.

wichtige geplante events, welche mir spontan bekannt sind: windows sicherung montags um 02:00 uhr früh, veeam backup immer mittwochs um 02:00 uhr früh und der wöchentliche scan der microsoft security essentials findet sonntags um 02:00 uhr früh statt. mir wären auf die schnelle eigentlich keine aufgaben bekannt, welche im zeitraum des auftretens der vier fehler (#1: 22:27 uhr, #2: 21:58 uhr, #3: 01:00 uhr, #4 23:28 uhr) laufen würden.
ich hab jedenfalls wie gesagt alles wichtige wie av-scan und backups immer nach mitternacht (immer ab 02:00 uhr früh exakt) geplant, um somit sicherzustellen, dass solche geschichten zu einer zeit stattfinden, wenn ich NICHT am rechner hocke sondern an der matratze säge...

zumal jene vier volsnap fehler bislang meist an anderen wochentagen auftraten (sonntag, freitag, donnerstag, sonntag)...

[jabu]

seit märz 2021 finden mittels veeam agent auch wöchentliche backups statt, und zwar auf einer externen 4tb festplatte, welche mittels usb angeschlossen ist. in der regel läuft das so ab, dass eines der backups im monat ein vollständiges "full" backup ist und die restlichen in dem jeweiligen monat sind inkrementell. ob voll oder inkrementell entscheidet veeam selbstständig.
[...]
wichtige geplante events, welche mir spontan bekannt sind: windows sicherung montags um 02:00 uhr früh, veeam backup immer mittwochs um 02:00 uhr früh und der wöchentliche scan der microsoft security essentials findet sonntags um 02:00 uhr früh statt. mir wären auf die schnelle eigentlich keine aufgaben bekannt, welche im zeitraum des auftretens der vier fehler (#1: 22:27 uhr, #2: 21:58 uhr, #3: 01:00 uhr, #4 23:28 uhr) laufen würden.
ich hab jedenfalls wie gesagt alles wichtige wie av-scan und backups immer nach mitternacht (immer ab 02:00 uhr früh exakt) geplant, um somit sicherzustellen, dass solche geschichten zu einer zeit stattfinden, wenn ich NICHT am rechner hocke sondern an der matratze säge...
[...]
da volsnap scheinbar keinerlei zeitliche vorgaben zu haben scheint und einfach irgendwann aktiv wird, lässt sich schwer feststellen, mit welchen diensten da zufällig kollidiert worden sein könnte. der 06.11.2022 (als der fehler um 22:27 uhr erstmals auftrat) war ein sonntag. der 14.04.2023 (fehler nr. 2 um 21:58 uhr) war ein freitag. 10.08.2023 (fehler nr. 3 um 01:00 uhr) war ein donnerstag. und der 13.08.2023 (fehler nr. 4 um 23:28 uhr) war wiedermal ein sonntag.

zumal jene vier volsnap fehler bislang meist an anderen wochentagen auftraten (sonntag, freitag, donnerstag, sonntag)...

Diese^ Abschnitte von dir beantworten Fragen zu Backups und Zeiten recht ausführlich. Ich zitiere sie zusammen, damit wir die Infos leicht finden können.

Der einfache (direkte) Fall scheint also nicht zu passen, falls du nichts übersehen hast.

Es fallen mir spontan Fälle ein, die trotzdem damit zu tun haben könnten:

• Ein Backup kann nicht gestartet werden, sodass es später nachgeholt wird.
  Nachholen z.B. wegen: PC läuft gerade nicht, zu viel Last, zu viel I/O, zu viel Schreiben auf die Partition (vorsichtshalber nichts vorschnell ausschließen)
• Ein Backup kann nicht abgeschlossen werden (Pausierung aus irgendeinem Grund), sodass es später fortgesetzt wird.
  Pausierung z.B. wegen: zu viel Last, zu viel I/O, zu viel Schreiben auf die Partition, Herunterfahren, Energiesparen (vorsichtshalber nichts vorschnell ausschließen)
• Vorbereitungen als Teil einer denkbaren Strategie, damit das Backup später mit erhöhter Wahrscheinlichkeit nicht nur konsistent, sondern auch termingerecht erfolgen kann. Dieser Fall ist spekulativ, da er auf einer oberflächlichen theoretischen Überlegung, die mir vorhin in den Sinn kam, beruht (kein Anpruch auf Praxisnähe, aber was weiß ich, was Leuten einfällt, also nicht kategorisch ausschließen).

der erste derartige volsnap-fehler ist jedoch erst am 06. november 2022 aufgetreten, also anderthalb jahre NACH dem klonen. davor hat der volsnap-job ordnungsgemäss funktioniert, auch nach dem festplattentausch.
bis zum bösen 06.11.2022, als der fehler erstmals im eventviewer auftrat, gab es von volsnap immer nur jenes ordnungsgemässe informations-event, welches man normalerweise erwarten würde:

Dass es vorher nicht passiert ist, könnte schlicht Zufall gewesen sein. Die Größe des beanspruchten Platzes während Backups richtet sich nämlich nach den gleichzeitig stattfindenden Schreiboperationen anderer Programme, evtl. (je nach Methode) auch nach den Größen der zum Schreiben geöffneten Dateien zum Zeitpunkt des Snapshots. Es könnte also nötig sein, dass eine oder mehrere sehr große Dateien in besagten Bereich kopiert werden müssen (um sie so zu bewahren, wie sie zum Zeitpunkt des Snapshots sind (COW (Copy-on-Write)). Es könnte sich dabei um Dateien handeln, mit denen Programme des Benutzers arbeiten oder mit denen Windows arbeitet.

Es geht dabei um einen Puffer, der zur Konsistenzwahrung nötig ist. Falls der Kram nicht hineinpasst, wird Altes nach und nach gelöscht, bis der komplette Platz zur Verfügung steht. Falls der so freigemachte Platz für den Rest nicht genügt, passt deine Fehlermeldung ungefähr*. In diesem Fall wäre das von dir per Systemsteuerung gesetzte Limit tatsächlich zu klein. Dass sich die Anforderung an den Wert ändert, liegt dabei schlicht an unterschiedlicher Benutzung bezüglich Schreiboperationen (von denen man nicht unbedingt etwas mitbekommen muss). Die Anforderung an den zur Verfügung stehenden Platz kann also unterschiedlich ausfallen, weswegen es nichts bedeuten muss, wenn der Platz früher oder meistens genügt hat.

*Weil zuvor alle Systemwiederherstellungspunkte gelöscht wurden und der neue Inhalt, der für konsistente Backups gebraucht wird, nicht hineinpasst und, zumindest später, nichts nützt, wird alles gelöscht, wozu der Wert 0 passt. Das ist also kein Blödsinn.

Das Konzept der Zwangsverquirksung ist Blödsinn. Das sollte man voneinander trennen.

erst am 06.11.2022 wurde erstmals versucht, an irgendeinem "benutzerdefinierten limit" herumzupfuschen, was dann in dem fehler-event resultierte:

Hier nur nebenbei bemerkt (deine Info habe ich zur Kenntnis genommen): Wie gesagt, würde ich solche Formulierungen vonseiten Windows nicht unbedingt wörtlich nehmen. Sie können wortwörtlich passen, müssen aber nicht.

erstmals am 06.11.2022, das zweite mal 5 monate später am 14.04.2023, das dritte mal 4 monate nach dem zweiten mal am 10.08.2013 und das vierte mal diesmal lediglich 3 TAGE nach dem dritten mal, am 13.08.2023...
das ganze problem nahm seinen anfang also erst am 06.11.2023, somit wie gesagt, anderthalb jahre NACH dem klonen.
daher würde ich mal definitiv ausschliessen, dass ein "alter" dateisystemfehler mitgeklont worden sein könnte. denn andernfalls hätte das problem ja bereits wesentlich früher seinen anfang nehmen müssen, unter umständen bereits vor dem festplattentausch im märz 2021...
falls also tatsächlich irgendein dateisystemfehler vorliegen sollte, dann muss das folglich ein neuer fehler sein, aufgetreten auf einer der neuen 2tb platten.

Ich tippe zwar auch nicht unbedingt darauf. Aber weil ich nicht belegen kann, dass ein solcher Zusammenhang unmöglich ist, bleibt der Kandidat für mich drin. Nur weil ich einen Zusammenhang nicht konkret bestimmen kann, bedeutet das nicht, dass er nicht existieren kann. Es ist ein Teil von Methodik bei Fehlersuchen, nichts vorschnell auszuschließen. Auch falls es in diesem Fall eine unzutreffende Fährte ist, ist die Methode sinnvoll, da es in anderen Fällen ganz anders sein kann, zum Beispiel indem man tagelang unnütz nach einem Fehler sucht, weil man eine andere Fährte vorschnell ausgeschlossen hat. Im Durchschnitt ist man ohne solche Ausschlüsse erfolgreicher.

Es hat sich sogar bewährt, den Spieß umzudrehen, indem man alles, was sich ohne besondere Verrenkungen prüfen lässt, routinemäßig durchführt, und zwar der Reihe nach, wie das Haus vom Fundament her aufgebaut ist. Das ist den meisten Leuten zu mühsam. Und so finden sie oft zwar ein Symptom nach dem anderen, aber die wahre Ursache nicht. Und so mühen sie sich, teils über lange Zeiträume verteilt, noch mehr. Währenddessen müssen sie mit den Macken leben.

[honx]

Diese^ Abschnitte von dir beantworten Fragen zu Backups und Zeiten recht ausführlich. Ich zitiere sie zusammen, damit wir die Infos leicht finden können.

Der einfache (direkte) Fall scheint also nicht zu passen, falls du nichts übersehen hast.

Es fallen mir spontan Fälle ein, die trotzdem damit zu tun haben könnten:

• Ein Backup kann nicht gestartet werden, sodass es später nachgeholt wird.
  Nachholen z.B. wegen: PC läuft gerade nicht, zu viel Last, zu viel I/O, zu viel Schreiben auf die Partition (vorsichtshalber nichts vorschnell ausschließen)
• Ein Backup kann nicht abgeschlossen werden (Pausierung aus irgendeinem Grund), sodass es später fortgesetzt wird.
  Pausierung z.B. wegen: zu viel Last, zu viel I/O, zu viel Schreiben auf die Partition, Herunterfahren, Energiesparen (vorsichtshalber nichts vorschnell ausschließen)
• Vorbereitungen als Teil einer denkbaren Strategie, damit das Backup später mit erhöhter Wahrscheinlichkeit nicht nur konsistent, sondern auch termingerecht erfolgen kann. Dieser Fall ist spekulativ, da er auf einer oberflächlichen theoretischen Überlegung, die mir vorhin in den Sinn kam, beruht (kein Anpruch auf Praxisnähe, aber was weiß ich, was Leuten einfällt, also nicht kategorisch ausschließen).

bzgl. windows sicherung kann ich mit absoluter sicherheit bestätigen, dass das ding immer pünktlich um 02:00 uhr gestartet wird und zwischen 02:30 uhr und 05:00 abgeschlossen ist, abhängig vom umfang der sicherung. denn auch das wird alles feinsäuberlich in der ereignisanzeige geloggt. windows backup kann man also definitiv ausschliessen, da das ding niemals zu den betreffenden zeiten lief. das windows backup wie auch systemwiederherstellungspunkte werden allerdings nicht auf der systemplatte c: gespeichert sondern auf der ersten partition d: der zweiten festplatte. folglich dürfte es in dem fall zumindest der logik nach von seiten der windows sicherung auch keine schreibzugriffe auf c: geben...

veeam backup kann ich ebenfalls bereits ausschliessen, denn das ding wird von mir höchstpersönlich immer mittwochs um 02:00 uhr angestossen, dafür stell ich mir notfalls nen wecker, sollte ich nicht mehr wach sein. denn den veeam dienst muss ich nach der erledigung des backup jobs wegen seines extrem exzessiven ramverbrauchs auch im idle mode immer killen. ich hab nämlich nur 6gb in der maschine, und wenn jene 6gb nahezu voll sind, dann ist das system unbenutzbar... bei veeam läuft also rein gar nichts mit automatisch. folglich kann ich auch hier mit absoluter sicherheit sagen, dass veeam niemals zu den besagten zeiten der fehler lief. zumal das veeam backup ja wie gesagt auf einer externen 4tb platte stattfindet, da hat auf den lokalen laufwerken c:, d:, e: (von welchen mittels veeam ja ein backup angefertigt wird) rein gar nichts geschrieben zu werden...

auch der geplante wöchentliche scan von microsoft security essentials findet wie geplant pünktlich sonntags um 02:00 uhr statt, auch das ist fein säuberlich dokumentiert in der ereignisanzeige...

Das Konzept der Zwangsverquirksung ist Blödsinn. Das sollte man voneinander trennen.

was ist "zwangsverquirksung"? das kapier ich grade gar nicht, dem kann ich also leider nicht folgen...

zum jüngsten mal, als der fehler im eventviewer auftrat (am 13.08.2023), kann ich noch sagen, dass zu dem zeitpunkt spyware chrome (portable version) bereits seit längerer zeit aktiv war mit einem offenen tab, ein pausierte youtube video, da ich zu dem zeitpunkt bereits länger afk war... kann allerdings nicht mehr sagen, ob oder was an software zu den anderen zeitpunkten geöffnet gewesen sein könnte... abgesehen vom process explorer, welcher seit jahren auf dem zweiten monitor dauerhaft aktiv ist. pe ist immer das erste, was nach einem boot starte und das letzte, das vor dem herunterfahren beendet wird.
achja, und ein explorer fenster war noch offen. da explorer als windows bestandteil bzw. prozess aber ohnehin immer läuft, selbst wenn davon kein fenster offen ist (desktop selbst ist ja auch explorer), zähle ich das mal nicht als zusätzliche software. und ein notepad fenster (ebenfalls windows bestandteil) mit einer geöffneten datei (so ne art todo gedöns) hab ich auch seit jahrzehnten ständig offen. das geht bereits weit bis zu msdos / windows for workgroups 3.11 zeiten zurück. so ein kleiner notepad prozess mit einer geöffneten datei welche vielleicht ein paar kilobyte gross ist, sollte also auch nicht wirklich ein problem darstellen...

[jabu]

bzgl. windows sicherung kann ich mit absoluter sicherheit bestätigen, dass das ding immer pünktlich um 02:00 uhr gestartet wird und zwischen 02:30 uhr und 05:00 abgeschlossen ist, abhängig vom umfang der sicherung. denn auch das wird alles feinsäuberlich in der ereignisanzeige geloggt. windows backup kann man also definitiv ausschliessen, da das ding niemals zu den betreffenden zeiten lief. das windows backup wie auch systemwiederherstellungspunkte werden allerdings nicht auf der systemplatte c: gespeichert sondern auf der ersten partition d: der zweiten festplatte. folglich dürfte es in dem fall zumindest der logik nach von seiten der windows sicherung auch keine schreibzugriffe auf c: geben...

veeam backup kann ich ebenfalls bereits ausschliessen, denn das ding wird von mir höchstpersönlich immer mittwochs um 02:00 uhr angestossen, dafür stell ich mir notfalls nen wecker, sollte ich nicht mehr wach sein. denn den veeam dienst muss ich nach der erledigung des backop jobs wegen seines extrem exzessiven ramverbrauchs auch im idle mode immer killen. ich hab nämlich nur 6gb in der maschine, und wenn jene 6gb nahezu voll sind, dann ist das system unbenutzbar... bei veeam läuft also rein gar nichts mit automatisch. folglich kann ich auch hier mit absoluter sicherheit sagen, dass veeam niemals zu den besagten zeiten der fehler lief. zumal das veeam backup ja wie gesagt auf einer externen 4tb platte stattfindet, da hat auf den lokalen laufwerken c:, d:, e: (von welchen mittels veeam ja ein backup angefertigt wird) rein gar nichts geschrieben zu werden...

Also nochmal (möglicherweise nicht in allen Details korrekt, dafür einfacher):

Der Zwischenspeicher für die Konsistenzwahrung liegt nicht auf dem logischen Laufwerk, auf das geschrieben wird, sondern auf dem der Quelle, also dem, von dem aus gelesen wird (hier: C)!

Eine sträflich vereinfachte Erklärung:
Da ein Backup nicht inkonsistent sein soll/darf, gibt es nämlich die Möglichkeit, den bisherigen Stand von Dateien (zum Zeitpunkt des Snapshots), die beschrieben (verändert) werden, mit ihrem bisherigen Stand in einen Zwischenspeicher (um den es hier geht) zu kopieren (als eine Schattenkopie, die das Backupprogramm sieht). Dieser kann leicht zu klein ausfallen, je nachdem, wieviel auf die Partition der Quelle (bei dir: C) geschrieben wird.

Ob es Windows haargenau so macht, wie ich es beschrieben habe (oder eine verbesserte Strategie anwendet), ist erst mal irrelevant (ich kenne die Details nicht, kann mir aber etwas denken). Es geht darum, dass dieser Zwischenspeicher irgendwann überlaufen kann und dass die Fehlermeldung bei dir grundsätzlich dazu passt (lassen wir mal Wortklauberei bezüglich des Meldungstextes beiseite).

Dieses Problem ist grundsätzlicher Natur, sodass andere Strategien bloß etwas verlagern können, aber das Problem an sich nicht aufzulösen vermögen.

Praktische Implementierungen sind viel komplizierter als diese sträflich vereinfachte Erklärung. Da geht es um ausgeklügelte Copy-on-Write-Semantik, Consumer-Producer-Probleme und solche Sachen (und das teilweise auf der Basis von Sektoren anstatt Dateien). Deswegen hatte ich absichtlich allgemein formuliert. Es würde sonst ausufern und unübersichtlich werden. Und meine Detailkenntnisse dessen, was Windows hier macht, sind sehr beschränkt (weswegen auch Möglichkeiten, die Windows nicht nutzt, mitberücksichtigt werden müssten, und dann wird es schnell sehr umfangreich). Wer es besser weiß, könnte damit Recht haben.

was ist "zwangsverquirksung"? das kapier ich grade gar nicht, dem kann ich also leider nicht folgen...

Wie ich bereits sagte, teilen sich Systemwiederherstellung, Dateihistorie und Schattenkopien für Backups ein gemeinsames Speicherkontingent (auf dem logischen Quelllaufwerk). Das ist zwar platzsparend, beschert aber das von dir beschriebene Problem, dass auch der aktuelle Wiederherstellungspunkt gelöscht werden kann, z.B. falls der Platz nicht für die für konsistente Backups benötigten Schattenkopien genügt.

Du kannst keine Regel vorgeben, die das Verhalten so ändert, wie du es gerne hättest (Unterscheidung nach der Art der Schattenkopien und eine verlässliche Reaktion darauf), da alles so weit miteinander gekoppelt ist (zumindest für den Benutzer) dass sich daraus ein Verhalten mit seltsamen Eigenheiten/Macken (≈Quirks) ergibt. Der Benutzer wird dazu gezwungen, es so zu fressen.

zum jüngsten mal, als der fehler im eventviewer auftrat (am 13.08.2023), kann ich noch sagen, dass zu dem zeitpunkt spyware chrome (portable version) bereits seit längerer zeit aktiv war mit einem offenen tab, ein pausierte youtube video, da ich zu dem zeitpunkt bereits länger afk war...

Dazu schreibt der Browser in einen Cache, bei dem das Dateihandle offen bleibt (andauernder Schreibzugriff, bei dem noch etwas angehängt werden könnte oder nicht). Sollte währenddessen ein Backup, welches einen konsistenten Snapshot erstellt, laufen, so ist es zumindest denkbar, dass von dem ganzen Video, bis zu dem Zeitpunkt des Snapshots, eine Schattenkopie angelegt werden muss, eben um den Stand genau so festzuhalten, wie er zu dem Zeitpunkt ist. Das ginge in den dafür reservierten Bereich des Quellaufwerks.

Zusätzlich dazu^: Was weiß ich, was Windows so schreibt, vielleicht ohne dass es aus Schattenkopien exkludiert wird. Und was weiß ich, welche Dateien sonst noch zum Schreiben geöffnet sind.

Es könnte in der Summe zu viel geworden sein, zum Beipiel durch zu viele oder zu große Dateien, die währendeines Backups zum Schreiben geöffnet sind.

Noch blöder:
Es ist sogar möglich, dass dieses außerhalb eines Backups passiert, nämlich indem eine Anwendung einen VSS-Writer implementiert, welcher munter in diesen Zwischenschpeicher (Schattenkopiespeicher) hineinschreibt, damit bei Backups bloß nichts schiefgeht. Windows selbst verwendet mehrere solcher VSS-Writer, zum Beispiel für die Registry, um sie konsistent zu halten.

Die bei Windows angemeldeten VSS-Writer lassen sich (z.B. per Konsole, Administratorberechtigungen erforderlich) folgendermaßen auflisten:

Vssadmin list writers

[honx]

Dazu schreibt er vorerst andauernd in einen Cache, bei dem das Dateihandle offen bleibt. Sollte währenddessen ein Backup, welches einen konsistenten Snapshot erstellt, laufen, so ist es zumindest denkbar, dass von dem ganzen Video, bis zu dem Zeitpunkt des Snapshots, eine Schattenkopie angelegt werden muss, eben um den Stand genau so festzuhalten, wie er zu dem Zeitpunkt ist. Das ginge in den dafür reservierten Bereich des Quellaufwerks.

wie gesagt, zu dem zeitpunkt lief definitiv kein backup. ich hab nur windows sicherung und veeam, beide haben deren zeiten. backup zeiten wurden auch im eventviewer dokumentiert, folglich fand zu dem zeitpunkt auch kein verspätetes backup statt. einziges "backup", welches ganz offensichtlich aktiv war, war besagtes schattenkopie-gedöns, das den fehler produziert hat.

desweiteren liegt der cache und alles temporäre des chrome-browsers ja bekanntlich im temp ordner (wegwerf-ordner).
welchen sinn sollte es also überhaupt haben, irgendwas temporäres (zum wegwerfen) in einer schattenkopie zu sichern?
so eine aktion wäre ja sowas von seltendämlich!!! wobei - microschrott kann man ja mittlerweile alles mögliche zutrauen...

Noch blöder:
Es ist sogar möglich, dass dieses außerhalb eines Backups passiert, nämlich indem eine Anwendung einen VSS-Writer implementiert, welcher munter in diesen Zwischenschpeicher (Schattenkopiespeicher) hineinschreibt, damit bei Backups bloß nichts schiefgeht. Windows selbst verwendet mehrere solcher VSS-Writer, zum Beispiel für die Registry, um sie konsistent zu halten.

Die bei Windows angemeldeten VSS-Writer lassen sich (z.B. per Konsole, Administratorberechtigungen erforderlich) folgendermaßen auflisten:

Vssadmin list writers

laut vssadmin gibt es eine ganze latte von vss-writern, wohl allesamt von windows selbst:
Task Scheduler Writer
VSS Metadata Storage Writer
Performance Counters Writer
System Writer
ASR Writer
SqlServerWriter
Registry Writer
WMI Writer
Shadow Copy Optimization Writer
COM+ REGDB Writer
BITS Writer

alle melden "Status [1] stabil" und "Letzter Fehler: Kein Fehler".

[jabu]

Vorweg: Ich habe einiges editiert und hoffe, damit Klarheit verbessert zu haben, siehe oben!

Ich will nicht behaupten, mit der Backup-Sache richtig zu liegen. Wegen ihrer allgemein als hoch zu vermutenden Plausibilität wäre es jedoch nicht gut, nicht darauf hinzuweisen.

wie gesagt, zu dem zeitpunkt lief definitiv kein backup. denn ich hab ja nur windows sicherung und veeam und beide haben deren zeiten...
desweiteren liegt der cache und alles temporäre des chrome-browsers ja bekanntlich im temp ordner (wegwerf-ordner). welchen sinn sollte es also überhaupt haben, irgendwas temporäres (zum wegwerfen) in einer schattenkopie zu sichern...
so eine aktion wäre ja sowas von seltendämlich!!! wobei - microschrott kann man ja mittlerweile alles mögliche zutrauen...

Man ahnt manchmal nicht, wieviele komische Fallkonstellationen es geben kann.

laut vssadmin gibt es eine ganze latte von vss-writern, wohl allesamt von windows selbst, allesamt melden "Status [1] stabil", "Letzter Fehler: Kein Fehler":
Task Scheduler Writer, VSS Metadata Storage Writer, Performance Counters Writer, System Writer, ASR Writer, SqlServerWriter, Registry Writer, WMI Writer, Shadow Copy Optimization Writer, COM+ REGDB Writer, BITS Writer

Das ist hier sehr ähnlich (kein BITS dabei, ist ein anderes Windows) und scheint zu passen. Vielleicht gibt es temporär (von Anwendungen veranlasst) weitere sogenannte "Abonennten" (Microsoft-Sprech, eng.: "subscriptions").

[honx]

ich hatte auch noch was editiert, was du zum zeitpunkt deines posts wohl nicht mehr gesehen hast:

... backup zeiten wurden auch im eventviewer dokumentiert, folglich fand zu dem zeitpunkt auch kein verspätetes backup statt. einziges "backup", welches ganz offensichtlich aktiv war, war besagtes schattenkopie-gedöns, das den fehler produziert hat.

auch liste der vss writer hab ich vertikalisiert, der lesbarkeit wegen.

und eine schnelle google suche nach dem ominösen "BITS writer" hat ergeben, dass das wohl irgendwas mit windows update zu tun hat...

hab nun, nachdem ich chrome gestartet hab, auch nochmal dieses vssadmin list gedöns ausgeführt, um zu sehen, ob durch chrome irgendwas dazugekommen ist, sieht allerdings nicht so aus. lediglich reihenfolge der liste hat sich geändert:
Task Scheduler Writer
VSS Metadata Store Writer
Performance Counters Writer
ASR Writer
System Writer
BITS Writer
SqlServerWriter
WMI Writer
Shadow Copy Optimization Writer
Registry Writer
COM+ REGDB Writer

z.b.
bits writer ist nun nicht mehr an letzter stelle sondern eher mehr in der mitte.
registry writer ist an vorletzte stelle gerückt, com+ regdb writer an letzte, etc.

[jabu]

ich hatte auch noch was editiert, was du zum zeitpunkt deines posts wohl nicht mehr gesehen hast:

Alles klar. Ähnliches hattest du wohl schon vorher geschrieben, hatte ich gelesen. Aber was soll man da machen, außer ein dummes Gesicht?

Neben der Fährte bezüglich Backups käme noch infrage, dass die Systemwiederherstellung tatsächlich mehr Platz braucht. Das System kann mit der Zeit anschwellen, zum Beispiel durch Updates (kann nicht mehr viel gewesen sein, ich weiß), systemweit installierte Laufzeitbibliotheken und weitere Treiber. Was Windows vom nicht zwingend benötigten Kram in die Systemwiederherstellung packt, weiß ich nicht (vllt. alles). Falls Laufzeitbibliotheken fehlen, könnte das schon zu einem handfesten Problem werden, bei nicht genutzten Treibern nicht unbedingt. Aber diese Variante wäre seltsam, wegen der viel größeren neuen Festplatte.

Bei mir ist die Systemwiederherstellung deaktiviert, es sei denn, ich verreise mit einem Gerät. "Kinder, bitte nicht nachmachen!"

auch liste der vss writer hab ich vertikalisiert, der lesbarkeit wegen.

Das war mir noch aufgefallen, aber ich war zu faul zum Anpassen.

und eine schnelle google suche nach dem ominösen "BITS writer" hat ergeben, dass das wohl irgendwas mit windows update zu tun hat...

Richtig. BITS heißt in der deutschen Variante des vollen Textes "Intelligenter Hintergrundübertragungsdienst". BITS soll sich nur so viel Bandbreite nehmen, dass man möglichst wenig an Beeinträchtigung merken soll.

[honx]

kann ich gegenwärtig nur beobachten, wann das problem nächstes mal auftritt?
und was an software zu jenem zeitpunkt dann gerade läuft?

das mit der veränderten vss reihenfolge ist egal? nichts, das beunruhigen sollte?

[jabu]

kann ich gegenwärtig nur beobachten, wann das problem nächstes mal auftritt?
und was an software zu jenem zeitpunkt dann gerade läuft?

Versuch macht kluch. Ich habe kein Patentrezept.

Eine weitere Möglichkeit wäre, zu versuchen, den Fehler zu provozieren.

das mit der veränderten vss reihenfolge ist egal? nichts, das beunruhigen sollte?

Ich würde nicht so viel in die Reihenfolge hineininterpretieren.
(Mir ist jedoch klar, wovon sich Reihenfolgen ändern können, aber das ist mir hier zu theoretisch und hat nichts per se mit Fehlern zu tun.)

Vielleicht lohnt sich mal ein Blick in die Aufgabenplanung, unter SystemRestore (Name: "SR", Beschreibung: "Diese Aufgabe erstellt normale Systemschutzpunkte." (bei meinem Windows 10)).
Vielleicht passt der Zeitpunkt des Jobs zu deinen Beobachtungen.

[honx]

Vielleicht lohnt sich mal ein Blick in die Aufgabenplanung, unter SystemRestore (Name: "SR", Beschreibung: "Diese Aufgabe erstellt normale Systemschutzpunkte." (bei meinem Windows 10)).
Vielleicht passt der Zeitpunkt des Jobs zu deinen Beobachtungen.

bei SR steht als "nächste laufzeit" 16.08.2023 00:00 uhr.
als trigger sind definiert: täglich um 00:00 uhr und bei systemstart.

mir fällt allerdings auf, dass die speicherplatzbelegung im systemschutz auch mal eben einfach so wächst, ohne dass ein systemwiederherstellungspunkt erstellt worden wäre. "derzeitige belegung" war heute morgen 3,04gb, aktuell 3,18gb. maximale belegung lass ich vorerst noch auf 1% damit es nicht so lange dauert, bis volsnap wieder aktiv wird. speicherplatzbelegung für partitionen d: und e: auf der zweiten platte wachsen nicht so schnell, bei d: ist das ding lediglich von 9,72gb heute morgen auf aktuell 9,73gb gewachsen. e: hat sich seit heute morgen von 9,27gb auf 9,29gb vergrössert. bei d: und e: beträgt das 1% allerdings nur 10gb, da jene beiden partitionen ja nur jeweils 1tb gross sind. das entspricht des früheren limits für c:, bevor beide festplatten getauscht und deren kapazität verdoppelt wurde.

ich will also nochmal erwähnt haben: das limit für c: wurde durch den tausch bereits verdoppelt, und vorher gab es mit lediglich 10gb limit nie ein problem... genau genommen müsste es sogar weniger als 10gb gewesen sein, denn auf der alten 1tb systemplatte gab es noch eine weitere hp-partition f: des rechnerherstellers, d.h., c: war damals gar nicht mal 1tb gross (1tb war es ohnehin nicht, denn es steht bei festplatten ja bekanntlich nur 1tb drauf, real steht ohenhin weniger kapazität zur verfügung)... das 1% limit für die anderen partitionen auf der zweiten platte müsste damals etwa 6gb für d: gewesen sein und 3-4gb für e:, denn vor dem tausch waren jene partitionen nicht gleich gross sondern 600gb für d: und der rest für e:.