Welcome to the forum @sthag
Thanks for the good detail. The main additional diagnostic that I can think of if it happens again is logging.
About → Show log → Live → Retry is handy. If need be, you can increase it to Profiling to look for action.
Long-term capture (if needed) is probably easier with log-file=<path> log-file-log-level (runs unattended).
It sounds almost like it’s having trouble writing to that USB drive, although I don’t know why that would be.
Stop now doesn’t stop immediately explains how that option doesn’t exist. It has to finish the file uploads.
There are typically two. The first is the Program Files base install. It just starts the latest installed update.
This would be the one doing the actual work, but that’s more work than I would expect it to be doing. If it’s somehow doing SQL, you would see that in the profiling log level. If it’s doing I/O, you could look at it with Sysinternals Process Monitor for details (which might show .sqlite* database file, or destination work).
I think that message just makes you password-protect the UI. The launch-at-login Duplicatis are per-user.
Duplicati.WindowsService.exe can make a start-at-boot Duplicati for all users if you like the arrangement.
There are some caveats, e.g. Windows version upgrades wipe out the SYSTEM profile, so go elsewhere.
I’m not seeing anything like that.
I’m not sure what you’d like, but I made some comments earlier. Ask questions if you want some more.
Non-regular probably requires the log file route. You don’t want to be watching a live log of every backup.
If it finishes, check your log and see if you did a compact that actually made some new files. It can take awhile for large backups compared to the time it takes to do the backup. It’s repackaging the older files.
This would not occur on the first backup mentioned in original post. It takes awhile to get wasted space.
Alternatively, you can run with no-auto-compact for awhile to see if it avoids the after-backup slowdown.