I need a bit of help. I have a PC running urBackup Server which “went mad” on me and failed. Two hard drives in this computer. So I pulled the drives, installed in a new Win10 Pro PC and reinstalled Windows to the C Drive
urBackup lives on the D drive. I reinstalled it and then set it running again, pointed at the old folders. I was hoping it was going to pick up the same old clients and old data - but it has started up empty
When I go to the GUI it says “This server has discovered clients which are currently not configured to use this server. See here for details on how this can happen.”
I am confused what to do next. How can I get this up and running and acknowledging the old clients and continuing their backups?
Is there a way to add the old clients and get them to pickup their old backups and continue?
Thanks
Okay - so I have found if I click “Show all Clients”, they are all listed. But each one has a date of NaN/NaN/NaN NaN:NaN and it says “Server Rejected”.
How to I get it to trust this server?
I tried on one client to delete server_idents.txt and it now is backing up, but not linking to the old backups. Which leaves an eve more confused state if that data is left unlinked.
Stop the UrBackup service, restore the server database from the backup storage to the new server… & restart the service I think that ought to do the trick.
1 Like
AHAHAH!! You nudged me into a thought. Thank you for the missing link. I kept looking a the D drive too much where the data is stored, and not the C drive where the app was running from.
For others. My URBACKUP is installed on C:\Program Files\UrBackupServer\
I STOPPED the service
Dived into a Backup of my server’s C drive
Grabbed the C:\Program Files\UrBackupServer\urbackup\ folder from the backup and replaced the one from the new install.
Restarted the service.
ALL is now happy and great again. Everything reconnected. All the old clients are happy. All the old backups are linked. All old settings back into place. And I’ll find out this evening if all those backups pickup correctly.
I forgot those vital files all live in that folder on C: and must be kept up to date on a separate backup.
Thanks again.
1 Like
You might want to now run remove_unknown.bat (in the UrBackupServer folder) from an admin command prompt ( just CD to C:\Program Files\UrBackupServer), to remove any stray files that arrived after that last backup from the backup storage, that is any backups that happened between that server backup and the restore. That’s not urge"nt, but “Good Housekeeping”, when convenient, it takes a while to run & stops the server doing backups while it runs.
1 Like
Excellent. That makes sense. I was wondering about that backup I managed to get to run last night as it now doesn’t show. I’ll run this now before the main backups kick in this evening.
Thanks again for your help.
Edit: now it is running it is also clearing up a number of old broken and incomplete files in that folder. Very useful.
That is just what I was going to suggest that you do. Glad you figured it out.
The config for the server is stored on the systemdrive of Windows, even if the backups are kept on a different drive.
-ASB
What I do find a little weird is the settings are in the Program Files folder. They should be in the %AppData% folder on a Windows PC. Kinda lucky I took a full disc snapshot as usually I’d only backup the settings folders.
Worryingly I am currently stuck in the housekeeping. I started the remove_unknown.bat script two days ago and it is still going. Finding all kinds of symlink errors in old backups.
Can I interrupt this? At least so I can get my backups run before going back to the cleaning?
Edit: This is stuck in a weird way. For last 12 hours I am getting the same error
2022-02-10 11:54:11: ERROR: Error getting symlink path in pool of "D:\STUFF\+URB+\HAL-PC\.directory_pool\g4\g4md6JwoJ116119677991776162609" (contains)
And before that it got stuck on a similar message. This is what I want to interrupt so I can get backups completed tonight. Thanks
I’d interrupt it CTRL+C
Restart the service
NET START UrBackupWinServer
Then I’d use an administrative command prompt:
CHKDSK /scan /perf D:
/scan won’t force the volume offline, though you might have to run with /spotfix later if it finds things to repair, which will but not for anything like the time the old /f switch does.
If you want to speed up remove_unknown.bat then copy the file & rename your copy fast_remove_unknown.bat edit your copy & change --loglevel debug to --loglevel error
You’ll see a lot less information but it speeds it up enormously in my experience not having to produce & display all that text.
But if you’re getting symlink errors & it’s getting stuck, I’d for sure run CHKDSK over it.
1 Like
Thanks @Bearded_Blunder. I stopped the cleanup and have now got the backups completed. Which is reassuring. All reattached and happy again.
Last night I started the CHKDSK using your arguments - but as the backup was also running it headed up to 199hours to complete. Have had to kill that for now. Looking in older backup logs I can see other mentions of issues with backups on the older PC. I think the old PC was hammering disc errors and I now have a weekend of cleanups to do.
Crystaldiskinfo is showing the SMART data as “Good” on that drive. It’s been running for five years now (44444 hours) so I’ll have this pencilled in for replacement later in the year I think. Need to argue on the budget there. Will see how the cleanups go.
Well if you run chkdsk without /perf it’ll take even longer, though it’ll run at lower priority & not interfere with other activities as much. At which point it scarcely matters if it takes a week.
1 Like
The CHKDSK took 1.30days for the 4TB 5400rpm disk. During stage one it was estimating 700hrs to complete, but I took the punt that would be wrong and left it to chug. Being old skool I did a full /f /r and took it fully offline. I didn’t want it “low priority” - I wanted it over quickest possible during the weekend window I had. Once it got to the later stages the estimate dropped back towards sanity levels. NO errors found.
There are LOADS of tiny files in this backup as we have multiple copies of Thunderbird mailboxes. That makes any kind of check estimates go wild.
With the tweak to the loglevel, fast_remove_unknown.bat took another day and a bit to run through. Still threw up some of the same symlink errors, but not as many this time.
I have certainly gained disk space at the end of this, and urbackup looks happy now.
The main message to anyone else reading this - patience. Just walk away and leave the machine to chug through these kinds of checks. That 5400rpm drive is a NAS drive so not designed for speedy reads. And chkdsk estimates are rubbish. 
1 Like