Thanks very much for the quick reply - the last paragraph is exactly the clarity I was looking for. Had previously started at the url you mention but in a journey through other doco and forum postings I ended up in confusion around the case specific to VEB backup sets (as these not VBR VM backups, rather host agent based file level backups, wasn't sure of 'CBT' in this context).
For example it says at https://helpcenter.veeam.com/endpoint/11/integration_backup_copy.html
"Backup copy jobs processing Veeam Endpoint backups have one limitation: you cannot use backup mapping for Veeam Endpoint backups. As a result, if you have a full Veeam Endpoint backup on the target repository, you will not be able to use this backup as a "seed" for the backup copy job. The backup copy job will always copy the whole Veeam Endpoint backup chain to the target repository "
Which I understood to mean you couldn't seed a target repository but that once BCJ had copied the VEB full across it would subsequently only effectively send incremental's (not always try and copy the whole chain across every time) ?
The remote repository will be located across the other side of a WAN, we could point VEB directly to the remote repository (or just a remote share) to get an off-site backup set but VEB (understandably) has limitations and not perform well across a WAN (VAW may address some of the VEB functional limitations but am assuming it still would not be very WAN friendly).
BCJ would appear to be a much better fit architecturally and by assumption performance wise, hence why seeking confirmation that using VEB backup as the source for a BCJ it will always only transfer changed blocks across the WAN to the remote repository (i.e. inherently minimise the WAN traffic involved) - it being the remote repository that effectively handles the backup set at that end for say its merge / transform functions ?
For completeness (and to give others all the info in one forum hit) - what would be the minimum Veeam components required for a remote repository and what would the license implications be ? (where the remote repository's only role is to act as the destination for BCJ from the existing licensed on prem VBR)
Thanks and have a good weekend