2Tb VMDK snapshot issue & replicas

[itdirector]

Exchange 2010 VM
Windows 2008 R2
Esxi 5.0 with 6TB of free space on an SSD Datastore (DAS)
VM had two Hard Disks (C: System - 200GB) & (D: Exchange databases - 1.7TB) . Both Thin Provisioned.
Veeam 7.0.0.833 : This VM is backed up (forward Incremental) & replicated daily.

The VM was close to running out of space on the D: drive & we shutdown the VM & increased the Provisioned size to 2TB, then extended the D: partition in Windows. Obviously, if we had done more research, we would have known that this will be a significant issue with snapshots & that VMware are a bunch of idiots for allowing the option to 2TB's.
The Hard Disk 2 (D:) VMDK provisioned size is now 2,147,484,000 KB which is over the snapshot limit & we can no longer create a snapshot of the VM - causing our Veeam backups & replication jobs to fail on this VM. (actual used space of the vmdk is 1,849,798,000 KB).

The only solution is for us to add another Hard Disk 3 (1.9TB) to this VM, copy the data from Disk 2 (D:); then delete Disk 2, & make Disk 3 the D: drive in Windows.
Before I do that, I need to know what type of issues I will run into during Veeam Backup & Replication.
-Will the backup job assume the data on Disk 3 on this VM is brand new & create a large 1.7TB+ forward incremental .Vib? Or is it smart enough to know this is the same data that has already been backed up?
-Will the replication job assume the data on Disk 3 on this VM is brand new & create a large 1.7TB+ VMDK snapshot on the destination datastore? If yes, can I use the "Low connection bandwidth" replica seeding option to alleviate this issue (because the replica's are at our DR site with only a 150/150Mb fiber connection. It will take 18+ hours to replicate 1.7TB).

Thank you in advance.

[max2015]

are you able to upgrade to ESXi 5.5? it supports > 2TB VMDK finally.

[foggy]

-Will the backup job assume the data on Disk 3 on this VM is brand new & create a large 1.7TB+ forward incremental .Vib? Or is it smart enough to know this is the same data that has already been backed up?
-Will the replication job assume the data on Disk 3 on this VM is brand new & create a large 1.7TB+ VMDK snapshot on the destination datastore? If yes, can I use the "Low connection bandwidth" replica seeding option to alleviate this issue (because the replica's are at our DR site with only a 150/150Mb fiber connection. It will take 18+ hours to replicate 1.7TB).

In theory, in both cases (backup and replica), if you attach the new disk to the same SCSI slot as its predecessor, CBT for this disk should be reset, it should be entirely read during the next job run and only changes should be sent to target.