Not easily… would be several steps…and to keep one to one relationships all data (including vfiler root etc) would need to be in qtrees. Then you would need to snapmirror convert or flexclone then snapmirror convert to even use the the volumes for vfiler create –r. It should work but would be several steps and would cause issues trying to resync back (manual copy) to the source site since you made it writeable on the target…so the reversion would be manual copies then start the vault again. Not something easy to support.
The vault is readonly and qtree level. Snapmirror would be better then you could break mirrors and vFiler create -r. Even better is vFiler dr which automates a dr vFiler that can be activated and snapmirror is automated.
Also. Unles you made /vol/vfiler_root/etc a qtree. The target would be one level deeper in a qtree and not usable. If you did make it a qtree you could snapmirror convert volumes but then you would lose your vault unless you clone first. And all volumes would need qtrees sonthebsame structure on the target. I couldn't recommend this with all the moving parts.
I would keep snapmirror/vFiler dr then consider a separate vault target if you need longer snapshot retention.
Not easily… would be several steps…and to keep one to one relationships all data (including vfiler root etc) would need to be in qtrees. Then you would need to snapmirror convert or flexclone then snapmirror convert to even use the the volumes for vfiler create –r. It should work but would be several steps and would cause issues trying to resync back (manual copy) to the source site since you made it writeable on the target…so the reversion would be manual copies then start the vault again. Not something easy to support.
