Hill, Aaron wrote:
Another question is how to deal with the complexity introduced when all your traditional volumes were snapmirrored to one or more other sites. Are we effectively talking a new snapmirror baseline initialization here for the flexvols? This is a nightmare because in a Disaster Recovery scenario we will essentially be exposed during the initialization period and the rate limiting step of a WAN link or snapmirror retrieve from tape.
When we move or re-arrange traditioanl voluems that have snapmirror relationships, we try to keep the old volume & mirror around until the new one is initialized. so there is no exposure. requires available disks.
what's more of a pain is that we run some applications from qtree snap mirrors, mounted read-only NFS. re-establishing the mirror, and migration to FlexVolumes for that matter, makes all NFS mounts go stale, meaning carefully coordinated site-wide remounts as things move.
we move qtrees around semi-frequently, so the process and pitfalls are understood. that makes it no less painful, just understood.
-skottie