Hi there
After much testing we noticed that during the restore the Node others Latency time was ballooning up to 100mS as SC copied the DB files back between nodes.
Therefore, we realigned the volume layout between the 2 servers so the volumes (5 off) were aligned on nodes. i.e Vol 1 on node1 vol 2 on node 2 etc. When performing the restore the overall time did not improve still circa 10 hours but the "Other" Latency figure for the target node did drop to Circa 50mS
So with the copy now between volumes on the same node we beleive that we have optimized this as far as we can, and the fact that the read/write latency on the nodes whilst the copy is running is low <1-5mS suggest that this is an internal operation within the cluster that is being throttled or treated as a background task.
This test also confirmed the first volume is not copied in minutes, but that at the windows OS level the file and folder appear, but the underlying data is still being streamed back. This is extrapolated by the fact the file time is initially the time of creation, but then reverts to the restore snapshot time once the restore for that file is complete.
Hence when restoring a DB between servers the time taken appears to be determined the underlying cluster performance and a throttling or background task priority set by Netapp. so for Large Databases be prepared to wait if you have to rollback the DB that is in an AOAG and then copy to another server(s)