UrBackup Server Service Randomly Stopping


#1

Hi there-

I am running Urbackup server 2.3.7 and the Windows service, UrBackup Windows Server seems to stop all on its own every few days and I end up having to manually restart the service to get things up and running again.

I’m really not sure how to begin troubleshooting this – any ideas?


#2

See here for where the log file is and what helps to fix problems:


#3

Assuming you can’t track the root cause down (I hope you do), a workaround would be to restart the service at regular intervals using task scheduler. Daily maybe? Possibly after a sufficient interval for the “nightly cleanup” to complete… I’m now wondering if the service is failing to restart after that… possibly worth investigating?


#5

Here’s an excerpt from the logs…

Error while writing compressed data to file
2019-02-03 09:06:02: ERROR: Writing to file failed
2019-02-03 09:06:02: ERROR: Last error: 665
2019-02-03 09:06:02: ERROR: Error while writing compressed data to file
2019-02-03 09:06:02: ERROR: Writing to file failed
2019-02-03 09:06:02: ERROR: Last error: 665
2019-02-03 09:06:02: ERROR: Error while writing compressed data to file
2019-02-03 09:06:02: ERROR: Writing to file failed
2019-02-03 09:06:02: ERROR: Last error: 665
2019-02-03 09:06:02: ERROR: Error while writing compressed data to file
2019-02-03 09:06:02: ERROR: Writing to file failed
2019-02-03 09:06:02: ERROR: Last error: 665
2019-02-03 09:06:03: ERROR: Error while writing compressed data to file
2019-02-03 09:06:03: ERROR: Writing to file failed
2019-02-03 09:06:03: ERROR: Last error: 665
2019-02-03 09:06:03: ERROR: Error while writing compressed data to file
2019-02-03 09:06:03: ERROR: Writing bitmap failed
2019-02-03 09:06:03: ERROR: Last error: 665
2019-02-03 09:06:03: ERROR: Fatal exception code 3221225477 at address 0x00007FFFAE90CC28
2019-02-03 09:06:44: ERROR: Fatal exception code 3221225477 at address 0x00007FFF9CFED5FC
2019-02-03 09:06:44: ERROR: Fatal exception code 3221225477 at address 0x00007FFFB43118DF
2019-02-03 09:06:44: ERROR: Fatal exception code 3221225477 at address 0x00007FFF8E3A27C3
2019-02-03 09:06:44: WARNING: Failed to write to file… waiting…
2019-02-03 09:06:44: ERROR: Fatal exception (APPLICATION CRASHED). Crash dump written to “C:\Windows\TEMP\UrBackup\v2.0.0-20190203-090603-10176-4568.dmp”
2019-02-03 09:06:44: ERROR: Program abort (SIGABRT)
2019-02-03 09:06:48: ERROR: Fatal exception code 3221225477 at address 0x00007FFF9CFED5FC
2019-02-03 09:06:50: ERROR: Fatal exception (APPLICATION CRASHED). Crash dump written to “C:\Windows\TEMP\UrBackup\v2.0.0-20190203-090644-10176-916.dmp”
2019-02-03 09:06:53: ERROR: Fatal exception (APPLICATION CRASHED). Crash dump written to “C:\Windows\TEMP\UrBackup\v2.0.0-20190203-090644-10176-6352.dmp”
2019-02-03 09:06:55: WARNING: Failed to write to file… waiting…
2019-02-03 09:06:55: ERROR: Fatal exception code 3221225477 at address 0x00007FFF9CFED5FC

The generated dump files created are about 1GB in size so I’m not sure how to get those uploaded anywhere. I guess I could FTP them if need be.

Any ideas?


#6

That’s ERROR_FILE_SYSTEM_LIMITATION. See e.g. here https://support.microsoft.com/en-us/help/2891967/error-file-system-limitation-when-a-write-operation-is-performed-on-a . It should not crash, because of this, but I guess it should stop crashing once this doesn’t occurr anymore.


#7

Also you haven’t told us your Windows version yet. Are you sure you have read Having problems with UrBackup? Please read before posting ?


#8

My apologies, I am running this on Windows Server 2016 x64. This problem is still persistent and I’ve yet to resolve it.

Currently attempting to run a dedup optimization job and defrag on my urbackup volume… Will keep you posted…


#9

This is still happening after running a defrag and an dedup optimization job on the UrBackup volume… Not sure what to do here. It’s really not realistic to set a scheduled restart of the UrBackup service especially when backing up new machines at times can take over 24 hours due to the amount of data being backed up.

Any other suggestions?


#10

You’ll probably have to reformat the volume: https://www.veeam.com/kb1893


#11

Understood. Just for my information, are there any steps that can be taken to prevent this from happening in the future? I am using dedup & NTFS compression – is this not recommended in terms of stability?

Thanks


#12

The NTFS compression is probably the cause. The dedup compresses, so there is no reason to enable NTFS compression if you have dedup enabled.