DR Planning Opinions/Thoughts on current setup w/ Veeam 8

[mcmcomput]

I would like to get some feedback on my DR plan I am working on and see if I'm on the right page or maybe there is a more efficient way to do it.

Production DC:
I plan to have a couple servers for all the companies applications/functions. These will be replicated to a local box over Gb network once a day, maybe as much as 4x a day. The replication box is in case any of those servers fail physically. All the server run direct attached storage, no SANs. I would like to setup the replication to contain the last 7 days of data, so 7-28 snapshots. All these servers are configured for RAID10.
DR DC:
I have 2x HP 2U servers w/ approx 28TB direct attached for replica's and another 130TB attached via SAS. Both servers have have approx 14TB direct attached and 65TB via SAS. All these are RAID10. At this site I would like to have a replica of every server in our environment from a daily basis and once a week have a backup of these machines for archival purposes. Single nightly replica then a weekly backup (Full first, then regular incremental)

I have my main Veeam box at the DR site via a 25Mb link to orchestrate all the proxies i have. All are running the latest version of Veeam B&R.
What I have now is...
1. Production DC is set to replicate machines daily to another hosts at the same site and keep 7x replica's on a daily basis. Compression is set to none & storage optimization is set to local.
2. Replica's are told to replicate to the DR site after local replica's are done, pulling the replica's from the replica box at the DC to the replica box at the DR DC.DR DC currently is set to also keep 7 replica's. Compression is set to extreme & storage optimization is set to WAN target.
3. After the above replica completes, around 3am currently, the DR replica's are then backed up to the D: on the Veeam Computer (Windows 2012 R2 server) which has the 65TB of storage once a week on Sunday after the replica jobs. Backup mode is set to Incremental with no creation of synthetic fulls ever and no check box for transform previous backup chains into rollbacks. Data reduction has enable inline data dedup checked with compression set to dedupe friendly and storage optimization set to Local.

Current questions:
-My current backup of the replica's are getting a "CBT data is invalid" every time it is ran. It takes approx 10hrs to run through all 5TB of data backed up. If this was fixed i think the backups of replica's would complete faster. Not really an issue since it has plenty of time before the next replica's try to sync across sites.
-Is there any benefit for doing a backup from the DC to DR DC site? Does a backup and replica job both take up the same amount of bandwidth across the network? I know the replica eats more HDD at the DC DR.
-Currently I am getting approx a 56% dedup ratio on my backup storage box in Windows 2012 R2. I haven't had any problems restoring from backups and it seems quick enough to make me not complain. This gives me more storage in the long run and since i have replica's those are my first line of defense again a site failure or DR scenario.

What are your recommendations/thoughts on all this?
I'm happy to share my hardware specs/experiences as well.

[foggy]

-My current backup of the replica's are getting a "CBT data is invalid" every time it is ran. It takes approx 10hrs to run through all 5TB of data backed up. If this was fixed i think the backups of replica's would complete faster. Not really an issue since it has plenty of time before the next replica's try to sync across sites.

This is expected both for replicating and backing up replica VMs (remember, they are always turned off, so no CBT). But since you still have them fit the required time frame, you seem to be ok with this.

-Is there any benefit for doing a backup from the DC to DR DC site? Does a backup and replica job both take up the same amount of bandwidth across the network?

Both backup and replica jobs transfer the same amount of data over the network link, provided compression level is the same and WAN acceleration is not used. However, you can consider the following: perform local backups in the production site, then local replica from these backups, use backup copy jobs (with WAN acceleration enabled) to sync backups to the remote site and, again, replicate from those copied backups in the remote site. Data will effectively traverse the WAN link only once and production VMs will be touched just once, however none of the jobs will need to read the entire VM disks (as they currently do, due to inability to use CBT).