I like Syncsort a lot. But he also has cifs shares on the source. He could use nsb for hosts but then has to address cifs. If the data is already on NetApp them NetApp tools are a great fit. Snapmirror in this case. If a mix of storage and you want all on NetApp for dr/backup nsb is a great fit.
It will work, we have done it for tests, as you mention this is on the cheap, but I applaud you, it is better than nothing. If this is "DR" ask your NetApp sales team for a temp/demo flexclone license. Don't implement it, keep it in you DR plan and use it to create a flexclone of your SV targets at time of test or disaster, the license remove them when you don't need them. Get a 90 day license, its good for 90 days of use (e.g. if you remove it you are not using it the counter stops).
Snapvault backs up to a QTREE, so it likes qtree sources, but you can snapvault an entire volume, even ones containing LUNS. Go through TR/best practices guidde. I believe its best practice to put LUNs in a qtree, either way you can non disruptively move a LUN into a Qtree within the same volume. This will give you a nice clean source qtree to go with your destination qtree.
One caveat doing DR with snapvault is that you can't do a reverse resync in the event of a real disaster. You will have to do a full sync, but I imagine that at the end of the day is not that big a deal. You recovered.
He still needs a snapmiror license for the snamirror convert. And to snapvault back would be qtree to qtree so non-qtree data on the source would become a qtree on resync back (full sync back)... brute force and not so clean. Given no other option I could see it but wouldn't recommend using snapvault for DR with all the caveats. And with snapmirror needed to convert it they should just use snapmirror... unless they can use a demo key for the convert and netapp is ok with that.