DEBUG Share "x" on "Client" is still in use (meta-data transfer). Waiting before removing snapshot

client
1

So we’ve been having a number of issues with file backups on this one particular client during the past couple of weeks. One due to Bitdefender locking up a suspicious file in a snapshot, the next one gave this early error:

Error while getting files in folder "\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy5\Profiler\Redacted.V6\AppData\Roaming\Microsoft\Teams\IndexedDB\https_teams.microsoft.com_0.indexeddb.blob\4\01". Windows errorcode: 87. Access to root directory is gone too. Shadow copy was probably deleted while indexing.

This seems to have gone away after a reboot.

Now though, we are getting this error that never clears:

01/17/24 11:21 DEBUG Share "x" on "Server" is still in use (meta-data transfer). Waiting before removing snapshot...

x in our case is the D-drive, which all files in the backup are originating from.

This has waited the initial ~8 hour holdoff time, and currently, the ETA is 292487235 years 4 months 2 weeks 1 day 8 hours 9 minutes :smiley:

Client is running Windows server 2016, a domain controller. Procmon on UrBackupClient only shows tcp traffic at regular intervals to the server, I did not manage to log when the holdoff period restarted.

Any tip on how to resolve this or troubleshoot further?

Best regards
Alexander

2

If that is not possible (or running it in debug log mode), please create a memory dump of the service process and send that. Maybe that tells something.

3

Thanks!
Both the client and the server are running in debug mode. I’ve got the debug files as well as memory dumps. They are too large to upload, so I’ll send a link to the bugreports-mail and reference this thread.

I have the feeling that the resuming of backups might not always be a good thing? Is there an official way to completely cancel a failed backup that tries to resume again and again, to make it start from scratch instead of resuming? (Or is my assumption baseless?)

Best regards
Alexander

4

For reference for anyone else reading, I sent logs via mail and got answers to what file was locked, but I was not able to find out what process was locking before the backup job timed out and the server rebooted.

Uroni, after starting the backup again manually, we see this pattern repeating, it dies a few hours in and tries to restart again after a while:

2024-01-23 03:15 INFO Starting scheduled incremental file backup…
2024-01-23 03:15 DEBUG Radio1: Connecting for filelist…
2024-01-23 03:15 DEBUG Radio1: Waiting for filelist
2024-01-23 03:15 DEBUG Radio1: Connecting for filelist (async)…
2024-01-23 03:18 INFO Component caption= name=RADIO1\LOCALDB#SH854732
2024-01-23 03:18 INFO Component caption= name=RADIO1\LOCALDB#SH854732
2024-01-23 03:18 INFO Component caption= name=RADIO1\LOCALDB#SH854732
2024-01-23 03:18 INFO Component caption= name=RADIO1\LOCALDB#SH854732
2024-01-23 03:18 INFO Scanning for changed hard links on volume of c:.…
2024-01-23 03:18 WARNING Restarting shadow copy of D:\ because it was started by this server
2024-01-23 03:18 INFO Scanning for changed hard links on volume of D:.…
2024-01-23 03:18 INFO Indexing of D done. 9 filesystem lookups 208910 db lookups and 8 db updates
2024-01-23 03:18 DEBUG Radio1: Doing backup with hashed transfer…
2024-01-23 03:18 INFO Radio1: Loading file list…
2024-01-23 03:18 INFO Radio1: Calculating file tree differences…
2024-01-23 03:19 INFO Waiting for metadata download stream to finish
2024-01-23 05:00 ERROR Error getting file metadata. Errorcode: TIMEOUT (2)
2024-01-23 05:00 ERROR Error starting file metadata download thread
2024-01-23 05:00 ERROR Backup had an early error. Deleting partial backup.

Best regards
Alexander