I’m sorry, I don’t know how to do what you asked.
I have replaced the drive with an internal one. Seems to have bypassed the problem.
Great! So, can we chalk this up to maybe bad blocks on an HDD or SSD? 
Absolutely not, the HDD was fine.
I believe it has to do with being connected through USB.
Ahhhh!! Maybe I missed some posts along the way. Sorry.
No problem, it’s a long thread. Thanks for trying to help.
@MrBates I’m running into this exact same issue on one of my clients. Have we come to some sort of conclusion or work-around or more research as of yet?
I was not having this problem before.
Unfortunately not. I have resolved to replacing the drive from external to internal in order to bypass the problem.
Is your client also using an external USB drive?
They are, yes. When you say.
Do you mean …
1). It no longer takes a long time because of the speed with which the data is read (front-to-back) each time
or
2). It no longer takes a long period of time because it only reads the data in its entirety once and reads server “caches” after that.
or
3). A different answer.
Further investigating:
After some consideration on this topic, I wanted to dig deeper into a possible “fix” or workaround of some sort. I don’t like the idea of having to drop all my current backups and re-do everything to fix things. I am in somewhat of an ideal situation here as well as I have the following clients (customers) I am responsible for.
1). Client with Windows Server: Doing backups on internal drives
2). Client with Windows Server: Doing backups on USB external drive
BOTH of these machines needed fresh clients installed because of a separate issue.
They connected (initial connection) without issue and were not identified as a “new client”.
Windows Server #1 continued doing INC file backups WITHOUT issue.
Windows Server #2 continued doing INC file backups WITH issues.
I want to make it clear that BOTH situations BEFORE the client software replacement were doing INC file backups WITHOUT issue EVEN though we have one from internal HDDs and the other from a USB interface.
Whatever happened in the client replacement (re-installation process) CAUSED the anomaly to become evident – that is async taking copious amounts of time.
Furthermore: I have decided that instead of trashing the whole client profile, I am going to run a FULL file backup and follow that up with an incremental file backup to see if this will clear the length of time issue. If it does, that would be preferable because I am also doing image backups for the server in question. This would be much more simple than trying to figure out what is wrong for the time being and you can still retain all of your previous backup sets and history along with it.
Backup is running now, will report back on this when its done.
I hope this makes some semblance of sense.
Here’s a screen grab of the disk IO on indexing.
I mean that I no longer get this error:
ERROR: Unknown error for Volume ‘e:’ - watchDir ec: 87
And that journaling now works:
Indexing of “E” done. 1 filesystem lookups 8615 db lookups and 0 db updates
See how only 1 filesystem lookup was done, whereas previously it would show:
Indexing of “E” done. 3265 filesystem lookups 0 db lookups and 0 db updates
(the number of lookups is now higher because I added more files to the backup, but you get the point).
Same here. I don’t know which change triggered it (I listed the changes here), but it used to work correctly on the previous setup, and then suddenly stopped.
It didn’t for me.
A few of the desktops our end have live drive monitors, during that time it looks like nothing is happening its actually reading the disk ALOT, on a RAID system pulling over 100Mb/s, we use Windows 10 godets to check this not Task Manager, so the chart data is pulled from WMI
Here’s an interesting development. After I did the full file backup and followed that up with an incremental file backup, guess what happened, it only took 2 minutes. 
So, whatever combo of settings I have is giving me quick incremental backups as it did before.
Here’s the real test: I brought down the server after this and I am going to bring it back up again, run another incremental file backup and see how long it takes. Isn’t this only supposed to be a feature on CBT?
We’ll see if restarts of both client and server modify this behavior.
Update: Server back online. Ran ANOTHER incremental file backup on the server with the external USB drive, still only 2 minute duration on backup. Something else is going on here.
I will now run the cleanup script (cleanup.bat) as admin and see if, once the server comes back online, whether this will effect anything. Just trying to push all the buttons, see if we can reproduce this behavior. So far, running the full backup once again has fixed my particular issue.
Running cleanup.bat did not affect the result, incremental file backup still ran successfully in only 2 minutes. For documentation purposes, I am running UrBackup on a Windows machine and all my clients are also Windows.
Not sure. The server I’m testing with needs to stay up, so I would have to test that with one of my local units – which I will do.
The question would be, does this behavior (doing a complete drive or file indexing) PERSIST after the first backup post-restart or does it go back to normal operation. I will test with a local machine here sometime today and report back.
This is starting to make sense to me now because all of the machines that stayed online did not have problems with overly lengthy backups – had to test for myself though and come to the same conclusion.
I’m guessing something changes, a counter or something, on the client side that invalidates the behavior we’re used to. Maybe this is the magic in the CBT versions? or does this happen CBT or NOT???
@MrBates More interesting behavior. Question: On any of the machines you had this issue with, did you EVER delete any of the incremental backups for those machines? Here’s what I jut ran into on another machine.
I went to do an incremental image backup, It showed x of y GB (y being the total capacity of the hard drive) instead of the total size of used blocks as it does when it works right.
Just before this, I had deleted some incremental backups for that client. AFTER deleting all images for that client and starting a full backup, it then went back to my expected figures on each of those x and y values. I’m sorry if this doesn’t make much sense right now. In the middle of testing different configurations to see what will come up to the surface.