Backups failing in various stages

AlmostRet · April 23, 2026, 11:33pm

I have started having issues with backup failures at various stages recently - perhaps after a Windows update (Windows 11 Pro, 25H2, 26200.8246)?. I have several more machines and only one other one has the same issue as the machine I’m trying things out on - the rest seem to be fine. Duplicati is Duplicati 2.3.0.0 - 2.3.0.0_stable_2026-04-14. Backing up to a shared drive on another machine, with 550 G free.

Initially was having issues with backups not completing successfully - would get to a certain file, usually near the end of the backup set and just stop - would show X files Y bytes to go, green progress bar, file name but no action on the network. Cannot stop the job - that never finishes.

Currently, I’ve created a new job to a different backup directory. Small backup completed (~1 gig), but next trial run with more directories added is stuck at ‘Verifying backend data…’.

Verifying the backend data for a 1 gig backup shouldn’t take too long, one would think - started at 3:27 PM; it is now 4:30 PM, so over an hour in that phase.

Verbose Log data from the server shows:

Apr 23, 2026 3:27 PM: Backend event: QuotaInfo - Started: ()
Apr 23, 2026 3:27 PM: Backend event: List - Completed: (13 bytes)
Apr 23, 2026 3:27 PM: Backend event: List - Started: ()
Apr 23, 2026 3:27 PM: The operation Backup has started

Using
–debug-output=true
–debug-retry-errors=true
–log-file-log-level=Verbose
–log-file=c:\temp\duplicati.debug.log
–log-http-requests=true

produces

2026-04-23 15:27:46 -07 - [Information-Duplicati.Library.Main.Controller-StartingOperation]: The operation Backup has started
2026-04-23 15:27:46 -07 - [Verbose-Duplicati.Library.SQLiteHelper.SQLiteLoader-CustomSQLiteOption]: Setting custom SQLite option ‘synchronous=NORMAL’.
2026-04-23 15:27:46 -07 - [Verbose-Duplicati.Library.SQLiteHelper.SQLiteLoader-CustomSQLiteOption]: Setting custom SQLite option ‘temp_store=MEMORY’.
2026-04-23 15:27:46 -07 - [Verbose-Duplicati.Library.SQLiteHelper.SQLiteLoader-CustomSQLiteOption]: Setting custom SQLite option ‘journal_mode=WAL’.
2026-04-23 15:27:46 -07 - [Verbose-Duplicati.Library.SQLiteHelper.SQLiteLoader-CustomSQLiteOption]: Setting custom SQLite option ‘cache_size=-65536’.
2026-04-23 15:27:46 -07 - [Verbose-Duplicati.Library.SQLiteHelper.SQLiteLoader-CustomSQLiteOption]: Setting custom SQLite option ‘mmap_size=67108864’.
2026-04-23 15:27:46 -07 - [Verbose-Duplicati.Library.SQLiteHelper.SQLiteLoader-CustomSQLiteOption]: Setting custom SQLite option ‘threads=8’.
2026-04-23 15:27:46 -07 - [Verbose-Duplicati.Library.SQLiteHelper.SQLiteLoader-CustomSQLiteOption]: Setting custom SQLite option ‘shared_cache=true’.
2026-04-23 15:27:46 -07 - [Information-Duplicati.Library.Main.BasicResults-BackendEvent]: Backend event: List - Started: ()
2026-04-23 15:27:46 -07 - [Information-Duplicati.Library.Main.BasicResults-BackendEvent]: Backend event: List - Completed: (13 bytes)
2026-04-23 15:27:46 -07 - [Information-Duplicati.Library.Main.BasicResults-BackendEvent]: Backend event: QuotaInfo - Started: ()

Wireshark shows no traffic between the machine being backed up and the machine with the shared drive.

Procmon shows TCP traffic, but appears to be local (SRC-PC is the machine I’m trying to back up). A few different patterns:



4:15:00.9307834 PM	TCP Send	kubernetes.docker.internal:8200 → kubernetes.docker.internal:64867	SUCCESS	Length: 160, startime: 341508, endtime: 341508, seqnum: 0, connid: 0	5328
4:15:02.1370278 PM	TCP TCPCopy	SRC-PC:8200 → SRC-PC:65407	SUCCESS	Length: 995, seqnum: 0, connid: 0	5328
4:15:02.1370349 PM	TCP Receive	SRC-PC:8200 → SRC-PC:65407	SUCCESS	Length: 995, seqnum: 0, connid: 0	5328

=============

4:15:02.1377921 PM	TCP Send	SRC-PC:8200 → SRC-PC:65407	SUCCESS	Length: 587, startime: 341628, endtime: 341628, seqnum: 0, connid: 0	5328
4:15:03.1501322 PM	TCP TCPCopy	kubernetes.docker.internal:8200 → kubernetes.docker.internal:50245	SUCCESS	Length: 954, seqnum: 0, connid: 0	5328
4:15:03.1501503 PM	TCP Receive	kubernetes.docker.internal:8200 → kubernetes.docker.internal:50245	SUCCESS	Length: 954, seqnum: 0, connid: 0	5328

=============

4:15:04.9901958 PM	TCP Send	kubernetes.docker.internal:8200 → kubernetes.docker.internal:50245	SUCCESS	Length: 160, startime: 341914, endtime: 341914, seqnum: 0, connid: 0	5328
4:15:05.9915495 PM	TCP TCPCopy	kubernetes.docker.internal:8200 → kubernetes.docker.internal:50245	SUCCESS	Length: 986, seqnum: 0, connid: 0	5328
4:15:05.9915564 PM	TCP Receive	kubernetes.docker.internal:8200 → kubernetes.docker.internal:50245	SUCCESS	Length: 986, seqnum: 0, connid: 0	5328

Procmon shows duplicati.server.exe accessing

Duplicati-server.sqlite-journal
Duplicati-server.sqlite
Duplicati-server.sqlite-wal

repeatedly with the same pattern, many times per second:

3:57:08.5111080 PM FASTIO_LOCK C:\Users\netbackup\AppData\Local\Duplicati\Duplicati-server.sqlite SUCCESS Exclusive: True, Offset: 1,073,741,824, Length: 1, Fail Immediately: True 5328
3:57:08.5111214 PM FASTIO_LOCK C:\Users\netbackup\AppData\Local\Duplicati\Duplicati-server.sqlite SUCCESS Exclusive: False, Offset: 1,073,741,826, Length: 510, Fail Immediately: True 5328
3:57:08.5111327 PM FASTIO_UNLOCK_SINGLE C:\Users\netbackup\AppData\Local\Duplicati\Duplicati-server.sqlite SUCCESS Offset: 1,073,741,824, Length: 1 5328
3:57:08.5112727 PM FASTIO_NETWORK_QUERY_OPEN C:\Users\netbackup\AppData\Local\Duplicati\Duplicati-server.sqlite-journal FAST IO DISALLOWED 5328
3:57:08.5114016 PM IRP_MJ_CREATE C:\Users\netbackup\AppData\Local\Duplicati\Duplicati-server.sqlite-journal NAME NOT FOUND Desired Access: Read Attributes, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a 5328
3:57:08.5114349 PM FASTIO_READ C:\Users\netbackup\AppData\Local\Duplicati\Duplicati-server.sqlite SUCCESS Offset: 24, Length: 16 5328
3:57:08.5115668 PM FASTIO_NETWORK_QUERY_OPEN C:\Users\netbackup\AppData\Local\Duplicati\Duplicati-server.sqlite-wal FAST IO DISALLOWED 5328
3:57:08.5117065 PM IRP_MJ_CREATE C:\Users\netbackup\AppData\Local\Duplicati\Duplicati-server.sqlite-wal NAME NOT FOUND Desired Access: Read Attributes, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a 5328
3:57:08.5117394 PM FASTIO_QUERY_INFORMATION C:\Users\netbackup\AppData\Local\Duplicati\Duplicati-server.sqlite SUCCESS Type: QueryStandardInformationFile, AllocationSize: 139,264, EndOfFile: 139,264, NumberOfLinks: 1, DeletePending: False, Directory: False 5328
3:57:08.5117643 PM FASTIO_UNLOCK_SINGLE C:\Users\netbackup\AppData\Local\Duplicati\Duplicati-server.sqlite SUCCESS Offset: 1,073,741,826, Length: 510 5328
3:57:09.1087896 PM FASTIO_LOCK C:\Users\netbackup\AppData\Local\Duplicati\Duplicati-server.sqlite SUCCESS Exclusive: True, Offset: 1,073,741,824, Length: 1, Fail Immediately: True 5328
3:57:09.1088063 PM FASTIO_LOCK C:\Users\netbackup\AppData\Local\Duplicati\Duplicati-server.sqlite SUCCESS Exclusive: False, Offset: 1,073,741,826, Length: 510, Fail Immediately: True 5328

Any suggestions as to how to proceed are welcome! If no ideas, next step might be to debug with Visual Studio?

Thanks!

TReKiE · April 24, 2026, 3:22am

I had this exact issue (same verbose log, and ‘Verifying backend data…’) after installing KB5083769 on a machine.

If you set/add the snapshot-policy option to Off in your backup and try again, does it work?

If so, I suspect you have the same problem I did. There is a current bug in KB5083769 that affects volume shadow copy snapshots on certain machines where the VSS service will suddenly pause when creating a snapshot. Duplicati will wait at “Verifying backend data…” as it waits for a reply.

On the UrBackup forum, you’ll see the exact same problem and some other references:

Uninstalling the update will fix it if this is the problem.

Sarah03 · April 24, 2026, 6:26am

That definitely sounds like a VSS (Volume Shadow Copy) hang. If you’re on Windows, it’s a good idea to check your Event Viewer under “Windows Logs > Application” to see if there are any specific VSS errors popping up when the backup hits that stage. In the meantime, you might want to try running a quick vssadmin list writers in an admin command prompt just to see if any of the writers are showing a “Failed” or “Timed out” status. Sometimes a simple restart of the Volume Shadow Copy service can clear things up if it’s just a temporary glitch.

AlmostRet · April 24, 2026, 5:31pm

Thanks, TReKiE and Sarah03.

Explicitly setting snapshot to ‘Off’ seems to have solved the issue. One had it ‘On’ and the rest did not have it set - which is equivalent to ‘Auto’. VSSAdmin list writers hangs on all machines at:

Waiting for responses.
These may be delayed if a shadow copy is being prepared.

Didn’t try uninstalling KB5083769 but will keep that in mind if the issue crops up again.

Thanks again for the quick responses.