Details of CIFS shares are held in the file /vol/rootvol/etc/cifsconfig_share.cfg. You could copy the contents to that file on the secondary, edit any differences in path and restart CIFS BUT this is not the way SnapVault is designed to be used.
SnapVault is designed as an archive where you restore data back from the secondary to the primary, if you're looking for a DR solution then SnapMirror is the correct product. SnapMirror replicates a volume from source to destination and keeps the destination read-only. In a DR scenario the mirror is broken and the destination volume becomes read-write, when the source site comes up the data flow is reversed and the source volume synchronised with the destination volume. Once complete the relationship from source to destination is resynchronised and updates carry on as before.
Excel and concatenate is clever. I am cautious editing cifsconfigshare though. In many cases it doesn't catch everything (a share or access doesn't process after edit sometimes and not sure if support would support shares created by editing directly). We often script to create the shares on the cli with cifs running. The key thing with that is that every new share has a default everyone "full control" which often isn't the requirement...when parsed in the config file at cifs startup there is no cifs access unless specifically listed. But when running cifs shares -add from the cli there is always an everyone full control access which may need to be removed/modified.