Migrate_storage_to crashes Server OS

Hello Everybody,
I am Martin and I need your help.
I am Running UrBackup Server 2.2.11 on Windows Sever 2016 Essentials as a virtual machine.
My Storage Folder is a shared Folder called “SRV1\Backups\UrBackup”
I want to Migrate it to another Hard Drive / Server Share.
I tried to create a File migrate_storage_to containing the future Backup Storage Path the hole Server OS crashes.
The Server Log shows nothing related, so how do I start investigating thiss error?
Any suggestions are very welcome.
Many thanks.


You could try this, it should show which driver crashed

Thank you for your help, orogor.

The tool says

The problem seems to be caused by the following file: ntoskrnl.exe

One of the crashes shows hal.dll as the file causing the bluescreen - all others show ntoskrnl.exe

Do you have any suggestions how I can avoid the bluescreens?


You can try rulling out a bad memory stick.
Boot on half your memory sticks if you have more than one.
Then see if the problem continue, then use the other half of memory sticks.

I am very sure this is not the cause:
The Urbackup Server runs on a virtualised Server 2016 Essentials system, running on a Server 2016 Hyper-V Host.
The Hardware ist a HP LML310e Server with ECC Ram.
On the same metal there are 4 virtualised Systems running perfectly stable - windows and linux.
When I start urbackup with the migrate_storage_to file active, the server crashes. Every time. When urbackup runs without the migrate_storage_to fil active everything is fine.
Any hints and suggestions are very welcome.
Best regards

Never guess. Ok, you’re running other VM’s, but that doesn’t check all your hardware. Use the tools to tell you what is a fact. Until you verify you’re working with hardware that is reliable you’re going to waste your time troubleshooting anything else

  1. Test RAM using tool: memtest86+
  2. Test HDD: chkdsk /f for file system structure (chkdsk /r to test all the sectors of your storage devices(s) )

(1 only needs to be run on the native hardware. 2 needs to be run on both the native OS, and the virtualized OS). Once you’ve verified your two primary hardware devices that affect system operations you start verifying your OS:

  1. DISM: check your installation files with checksum utility to verify file integrity. There’s 3 levels of checks with DISM, google search for how to use DISM
  2. sfc /scannow: Check the active OS files against the image files you just verified as good.

Only then can further application troubleshooting commence.

Above is all good advice I can understand why the OP is reluctant to shut down all running VMs to run memtest86, typically modern servers will either log or send an email alert in the case of bad RAM depending if they’re configured to do so, Very much worth looking at the management interface to see if ECC errors are being reported at the very least, running memtest86 would be better.

Since you appear to be running newer versions of windows I’d suggest chkdsk /scan rather than chkdsk /f as it can do some fixing without forcing a reboot or taking the storage offline unless it finds it needs to though I’d still personally run chkdsk /r on the new storage before deploying it.

Discussion of the tweaks made to chkdsk in Win 8 & later can be found here

Thank you very much so far for your advise.
I ran memtest and it said “Passed complete, no errors”
My Hard drives were all checked just 8 days ago (surface scan with WD DriveGuard) because I bought a new drive and therefore checked the old ones as well. SMART Values are ok.

Any suggestions?
Is there a workaround e.g. to manually move the contents of the storage folder to another location or will this break the hardlinks? I don´t mind the Downtime in the urbackup service, I just do not want the downtime of the whole machine.
The Backup storage is a shared folder of Windows Server 2016 Essentials. I could stop urbackup server, try and move it to the desired drive with Essentials Server Manager and restart urbackup. It should look like it never moved.

What do you think?

Imaging the disk it’s on & restoring the image shouldn’t break the hard-links, I’m guessing you could then restore the database backup in the new server so it thinks it’s the old one. Windows backup ought to work for imaging & restoring it, you’ll need temporary storage for the backup to use that method.

Or there’s rsync for windows which you’d have to install & figure out the command line arguments for, sadly nobody has managed to do it using robocopy or any of the other native windows file management tools.

The more I think about the situation the more i fear I broke the hardlinks trying to move the folder with Windows Explorer (aborted it and moved it back if I remember correctly) - maybe that is the cause of my system-crashes and it is my mess an not urbackup´s fault :frowning:
I think I will try the following method for migration:

  • change the storage path of urbackup to the new location,
  • set up a urbackup-client to backup the location of the old storage path to my server via LAN => therefore I can avoid repeating the initial backups via internet and I am sure all hardlinks are created correctly.

I do not have the chance to do a full image-backup of the storage volume.
Probably the backup-history of my clients gets lost but I don´t mind that. As long as they do not need to repeat backing everything up from start that ist ok for me.

Does anybody see a problem I am overseeing here? Or another method to assure all hardlinks are set correctly and no duplicate files are in the Backup storage Folder?
I will report back how this worked.

started the process 8 hours ago…

|28.08.18 22:08 |INFO |Starting unscheduled full file backup…|
|28.08.18 22:08 |DEBUG |srv1: Connecting for filelist…|
|28.08.18 22:08 |DEBUG |srv1: Waiting for filelist|
|28.08.18 22:08 |DEBUG |srv1: Connecting for filelist (async)…|

hope it does not abort…

OK, that didn´t work either.
Crashed again.
I think I am going to start over new and backup from scratch.

Thank you very much for your help on my problem.
I came to the conclusion that it has nothing to do with urbackup - I probably messed it up by trying to move the backup-folder with Windos Explorer.

Best regards