Backup either stuck or incredibly slow after resume from hibernate

[ts678]

@Billy_Te

You mean restored files are not overwritten but skipped if they’re the same exact file?

Yes. You can follow the links I posted for more details, for example:

Prepare the list of files to restore the list of blocks each file needs.

There’s no point in taking potentially large efforts to overwrite files with exact same data.

@Billy_Te

Yes, but shouldn’t the backup log display which one I selected so I can double check?

Maybe, but there are almost no places now where an operation does such double check.
Deleting all files on the destination is one of them, as nothing else is quite as destructive.

@Billy_Te

The whole point is that I want to make sure I’m selecting the right one.

Read and click carefully, sanity-check your results, for example look over file timestamps.

Although it’s not a beforehand check, job log Complete log can show what you did, like:

  "Messages": [
    "2025-09-08 17:49:05 -04 - [Information-Duplicati.Library.Main.Controller-StartingOperation]: The operation Restore has started",
    "2025-09-08 17:49:05 -04 - [Information-Duplicati.Library.Main.BasicResults-BackendEvent]: Backend event: List - Started:  ()",
    "2025-09-08 17:49:05 -04 - [Information-Duplicati.Library.Main.BasicResults-BackendEvent]: Backend event: List - Completed:  (9 bytes)",
    "2025-09-08 17:49:05 -04 - [Information-Duplicati.Library.Main.BasicResults-BackendEvent]: Backend event: QuotaInfo - Started:  ()",
    "2025-09-08 17:49:06 -04 - [Information-Duplicati.Library.Main.Database.LocalRestoreDatabase-SearchingBackup]: Searching backup 1 (9/7/2025 11:38:01 AM) ...",

@Billy_Te

with errors

Can’t comment without some details. Whenever you get warnings or errors, please note.
Your job log might also preserve them, or the server log at About → Show log → Stored.

@Billy_Te

I’m trying to figure out ways to verify that the files restored are actually the full backup.

Duplicati verifies this at the end, may give warnings or errors, and they might give a clue.

If you restore to a specific empty folder initially, you can also count the files with Explorer.
You could try matching that against the RestoredFiles count in the job Complete log.

You can browse to see if everything you think should be there is there.

Beyond this, there is much data in files on Destination, and job database, if you have one.

How did you do the restore? Did you do “Direct restore from backup files”? If so, database notes that it is partial temporary. If you want a permanent database, try to recreate the job.

Recreate Backup Task describes how, if you didn’t have job Export, or did you Import one?

Regardless, once you get at least a slightly sketched in job, do a Database screen Repair.

GUI Commandline list without any commandline arguments will show version files, like:

Listing filesets: 
 0	: 9/7/2025 5:14:18 PM (3 files, 41 bytes) 
 1	: 9/7/2025 7:38:01 AM (3 files, 41 bytes) 
 2	: 9/6/2025 3:21:43 PM (3 files, 41 bytes) 
 3	: 9/3/2025 8:35:59 AM (3 files, 41 bytes) 
 4	: 9/3/2025 8:32:39 AM (2 files, 2 bytes) 
 Return code: 0 

You can get all the paths by using a wildcard such as a *, with version= for wanted one.
You can do the same thing using an OS command line if you want to capture paths in file.

If you’re very ambitious and technical, the dlist file even has the SHA-256 sums of files which you could verify. This is what Duplicati does. The older flow of doing this looks like:

@carljohnsen

Verify the restored files; for each target file:

1. Read the target file.
2. Compute the hash of the target file.
3. Check that the hash and size matches to ensure that the file has been restored to the state recorded during the backup.

but if you see warnings and errors, it’s important to look at them to see what went wrong.