Hi Scott --
When you apply a DR-enabled policy to a dataset, two things happen. First, we know the dataset is DR-enabled, so we allow some extra configuration options on the DR node (to set up data exports, just like you can on the primary node). Second, we compute a DR readiness status and make that front and center. This rolls up all the information we can find to predict whether a failover would work. Basically this says all the primary data is being replicated, it's within it's lag threshold, and all the secondary systems are in fact up and running.
On the storage system you won't see any different. It's still just a bunch of volumes with SnapMirror relationships.
To answer your questions:
1. Yes, you can replace a "Mirror and Backup" policy with "DR Mirror and Backup" policy without a rebaseline. Both Mirror and DR Mirror connections get implemented with volume SnapMirror. You can always just try it and see: edit the dataset, look at the preview results, then cancel the edit wizard. There's never any harm in doing that.
2. With ProtMgr DR, you don't have to use vfilers on both sides (you can if you wish, but it's not required). When you want to fail over, there's a "Failover" button on the DR screen. Push that. ProtMgr will break all the mirrors and ensure your data is exported on the DR side. By "exported", I mean we'll create NFS and/or CIFS shares on the destination that match the source for NAS data, and we'll create igroups and map LUNs for SAN data. You have the flexibility to export the DR data to the same hosts you used to access the primary data, or to a different set of host if you plan on using different hosts after a disaster.
-- Pete
