Hello, since December one client won´t backup anymore.
After removing the client on the server, manually triggering cleanup on the server, removing and installing urbackup client on the client, error is still the same.
Server live Log:
17.01.21 22:32
INFO
Starting scheduled full file backup…
17.01.21 22:32
DEBUG
SRV-TERM-01: Connecting for filelist…
17.01.21 22:32
DEBUG
SRV-TERM-01: Waiting for filelist
17.01.21 22:32
DEBUG
SRV-TERM-01: Connecting for filelist (async)…
Client Windows Server 2016
Shot in the dark, but, is the client showing as connected using IPv4 or IPv6? (You can enable a column to show IP on the status page).
If so, does setting the client to prefer IPv4 addressing or disabling IPv6 on it & forcing IPv4 cure it?
Yes it shows the correct IPv4 adress of the client.
At this point all I can suggest is the process here
Debug logs as described are probably more helpful, without that sort of detail, we can only guess.
I just tried now to backup only one folder, when i start a complete databackup:
Server Live Log:
19.01.21 10:06
INFO
Starting unscheduled full file backup…
19.01.21 10:06
DEBUG
SRV-TERM-01: Connecting for filelist…
19.01.21 10:06
DEBUG
SRV-TERM-01: Waiting for filelist
19.01.21 10:06
DEBUG
SRV-TERM-01: Connecting for filelist (async)…
client Log file:
2021-01-19 10:06:21: rc=0 hasError=true state=0#ILIVPVru1LAH10jux7SLF #2PING RUNNING pc_done=&status_id=3&speed_bpms=0&total_bytes=-1&done_bytes=0&paused_fb=1#token=L2ZhOnDnidWU8iPjkr11#ILIVPVru1LAH10jux7SLF #3START FULL BACKUP group=0&running_jobs=1&sha=528&with_permissions=1&with_scripts=1&with_orig_path=1&with_sequence=1&with_proper_symlinks=1&status_id=3&async=1#token=L2ZhOnDnidWU8iPjkr11#ILIVPVru1LAH10jux7SLF #WAIT FOR INDEX async_id=6753e416d569c97a1630471021bffd96#token=L2ZhOnDnidWU8iPjkr11Windows_System32_LServer#ILIVPVru1LAH10jux7SLF #2PING RUNNING pc_done=&status_id=3&speed_bpms=0&total_bytes=-1&done_bytes=0&paused_fb=1#token=L2ZhOnDnidWU8iPjkr11 .cbt does not exist. Nothing to merge.#ILIVPVru1LAH10jux7SLF #2PING RUNNING pc_done=&status_id=3&speed_bpms=0&total_bytes=-1&done_bytes=0&paused_fb=1#token=L2ZhOnDnidWU8iPjkr11#ILIVPVru1LAH10jux7SLF #2PING RUNNING pc_done=&status_id=3&speed_bpms=0&total_bytes=-1&done_bytes=0&paused_fb=1#token=L2ZhOnDnidWU8iPjkr11#ILIVPVru1LAH10jux7SLF #2PING RUNNING pc_done=&status_id=3&speed_bpms=0&total_bytes=-1&done_bytes=0&paused_fb=1#token=L2ZhOnDnidWU8iPjkr11#ILIVPVru1LAH10jux7SLF #2PING RUNNING pc_done=&status_id=3&speed_bpms=0&total_bytes=-1&done_bytes=0&paused_fb=1#token=L2ZhOnDnidWU8iPjkr11#ILIVPVru1LAH10jux7SLF #2PING RUNNING pc_done=&status_id=3&speed_bpms=0&total_bytes=-1&done_bytes=0&paused_fb=1#token=L2ZhOnDnidWU8iPjkr11#ILIVPVru1LAH10jux7SLF #2PING RUNNING pc_done=&status_id=3&speed_bpms=0&total_bytes=-1&done_bytes=0&paused_fb=1#token=L2ZhOnDnidWU8iPjkr11
Server Logfile:
2021-01-19 10:06:21: msg=WAKEUP
Maybe the screenshots help:
uroni
January 19, 2021, 6:43pm
7
Do you have a thread that uses 100% CPU? Could be this fix:
committed 11:16PM - 18 Oct 20 UTC
This one isn’t in the non-CBT client (2.4.11). So if you use the non-CBT client with CBT you’ll get this issue. Solution: Use the CBT client or disable CBT.
No thread with 100% CPU
uroni
January 19, 2021, 7:59pm
9
Driver is definitely running:
I was dreaming tonight (I SWEAR!) that it was suddenly functioning. (Dreaming of Urbackup, you guys made it!)
I again tried to deinstall client completly, restart client, stop server, remove-unknown, cleanup on server, remove the folder on the nas from the client manually, again remove-unknown, cleanup, start server service, install client again, but same, still indexing since 2 days.
I will wait one day more until tomorrow with indexing and then kill the service and try your fix of CBT (I am not familliar with github and fixing it etc. need some time to read through your manuals)
FML! I DID IT! After 14 days tweaking around:
I think it had something to do with the indexing of my C: drive.
deleted Urbackup client, started “windows search” service (back to automatic), reindexed the whole drive. restarted the client.
installed urbackup client freshly, suddenly new behavior: client couldnt connect to urbackup srv.
RUN IT
Working again.
I wanna thank my mum, my dad and of course uroni, i had a dream, and i did it. Everything is possible.
You may not have to go through all the faff of uninstalling and reinstalling the client.
Sorry to revive this, but I thought I would interject some info here as I have a similar problem. However, I know what is causing it. Since this is one of the top results when googling this problem, it may be useful info for someone who comes across this.
You see, whenever it gets stuck indexing, it is because my computer has gone to sleep while UrBackup has been attempting to index. When the computer has woken up, it is then stuck in Index limbo.
The way I fix it is by simply restarting the UrBackupClientBackend service. The server will then give the following error:
"Constructing of filelist of "COMPUTER NAME" failed: ERR"
It will then clear the partial backup automatically. But you can initiate a new backup just fine from the client.
haertig
December 31, 2022, 8:01pm
13
John_Doe:
You see, whenever it gets stuck indexing, it is because my computer has gone to sleep while UrBackup has been attempting to index. When the computer has woken up, it is then stuck in Index limbo.
This makes sense given my personal experiences. I have seen stuck indexing on several occasions for one client. That client does not go to sleep, but it is running Windows and a family member has just kept installing a new version of Windows over old versions for a while. I try not to touch this computer if at all possible, it is a nightmare. I just backup it up with urbackup.
But this computer is basically a rolling Windows garbage truck hauling broken and outdated stuff around. It is exceptionally slow, and it has a propensity to take itself offline randomly (even though it is connected via ethernet, not WiFi).
So when I see a stuck indexing, I first try to kill the backup job from the server. If the garbage truck is offline, then killing the backup from the server end is not going to do anything on the client end. But I have been of the thought that maybe it would clean up things on the server. I reboot the garbage truck, and generally on the next backup it does not hang on indexing. It’s not worth my time to try an troubleshoot why urbackup is hanging here. I can’t exactly expect urbackup to chew it’s way out from the bottom of a garbage pile, that would be an unrealistic expectation.
But my experiences with this particular client hanging on indexing while also being prone to taking itself offline somewhat reinforce John_Doe’s observation about sleeping computers hanging on indexing. It may very well have something to do with a computer isolating itself from the network at a critical time. Seems plausible at least.
