Hello Group,

Sorry if this double posts, I received an error when Sending.

I was provided with a largish (~27GB) Firebird 2.5 backup file (gbak) yesterday. I have been restoring this on Windows 2012R2 running 2.5.6 Classic using gbak with the -service_mgr switch. This particular VM only has a single CPU core but it is connected to the SAN and isn't doing anything else. I am remote desktop'd into the machine.

I have been tracking the restore through several mechanisms:
* -v switch of gbak
* How large the file is on disk
* CPU utilisation (Resource Monitor)
* Disk I/O (Resource Monitor)

The first 40GB or so of the restored FDB took about an hour or so. The I/O for fb_inet_server.exe was consistently in the 30MB/s range (usually about 10 read from the fbk and 20 write to the fdb file)
The next 10 GB took 10 hours. Now obviously when it gets to "activating and creating deferred index xyz" it slows down, but I cannot see where the bottleneck is. I have seen extended periods of about 1MB/s reads corresponding with 5% CPU utilisation whilst activating some of those indices. I copied an unrelated 20GB file in the same folder and it happily copied at 50MB/s so there is definitely capacity that isn't being used.

I can see that when it activates indices on larger tables it is creating temp files and these are at least being written to at 8+ MB/s.

Although I get that activating the indices is going to be slower than restoring the data, I was expecting to see it either CPU and/or disk bound at any moment in time. (Plenty of headroom for memory and network utilisation is very low).

Any suggestions on what I can look for or is this an expected characteristic/limitation?

Thanks in advance
Adam