Have a client with an existing 3-site infrastructure. They're having issues with meeting their BCJ intervals, so in addition to upgrading them from v8 to v9, we're implementing WAN Accel (intersite bandwidth is 20Mbps or 30Mbps, depending on which link). The first site--with the Veeam Server--had a 1TB NVMe card installed and assigned for WANaccel cache (100GB, the default) and the "Populate cache..." function was run on it, using a local DataDomain repository as the Source Repository; it had 4 unique OS instances and it took ~1h/instance to complete the seeding.
Second site is similar, with the exception that the Veeam server is not local: 1TB NVMe, 100GB (default) cache size, site-local DataDomain used as source repository. In contrary to the first site, the second site is taking far, far longer to populate its three (3) OS instances; it's been almost 23h and the first instance is only 52% complete (according to the dialog).
First question: is this expected behavior, because the remote instance--although the WAN accel & selected source repo are together--is having to send data back-and-forth to the main server, and the WAN (and any configured throttling) is the bottleneck?
Second question: If the answer to Q1 is "yes," can you please add it to the list of features that sufficient intelligence be added to the WAN Accel service to be able to run the cache population independently of the Veeam Server (with the exception of progress updates) so that this process is more efficient?
[If the answer to Q1 is "no", I'll get a case opened up and we'll dig into this further...]