I find this scenario works the best since it is one I have used in house:
Configuration:
Production Site:
Master Server A
DataDomain A (with or without OST)
DR Site:
Master Server B
DataDomain B (with or without OST)
Replication:
At the production site, the master backs up the hosts to a DataDomain appliance which appears as a disk storage unit either mounted as NFS mount on the master or using the OST licensing (NFS is cheaper since it does not require a license). The DataDomain appliance is configured to replicate the deduplicated data to the DataDomain at the DR site. Now the data (ie the catalog images and backup data) are in both locations. The replication is realtime over the WAN so whenever the catalog changes at the production site, it is updated at the DR. Further since the data is deduplicated, you are sending less data over the WAN.
Recovery:
Now say the production site has a massive flood and everything is lost. Now the DR plan comes into play. At this point, you use the master at the DR site to do an import of the images on the DataDomain at the DR site to make the master at the DR site aware of what you have for backups from the production site. Since everything is on disk either mounted to the DR master via NFS or using OST, it takes only a matter of a few hours to populate the catalog with the information that was replicated from your production site. Once the import is done, you could begin doing restores or whatever your DR plan indicates.
Note: At the DR site you could write a script that would run out of cron/task manager and prepopulate the DR master weekly by doing the imports for weekly time ranges. This would reduce the amount of import time required during an actual DR recovery.
Regards,
Benjamin Schmaus
