As tomjedrz says in his answer, DFS replication can be problematic with files being modified in multiple locations simultaneously. If your data is such that the modifications for a given set of files only occur in one building (i.e. on one server) the majority of the time then you may not have problems with DFS replication and conflicts.
Using a single file server to share the files mitigates the possibility of conflict. The 100Mb/sec pipe is certainly not slow, but depending on the size of the files being shared and frequency of access the users in the building w/o the file server may be subject to delays opening files. You'll have to benchmark that and see. Microsoft Office documents over a 100Mb/sec pipe are no problem. Multi-gigabyte solid model files over a 100Mb/sec pipe may be a source of major pain for the users.
To summarize: I think DFS replication is definitely an option, but you'll have to gauge the "character" of your file modification and access patterns to decide if it's a "win". A single file server can be a "win", too, but might also be a "loss" for some types of file access in the "remote" building where that single server isn't located.
DFS replication only protects you from catastrophic failure / destruction of the replica. Accidental deletion or data corruption will require some other type of protection. Additionally, if your buildings are situated closely, physically, I'd argue that having a replica in the other building might not be sufficient defense against physical disaster (fire, flood, theft, etc). You'll have to gauge the risk and act appropriately.
Volume Shadow Copy might just be the ticket for accidental deletion / corruption protection. I haven't used it extensively in production, but it certainly seems reasonable and has performed properly in lab settings. (Just don't be fooled into believing the marketing hype that tries to characterize it as a true versioned filesystem and you'll be fine...)
You would still need some type of off-site and offline backup (ideally with muliple full back retention capability). Tape probably fits the bill from a cost / performance standpoint.
An LTO-4 autoloader would make short work of backup of that data, so long as your server computers can feed data to the drive fast enough. Whether or not you run full backups every day will depend on your backup window and the speed of the backup. The cost per tape is pretty reasonable (around $50.00, last time I looked) such that you can maintain a rotating archive of older backups at a manageable expense.
Hopefully you can time things such that you'll exceed your backup window or the capacity of the autoloader at the end of the planned lifetime for the autoloader. At 20% / year growth, your 2TB volume should be around 3.5TB at the end of year 3. An 8 slot LTO-4 autoloader (800GB natve / 1.6TB compressed capacity per cartridge) would still have capacity. You might have to move to full / differential backups to continue to fit in your backup window, but it seems feasible to get 3 years out of an LTO-4 autoloader solution.
I agree w/ tomjedrz, too, re: the possibility of doing disk-to-disk-to-tape if you have frequent needs for performing incidental restores (and either aren't using Volume Shadow Copy or aren't getting the protection you need out of it). Something simple like a RAID-0 or RAID-10 array of inexpensive SATA disks can feed data to the LTO-4 fast enough to keep it running and can serve as a place to perform quick incidental restores from w/o having to deal with mounting tapes (going to the off-site storage facility to get tapes, etc).