Hi Jeffrey,
#1 Full Backups only is fine from the PoV of StoreOnce (at least in theory) as dedup will squeeze the redundancies out no matter if the same data is repeatedly transferred to the SO store (Full) or omitted (Incr). But of course, it isnt fine for the sources (load on the storage backends, CPUs etc, especially at the backup rate you use) and in practice, SO too has to chew on the data it has to dedup away or rehydrate. Incremental forever (aka virtual full using consolidation) is dead IMO (it can still be implemented on SO AFAIK, but it's really not performing great and I see no longer any reason for the hassle). So what I do is just use classic staggered cadences of Full, Incr and Differentials (Incr N in DP parlance), exactly as I used them before on tape, not least because I'm going to copy to tape later anyway. For me that works best. I've meanwhile scrapped every DFMF FileLibrary I ever implemented for Consolidation and Incr4ever.
#2 With SO Software, you can only have one backend filesystem per machine where SO runs. So in order to achieve what you want, you may put another machine in your DR site, install SO Software and an MA on it and then direct backups there. Or you may actually buy a StoreOnce Backup Appliance and connect that via Catalyst. For that to truly make sense, though, you ideally need two appliances and not SO Software - AFAIK you can only do thin replication (Copy specs that are executed without rehydration, c.f. federated dedup) between appliances, not between SO Software stores or Software and Appliance stores. This way, you could backup to the local appliance (high bandwidth) and then thin copy to the remote one, using bandwidth effectively. And of course you could do this bidirectionally between DCs. With SO software, there's no way around rehydration and high bandwidth copies (I'd really like to hear I'm wrong here, because I do have both kinds of SO stores and would like to use replication).
#3 Tape isn't going to die soon. Of course, you don't backup to tape directly any longer. Just copy to it. The point of tape is duplication and resiliency. With one SO store, you are just ONE malfunction away from losing EVERY backup you ever made. And it happens. I've seen stores go wonky e.g. after a SmartArray controller crash. And just last week enough disks failed in a RAID5 in short enough sequence for a store to just vanish. That doesn't happen with tape, at least when done right (off-DC and off-Site Vaulting, combined). The risk is reduced with two georedundant SO stores like discussed in #2, but I still wouldn't bet the farm on just that. That being said, keep your data on SO as long as you want. As long as you store isn't filling up or getting extremely slow due to the vast amounts of data in it, there's no limits. It's just that it may be gone in a split second, completely. I actually plan to return to GFS style schedules on my SOs for the same reason: They have plenty of free space still, so I can run some fulls in my schedule with extented data protections. Say, default protection 8 weeks, every 4 weeks a full with 24 weeks protection, every 12 weeks one with 2 years protection and a yearly full with permanent or 10 years or so. Of course, that's no longer backup but abusing the free capacity as a poor mans archive - fully knowing it's unreliable (so it doesn't replace an archive for the stuff where you need one for legal reasons). But why should the SO store have 30TB unused physical disk space ;)
BTW, I'm currently running a scheme where my backups go to two SO stores mirrored (one SO software, one SO Catalyst appliance at another location), then two post-backup copies stage them to tape. One reads from the SOS store and writes to local LTO6 drives, the other reads from the remote SOC appliance and writes to a bunch of LTO3 tapes at yet another location (I had to find some use for my older MSLs and LTO3 media pool). The mirroring on backup and the parallel staging to a total of 5 tape drives have shrunk my backup windows more than I initially expected. Of course it's all new, we'll see how it copes in 7 years ;)
HTH,
Andre.