As I see the bottleneck is the network. Do you experience the same with incremental backups or only synth. full backups are affected? What is your network bandwidth?
As a late response, I do not have the same issue with incrementals. I did not try a full backup as this would send over 2TB of data and would take forever.
The NAS is added as a CIFS repository and without a proxy at the remote site.
After further review, I think the 50/50 offsite WAN connection is simply not enough for that much data to transfer. The proxy machine was at the maximum bandwidth of 50MB/sec the whole time. I find it weird that it was not showing in the throughput graph of VEEAM. Is it not reliable when watching live throughput?
As an alternative, you may point your backup job to a repository located at the main site, then deploy WAN accelerators at both locations and configure a Backup Copy job to copy the data from the main location to the offsite. WAN acceleration should help you to deal with low bandwidth. I'd recommend taking a loot at this BP article for more info on WAN acceleration.
Speaking about the graph within the backup job, please refer here for additional information.
For the remote connected CIFS, it is highly recommended to deploy a remote windows server as a gateway server. This way, the synthetic full, reading all the data/and writing it back to the same NAS but a different file, will be done at the remote site by the gateway server and not by the backup server/proxy at the source site
After reading what a synthetic backup is, it is supposed to be taking alot of ressources from the backup destination. As far as network trafic over WAN, it should only be doing a regular incremental. From what I can see after 5 days of the running task, it is still using the WAN connection at maximum speed. A regular incremental backup is only taking like 2 hours. Why is is still transfering data after 5 days when most of the work should be done "localy" on the remote NAS?
To make the work "locally" on the remote NAS, gateway server located close to it is required as the data mover cannot be installed directly on NAS. In your case, the data mover installed on the backup server itself is used that's why all the synthetic activity is being performed over the network. Thanks!
I came across this recently. A site had a Veeam server connecting to a Synology NAS via 1Gb Ethernet. The synthetic full backup was taking 38hrs here. Having a deeper look at what was going on I noticed that the actual backup component was around 50 minutes, meaning there was 37hrs unaccounted for.
It became apparent that the creation of the synthetic full was taking 37hrs, due to fact the bottleneck was the exchange of data between the veeam server and the synology nas. Previously this site had a SAS tray connected via 6Gb, but when this failed a 1GB connected NAS was installed as a replacement. It was noted that the previous synthetic full happened in a lot less time...
I hope this helps...it is based on my observation of the process and having a chat to a local Veeam SE to confirm
I am actually in the process of fixing this, looking at a server with plenty of local disk (REFS format). The bus speeds for the storage sub-system should make this job finish a lot quicker....
