File copy job VS File backup job

[sogapex]

Hi,

we have a "cold" files share with some non important data (example : pictures of ceremonies, festivities and so on)
These data are not vital for the enterprise, there is no reason to backup it a few times per day 365/7.
In case of disaster (fire damage, ransomware, heist), this is something we "can" lost (this would not prevent our enterprise to keeps its activity)

all these data were only at one location = Veeam B&R server local disks (RAID5)
With our new backup infrastructure (one physical server Veeam B&R + one physical server Linux Hardened), I want to backup these data on another location

All these data is pretty "static" (very few change over the year)
Currently, we are talking of : 9098 folders and 95890 files for a total of 66.1GB

The Veeam Server and Linux server have both the "same" hardware = cpu 8 cores - 16 threads @3.8-4.6Ghz / 32Go ram / 4x20TB hdd in raid0 (soft)
There are already other jobs making use of these "guys" => sequential read/write peak @800MB/s.
Full Backup job (vsphere) = 283MB/s (full - data read = 1.8TB / data write = 1.2TB / 74min)
Backup copy job from Veeam Server to Linux server = 218 MB/s (full - data read = 1.8TB / data write = 1.2TB / 96min) - 185 MB/s (incremental - data read = 402GB / data write = 188GB /17min)

If I use robocopy or fastcopy to copy the "cold" files, it can be done in a matter of minutes (less than 10 min)

So, in veeam V12 console, I naturally click on the "Copy Job" then I select "File..." and then set up a job to run once a week, just to make sure we have a backup in case the Veeam server "dies".
I was "stunned" to see a working rate of less than 1MB/s when I first launch the job ! (there was nothing running at this time, no other jobs involved)
Disk activities were nearly 0%
The only bottleneck = veeam server cpu at its max, struggling with the "veeam.ddd.dd" process (only one thread = cpu @6-7% on the windows task manager since this is a 16 cpu for the system)
I really don't understand why a modern cpu (@4.6Ghz for this task) would be the limiting factor "just" to copy some files from a local disk to a linux repo folder

I spent some time on the web to search for similar problem, but didn't find anything useful. Most of the time, they were not talking about the "file copy job" but about the "backup copy job".
And then, I see someone talking about "nas backup" (file share backup), and I reminded there was a new feature since ??? (Veeam V11 ?) especially made to backup shared folders.

Next step = in Veeam V12, I clicked on "Backup Job" then "File share..." and created a new job for our "cold" files.
I launched the job... and guess what ? the job finished in 6min42s / 66.2GB read / 54.4GB written => 546MB/s
And the cherry on the cake = if some files are removed from the source, they will also be removed from the backup copy over time (this would not be the case with the "file copy job" if I understood well how it works). I can also restore files as I would do with normal VM job, and I can keep a few restore points (different points in time, like VMs)

Last but not least : if I run the job again (no data changed in our case) = it takes about 1 minutes to complete !

I can't see if there is any downside, but in our case, it seems this is 10000% better to use this job instead of the file copy one
Eventually : I am convinced the "File share" backup feature is not enough "advertized" when someone (not a veeam expert of course) is trying to guess what job kind he would use to "just" backup some files (not a VM, not a full physical server, just a "folder")

This is really a nice feature, good job Veeam !

[sogapex]

"veeam.ddd.dd" process

I am sorry, I forgot to replace this string with the correct name of the process
This is :
C:\Program Files\Veeam\Backup and Replication\Backup\Veeam.Backup.Manager.exe