For the past few days, my W11 client has been stuck at the indexing stage for incremental file backups.
The server log that’s viewable from the online GUI:
29/11/22 12:10 DEBUG Reflink copying is enabled
29/11/22 12:10 DEBUG Reflink copying is enabled
29/11/22 12:10 INFO Starting unscheduled incremental file backup...
29/11/22 12:10 DEBUG Fiz: Connecting for filelist...
29/11/22 12:10 DEBUG Fiz: Waiting for filelist
29/11/22 12:10 DEBUG Fiz: Connecting for filelist (async)...
The client debug.log file. This is from a fresh attempt at a backup, hence its shortness. The last few lines repeat forever in the older backups debug.log (992.3 KB)
The ETA for the backup starts at 2 hours and counts down to 0, but the indexing continues on forever.
What I’ve tried:
Deleting the last few incremental file backups (but I cannot delete the most recent backup as there is no delete button in the GUI)
Deleting the fileindex on the server + allowing it to rebuild after a restart
Other key info:
Server is in the official docker container on a linux host. Version 2.4.15
It’s not clear to me if that the backup gets stuck at the indexing stage, is the issue on the server or the client? I’d naively assume the client but I guess the server may be failing to setup something like the BTRFS snapshot?
I’m having the same issue on a Linux server. On the Linux client. I can run the service in the foreground and I can see it is “hashing” a very large NFS volume. I’ve specifically excluded that mount point in the config, but still it hashes. Is it possible for you on Windows to run the service in the foreground from the command line? You will see what’s going on.
It doesn’t look like urbackup is run as a windows service, just two exes running in the task manager (the client and the backend). Unfortunately running the backend from the command line doesn’t show much (it just prints out the runtime flags) and the client.exe just reopens the tray icon…
I figure that the printout in the log file would show everything already but maybe that’s wrong…
Unfortunately this is still happening.
Today I deleted all of the backups, deleted the client from the server, reinstalled the urbackup client on the windows machine and have set a backup going. The indexing has been going on for a couple of hours now.
One thing that is new the Microsoft Window Search Indexer process is using some small-ish amount of my CPU (typically about 5%). I don’t -think- this was happening before. The task manager reports 0% disk usage for Microsoft’s indexer though…
ah that’s really painful. I’ve not got a full file backup running.
I’d setup the prescripts to run Windows PowerToys awake as my PC had been sleeping before completing backups previously.
I’m surprised its hanging on running that script though, as I’d setup the script to immediately return to the user. Here’s the entire contents of the file:
…actually, running this script on the windows command line, it opens up a new command line window (but returns access to the old one). Is that possibly causing the problem?
Are there other ways to disable sleeping when the backups are running?
That is actually atypical. Normally Windows is good w.r.t. backward compatibility in the win32 API area. Something really went wrong with Windows 11 at Microsoft it seems.
@uroni thanks a -lot- for taking a look at what was wrong.
I’m glad something (W11 sleep issue) useful could be indirectly learnt from my inability to write decent BAT scripts.
Just addressing the “data” vs “italicized data” thing, I’m betting that they typed asterisks before and after /data/, resulting in it being italicized by the markdown interpretation. So what they meant was that they had to specify */data/*, not just /data/.