UrBackup Server/Client/Restore 2.0.0 beta

Hi,

I keep getting these messages while doing backups over internet using v2beta server and client the backup just hangs and never completes sometimes at 100% or lower

16/01/27 20:56 DEBUG Loading “SCRIPT|urbackup/FILE_METADATA|bDP9Sijri7SLoddXhJUm|2276”. Loaded 14 MB at 56 Bit/s
16/01/27 20:58 DEBUG Loading “SCRIPT|urbackup/FILE_METADATA|bDP9Sijri7SLoddXhJUm|2276”. Loaded 14 MB at 56 Bit/s
16/01/27 21:00 DEBUG Loading “SCRIPT|urbackup/FILE_METADATA|bDP9Sijri7SLoddXhJUm|2276”. Loaded 14 MB at 56 Bit/s
16/01/27 21:02 DEBUG Loading “SCRIPT|urbackup/FILE_METADATA|bDP9Sijri7SLoddXhJUm|2276”. Loaded 14 MB at 56 Bit/s
16/01/27 21:04 DEBUG Loading “SCRIPT|urbackup/FILE_METADATA|bDP9Sijri7SLoddXhJUm|2276”. Loaded 14 MB at 56 Bit/s
16/01/27 21:06 DEBUG Loading “SCRIPT|urbackup/FILE_METADATA|bDP9Sijri7SLoddXhJUm|2276”. Loaded 14 MB at 56 Bit/s
16/01/27 21:08 DEBUG Loading “SCRIPT|urbackup/FILE_METADATA|bDP9Sijri7SLoddXhJUm|2276”. Loaded 14 MB at 56 Bit/s
16/01/27 21:10 DEBUG Loading “SCRIPT|urbackup/FILE_METADATA|bDP9Sijri7SLoddXhJUm|2276”. Loaded 14 MB at 56 Bit/s

if i check the client side debug log I’m getting these messages

2016-01-27 20:57:56: ERROR: FileSrv: Error: Seeking in file failed (5044) to 14680064 file size is -1
2016-01-27 20:59:56: ERROR: FileSrv: Error: Seeking in file failed (5044) to 14680064 file size is -1
2016-01-27 21:01:57: ERROR: FileSrv: Error: Seeking in file failed (5044) to 14680064 file size is -1
2016-01-27 21:03:57: ERROR: FileSrv: Error: Seeking in file failed (5044) to 14680064 file size is -1
2016-01-27 21:05:57: ERROR: FileSrv: Error: Seeking in file failed (5044) to 14680064 file size is -1
2016-01-27 21:07:57: ERROR: FileSrv: Error: Seeking in file failed (5044) to 14680064 file size is -1

it does this for both full and incr backups

Thanks for the client log. It seems to have removed the download stream before the server acknowledged that it has received it.

I’ve already improved this area and will be releasing a new beta version soon.

Ok thank you for the feedback i look forward to the next beta

I upgraded the server to the Beta 2.0.0 and am getting an unending progress bar in the web interface. I tried uninstalling and installing fresh, but the problem still occurs. Here is the log :

2016-01-28 09:26:27: ERROR: Loading urlplugin.dll failed
2016-01-28 09:26:29: ERROR: Loading urbackupserver_prevista.dll failed
2016-01-28 09:26:50: WARNING: Error: Unknown action [login]

The system is 32 bit Windows 2003 Standard if that helps.

Note: Server 2003 is EOL since July 2015… Please consider upgrading to at least Server 2008 R2…

It’s a private lab network. The server is just used for backup. The machines don’t even access the internet. 3 of 4 clients run XP. Is there any helpful information someone can offer?

Has anyone notice a speed difference between a client with 2.01 installed and 1.4.10? In a virtualized environment with all machine assigned the same amount of hardware resources I get 45Kbps for clients using 2.0.1 and 560Mbps for machines running the 1.4.10 client. Or was there a setting I missed?

Yeah, EOL does not simply mean that it is not receiving updates and that your only worries are from the internet. It also means that there will not be any bug fixes and that you are several years behind on features.

I know precisely what End Of Life means. I work in IT. I was running 1.4.12 on the server quite well. I decided to test the Beta as the new features are quite enticing. I found it is not working and posted to this forum as that is what this thread is for. If what you are saying is that the new version is specifically designed not to run on Server 2003, then I will either reinstall 1.4.12 or search for a different software for my purposes.

It means that few people will be interested in running it on Windows Server 2003. This being an Open Source project of course somebody could put in the work to support Windows Server 2003.

There is nothing wrong with staying on 1.4.12 either, if it works for you. After all you are staying with Windows Server 2003 because that still works.

Hi Uroni,

Just double checking I’m guessing this means the new client side will also not support windows xp?

To be quite frank, we are approaching a year that XP has been EOL, why would anyone target it? At this point, any project will continue building for it as long as it does not block anything else. As soon as it causes any difficultly in development, you drop all support. There is no sense in supporting a market that has completely faded.

Yeah, I haven’t done anything on purpose to remove the Windows XP support, but I haven’t tested it either (so it probably won’t work). This area is entirely complaint-driven.
If it does not load please use DependencyWalker to tell me which function it cannot load.

Hi Uroni,

I haven’t done any major testing I just noticed that the lone xp client I was running the test on (rest are windows vista/7/8/10 and server 2008/2012) automatically updated to the 2.0.x beta from the server and then stopped connecting to the server (internet based) so no longer backing up

hi,
tried to upgrade 1.4.13 with 2.0.x on a windows 2008 server and the windows service does not start anymore.

Faulting application urbackup_srv.exe, version 0.0.0.0, time stamp 0x56b9cccb, faulting module api-ms-win-crt-runtime-l1-1-0.d, version 6.0.6002.18881, time stamp 0x51da3d16, exception code 0xc0000135, fault offset 0x00000000000b6fc8, process id 0x490, application start time 0x01d16f4ee232727f.

arollback to 1.4.13 works fine

Thanks uroni for the new updates!

Once version 2 has become stable, will you be applying the commits to the ‘next’ branch in github? This way we can see what are the modifications we need to make to version 1 of the source code in order to ‘upgrade’ to version 2.

Or do we have to recompile the new version 2 source code from scratch?

So, I have a bunch of specialty XP clients which run specialized software (such as CNC control software) which cannot be upgraded without replacing the specialized equipment ($$$). I know XP is long out of support, but if there is a way we get get these backed up, it would be super awesome. I’ve tried using the 1.4.11 client with a 2.0.8 server, but have been having issues with getting image backups working (I will post details in a separate post).

I ran DependancyWalker for UrBackupClient.exe and UrBackupBackend.exe on a fully updated XP VM and it said the following DLLs were missing:

api-ms-win-core-delayload-l1-1-0.dll
api-ms-win-core-io-l1-1-0.dll
api-ms-win-core-localregistry-l1-1-0.dll
api-ms-win-core-misc-l1-1-0.dll
api-ms-win-downlevel-advapi32-l1-1-0.dll
api-ms-win-downlevel-ole32-l1-1-0.dll
api-ms-win-downlevel-shlwapi-l1-1-0.dll
api-ms-win-security-lsalookup-l1-1-0.dll
api-ms-win-security-sddl-l1-1-0.dll
cryptbase.dll
cryptsp.dll
dui70.dll
dwmapi.dll
IEShims.dll
sspicli.dll
wer.dll
werui.dll

These DLLs don’t natively exist in XP.

I’ve zipped up Dependency Walker image files here:

UrBackup.zip.txt (1.4 MB)

Rename from .txt to .zip to unzip them.

If there is any other info I can provide, please let me know :wink:

Just use 1.4.13. It still supports XP. You will not be able to upgrade to the 2.x release though.

The reason I’m using 2.x server is for “synthetic full image backups” support for off-site image backups… sorry, I should have stated that in my last post.

I am getting these errors too but I cant run a full file backup as it is an internet client. Is there any other way to get rid of the errors?