My server has good speed hardware, i7-3770, 16GB RAM, H730P RAID controller with an 8 disk RAID10 array of 10k SAS drives. Read/write performance on the array is around 500MB/s. The operating system is Windows Server 2019 on a separate RAID1 SSD array.
When restoring through the web gui of a file from an incremental image backup, the download comes at about 5MB/s. This happens even when downloading through the web gui on the host itself. Where is a good place to begin troubleshooting this?
Resource monitor, you’ll be able to identify what processes may be maxing out disk access vs CPU usage vs network activity.
I’ve checked the easy stuff already- CPU/RAM/DISK/NET, everything is just running at very low percentages. It’s strange.
Never looked at the performance of this… It works like this:
UrBackup Server (web interface) / explorer -> NT kernel (NTFS) -> imdisk driver (block device) -> UrBackup Server (VHD(z) code) -> NT kernel (probably NTFS). Any one of those steps could have the performance problem, or they increase latency too much or don’t allow parallelism.
Do you use VHDZ? For example, the default vhdz decompression cache might be too small.
VHD backups. The volume of the urbackup datastore is NTFS.
I’ve tried these steps with no noticeable change:
-Disable deduplication and reinflate all of the data
-Browse to the urbackup GUI on the urbackup host itself and download
-Run a new incremental
-Try incrementals from different computers
Screenshots: https://imgur.com/a/RxHDpGx
As an alternative, since you are not using VHDZ, you could simply natively mount the VHD files?
This is still in the FAQ https://www.urbackup.org/faq.html#i-want-to-extract-a-file-from-the-image-backups-how-do-i-do-that from when the server couldn’t mount the VHD(Z) files natively.
I can, however the purpose here is to test to make sure that image backups are bootable. Unless something has changed, when you mount the C volume, it doesn’t contain the special boot volume, and so you can’t boot to it in a virtual environment.
From the screenshot you are extracting a vmdk file from the disk image…
My apologies uroni, I went back and re-read this. Ultimately, I would like image backups to restore faster. In my testing, once I realized that mounted images also restored slowly through the website, this seemed like an easier area to troubleshoot.
I tried creating a few different types of backup to see if the problem was specific to VHD, or VHDz. Although I am using VHD as standard for all backups, the screenshot was from one of those test restores.
Could be the Windows dedup then (if you haven’t tested without) or with a lot of incrementals random IOPS in general (I guess you can look if IOPS is maxed out?), though RAID10 should help for that…
The VHD code isn’t optimized very well… I use it mostly with btrfs raw images on Linux.
I have tried disabling dedup altogether and inflating the data. Also have made sure that no other backup/restore operations were running. I’ll do some more testing and post my findings.