Erstellt man häufig Schattenkopien oder diese sollen von großen Dateien erstellt werden, reicht mitunter der vordefinierte Speicherplatz nicht aus. Scheitert zudem die Datensicherung bei Verwendung von VSS kann es hilfreich sein, den Speicherplatz für die Schattenkopien zu erhöhen.

Am Beispiel von einem Windows Server 2022 mit einem MS SQL Server drauf kam es immer wieder die letzte Zeit zu verschiedenen Schwierigkeiten. Mal streikten die Schattenkopien mit der Ereignisprotokoll-Meldung (Ereignis-ID 36):

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

oder Drive Snapshot meldete entweder

23:01:38 Can't create VSS Snapshot, using internal backup engine.

oder (schlimmer) es versucht endlos (von einem verworfenen Snapshot) zu lesen:

23:25:13 D: -> V:\SRV01\Diff-2-Tuesday-D.sna
01:52:00 Read error at sector 1645319040 (Errorcode: 0x1b1)
01:52:00 Read error at sector 1645319041 (Errorcode: 0x15)
01:52:00 Read error at sector 1645319042 (Errorcode: 0x15)
01:52:00 Read error at sector 1645319043 (Errorcode: 0x15)
01:52:00 Read error at sector 1645319044 (Errorcode: 0x15)
...

Die Fehlercodes 0x1b1 und 0x15 bedeuten das die Schattenkopie nicht mehr zur Verfügung steht (Vielen Dank an Tom Ehlert Software für den Hinweis.)

Abhilfe kann schaffen, den für Schattenkopien verfügbaren Speicherplatz erhöhen. In diesem Fall:

C: 3479 MB -> 10240 MB (10 GB)
D: 8178 MB-> 20480 MB (20 GB)

Die Werte ändern kann man im Explorer nach einem Rechtsklick auf ein Laufwerk und “Schattenkopien konfigurieren…”:

In der Eingabeaufforderung geht dies mit

vssadmin resize shadowstorage /For=D: /On=D: /MaxSize=20480MB

Statt fester Werte kann man zudem “Unbegrenzt” (“/MaxSize=UNBOUNDED”) oder einen prozentualen Wert (“/MaxSize=20%”) angeben.

Quelle

Microsoft Learn – vssadmin resize shadowstorage

Update 05.12.2023

Wir hatten bei diesem Praxis-Fall noch ein paar weitere Überraschungen. So wurde das Limit von 20 GB plötzlich auf 102 GB erhöht. Woher das allerdings kam konnte nicht geklärt werden. Letztlich mussten wir dem diesem Beitrag zugrundeliegenden System (ist eine VM) dem Laufwerk D: nochmal 500 GB zusätzlich an Speicherplatz zuweisen und den Schattenkopie-Speicher auf 200 GB erhöhen. Seitdem funktioniert sowohl die Sicherung mit Drive Snapshot sowie die System-eigenen Schattenkopien.

Vermutlich hing es hier daran, das ein MS SQL Server mit zusammengefasst 685 GB Datenbankgröße vorhanden ist.

Update 22.05.2024

Bei einem anderen Kunden schlug das Client-Backup von einem Windows 11 Pro gerne mal mit folgender Meldung fehl:

...
Read error at sector 112935808 (Errorcode: 0x1b1)
12:37:33 Volume shadow copy is corrupted, maybe you run out of disk space in the VSS storage area. VSS Errorcode: 0x1
12:37:34 1 unreadable Sectors found! Please visit E:\Backup\<HOSTNAME>\BadSectors_C-<HOSTNAME>-05222024.txt
12:37:34 operation aborted
12:37:34 Backup of C: aborted
...

Ein Blick mit “vssadmin list shadowstorage” offenbarte diese etwas seltsame Ausgabe:

vssadmin 1.1 - Verwaltungsbefehlszeilenprogramm des Volumeschattenkopie-Dienstes
(C) Copyright 2001-2013 Microsoft Corp.

Schattenkopie-Speicherassoziation
Für Volume: (C:)\\?\Volume{8eadd518-9865-4cb4-b716-9993879974a2}\
Schattenkopie-Speichervolume: (\\?\Volume{21893146-6c80-46e1-b474-b3105e034c40}\)\\?\Volume{21893146-6c80-46e1-b474-b3105e034c40}\
Verwendeter Schattenkopie-Speicherbereich: 0 Bytes (0%)
Zugewiesener Schattenkopie-Speicherbereich: 0 Bytes (0%)
Max. Schattenkopie-Speicherbereich: 47,6 GB (3749%)

Kurios ist hier vor allem die prozentuale Angabe in der letzten Zeile. Ein Blick via “sysdm.cpl” zeigte das 10% des Speicherplatzes für den Schattenkopiespeicher eingestellt waren. Beim Versuch diesen Wert zu erhöhen erschien eine Meldung dass das angegebene Objekt nicht gefunden werden konnte.

Daraufhin wurde der Computerschutz für das Laufwerk C: einmal komplett deaktiviert sowie anschließend neu aktiviert und dabei gleich der Wert erhöht. Diesmal kam es zu keiner Fehlermeldung und eine erneute Ausgabe von “vssadmin list shadowstorage” sieht ebenfalls besser aus. Offensichtlich war irgendwie das Schattenkopie-Speichervolume beschädigt oder nicht mehr vorhanden.

Ob die Datensicherungen nun wieder richtig laufen muss sich noch zeigen.