Drive Snapshot: Corrupted hash file nach Windows Updates

Reproduzierbar erleben wir monatlich bei zum Glück nur einem Kunden bislang, das die Datensicherung mit Drive Snapshot am Tag des Einspielens der jeweils aktuellen Windows Updates scheitert.

Ein entsprechendes Protokoll sieht z.B. so aus:

21:00:05 Start of Snapshot 1.48.18825 [Jul 28 2020] at 13.01.2021
21:00:05 Running on Windows Major Version 10, Minor version 0 Standard 64-bit Version 1809 (17763)
21:00:05 Memory Info: Total: 7963Mb, Free: 5786Mb, Pagefile total: 9243Mb, Pagefile free: 6822Mb
21:00:05 Command line: snapshot64.exe C:+D: V:\\Diff-1-Wednesday-$disk.sna -hV:\\Full-1-Monday-$disk.hsh -RW --AllWriters -L0 --LogFile:C:\Backup\Logs\Current.log --FullIfHashIsMissing --exclude:"\Roentgen\Backup,\Backup\Clients,\Backup\Server"
21:00:33 clearing Recycle Bin on drive C: - 0 Files, 0 Bytes
21:00:33 clearing Recycle Bin on drive D: - 0 Files, 0 Bytes
21:00:33 Disks in backup:
21:00:33 C: -> V:\\Diff-1-Wednesday-C.sna
21:00:33 Scanning excluded files: C:\Roentgen\Backup 
21:00:33 Scanning excluded files: C:\Backup\Clients 
21:00:33 Scanning excluded files: C:\Backup\Server 
21:00:33 D: -> V:\\Diff-1-Wednesday-D.sna
21:00:33 Scanning excluded files: D:\Roentgen\Backup\* 
21:02:04 Scanning excluded files: D:\Backup\Clients\* 
21:02:04 Scanning excluded files: D:\Backup\Server\* 
21:02:04 Preparing for backup
21:02:21 Including all available VSS writers
21:02:21 Starting Snapshot creation
21:02:21 Creating shadow set {3b414e7c-a5a2-4dc2-8386-5a95d5e5c850}
21:03:14 Register shadow copy {a8d9f1a5-2e34-431d-9269-dd515a798350}
21:03:14 Register shadow copy {9ee77e1a-eb85-4c52-8eb2-762cd6fc4e90}
21:03:14 The Volume Snapshot was created successfully
21:03:17 Start differential VSS backup of C: -> V:\\Diff-1-Wednesday-C.sna
21:03:17 Scanning excluded files: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy215\Roentgen\Backup 
21:03:17 Scanning excluded files: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy215\Backup\Clients 
21:03:17 Scanning excluded files: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy215\Backup\Server 
21:03:17 0 MB saved by skipping 0 files
21:03:17 free space info: total 227.799MB, 162.567MB free, 41.607MB must be saved
21:03:17 C: -> V:\\Diff-1-Wednesday-C.sna
21:06:29 C: 65.232MB in use - stored in 2.677MB - 3:13 minutes
21:06:29 Success
21:06:35 ***********************************************************
21:06:35 Snapshot error HashFileUtils, line 408
21:06:35 Corrupted hash file(V:\\Full-1-Monday-D.hsh), checksum failure.
Please generate a new hash file from the original image.
21:06:35 ***********************************************************
21:06:35 Error occurred - exitcode 21
21:06:35 End of Snapshot 1.48 [Jul 28 2020] at 13.01.2021

Das Ganze geschieht nur wenn das Ziel ein Netzlaufwerk bzw. eine Freigabe ist und das System, in diesem Fall ein Windows Server 2019 Standard, nach der Installation der Updates noch nicht neu gestartet wurde. Das Ziel ist übrigens ebenfalls ein Windows Server 2019 Standard.

Als ich diesen Fehler das erste Mal gesehen hatte, dachte ich wirklich, das Hashfile sei defekt, obwohl die Tests nicht negatives zeigten. Nach Abklärung mit Tom Ehlert Software, dem Macher von Drive Snapshot, ist das Ganze wohl auf irgendeine Ungereimtheit bei der Netzwerkübertragung zurückzuführen.

Letztlich genügt entweder ein Neustart nach der Installation der Updates, in diesem Fall erfolgt er allerdings erst Nachts um 02:00 Uhr, die Datensicherung läuft allerdings bereits um 21:00 Uhr wie man im Protokoll sieht, wenn man so möchte schlechtes Timing in diesem Szenario oder eben den Zeitplan ändern. Die dritte Option besteht darin, einmal im Monat diesen Fehler zu ignorieren.

Andy

Verheiratet, Vater von zwei Kindern, eines an der Hand, eines im Herzen. Schon immer Technik-Freund, seit 2001 in der IT tätig und seit über 10 Jahren begeisterter Blogger. Mit meiner Firma IT-Service Weber kümmern wir uns um alle IT-Belange von gewerblichen Kunden und unterstützen zusätzlich sowohl Partner als auch Kollegen.