Veeam VSS Fehler mit ID 24 und 35 - Kein Platz?
Hallo,
ich habe hier gerade etwas was ich so noch nicht gesehen habe.
Server mit ESXi 6.0 auf einem Fujitsu TX2540.
Darauf 2 VMs mit Windows Server 2012 R2. Einmal als AD mit Dateifreigaben und einmal als Exchange 2013.
Die Datensicherung läuft mit Veeam B&R 9.5u4.
Die Datensicherung läuft fehlerfrei durch.
Aber im Eventlog des ADs stehe 2 Fehler im Abstand von ca. 1 Minute.
1. ID 24
Es steht nicht genügend Speicherplatz auf Volume "C:" zur Verfügung, um den Schattenkopiespeicher für Schattenkopien von "C:" zu erhöhen. Möglicherweise werden aufgrund dieses Fehlers alle Schattenkopien auf Volume "C:" gelöscht.
2. ID 35
Die Schattenkopien von Volume "C:" wurden abgebrochen, weil der Schattenkopiespeicher nicht vergrößert werden kann.
Der AD hat zwei Laufwerke
C: 120 GB insgesamt, davon 23,5 GB frei, Schattenkopie nicht aktiviert
D: 600 GB insgesamt, davon 119 GB frei, Schattenkopie mit 80GB max aktiviert
Ich habe mal spasseshalber auf C die Schattenkopien aktiviert.
Ich kann ohne Probleme einen Snapshot erstellen.
Mit aktiviertem Schattenkopien auf C schlägt die Sicherung mit Veeam fehl.
1. Warum gibt es ein Problem mit den Schattenkopien für C:?
Dies sind doch gar nicht aktiviert.
2. 23,5 GB sind für Windows-Server doch recht viel was frei ist.
Wo liegt das Problem?
Bzw. ist es ein Problem?
Am Rande:
Ich habe Schattenkopien immer nur auf Laufwerken mit Dateifreigaben aktiviert um einfach und schnell Dateien und Verzeichnisse wiederherstellen zu können.
Sollte/kann/muss/sollte nicht/kann nicht/muss nicht das auf dem Systemlaufwerk aktiviert werden?
Vieleicht hat ja einer eine Idee.
Danke und viele Grüße
Stefan
ich habe hier gerade etwas was ich so noch nicht gesehen habe.
Server mit ESXi 6.0 auf einem Fujitsu TX2540.
Darauf 2 VMs mit Windows Server 2012 R2. Einmal als AD mit Dateifreigaben und einmal als Exchange 2013.
Die Datensicherung läuft mit Veeam B&R 9.5u4.
Die Datensicherung läuft fehlerfrei durch.
Aber im Eventlog des ADs stehe 2 Fehler im Abstand von ca. 1 Minute.
1. ID 24
Es steht nicht genügend Speicherplatz auf Volume "C:" zur Verfügung, um den Schattenkopiespeicher für Schattenkopien von "C:" zu erhöhen. Möglicherweise werden aufgrund dieses Fehlers alle Schattenkopien auf Volume "C:" gelöscht.
2. ID 35
Die Schattenkopien von Volume "C:" wurden abgebrochen, weil der Schattenkopiespeicher nicht vergrößert werden kann.
Der AD hat zwei Laufwerke
C: 120 GB insgesamt, davon 23,5 GB frei, Schattenkopie nicht aktiviert
D: 600 GB insgesamt, davon 119 GB frei, Schattenkopie mit 80GB max aktiviert
Ich habe mal spasseshalber auf C die Schattenkopien aktiviert.
Ich kann ohne Probleme einen Snapshot erstellen.
Mit aktiviertem Schattenkopien auf C schlägt die Sicherung mit Veeam fehl.
1. Warum gibt es ein Problem mit den Schattenkopien für C:?
Dies sind doch gar nicht aktiviert.
2. 23,5 GB sind für Windows-Server doch recht viel was frei ist.
Wo liegt das Problem?
Bzw. ist es ein Problem?
Am Rande:
Ich habe Schattenkopien immer nur auf Laufwerken mit Dateifreigaben aktiviert um einfach und schnell Dateien und Verzeichnisse wiederherstellen zu können.
Sollte/kann/muss/sollte nicht/kann nicht/muss nicht das auf dem Systemlaufwerk aktiviert werden?
Vieleicht hat ja einer eine Idee.
Danke und viele Grüße
Stefan
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 502721
Url: https://administrator.de/forum/veeam-vss-fehler-mit-id-24-und-35-kein-platz-502721.html
Ausgedruckt am: 29.04.2025 um 05:04 Uhr
9 Kommentare
Neuester Kommentar
Servus.
Der VSS-Writer wird von der Backup-Software genutzt. Sonst bekommst kein konsistente Backup aus einer laufenden Maschine.
Grüsse Henere
Der VSS-Writer wird von der Backup-Software genutzt. Sonst bekommst kein konsistente Backup aus einer laufenden Maschine.
Grüsse Henere
Moin Stefan,
liegen die Schattenkopien auf dem gleichen Laufwerk, wo Sie erstellt wurden?
Ich kenne es so, daß man die Schattenkopien NICHT, auf dem gleichen Volume erstellen sollte, für welches man diese erstellt.
> Sollte/kann/muss/sollte nicht/kann nicht/muss nicht das auf dem Systemlaufwerk aktiviert werden?
Wie schon ob en von mir geschrieben, habe ich die Schattenkopien von Laufwerk C: immer auf ein anderes Laufwerk (z.B.: Laufwerk D
erstellt.
Wenn kein zweites Laufwerk auf dem Server existiert, kann man notgedrungen dies auch auf de gleichen Laufwerk erstellen, oder ein weiteres Laufwerk explizit für Schattenkopien erstellen. Bei VMs ist es dann eine weitere VMDK (VMware) oder vhd / xvhd (Hyper-V).
Gruss Penny.
liegen die Schattenkopien auf dem gleichen Laufwerk, wo Sie erstellt wurden?
Ich kenne es so, daß man die Schattenkopien NICHT, auf dem gleichen Volume erstellen sollte, für welches man diese erstellt.
vssadmin add shadowstorage /for=‹Volume› /on=‹Volume› /maxsize=‹Größe›Ich habe Schattenkopien immer nur auf Laufwerken mit Dateifreigaben aktiviert um einfach und schnell Dateien und Verzeichnisse wiederherstellen zu können.
Sollte eigentlich kein Thema sein, zumindest habe ich im Internet nichts gegenteiliges finden können.> Sollte/kann/muss/sollte nicht/kann nicht/muss nicht das auf dem Systemlaufwerk aktiviert werden?
Wie schon ob en von mir geschrieben, habe ich die Schattenkopien von Laufwerk C: immer auf ein anderes Laufwerk (z.B.: Laufwerk D
erstellt.Wenn kein zweites Laufwerk auf dem Server existiert, kann man notgedrungen dies auch auf de gleichen Laufwerk erstellen, oder ein weiteres Laufwerk explizit für Schattenkopien erstellen. Bei VMs ist es dann eine weitere VMDK (VMware) oder vhd / xvhd (Hyper-V).
Gruss Penny.
Zitat von @Henere:
Der VSS-Writer wird von der Backup-Software genutzt. Sonst bekommst kein konsistente Backup aus einer laufenden Maschine.
Und was hat das mit meiner Frage zu tun? Denn VSS funktioniert fehlerfrei. Er meckert nur bei den Schattenkopien.Der VSS-Writer wird von der Backup-Software genutzt. Sonst bekommst kein konsistente Backup aus einer laufenden Maschine.
Ja
Ich kenne es so, daß man die Schattenkopien NICHT, auf dem gleichen Volume erstellen sollte, für welches man diese erstellt.
Und was soll das bringen? Außer mehr Platz. Für mich gehören die Daten bei einem Datenlaufwerk gefühlt dazu. > Sollte/kann/muss/sollte nicht/kann nicht/muss nicht das auf dem Systemlaufwerk aktiviert werden?
Wie schon ob en von mir geschrieben, habe ich die Schattenkopien von Laufwerk C: immer auf ein anderes Laufwerk (z.B.: Laufwerk D erstellt.
Wenn kein zweites Laufwerk auf dem Server existiert, kann man notgedrungen dies auch auf de gleichen Laufwerk erstellen, oder ein weiteres Laufwerk explizit für Schattenkopien erstellen. Bei VMs ist es dann eine weitere VMDK (VMware) oder vhd / xvhd (Hyper-V).
Aber ich habe die Schattenkopien für C ja gar nicht aktiviert.Wie schon ob en von mir geschrieben, habe ich die Schattenkopien von Laufwerk C: immer auf ein anderes Laufwerk (z.B.: Laufwerk D
erstellt.Wenn kein zweites Laufwerk auf dem Server existiert, kann man notgedrungen dies auch auf de gleichen Laufwerk erstellen, oder ein weiteres Laufwerk explizit für Schattenkopien erstellen. Bei VMs ist es dann eine weitere VMDK (VMware) oder vhd / xvhd (Hyper-V).
Also aktiviert Veeam die für die Sicherung und ihm reichen 23,5 GB als Speicherplatz nicht aus. Ist doch absurd.
Moin,
einfach die VMs durchbooten, dann gehts wieder.
Hab das identische Thema bei einer 2016er VM mit SQL 2014 drauf, da kommt der Fehler auch von Zeit zu Zeit.
Hab für die VM einen Reboot-Task erstellt, der die VM 2x wöchentlich nachts durchbootet. Seitdem nie wieder fehlerhafte Sicherungen gehabt.
einfach die VMs durchbooten, dann gehts wieder.
Hab das identische Thema bei einer 2016er VM mit SQL 2014 drauf, da kommt der Fehler auch von Zeit zu Zeit.
Hab für die VM einen Reboot-Task erstellt, der die VM 2x wöchentlich nachts durchbootet. Seitdem nie wieder fehlerhafte Sicherungen gehabt.
Zitat von @StefanKittel:
Aber ich habe die Schattenkopien für C ja gar nicht aktiviert.
Also aktiviert Veeam die für die Sicherung und ihm reichen 23,5 GB als Speicherplatz nicht aus. Ist doch absurd.
Aber ich habe die Schattenkopien für C ja gar nicht aktiviert.
Also aktiviert Veeam die für die Sicherung und ihm reichen 23,5 GB als Speicherplatz nicht aus. Ist doch absurd.
Das Problem bei Backups ist ja imem die Konsistenz, d.h. daß alle Dateien den zustand zu einem bestimmten Zeitpunkt haben. Ansonsten läuft man ja Gefahr, daß zusammengehörige Dateien verschiendene Stände haben und nachdem Restore nicht mehr zuammenpassen. Wer jemals ein tar- oder cpio-backup über mehrere MB und viele zigtausend Dateien gemacht hat, weiß was ich meine.
Von daher ist ein VSS-Snapshot gar nicht mal so verkehrt. Dumm ist nur, daß der Platz nicht reicht, vermutlich ändern sich zu viele Dateien während dem Backup. Ich würde daher einfach "C:" mehr Platz spendieren, auch wenn das wurmt.
Oder mal mit einer Kopie der VM testweise mit einer doppelt so großen "Platte" versuchen.
lks
Zitat von @chgorges:
Hab für die VM einen Reboot-Task erstellt, der die VM 2x wöchentlich nachts durchbootet. Seitdem nie wieder fehlerhafte Sicherungen gehabt.
Hab für die VM einen Reboot-Task erstellt, der die VM 2x wöchentlich nachts durchbootet. Seitdem nie wieder fehlerhafte Sicherungen gehabt.
Ach ja, die alte NT-Krankheit, den Server alle paar Tage zeitgesteuert durchbooten zu müssen.
lks
Nö
Da ändert sich nachts eigentlich eher "gar nichts" oder zumindest sehr wenig.
Zitat von @Lochkartenstanzer:
Das Problem bei Backups ist ja imem die Konsistenz, d.h. daß alle Dateien den zustand zu einem bestimmten Zeitpunkt haben. Ansonsten läuft man ja Gefahr, daß zusammengehörige Dateien verschiendene Stände haben und nachdem Restore nicht mehr zuammenpassen. Wer jemals ein tar- oder cpio-backup über mehrere MB und viele zigtausend Dateien gemacht hat, weiß was ich meine.
VSS ist aktiviert und funktioniertDas Problem bei Backups ist ja imem die Konsistenz, d.h. daß alle Dateien den zustand zu einem bestimmten Zeitpunkt haben. Ansonsten läuft man ja Gefahr, daß zusammengehörige Dateien verschiendene Stände haben und nachdem Restore nicht mehr zuammenpassen. Wer jemals ein tar- oder cpio-backup über mehrere MB und viele zigtausend Dateien gemacht hat, weiß was ich meine.
Von daher ist ein VSS-Snapshot gar nicht mal so verkehrt. Dumm ist nur, daß der Platz nicht reicht, vermutlich ändern sich zu viele Dateien während dem Backup. Ich würde daher einfach "C:" mehr Platz spendieren, auch wenn das wurmt.
Wir sprechen von der Systempartition des AD/File-Servers. Es läuft auch keine andere aktive Software darauf.Da ändert sich nachts eigentlich eher "gar nichts" oder zumindest sehr wenig.
Zitat von @StefanKittel:
Wir sprechen von der Systempartition des AD/File-Servers. Es läuft auch keine andere aktive Software darauf.
Da ändert sich nachts eigentlich eher "gar nichts" oder zumindest sehr wenig.
Wir sprechen von der Systempartition des AD/File-Servers. Es läuft auch keine andere aktive Software darauf.
Da ändert sich nachts eigentlich eher "gar nichts" oder zumindest sehr wenig.
O.k. Da sollte sich tatsächlich Nicht viel tun.
Ich würde aber trotzdem mit einer Kopie der VM den Test machen, ob des einen Unterschied macht, ob da "nur" 23 oder 40 oder 60 GB frei sind..
lks
Edit: Typos. War vorhin an einer Tatschtatur, neudeutsch Schlaufon genannt, statt Tastatur
Zitat von @Penny.Cilin:
liegen die Schattenkopien auf dem gleichen Laufwerk, wo Sie erstellt wurden?
Ich kenne es so, daß man die Schattenkopien NICHT, auf dem gleichen Volume erstellen sollte, für welches man diese erstellt.
liegen die Schattenkopien auf dem gleichen Laufwerk, wo Sie erstellt wurden?
Ich kenne es so, daß man die Schattenkopien NICHT, auf dem gleichen Volume erstellen sollte, für welches man diese erstellt.
vssadmin add shadowstorage /for=‹Volume› /on=‹Volume› /maxsize=‹Größe›Damit funktioniert es nun fehlerfrei
vssadmin add shadowstorage /for=c: /on=e: /maxsize=10GBZitat von @Lochkartenstanzer:
Ich würde aber trotzdem mit einer Kopie der VM den Test machen, ob des einen Unterschied macht, ob da "nur" 23 oder 40 oder 60 GB frei sind..
Ich habe mal 100GB für C dazugegeben. Funktioniert trotzdem nicht.Ich würde aber trotzdem mit einer Kopie der VM den Test machen, ob des einen Unterschied macht, ob da "nur" 23 oder 40 oder 60 GB frei sind..
Ich habe aber auch keine Lust das zu suchen...
