Bei der täglichen Sicherung eines virtuellen Computers unter Hyper-V mit Bvckup 2 wurde die virtuelle Datenfestplatte immer vollständig und nicht wie vorgesehen das Delta (die Änderungen innerhalb der Datei) kopiert.

Im Log stand dazu folgendes:

2018.06.07 03:30:25.489 (UTC+1) 2 3 Destination file timestamps have changed since the last run
2018.06.07 03:30:25.489 (UTC+1) 3 4 Was: created 2016.04.20 10:34:58.204, modified 2018.06.06 03:30:21.933
2018.06.07 03:30:25.489 (UTC+1) 3 4 Now: created 2016.04.20 10:34:58.204, modified 2018.06.06 05:43:28.891
2018.06.07 03:30:25.489 (UTC+1) 2 3 Resetting delta state...
2018.06.07 05:38:32.315 (UTC+1) 3 3 Completed in 2 h 8 min, copied in full
2018.06.07 05:38:32.315 (UTC+1) 3 4 118.12 MBps | 271.70 reading, 338.85 hashing, 171.31 writing

Ein Blick in den Explorer zeigte ebenfalls, das der Zeitstempel sich geändert hatte. Unklar war bzw. ist, warum dies so ist, denn mit der System-VHDX des gleichen virtuellen Computers geschah dies nicht.

Auf Nachfrage bei Pipemetrics, den Machern von Bvckup 2, kam der Hinweis, das wohl irgendein Prozess auf die Datei zugreift und sich folglich der Zeitstempel ändert. Man könne dies mit dem Process Monitor bei entsprechend konfigurierten Filtern eingrenzen.

Im Process Monitor wurden daraufhin zwei Filter gesetzt:

Include - Path - contains - <Pfad und Dateiname zur gesicherten VHDX>
Exclude - Process Name - contains - Bvckup2.exe

Ersteres um nur die Zugriffe auf die gesicherte VHDX anzuzeigen und letzteres um die gewünschten Zugriffe durch Bvckup 2 auszufiltern. So sollten nur die unerwünschten Zugriffe und ggf. Aufrufe durch den Windows Explorer übrig bleiben.

Zwischenzeitlich viel beim Durchschauen des Hyper-V auf, das bei einem ausgeschaltetem virtuellen Computer die betreffende gesicherte Daten-VHDX verbunden war. Hintergrund dieses Umstands war ein Test mit den gesicherten Daten. Allerdings war dieser bereits mehrere Tage her, inzwischen hätte nach einen erneuten vollem Kopieren nur noch das Delta abgeglichen werden sollen.

Jedenfalls wurde die gesicherte VHDX von diesem ausgeschaltetem virtuellen Computer getrennt. Anschließend wurden mittlerweile mehrere Durchgänge mit Bvckup 2 durchlaufen, ohne das es nochmal zu einer ungewollten Veränderung des Zeitstempels bzw. ungewollten Zugriffs gekommen ist.

Soweit liegt der Gedanke nahe, das irgendwie über VSS und Hyper-V dieser Zugriff stattgefunden hat. Nachvollziehen konnten wir das leider nicht (mehr). Auf unserem Testserver mit gleicher Hyper-V Version konnten wir dieses ebenfalls nicht reproduzieren. Möglicherweise hing irgendwas im Hintergrund, was man so nicht ohne weiteres feststellen oder sehen kann.

Plan B (der Vollständigkeit halber)

Pipemetrics teilte zudem mit, das man, was die Zeitstempel betrifft, eine gewisse “Unschärfe” einstellen kann:

If you are *confident* that the backup copy stays the same between the runs, you *can* suppress the delta state reset. This is done as follows:

• 1. Right-click on the job in question, select “Open Folder” > “Configuration and Logging”
• 2. Use Notepad to create there override.ini file and put the following line in it:
  conf.copying.ultra.delta.weak_dst_times 1
• 3. Save the ini, exit Notepad, restart the program. If it’s running in service mode, restart the bvckup2 service.

Update 11.06.2018

In Verbindung mit einer AVM FRITZ!BOX als Ziel (NAS) kann dieser Fehler, gemeint sind diesmal Schwierigkeiten mit den Zeitstempeln, ebenso auftreten. Laut Alex Pankratov von Pipemetrics verhält es sich so:

“When file copying is complete, the program then copies the timestamps from the source file to the backup. Once copied it then queries timestamps of the backup copy. All of this – data copying, timestamp copying and querying – is done using the same instance of file handle, i.e. without re-opening the file for each stage. Normally, if there’s any timestamp truncation or rounding happening, returned timestamps will reflect that. However in your case it doesn’t – your device returns the high-precision timestamp that it saw with the “set” request rather than a truncated version of it that it ends up writing on disk. This is a bug, it shouldn’t be doing that.”

Kurzum: Es ist ein Bug im FRITZ!OS bzw. dem dort verwendet (recht alten) Samba-Server. Im Moment hoffe ich darauf, das mit FRITZ!OS 7 sich dieses und die alten SMB1-Version von selbst “erledigen”. Nebenbei bemerkt: Wenn möglich sollte man auf ein richtiges NAS z.B. von Synology oder Qnap oder einen entsprechenden Server sichern.

Vorläufig bleibt der oben unter “Plan B” genannte workaround als erste Abhilfe und die Ankündigung von Pipemetrics, das mit der nächsten Version von Bvckup 2 auf Zeitstempel-Feinheiten geachtet wird.

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.