pg_restore idling during second half of restore

Question

We're migrating from PostgreSQL hosted on our VM to Azure Database for PostgreSQL managed database. One of the first problems we hit has been time to restore database dump. It took 20-30 min on our VM but on hosted solution it takes more than 4 hours.

We are aware that there are many differences between these two environments but one thing that is confusing us the most is resource utilisation during pg_restore execution. Execution started at 10:23am and finished at 2:37pm but in period 12:46pm-2:37pm CPU and IO are both practically idling and we're having trouble understanding why.

Here's the graph of resource utilisation over that time:

Additional info:

• Our VM we are moving from is: Standard F4s (4 vCPUs, 8 GB memory) with 230 GB Premium SSD storage.
• Our hosted PostgreSQL environment is: Gen 5 General Purpose (2 vCores, 10 GB memory) with 122 GB Azure Premium Storage.
• Database is around 20 GB in size.
• We tried playing with number of jobs (2 and 4), increasing maintenance_work_mem via PGOPTIONS environment to 640 MB with no effect.

Does anyone have any ideas what might be causing this idling? For the first phase, it's clear that we need to increase IOPS limit (e.g. by purchasing more GB as IOPS limit is set my Azure to 3 IOPS/GB) to speed it up, but idling is puzzling us.